0 reply
0 recast
0 reaction
15 replies
9 recasts
87 reactions
Hi Varun,
1. I did not realise Snapchain didn't have a license, so its a good thing to have
2. Permissive licenses are good, but you don't get the benefit of copyleft, to ensure that if people do make changes, you can also get them upstreamed
3. GPLv2/3 is probably ideal for Snapchain. Though, what are the risks someone like Amazon takes Snapchain, and runs it as a service, ala MongoDB? And they were using the AGPL, before changing to their non-OSI approved, SSPL. I know for one, MySQL would prefer if they were AGPL licensed rather than GPLv2 because Amazon makes more money on RDS MySQL than all the others combined ;)
4. I would caution against something like AGPL - even though it fits better for network stuff - since a company like Google actually says no to it. They're not the only ones. https://opensource.google/documentation/reference/using/agpl-policy
So if I had to personally pick, I'd go with the GPLv2/GPLv3.
If people are worried about interacting with the Snapchain, i.e. if you were to provide client library interfaces, you could always LGPL those, so people can build on top of it. In fact, you'll note that MySQL were one of the first to "invent" the idea of the LGPL for client libraries + FLOSS Exception (which one can do as a copyright holder). This is how it got so widely distributed.
BTW, you have a contributing section - I would recommend to ensure that you have gotten the permissions from any contributors when you do add a license. Because so far, they've been committing to copyrighted code, and well, they own the copyright ;) Any relicense also requires their permission (which is why the Linux kernel is still GPLv2) - and its pretty hard to get it with something as wide & varied as Linux. Employees of Merkle obviously do not need to give such consent, usually covered by employment contract anyway. 1 reply
2 recasts
8 reactions
1 reply
0 recast
0 reaction
0 reply
0 recast
2 reactions
