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:
A minimal set of clearing information must be defined, and a database must be provided to store curated data.
A platform must be established where a community can grow that creates, shares, and makes such curation data generally available.
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).
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.
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!
The Compact OSADL Online Lecture (COOL) September edition is presenting a tool to integrate OSSelot curation data into OpenEmbedded and Yocto build systems. The OSSelot curation database has been topic of several COOL editions in the past where the general concept of the project and the different ways of using the provided compliance data as well as the curation and contribution process have been demonstrated. Since the conception of the project, not only the amount of data has increased but also the availability of tools to work with this data and integrate it into other projects. This is an important step towards automating FOSS compliance tasks and as such a key aspect for the data’s practical application. One of these projects is the meta-osselot layer for integrating OSSelot curation data into OpenEmbedded and Yocto build systems.
In this COOL edition, Jasper Orschulko, the project’s creator and maintainer, will present the genesis of meta-osselot as well as its current status and plans for the future. First in theory and in the second part in practice, he will explain and demonstrate the functionality of the tool and show how it can be used in a development project to create an SBOM, obtain available compliance data from the OSSelot database and list those components for which curated data are not yet available. Anyone who builds software for embedded systems with OpenEmbedded or Yocto can learn how to simplify and accelerate FOSS compliance tasks by automating them as far as possible without compromising their quality.
The COOL edition takes place on September 25, 2024 from 2pm to 4pm CEST. Participation in COOL is free of charge. More details as well as the registration form can be found on the COOL event page.
