Open source components are a major part of the software products we create and use. Along with the many advantages that using open source projects brings to software development organizations, it also comes with obligations and added responsibilities.
One of these requirements is open source licensing compliance. This is a task that most developers prefer to relegate to their organizations’ legal department, who, in turn, spend many late nights requesting, compiling, and double-checking the data to ensure that all open source code is accounted for and attributed.
That’s where the open source attribution report comes in.
Hopefully, we all know by now that while open source components are free in the sense that they don’t cost money, users are still required to comply by certain terms and conditions.
Usually, open source licenses require users to give credit to the creators of the open source project when they release and distribute the software. These credits are often called “attribution statements” or “open source notices.” Organizations distributing a product that uses open source components need to be able to produce an attribution report, covering the required information about all of the licenses, copyrights, and notices pertaining to the open source components in the software that they are producing.
Considering the fact that today’s software products are built with 60%-80% of open source code, creating an attribution report covering all of their open source components can be a hefty mission.
In the olden days, compiling an open source attribution report used to be quite the paper chase for a number of reasons. First, while some open source projects have clear and simple attribution statements, large open source projects can include several smaller open source libraries with a variety of information about licensing, copyright, and notices.
Next, locating the information for an attribution report is also a challenge, since the details are often scattered across a number of libraries and directories. To add to the confusion, there is no fixed standard for the name or location of an attribution statement in an open source library, so sometimes it can be found in a “readme” file, and other times it can be found in files named “license,” “copyright,” “notices” in any number of locations under a title that the creators of the software found appropriate.
Even after locating the license, copyright, or notice, the job isn’t done because sometimes an open source component’s license will be updated. This requires organizations to ensure that their attribution report is up to date and accounts not just for the open source components that they are using, but also for their versions.
In the past, keeping track of open source components and gathering the information was done manually on a spreadsheet. This made the creation of an Attribution Report extremely tedious business and open to human error, especially considering how tricky and time consuming it is to gather all of the information, and then update it continuously with every change.
Today, more and more software organizations manage their open source components to ensure that they are both secure and compliant with automated software composition analysis (SCA) tools, like Mend that continuously track their projects for security and licensing compliance risks in their open source components, for both direct and transitive dependencies.
Mend’s SCA capabilities allow the easy production of an attribution report containing all of the information about the open source software components in managed products and projects. It includes the open source components’ license with full license text, copyrights, notice files, and more.
Since each organization’s legal team needs its own specific format and content when producing an attribution report, it’s important you have as many customizable options as possible. Legal teams can produce an attribution report tailored to their specific requirements. Some organizations only require basic open source licensing data in their attribution reports, while others require detailed information like the original license text for each component and notice files. Some legal teams prefer the report to be in a tabular format, while others need to incorporate comments on certain components.
Mend allows teams to pick and choose the attribution data that they need for the report. They can publish extended copyright data and include the licensing text for each license associated with the reported component and the associated product or project. They can even choose which projects they want to include in each specific report, by preselecting a specific software product or project. The report also provides a number of export options so that teams can generate the report type that their organization requires.
The massive use of open source code in software products and services adds a new set of demands on organizations that require both legal and development teams to incorporate new processes and policies into their workflows.
In the past, legal teams and development teams struggled to create a comprehensive and up to date attribution report that suited their and their customers’ needs. Today’s automated tools enable continuous tracking of open source components’ licensing and copyright data so that generating an attribution report becomes a simple and easy process.