@frechdachs It’s also the point at which I realise that it’s not a crusade that I will be contributing to, which is a shame because I agree with all of the other points.

I’ve written a lot about why I don’t contribute to copyleft projects over the years, so I won’t repeat it all here, but at a high level, it boils down to two points:

Copyleft project licenses always include some conditions that are easy to accidentally violate. For example, if I compile a GPLv2 project and give a friend a binary so that they don’t have to build it themselves, I’ve violated the license. Will anyone take me to court? Almost certainly not, but now we’re in a land of selective enforcement and everyone needs to talk to lawyers to understand when they are compliant, not compliant but probably fine, or not complaint and at risk. I’ve spent a depressing amount of time talking to lawyers about the GPL and the number of things where the conclusion was that it was a technical violation but it would not be in the interests of anyone with standing to sue to take it to court was depressing.

I also contributed to a GPL’d FSF project where we had strong evidence of a company taking the code and distributing modified versions, but the FSF decided that it was too expensive to enforce the license. This is the worst situation because all of the legal restrictions apply to people acting in good faith but not to others because the cost of enforcement is too high.

More importantly, forcing people to cooperate via legal threat never works. People contribute changes to permissively licensed projects because they understand the value of the commons. I’ve seen far more proprietary software written as a result of the GPL than Free Software. Even small companies would rather reimplement something in house than understand the GPL in all of its intricate corner cases and so we end up with them providing no benefit to the commons. In contrast, the evolution I’ve seen many times with permissive software is as follows:

1. They take the code and maintain their own fork. Yay, the commons gives us free stuff!
2. They implement a new feature in their own fork. Yay, building on the commons lets us differentiate!
3. Upstream implements the same feature but a different way. Oh, private stuff on top of the commons is costing us,
4. They reevaluate how much of a competitive advantage they actually get. Hmm, maybe out 2% addition is not actually as valuable as we thought it was.
5. They developed their next new feature upstream and strive to have as small a diff as possible in house.

After step five, they are eager and willing contributors to the open ecosystem. With GPL’d projects, this doesn’t happen. They either do an in-house rewrite or they take GPL’d code and have compliance people deal with upstream and regard the license as a cost centre.

There are exceptions to this, but they tend to be projects that already grew to the size where a proprietary reimplementation is not feasible, such as Linux (and, even then, the level of grudging compliance from phone vendors, for example, shows you how little the GPL is actually helping).