Even organizations that are fully dedicated to software development don’t want to spend their time and competitive energy chasing software compliance. But ignoring changing legal requirements is dangerous.
A recent policy change on a popular software license was caused by patent issues and affects more than just open source projects.
Contract for collaboration
If you spend even a few minutes looking for freely available or public domain images, tools, and content, you’ll see dozens of options listed with a “Creative Commons” license. This alternative to simple copyright allows creators to share their works online and make clear what (if anything) they want in return. The system represents a more nuanced contract between the creator and user than standard copyright.
Authors and inventors can use the Creative Commons to request attribution, collaboration, payment for commercial use, and more. All within an established legal framework of contracts and documentation underlying the whole system.
More about the Creative Commons project.
A child project prodigy
The Creative Commons legal framework came about independently but mirrors many open software efforts that began in the late 80s and 90s. However, the project has been so successful, it may have outdone its predecessor at least in name recognition. Now, many software projects employ a Creative Commons license for software.
Just one problem: the Creative Commons project itself advises against its use in software.
On Monday, July 25, LWN reported that a popular open source project no longer allows code to use the CC0 license. The Fedora project, probably best known for its Linux distributions, took issue with the statement about patent language:
“…Licenses that preclude any form of patent licensing or patent forbearance cannot be considered FOSS (Free Open Source Software).”
As an influential project in the community, this rejection means that more projects will likely follow suit and also decline software with the CC0 license (1).
And the concerns about patents extend beyond the open source community.
Who’s afraid of a license?
License and patent questions like these may seem like a concern for lawyers and legislators, but the tools it governs are at the core of today’s software development. In fact, the explosion of 3rd party components means an estimated 80 to 90% of projects are made up of open source code. And each part of that code is governed by a legally-binding license that addresses patent usage.
It’s clear that open source license management is an issue for development teams. Fedora’s move suggests that patent concerns must be part of that discussion.
Patent concerns are a major issue in this space and have been an issue in open source for a long time. Litigation on this front (also known as a “patent attack”) is a real concern. You could be liable for monetary damages, royalty payments, or an injunction on the sale of products.
Because patents are here to stay
Although we cannot hope to make legal recommendations for the whole industry, we can predict more decisions like this from the open source community. Fedora is not only pushing away from this license, they will continue to reject any licenses with patent issues. This episode highlights an ongoing evolution in governance and encourages us to reconsider what’s in our software.
Again, the Creative Commons as a whole was not meant to apply to source code. As of this writing, patent claims have yet to be tested in court, but how that will eventually be decided is unknown. And making software with an unclear or problematic legal status means unwelcome risk for software projects.
Development teams are trying to move fast and the use of open source can help them innovate. But because concerns around patents remain a concern in 2022, we recommend setting clear policy to save time and headaches.
How to avoid the CC0 license?
Small teams and projects can do a simple keyword search for CC0 in their source code repository to ensure no software with this license is present. However, as the average project carries 100s of open source components and dozens of licenses, that means a lot of ongoing, manual effort and confusion. For most teams, adding tasks around this kind of analysis is not an option.
What’s needed is an automated and transparent tool that will work inside of your development environment to govern the process and select safe licenses. Nexus Lifecycle users can set policy to either warn or block usage by any individual or group of licenses, including CC0 and others in the Creative Commons family.
View of the license analysis interface
Legal reviewers and developers may also benefit from the Advanced Legal Pack. It provides a full breakdown and explanation of license obligations, as well as advanced tooling and workflows to identify the exact source files that contain restricted licenses.
A flagged CC0 license with explanation
Get out in front of legal issues now
Gaining compliance around open source software means avoiding litigation and other burdens, including patent attacks. Automated compliance tools like the Advanced Legal Pack enable rapid license review and help avoid projects with licenses like CC0 (2).
Example license analysis with requirements highlighting
Advanced scanning also means confidence that open source components in your software supply chain aren’t accidentally bringing in any undeclared licenses.
 This ban only applies to source code and Creative Commons licenses remain a great option for licensing software documentation. CC0 in particular is a much better option than committing your work to the “public domain,” as the meaning varies greatly depending on where you live and current legislation.
 The Creative Commons project has amended licenses in the past and may yet make a change to address these concerns.