This is an unfinished blog post imported from the Disintermedia project on CoActivate.
At the Netizen21 conference I attended recently in Hangzhou, I learned that ShareTribe has joined a growing movement of the projects switching from free code licenses to proprietary 'source available' licenses.
I met some of the ShareTribe folks at the Platform Cooperative conference in Hong Kong last year and I really respect and appreciate the work they've been doing, building a free code CMS that platform cooperatives can use to run genuine sharing websites. I think their intuition to adopt a free code license and leverage an open source development model still makes sense, although I think part of the problem that has motivated the shift to 'source available' is that they chose the wrong license for their needs (more on that below).
With all due respect for community autonomy and genuine concern for project sustainability, I suggest that all the projects who have moved to proprietary ‘source available’ licenses rethink this decision.
The biggest economic sustainability in free code software isn’t for user-facing software like ShareTribe Go, which has a fairly direct relationship with its users and can appeal to them to support the project’s sustainability. It’s a much more serious challenge for all the underlying components, from the Linux kernel up, which users of software packages like ST Go often don’t even realize they are using under the hood. I wonder if you’ve considered how it would affect your business model if the developers all these free code components your servers depend on made the same decision you have?
Imagine a world where you had to negotiate a commercial license with each of these projects, or rewrite that component from scratch and maintain it yourselves. Avoiding the complex legal and financial obstacles this scenario creates is one of the super powers of the open source development model. Abandoning this freedom of commercial re-use may have negative unintended consequences that far outweigh the benefits.
"After investigating the issue, we concluded that the company was not doing anything that would be against the terms of our permissive MIT license."
Right, I agree that the “MIT” license isn’t suitable for what you’re doing. The Loomio Cooperative originally chose “MIT”, but early on I convinced them to switch to the GNU AGPL. They’ve been developing and commercially hosting Loomio under AGPL for 7 years, without it causing any serious threats to their financial sustainability (that I’m aware of).
Like any copyleft license, the AGPL obliges anyone distributing the software to make source code available to anyone they give it or sell it to, and automatically licenses any modifications they make to the software under the same license. What makes the AGPL different from the GPL is that it extends the definition of “distributing” to include running the software on a server (“SaaS”), so web services have to inform their users if they are using AGPL software on their server and make source code available to them under AGPL.
In a response to Dan’s question about AGPL, you said
"it wouldn’t even force them to contribute the code they’ve written back to us"
IANAL but as indicated above, I don’t think that’s correct.
Here’s another angle that doesn’t often seem to come into these discussions. If a business is running a web service that depends on your software, it’s in their direct financial interest to make sure your business is sustainable. ST Go is not an off-the-shelf component like a database that they can swap out if you go under, it’s an essential tool of their business.
Have you considered combining an AGPL license with a voluntary commercial use agreement that such re-users could opt-in to, to support the ongoing R&D work you do as stewards of the software? If you mentioned that a percentage of the revenue from such agreements would be passed on to the developers of free code components ST Go depends on, that would make it an even more attractive proposition. This approach would also head off the risk of the open source community forking the last version of ST Go released under MIT and sidelining you as the stewards.
Just some things to think about. Either way, I wish you well.