- trustgraph.ai
- Posts
- Open Source Licenses Matter
For two weeks, we at TrustGraph agonized over our license choice. The arguments were heated. The pendulum swung to opposite ends of the spectrum. Finally, we made a decision. While we spent two weeks on this decision, it sounds like PearAI was too “busy building rn can’t be bothered with legal”. I guess we just don’t know how to Founder Mode.
And after two weeks, where did we end up? AGPL-3.0. Not exactly the most creative choice, but at this point in TrustGraph’s growth, we feel it is the best option. So what is AGPL-3.0 and why did we choose it?
AGPL-3.0 is a copyleft license. If you’ve never heard the term copyleft, it’s a play on words of copyright. The concept is quite simple. With a copyleft license, anyone can still take the code, modify it, redistribute it, and commercialize it, but they must publish the code with the original license agreement. In other words, the AGPL-3.0 must follow with any projects using the original code. In the case of TrustGraph, anyone can fork it, modify it, redistribute it, or even commercialize it, as long as they maintain the AGPL-3.0 license. The AGPL-3.0 license guarantees TrustGraph and any derivatives will remain true open source.
Why have open source licenses become so complicated? One word - er, buzzword - SaaS. All of these legal issues stem directly from the distribution aspect. When a software vendor completely controlled the distribution of the software product either through physical media or access to downloads, the software was packaged as executables with no access to the source code. There was no way to use the software product without having acquired the vendor packaged executables.
And SaaS changed all that. Much like streaming forever changed music, tv, and movies, SaaS has similarly changed software. Now users login into a web-based portal where they consume the software services on demand. There is no exchange of a software package from the vendor to the purchaser. Instead, the distribution model has shifted to on-demand access to a cloud software service. The purchaser never has direct access to the software executable or source code in any format.
This shift has, not surprisingly, not been without controversy. Two of the most well known examples are MongoDB’s introduction of the SSPL license and Elastic’s battle with AWS which also involved SSPL. SSPL, Server Side Public License, was introduced by MongoDB to prevent, for instance, cloud providers from simply forking open source projects and reselling those versions natively within their cloud ecosystem. That intent seems entirely reasonable - except that the language of the SSPL license goes much further than that. Most interpret the SSPL as being a “poison pill”, that requires releasing all source code that integrates or deploys the code with the SSPL license. In other words, if you’re a cloud provider, all the code that’s unique to your environment would also have to be released, even though it has nothing to do with the software in question - it’s just deploying it.
In response, the Open Source Initiative has made it quite clear that the SSPL is not an open source license. During Elastic’s battle with AWS, Elastic shifted to a SSPL license for both Elasticsearch and Kibana. This move was not well received. On August 29, 2024, Elastic announced they would be making both Elasticsearch and Kibana available with an AGPL-3.0 license option.
So what actually matters when it comes to an open source license? Here are the questions of interest:
Can I modify the code?
Can I distribute my modified code?
Can I commercialize the code and/or my modified code?
Can I issue the code and/or my code under a different license?
A great test of these questions is the Winamp license. Yes, you probably just said the same thing I did - people still use Winamp? Is this 2002? I would have thought they would have gone with a very permissive license like the MIT License. Instead they have released Winamp under the Winamp Collaborative License (WCL) Version 1.0.1. So let’s ask our questions:
Can I modify the code? Yes!
Can I distribute my modified code? No!
No? Already? Don’t ask me, not my license. This license certainly does not qualify as an open source license, and I’m not even sure what Winamp are trying to accomplish. Well, I have an idea, but it’s too cynical for this polite license discussion.
How about the two most common licenses MIT and Apache 2.0. MIT is quite simple - it allows everything. Apache 2.0 is nearly as permissive except that it does require attribution. In short, you can take Apache 2.0 code, change it, add to it, and distribute those changes and additions under a different license. However, unmodified code must be distributed with the original license statements. So, can you fork an Apache 2.0 repo and start building? Absolutely. Can you fork an Apache 2.0 repo and slap a different license on it? My lawyers have just alerted me to not answer that question and simply wag my finger and scowl.
We’re serious about building a community around TrustGraph, but we also want to give us a path to commercialization that isn’t littered with landmines. No license is perfect, but we believe AGPL-3.0 is a good fit for projects like TrustGraph. Come join the community and give us your thoughts on open source licenses and don’t forget to deploy some GraphRAG pipelines while you’re at it!