Winning the copyleft fight

Winning the copyleft fight

Yes it can, just like proprietary code can be opened up. But I see your point.

Proprietary code usually has one copyright owner. If you have several dozens of contributors then getting them all to agree to relicense the code might be impossible.

IIRC "our code base integrates code from an unspecified third-party who is not willing to change their license" has often been brought up as a showstopper from companies who were being pressured to open up some of their stuff. So taking that "usually" with a grain of salt.

That said, I expect that copyleft code remains useful and accessible for the vast majority of people or entities who would want to use it. The two obvious exceptions being entities who want to distribute proprietary derivatives and entities who want to integrate the software in a setup that is locked down (as far as their users/customers are concerned).

With that in mind, it seems to me the split of a copyleft fork (which doesn't happen that often anyway, see below) only disenfranchises a few contributors to a project (steering clear of the word 'community' here; it's debatable whether developers of proprietary forks at least should be considered well-behaved members of an open source / free software project community).

Granted, those contributors might be economically powerful and could be employing many of the most active contributors. Which is one of the reasons not to fork lightly. AFAICT, copyleft forks of permissively-licensed projects don't happen often (evidence: all the projects out there that could have been forked but haven't). The examples that come to mind ATM were actually forked for very good reasons, e.g. LibreOffice and Kallithea. The earlier reference to Xemacs vs GNU Emacs above doesn't seem directly relevant to this discussion BTW, as IIUC, the main contention point was the copyright assignment requirement; both projects are copyleft-licensed. When such a fork does happen, it seems to be because the prior arrangement is deemed unreasonably beneficial to the parties left behind.

So, while casually forking projects is not a good idea (and AFAIU nobody claimed that it was), a copyleft fork is not necessarily "community splitting" either. In fact, the word "community" brings with it a narrative of entities happily working together, whereas it's very often the case that contributors to an open source project will have different or even opposing interests. In that case, the benefits of collaborating need to be considered in the larger context of "how can we best achieve our goals?"

Your reference to apple and gcc's switch to gplv3 seems disingeous to me. The anti-tivoization clause should be pretty much irrelevant for a compiler. And the posturing of having apple-employed clang developers presenting benchmarks against the latest gplv2 version of gcc (b/c they weren't allowed to /use/ any later gcc apparently) seems indicative of fanaticism at best. Hopefully that's changed since I last saw such a presentation...