The Linux Foundation Member Summit

For many years, the landscape of open source licensing seemed stable and predictable. However, the advent of large language models (LLMs) has introduced new licenses and raised numerous questions about the application of existing open source licenses. At Fidelity, our Open Source Program Office (OSPO) and legal team have evolved our processes to navigate these changes and better understand what they require of us. This session will provide a practical case study and an accessible discussion on how OSPOs and legal teams can collaborate effectively in this evolving landscape.

“Perfect is the enemy of good.” Whether it was Voltaire or Aristotle who said it first, it’s true for risk management in open source software.

For both vulnerability mitigation and license compliance, risk management is always a sliding scale. How do you define or apply practical policies to focus identification and mitigation for the highest risk vulnerabilities in the context of your technology stack? And for the highest risk licenses in the context of how you deploy or distribute products or applications?

In this talk, Michael will discuss setting priorities for open source software compliance and how to avoid the pitfalls of focusing on low value / high cost activities, based on over 15 years of experience running Software Composition Analysis projects. The best advice? Focus on accuracy over precision.

The licensing of open source software, as embodied in source code and package metadata, has long suffered from lack of clarity and consistency. This has become more evident with the use of sophisticated license scanning tools. Discussions among open source legal and compliance experts often express the desirability of having such problems addressed upstream.

We will describe the progress on an initiative driven by Red Hat and the Fedora Project community to revitalize its traditional role of curating a distribution with careful attention to licensing. This initiative includes: improved documentation and explanation of license policies, evolution of "allowed" and "not allowed" license lists from a project wiki to a repository of machine-readable data; the use of SPDX identifiers in package license metadata, including close collaboration with the SPDX-legal community; and traceable license review process. We will cover an overview of the process, challenges faced and overcome, and planned next steps.

By sharing the Fedora approach, we hope others can learn or borrow from this work and also contribute to improving license information upstream.

If you had a collection of every kind of animal on earth, from mules to narwhals to goldfish, how would we pick out just the housepets? And how does AI distinguish between a pack mule and a Moscow Mule?

Embeddings are numerical representations that capture the essential features and relationships of objects, like words or images, in a continuous vector space, enabling tasks such as semantic search, clustering, and recommendations. We'll explore the core concepts of embeddings, using relatable examples to make advanced ideas accessible.

Legal professionals may find embeddings particularly relevant due to their ability to distinguish between different entities and concepts with nuance. Such capability is crucial for addressing legal issues like data privacy, bias mitigation, and intellectual property.

By understanding how embeddings distinguish between concepts, attendees can draw parallels to their own legal reasoning processes, gaining insights into how these AI mechanisms intersect with legal frameworks. This session encourages legal professionals to explore the intellectual and professional possibilities that embeddings present, deepening an understanding of AI’s role in law

The rapid evolution of AI has outstripped traditional open source licensing, creating legal uncertainties around copyrightability of model weights, fair use in training, and liability. This session will begin with an overview of the Model Openness Framework, which breaks AI models into 17 components, offering tailored open licensing strategies. However, its complexity has hindered broad adoption.

To that end we will present the OpenMDW License, a permissive license designed specifically for AI models. Covering architecture, data, weights, tools, and documentation, it addresses gaps in existing frameworks and incorporates AI-specific liability considerations. This license offers a standardized solution to the challenges faced by model creators and users.

This session will equip attorneys with critical insights into AI model artifacts, the limitations of current licensing practices, and practical tools for handling openness and completeness in the evolving AI landscape.

The release of v.1.0 of the Open Source AI Definition answers a lot of questions and leaves a few more open. This session will briefly cover the 2+ years of the co-design process that led to the Open Source AI Definition and highlight the unanswered questions. leaving time for a brainstorming session.

As Open Source continues to grow in functionality & adoption, so does the likelihood & risks of patent attacks. OIN protects OSS through a unique cross-license whereby OIN’s members agree to not sue each other for use of their Linux & Open Source related patents. The cross-license is defined in scope by over 4,5o0 core Linux & Open Source technology packages known as the Linux System which is updated & expanded every 18-24 months. Newly released in August 2024, Linux System Table 12 covers cloud-native computing, enterprise software, IoT, networking, automotive, embedded systems & hardware development technologies, among others. Table 13 is open for nominations from Linux Foundation members and the greater open source community.

We’ve been doing source level license scans for LF projects for a long time including generating SPDX formatted files, but what about SBOMs that can meet (and exceed) the government minimum specification? Here at the LF, we are now leveraging our existing scanning capabilities to generate SBOMs for these same critical open source projects.

In the LF spirit, we are using existing open source tools to scan project dependencies to produce an SBOM that meets the minimum spec. We are also producing dependency level license data to compliment our source level scans. In the near future we will be combining these to produce a grand unified SBOM that will meet a newly defined LF minimum specification for SBOMs.

We will talk about our process to generate these SBOMs, the challenges we faced, our future plans, and share more about how you can make use of these for the projects you care about most.

The “Software” Product Data Exchange was created in 2010 to provide machine and human readable metadata for licensing information to consumers of open source software. Over the years, the SPDX community has added support for a wide range of additional use cases. Complex software component interactions between open source and proprietary as well as the requirements to support SBOMs optimized for security risk management have been driving forces for many of the changes. With the SPDX 3.0 release and work being done for the upcoming SPDX 3.1 release, the scope of SPDX has expanded beyond software to entire systems including datasets, AI models, services and hardware. This will enable consumers to satisfy additional use cases in areas like product safety and export regulation compliance. With the SPDX 3.0, we’ve renamed SPDX from “Software” Product Data Exchange to “System” Product Data Exchange to better reflect where the project is aiming. In this talk, we’ll go over changes we’ve made to the SPDX model to support systems, the additional profiles that are focused on system level problems and what this means to both the producers and consumers of SPDX data.