In the last few years we have witnessed the unprecedented growth of open source in all industriesfrom the increased adoption of open source software in products and services, to the extensive growth in open source contributions and the releasing of proprietary technologies under an open source license. It has been an incredible experience to be a part of.

As many have stated, Open Source is the New Normal, Open Source is Eating the World, Open Source is Eating Software, etc. all of which are true statements. To that extent, I’d like to add one more maxim: Open Source is Eating the Startup Ecosystem. It is almost impossible to find a technology startup today that does not rely in one shape or form on open source software to boot up its operation and develop its product offering. As a result, we are operating in a space where open source due diligence is now a mandatory exercise in every M&A transaction. These exercises evaluate the open source practices of an organization and scope out all open source software used in product(s)/service(s) and how it interacts with proprietary components—all of which is necessary to assess the value creation of the company in relation to open source software.

Being intimately involved in this space has allowed me observe, learn, and apply many open source best practices. I decided to chronicle these learnings in an ebook as contribution to the OpenChain project: Assessment of Open Source Practices as part of Due Diligence in Merger and Acquisition Transactions. This ebook addresses the basic question of: How does one evaluate open source practices in a given organization that is an acquisition target? We address this question by offering a path to evaluate these practices along with appropriate checklists for reference. Essentially, it explains how the aquirerer and the target company can prepare for this due diligence, offers an explanation of the audit process, and provides general recommended practices for ensuring open source compliance.

If is important to note that not every organization will see a need to implement every practice we recommend. Some organizations will find alternative practices or implementation approaches to achieve the same results. Appropriately, an organization will adapt its open source approach based upon the nature and amount of the open source it uses, the licenses that apply to open source it uses, the kinds of products it distributes or services it offers, and the design of the products or services themselves

If you are involved in assessing the open source and compliance practices of organizations, or involved in an M&A transaction focusing on open source due diligence, or simply want to have a deeper level of understanding of defining, implementing, and improving open source compliance programs within your organizationsthis ebook is a must read. Download the Brief.

The OpenChain Specification is the only standard for open source compliance in the supply chain. It is a document created by user companies for user companies, and it is uniquely suited for building trust between entities in procurement and M&A.

The core precept of OpenChain is that any company in any market sector can quickly and effectively self-certify at no cost, providing a simple way to display their adoption of the key requirements for a quality open source compliance program. This approach provides the maximum flexibility balanced against ensuring fidelity.

Of course some market sectors have different requirements and—in some cases—entities in a supply chain may prefer to follow a workflow with third-party, or audited, certification. The OpenChain standard is compatible with this approach too and we have been building relationships to support such third-party certification in key demographics like automotive.

Our first certification partner is TÜV SÜD, a renowned German certification authority with a long history of providing that essential precept of “trust but audit” in components used in the automotive sector and further afield. We are delighted to work with TUV SUD in Germany, in Japan and globally as we build out broader adoption of our standard.

Learn more about TUV SUD’s certification process based on the OpenChain Specification and how Hitachi, Ltd. became the first company to receive the new TÜV SÜD certificate in this recent announcement. Congratulations to Hitachi and TÜV SÜD for this significant achievement!

We are rapidly approaching a point where suppliers that are OpenChain Conformant will be preferred suppliers. In accomplishing this we will simultaneously reduce uncertainty and cost for all parties while increasing fidelity and security for every participant in global supply chains. We invite every company and every interested individual starting on their open source compliance journey to visit our website and subscribe to our newsletter for updates.

Open Source Compliance at NHSOne of the powerful things about open source is the way it allows various organizations and stakeholders come together to achieve common objectives. Open source projects play a critical role by providing a common platform that can integrate with new and existing systems. This is even more apparent when discussing open source compliance and aligning the various stakeholders in an open source supply chain.

A great example of this is a recent NHS case study published on openchainproject.org. NHS England is the public health services provider in England that treats more than 1.4 million patients every 24 hours. The organization needed a way to manage and leverage their open source assets across the organization without vendor lock in. Our partners at Source Code Control proposed the OpenChain Specification and brought us in to work with the Apperta Foundation, Code4Health initiative, OpenEyes, and AB EHR Digital for a training and pilot program.

The result enabled the project participants to meet open source industry best practices. It also helped NHS take the first step in a broader deployment plan across multiple projects and providers in the coming months and years. Thank you to all of our partners and we look forward to future collaboration in healthcare, automotive, and many more industries as they increasingly adopt open source. Read the NHS case study.

Bosch to leverage industry’s only open source compliance standard to provide common approaches and understanding for collaboration across automotive & IoT supply chains

SAN FRANCISCO –  February 28, 2019 — The OpenChain Project, which builds trust in open source by making open source license compliance simpler and more consistent, announced today that Bosch has joined as a platinum member. Membership momentum continues to grow for the project, as Microsoft joined just a few weeks ago as well as other large companies including Uber, Google and Facebook in December. OpenChain provides a specification as well as overarching processes, policies and training that companies need to be successful in managing open source license compliance so that it becomes more efficient, understandable and predictable for participants of the software supply chain.

As code flows between companies that consume billions of lines of open source software through their supply chains to build new products and services, a key challenge is ensuring the relevant license requirements are met in a timely and effective manner. The OpenChain Project provides a consistent way to address that and other challenges. Conformance with the OpenChain Specification shows that an organization follows the key requirements of a quality open source compliance program, and builds trust between organizations in the supply chain. It makes procurement easier for purchasers and preferred status easier for suppliers.

Over the last 15 years, Bosch has embraced open source software starting with consuming open source tooling in automotive using the Eclipse IDE, embedding Linux into Bosch products, and co-innovation of software in public funded projects. Bosch is now leading more than a dozen open source projects and actively driving its open platform strategy for the Bosch IoT Suite at Eclipse IoT with over 1.5 million contributed lines of code. Therefore, it has a special interest in increasing the number of collaborating companies using mature open source management processes. Bosch believes OpenChain is a great platform to share good practices and improve the open source management systems and processes, so other companies can join open source communities.

The OpenChain Specification is the only standard for open source compliance in the supply chain and has major interest from automotive companies. Toyota is currently a platinum member and Scania recently became OpenChain conformant. Also, companies like Panasonic and Renesas are active in the community work groups.

“An open source management system standard will be key for successful collaboration on open source management infrastructure and services,” said Hans Malte Kern, Head of the Center of Competence Open Source, Bosch. “We’re excited to join the OpenChain project, as it reflects the importance of compliant open source usage, distribution, and contribution. Instead of negotiating the open source requirements with all our partners and suppliers, Bosch will leverage OpenChain as an open standard that provides common approaches and understanding for open source collaborations – not only in the automotive industry but also the connected world of IoT. We are convinced the OpenChain standard will replace bilateral negotiations, educations, and open source risk mitigation discussions.”

“It is terrific to have Bosch join other automotive companies such as Toyota as a platinum member,” said Shane Coughlan, OpenChain General Manager. “Bosch is no stranger to the OpenChain Project and has a long history of contributing to open source compliance activities. We are thrilled to have them participate in the Governing Board, Steering and Outreach Committees, as well as the work team calls and meetings to help drive this community forward.”

As a platinum member, a representative from Bosch will join the OpenChain Governing Board. Other platinum members of the OpenChain project include Adobe, ARM Holdings, Cisco, Comcast, Facebook, Google, Harman International, Hitachi, Microsoft, Qualcomm, Siemens, Sony, Toshiba, Toyota, Uber and Western Digital.

Additional Resources

About the OpenChain Project

The OpenChain Project builds trust in open source by making open source license compliance simpler and more consistent. The OpenChain Specification defines a core set of requirements every quality compliance program must satisfy. The OpenChain Curriculum provides the educational foundation for open source processes and solutions, whilst meeting a key requirement of the OpenChain Specification. OpenChain Conformance allows organizations to display their adherence to these requirements. The result is that open source license compliance becomes more predictable, understandable and efficient for participants of the software supply chain.

About The Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, and more.  The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

Open Source Compliance

This fully updated ebook provides detailed information on issues related to the licensing, development, and reuse of open source software.The Linux Foundation has released the second edition of Open Source Compliance in the Enterprise by Ibrahim Haddad, which offers organizations a practical guide to using open source code and participating in open source communities while complying with both the spirit and the letter of open source licensing.

This fully updated ebook — with new contributions from Shane Coughlan and Kate Stewart — provides detailed information on issues related to the licensing, development, and reuse of open source software. The new edition also includes all new chapters on OpenChain, which focuses on increasing open source compliance in the supply chain, and SPDX, which is a set of standard formats for communicating the components, licenses, and copyrights of software packages.

“Open source compliance is the process by which users, integrators, and developers of open source observe copyright notices and satisfy license obligations for their open source software components,” Haddad states in the book.

This 200+ page book encompasses the entire process of open source compliance, including an introduction on how to establish an open source management program, a description of relevant roles and responsibilities, an overview of common compliance tools and processes, and all new material to help navigate mergers and acquisitions. It offers proven best practices as well as practical checklists to help those responsible for compliance activities create their own processes and policies.

Essential topics covered in this updated ebook include:

  • An introduction to open source compliance
  • Compliance roles and responsibilities
  • Building a compliance program
  • Best practices in compliance management
  • Source code scanning tools

To learn more about the benefits of open source compliance and how to achieve it, download the free ebook today!

VMware and Endocode Contribute Tern and QMSTR Compliance Tools to New Project, Respectively

YOKOHAMA, JAPAN – Open Compliance Summit – December 6, 2018 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announces the formation of the new Automated Compliance Tooling (ACT) project. Using open source code comes with a responsibility to comply with the terms of that code’s license, which can sometimes be challenging for users and organizations to manage. The goal of ACT is to consolidate investment in, and increase interoperability and usability of, open source compliance tooling, which helps organizations manage compliance obligations.

ACT also welcomes two new projects to be hosted at The Linux Foundation as part of the initiative, in addition to two existing Linux Foundation projects that will become part of the new project. The new projects are complementary to existing Linux Foundation compliance projects such as OpenChain, which identifies key recommended processes to make open source license compliance simpler and more consistent, and the Open Compliance Program, which educates and helps developers and companies understand their license requirements and how to build efficient, frictionless and often automated processes to support compliance.

“License compliance is an important hygiene factor in the open source ecosystem. With QMSTR, we started to create a toolchain that focuses on fact finding and accurate, complete and up-to-date compliance documentation for every software build. Endocode is extremely happy to contribute QMSTR to ACT and to take it to the next level together with The Linux Foundation and the other project partners,” said Mirko Boehm, CEO of Endocode and the initiator of the QMSTR project.

“We are excited that The Linux Foundation has accepted Tern, an open source project for inspecting container images for OSS compliance, for its ACT group of projects,” said Nisha Kumar, Open Source Engineer, VMware Open Source Technology Center. “Since releasing Tern in June 2017, the project has grown in community and features continuing with the most recent release version 0.2.0–which adds features to make the project more accessible to users and contributors. Moving the project under ACT is a great next step in encouraging wider collaboration from folks who are looking to meet their OSS compliance obligations as part of their container strategy. I look forward to working with the greater community towards this goal.”

“As a long-term contributor to SPDX and open source license compliance tools, I am excited to see the formation of ACT and the inclusion of the SPDX tools in the project, said Gary O’Neall, CEO, Source Auditor, Inc. “The SPDX tools are a result of many years of collaboration and contributions from the SPDX community. The SPDX tools provide users the ability to view, verify and translate SPDX documents while the libraries provide developers tools to integrate with SPDX licenses and documents. These capabilities will form a nice complement to the other ACT tools.”

The four projects that will be part of ACT are:

  • FOSSology: An open source license compliance software system and toolkit allowing users to run license, copyright and export control scans from the command line. As a system, a database and web UI are provided to provide a compliance workflow. License, copyright and export scanners are tools available to help with compliance activities. FOSSology is an existing Linux Foundation project that will move under ACT.
  • QMSTR: Also known as Quartermaster, this tool creates an integrated open source toolchain that implements industry best practices of license compliance management. QMSTR integrates into the build systems to learn about the software products, their sources and dependencies. Developers can run QMSTR locally to verify outcomes, review problems and produce compliance reports. By integrating into DevOps CI/CD cycles, license compliance can become a quality metric for software development. The project is being contributed to ACT by Endocode.
  • SPDX Tools: Software Package Data Exchange (SPDX) is an open standard for communicating software bill of material information including components, licenses, copyrights and security references. The main SPDX specification will remain separate from, yet complementary to, ACT, while the SPDX tools that meet the spec and help users and producers of SPDX documents will become part of ACT. SPDX is an existing Linux Foundation project.
  • Tern: Tern is an inspection tool to find the metadata of the packages installed in a container image. It provides a deeper understanding of a container’s bill of materials so better decisions can be made about container based infrastructure, integration and deployment strategies. Tern was created by VMware, who are contributing the project to ACT, to help developers meet open source compliance requirements for containers.

 

“There are numerous open source compliance tooling projects but the majority are unfunded and have limited scope to build out robust usability or advanced features,” said Kate Stewart, Senior Director of Strategic Programs at The Linux Foundation. “We have also heard from many organizations that the tools that do exist do not meet their current needs. Forming a neutral body under The Linux Foundation to work on these issues will allow us to increase funding and support for the compliance tooling development community.”

ACT is seeking new members, community partners and additional tooling projects. To get involved, contact act@linuxfoundation.org.

About The Linux Foundation

The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and industry adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at www.linuxfoundation.org.

# # #

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Learn how to align your goals for managing and creating open source software with your organization’s business objectives using the tips and proven practices from the TODO Group.

The majority of companies using open source understand its business value, but they may lack the tools to strategically implement an open source program and reap the full rewards. According to a recent survey from The New Stack, “the top three benefits of open source programs are 1) increased awareness of open source, 2) more speed and agility in the development cycle, and 3) better license compliance.”

Running an open source program office involves creating a strategy to help you define and implement your approach as well as measure your progress. The Open Source Guides to the Enterprise, developed by The Linux Foundation in partnership with the TODO Group, offer open source expertise based on years of experience and practice.

The most recent guide, Setting an Open Source Strategy, details the essential steps in creating a strategy and setting you on the path to success. According to the guide, “your open source strategy connects the plans for managing, participating in, and creating open source software with the business objectives that the plans serve. This can open up many opportunities and catalyze innovation.” The guide covers the following topics:

  1. Why create a strategy?
  2. Your strategy document
  3. Approaches to strategy
  4. Key considerations
  5. Other components
  6. Determine ROI
  7. Where to invest

The critical first step here is creating and documenting your open source strategy, which will “help you maximize the benefits your organization gets from open source.” At the same time, your detailed strategy can help you avoid difficulties that may arise from mistakes such as choosing the wrong license or improperly maintaining code. According to the guide, this document can also:

  • Get leaders excited and involved
  • Help obtain buy-in within the company
  • Facilitate decision-making in diffuse, multi-departmental organizations
  • Help build a healthy community
  • Explain your company’s approach to open source and support of its use
  • Clarify where your company invests in community-driven, external R&D and where your company will focus on its value added differentiation

“At Salesforce, we have internal documents that we circulate to our engineering team, providing strategic guidance and encouragement around open source. These encourage the creation and use of open source, letting them know in no uncertain terms that the strategic leaders at the company are fully behind it. Additionally, if there are certain kinds of licenses we don’t want engineers using, or other open source guidelines for them, our internal documents need to be explicit,” said Ian Varley, Software Architect at Salesforce and contributor to the guide.

Open source programs help promote an enterprise culture that can make companies more productive, and, according to the guide, a strong strategy document can “help your team understand the business objectives behind your open source program, ensure better decision-making, and minimize risks.”  

Learn how to align your goals for managing and creating open source software with your organization’s business objectives using the tips and proven practices in the new guide to Setting an Open Source Strategy. And, check out all 12 Open Source Guides for the Enterprise for more information on achieving success with open source.

SPDX License Identifiers can be used to indicate relevant license information at any level, from package to the source code file level.

Accurately identifying the license for open source software is important for license compliance. However, determining the license can sometimes be difficult due to a lack of information or ambiguous information. Even when there is some licensing information present, a lack of consistent ways of expressing the license can make automating the task of license detection very difficult, thus requiring significant amounts of manual human effort.   There are some commercial tools applying machine learning to this problem to reduce the false positives, and train the license scanners, but a better solution is to fix the problem at the upstream source.

In 2013,  the U-boot project decided to use the SPDX license identifiers in each source file instead of the GPL v2.0 or later header boilerplate that had been used up to that point.   The initial commit message had an eloquent explanation of reasons behind this transition.

Licenses: introduce SPDX Unique Lincense Identifiers


Like many other projects, U-Boot has a tradition of including big

blocks of License headers in all files.  This not only blows up the

source code with mostly redundant information, but also makes it very

difficult to generate License Clearing Reports.  An additional problem

is that even the same lincenses are referred to by a number of

slightly varying text blocks (full, abbreviated, different

indentation, line wrapping and/or white space, with obsolete address

information, ...) which makes automatic processing a nightmare.


To make this easier, such license headers in the source files will be

replaced with a single line reference to Unique Lincense Identifiers

as defined by the Linux Foundation's SPDX project [1].  For example,

in a source file the full "GPL v2.0 or later" header text will be

replaced by a single line:


        SPDX-License-Identifier:        GPL-2.0+


We use the SPDX Unique Lincense Identifiers here; these are available

at [2].

. . .


[1] http://spdx.org/

[2] http://spdx.org/licenses/

The SPDX project liked the simplicity of this approach and formally adopted U-Boot’s syntax for embedding SPDX-License-Identifier’s into the project.  Initially, the syntax was available on the project WIKI and was formalized in SPDX specification version 2.1 “Appendix V: Using SPDX short identifiers in Source Files”.  Since then,  other upstream open source projects and repositories have adopted use of these short identifiers to identify the licenses in use, including github in its licenses-API.  In 2017, the Free Software Foundation Europe created a project called REUSE.software  that provided guidance for open source projects on how to apply the SPDX-License-Identifiers into projects.   The REUSE.software guidelines were followed for adding SPDX-License-Identifiers into the Linux kernel, later that year.

The SPDX-License-Identifier syntax used with short identifiers from the SPDX License List short form identifiers (referred here as SPDX LIDs) can be used to indicate relevant license information at any level,  from package to the source code file level. The “SPDX-License-Identifier” phrase and a license expresssion formed of SPDX LIDs in a comment form a precise, concise and language neutral way to document the licensing, that is simple to machine process.  This leads to source code that is easier to read, which appeals to developers, as well as enabling the licensing information to travel with the source code.

To use SPDX LIDs in your project’s source code,  just add a single line in the following format, tailored to your license(s) and the comment style for that file’s language.  For example:

// SPDX-License-Identifier: MIT

/* SPDX-License-Identifier: MIT OR Apache-2.0 */

# SPDX-License-Identifer: GPL-2.0-or-later

To learn more about how to use SPDXLIDs with your source code,  please see the guidance in the documentation in the SPDX project, REUSE.software  or David Wheeler’s SPDX tutorial.    

In addition to U-boot and Linux transitioning to use the SPDXLIDs,  newer projects like Zephyr and Hyperleger fabric have adopted them right from the start as a best practice.   Indeed, to achieve the Core Infrastructure Initiative’s gold badge, each file in the source code must have a license, and the recommended way is to use an SPDX LID.  

The project MUST include a license statement in each source file. This MAY be done by 
including the following inside a comment near the beginning of each file: 
SPDX-License-Identifier: [SPDX license expression for project].

When SPDX LIDs are used,  gathering license information across your project files can start to become as easy as running grep. If a source file gets reused in a different package,  the license information travels with the source, reducing the risk of licence identification errors, and making license compliance in the recipient project easier.  By using SPDX LIDs in license expressions, the meaning of license combinations is understood more accurately. Saying “this file is MPL/MIT” is ambiguous, and leaves recipients unclear about their compliance requirements. Saying “MPL-2.0 AND MIT” or “MPL-2.0 OR MIT” specifies precisely whether the licensee must comply with both licenses, or either license, when redistributing the file.

As illustrated by the transition underway in the Linux kernel,  SPDX LIDs can be adopted gradually. You can start by adding SPDX LIDs to new files without changing anything already present in your codebase.  A list of projects known to be using SPDX License Identifiers can be found at: https://spdx.org/ids-where,  and if you know of one that’s missing,  please send email to outreach@lists.spdx.org.  

Learn more in this presentation at Open Source Summit: Automating the Creation of Open Source BOMs

Open Source Summit

Greg Kroah-Hartman talks about the importance of community interaction, and the upcoming Open Source Summit.

People might not think about the Linux kernel all that much when talking about containers, serverless, and other hot technologies, but none of them would be possible without Linux as a solid base to build on, says Greg Kroah-Hartman.  He should know. Kroah-Hartman maintains the stable branch of the Linux kernel along with several subsystems.  He is also co-author of the Linux Kernel Development Report, a Fellow at The Linux Foundation, and he serves on the program committee for Open Source Summit.

Greg Kroah-Hartman (right) talks about the upcoming Open Source Summit. (Image copyright: Swapnil Bhartiya)

In this article, we talk with Kroah-Hartman about his long involvement with Linux, the importance of community interaction, and the upcoming Open Source Summit.

The Linux Foundation: New technologies (cloud, containers, machine learning, serverless) are popping up on weekly basis, what’s the importance of Linux in the changing landscape?

Greg K-H: There’s the old joke, “What’s a cloud made of? Linux servers.” That is truer than most people realize. All of those things you mention rely on Linux as a base technology to build on top of.  So while people might not think about “Linux the kernel” all that much when talking about containers, serverless and the other “buzzwords of the day,” none of them would be possible without Linux being there to ensure that there is a rock-solid base for everyone to build on top of.  

The goal of an operating system is to provide a computing platform to userspace that looks the same no matter what hardware it runs on top of.  Because of this, people can build these other applications and not care if they are running it locally on a Raspberry Pi or in a cloud on a shared giant PowerPC cluster as everywhere the application API is the same.

So, Linux is essential for all of these new technologies to work properly and scale and move to different places as needed.  Without it, getting any of those things working would be a much more difficult task.

LF: You have been involved with Linux for a very long time. Has your role changed within the community? You seem to focus a lot on security these days.

Greg K-H: I originally started out as a driver writer, then helped write the security layer in the kernel many many years ago.  From there I started to maintain the USB subsystem and then co-created the driver model. From there I ended up taking over more driver subsystems and when the idea for the stable kernel releases happened back in 2005, I was one of the developers who volunteered for that.

So for the past 13 years, I’ve been doing pretty much the same thing, not much has changed since then except the increased number of stable trees I maintain at the same time to try to keep devices in the wild more secure.

I’ve been part of the kernel security team I think since it was started back in the early 2000’s but that role is more of a “find who to point the bug at” type of thing.  The kernel security team is there to help take security problem reports and route them to the correct developer who maintains or knows that part of the kernel best.  The team has grown over the years as we have added the people that ended up getting called on the most to reduce the latency between reporting a bug and getting it fixed.

LF: We agree that Linux is being created by people all over the map, but once in a while it’s great to meet people in person. So, what role does Open Source Summit play in bringing these people together?

Greg K-H: Because open source projects are all developed by people who work for different companies and who live in different places, it’s important to get together when ever possible to actually meet the people behind the email if at all possible.  Development is an interaction that depends on trust, if I accept patches from you, then I am now responsible for those changes as well. If you disappear, I am on the hook for them, so either I need to ensure they are correct, or even better, I can know that you will be around to fix the code if there is a problem.  By meeting people directly, you can establish a face behind the email to help smooth over any potential disagreements that can easily happen due to the lack of “tone” in online communication.

It’s also great to meet developers of other projects to hear of ways they are abusing your project to get it to bend to their will, or learn of problems they are having that you did not know about.  Or just learn about new things that are being developed in totally different development groups.  The huge range of talks at a conference like this makes it easy to pick up on what is happening in a huge range of different developer communities easily.

LF: You obviously meet a lot of people during the event. Have you ever come across an incident where someone ended up becoming a contributor or maintainer because of the exposure such an event provided?

Greg K-H: At one of the OSS conferences last year, I met a college student who was attending the conference for the first time.  They mentioned that they were looking for any project ideas that someone with their skill level could help out with. At a talk later that day, a new idea for how to unify a specific subsystem of the kernel came up and how it was going “just take a bunch of grunt work” to accomplish.  Later that night, at the evening event, I saw the student again and mentioned the project to them and pointed them at the developer who asked for the help. They went off to talk in the corner about the specifics that would be needed to be done.

A few weeks later, a lot of patches started coming from the student and after a few rounds of review, were accepted by the maintainer.  More patches followed and eventually the majority of the work was done, which was great to see, the kernel really benefited from their contribution.

This year, I ran into the student again at another OSS conference and asked them what they were doing now.  Turns out they had gotten a job offer and were working for a Linux kernel company doing development on new products during their summer break.  Without that first interaction, meeting the developers directly that worked on the subsystem that needed the help, getting a job like that would have been much more difficult.

So, while I’m not saying that everyone who attends one of these types of conferences will instantly get a job, you will interact with developers who know what needs to be done in different areas of their open source projects.  And from there it is almost an easy jump to getting solid employment with one of the hundreds of companies that rely on these projects for their business.

LF: Are you also giving any talks at Open Source Summit?

Greg K-H:  I’m giving a talk about the Spectre and Meltdown problems that have happened this year.  It is a very high-level overview, going into the basics of what they are, and describing when the many different variants were announced and fixed in Linux.  This is a new security type of problem that is going to be with us for a very long time and I give some good tips on how to stay on top of the problem and ensure that your machines are safe.

Sign up to receive updates on Open Source Summit North America:

As you may be aware, the European Union’s General Data Protection Regulation (GDPR) is leading to many changes in the regulatory framework for protecting personal data of EU individuals. You may find it useful to review our “Summary of GDPR Concepts for Free and Open Source Software Projects” white paper. The Linux Foundation will be compliant with the GDPR as of its effective date of May 25, 2018. The revised policies described below go into effect on this date.

Like many other global organizations, The Linux Foundation has been working hard to review the ways that it collects and processes personal data, in preparation for the effectiveness of the GDPR on May 25, 2018. As part of this, we’ve updated our policies and have enhanced the ways that we protect the personal data of people who interact with The Linux Foundation and our projects and services. We wanted to explain a few of the updates and changes we’re making.

We have updated our Privacy Policy to clarify and improve privacy protections and align with GDPR requirements. Briefly, the updated policy includes the following changes:

  • Clearer and more specific language. Our new Privacy Policy is easier to read and uses plain language where possible.
  • More details about our privacy practices. We provide more information about the types of personal data that we collect; the purposes for which we collect and process it; and the instances where data may be shared with third parties.
  • Information on your ability to control your personal data. We outline details about your legal rights under the GDPR regarding (1) how to get specific information about the processing of your personal data, and (2) how to control the ways that your personal data is processed.

Please take a minute to read the Privacy Policy itself, as the above points are just a quick overview of a few of the main changes.

We have also created a Cookies Policy to clarify how The Linux Foundation’s websites use cookies. The updated policy includes details about the specific types of cookies we use, a list of third-party cookies used on our sites, and information on how you can disable cookies if desired.

We have taken other steps as well to ensure compliance with the GDPR. These include performing an analysis of how we collect, process and transfer personal data throughout our services; documenting our lawful bases for this processing; updating internal processes and policies relating to the handling of personal data; and entering into data protection agreements with key third parties.

If you have any questions, please feel free to reach out to us at privacy@linuxfoundation.org.