The great thing about using open-source software is not having to reinvent the wheel when creating your own applications. The reason that we can use so much third-party open source code is that there are licenses that allow us to do so–but, as with all things legal, there can be many tricky conditions and clauses that we have to worry about.
Full disclosure here: I am not a lawyer, nor have I ever played one on television. But this stuff is in the news–Truth Social is being accused of violating some open source license agreements. That’s because it is alleged that Truth Social is just a forked version of Mastodon, an open-source project (written in Ruby) that anyone can use to roll their own social media network (think of it as an open source Twitter). You can find a few examples of such online communities here.
Since anyone can have their own instance of Mastodon, it is possible to add your own flair to Mastodon as well as to modify the source code. Mastodon uses a license called AGPLv3 –and there are clauses within this that seem to say that if you modify the code and then make the application or product based on said code available to the public, that you have to release your modified source code. That is, people have to be able to download that modified source code, not just use the product that you made with it.
Open Source Software’s Legal Issues
This isn’t a new problem, nor does it affect just social media type online-only products. The television maker Vizio was also sued for using open-source code in its SmartCast platform that allows you to use Apple AirPlay or Google ChromeCast services to, for example, cast your smartphone content or media to your TV. They modified the code, but never released that modified code to the public. Back in 2017, the Northern District of California upheld the right of open source software developers to sue for license breaches of this very sort, setting a precedent for the rest of the US. Consider yourself warned.
According to one site, the “high risk” AGPL license comes in at #15 in the rankings of top open source licenses, accounting for less than 1% of usage. However, the more popular GPL 2.0 and 3.0 licenses, together, account for 25% of usage and are considered high risk as well. Are you sure your project doesn’t have any of these lurking around? And if so, are your applications and products compliant with these licenses?
SOOS can help with this by ensuring that you always have a clear picture of what licenses and what legal risks your application might face. If your code has manifests in one of our many supported file formats, you can upload the manifest or have it continually scanned through integration with most CI/CD systems. After each scan, go to our web app and check out the LEGAL section in the menu, or just check the LICENSES page to see every license involved in your project. You will find a complete dependency tree, showing all your direct and indirect dependencies, and you can click on any one of them to find the license that covers it.
Scan the Licenses with SOOS
In the screenshot shown here, we see some data from a mock Python requirements file that I uploaded for scanning. You can see that there is an indirect dependency (python-dateutil) that uses the D-FSL 1.0 license (aka the German Free Software License). This license, like the aforementioned AGPL license, has a “Same License” requirement, as well as a “Network Disclosure” requirement (seen in next screenshot). The first part means that you have to release modifications to the code under the same license, which means that if someone can copy your software they have to be able to access the modified code as well (and see what modifications were made). The second part means that if the code ends up in some software that is executed, for example, in the cloud–that you have to make that code accessible as well–because if you didn’t, well, then it wouldn’t really be open source anymore, would it?
