What is OSSelot?
OSSelot does the tedious work for you: It provides ready-to-use licensing material for frequently used Open Source software packages.

Rationale

When people who copy and distribute Open Source software for whatever purpose are asked what they think most hinders and limits the use of such software, they regularly answer, “Clearing a software component for distribution and correctly fulfilling the various license obligations is so much painful work.” And they usually add: “It’s especially painful because you know that most of the work has been done a thousand times before by others, but you can’t get to the results.” It seems therefore obvious to share these efforts just as the development of the software itself is shared. To do so, three prerequisites must be fulfilled:

1. A minimal set of clearing information must be defined, and a database must be provided to store curated data.
2. A platform must be established where a community can grow that creates, shares, and makes such curation data generally available.
3. To create trust in the reliability of the provided material, its quality must be undeniably high, requiring experienced and responsible contributors and continuous, rigorous and thorough review.

To make this happen, the OSSelot project was established.

Content

The project data are provided in a publicly accessible repository for selected versions of software packages such as Coreboot, the Linux kernel or the OpenSSL library. Typically, three artifacts are included per package – a README file with general information, an SPDX tag:value file with curated data for every single source code file and a ready-to-use OSS disclosure file. The tag:value files can be integrated into the build process, so only the licenses of those files that are actually compiled into the build artifact and distributed need to be considered. See Presentations for use cases and examples on how to use the provided data. In addition, the tag:value files contain annotations to the license conclusions to elucidate decisions that are not obvious. The OSS disclosure files contain all applicable licenses and all copyright notices for the entire package. In addition, the OSS disclosure files contain “acknowledgment text” when such acknowledgment is required by the license.

Following the principle of Open Source software development, contributions, review of existing data and bug reports are encouraged. Feedback can be given via git issues in the repository or in direct contact to infoªosselot.org. In return, any inconsistencies or problems that are found while curating data are communicated to the respective projects in the hope that future versions are improved for everyone.

License

OSSelot is not only on Open Source software, but also is Open Source itself and licensed under CC0 1.0 Universal (SPDX-License-Identifier: CC0-1.0).

For some time now, a widget has been available on the Tools page that can be used to select an OSSelot package and a set of binaries created by that package to generate an SBOM based solely on the files and licenses contained in the binaries. To make the background of the functionality of this widget easier to understand and to describe the individual steps from entering the name of a package or binary file to downloading the generated SBOM, a corresponding slide set has been uploaded to the Slides section.

There are a number of reasons why one would like to know which other binary software components a program requires at runtime. Some of these reasons are specific to the OSSelot project, while others are more general or related to copyright issues. Typically, a list of runtime dependencies is created using link dependency analyzers such as callgraph, but this requires that the respective projects be built on a trial basis.

OSSelot-specific reasons

• Check whether the project to be curated can be built at all.
• Based on the list of dependent packages, determine the priorities for further curation.
  

  General reasons

• Use the dependency list to estimate the complexity and integration effort of a project.
• When using copyleft licenses, ensure that license compatibility is maintained across the combined works.
  
  For the reasons mentioned above, all packages were built on a trial basis in OSSelot, dependency lists were created and these were displayed graphically in the form of callgraphs.
  
  

  Example callgraph

  
  
  
  Callgraph of the wget application
  
  
  A new section was added to the Tools page that allows to search for curated packages and versions and display callgraphs of all related programs and libraries.

Last week, the first contribution of curated compliance data from OSADL member AUDI and Kanzlei Jun has been merged into the OSSelot database. Many thanks to everyone involved for their effort to make this happen!

We know that it can be difficult to motivate employers to allow contributions to Open Source projects and to find the time to realize them. We hope that others will see AUDI’s example as a springboard to grow their own culture of contribution to Open Source projects such as OSSelot. Every new contribution is an important step for the OSSelot project towards a more extensive set of Open Source compliance data “created once for the use of many” – the OSADL credo in action!