Don't trust "open source" projects with Contributor License Agreements, they are effectively not open source/free software at all and cannot be trusted or forked in productive ways that eliminate corporate control. (glares at Microsoft with VSCode and Azure)

@jalcine @lunaterra The Linux kernel famously doesn't have this which is why it will forever be GPL v2 and never be licensed to a more recent version of the GNU GPL.

Also, hi, I work in Azure. I don't think I've seen any volunteer open source contributions to the projects I've touched. I don't think anyone here is bummed out about that. It is more so that you can read all the code that's running inside your Linux VMs. The equivalent Windows codebases are "surprisingly" not open source.

As far as forking the projects go, there is no backsies once the code is out there under an open source license. Now, theoretically, Microsoft could take the code back and make future improvements that aren't distributed under a FOSS license. Your fork of the last open source commit would be safe though and you'd be free to make improvements to that fork. Apache 2.0 isn't even a copyleft license so you could make improvements and distribute them under a compatible non-FOSS license too.

@will @jalcine
"Now, theoretically, Microsoft could take the code back ..."
Yes and then they are taking advantage of the contributions of developers, to put it the nicest way possible. I'm sure you know though that what you described above isn't really an excuse since anything of the sort would inevitably kill the project as anything remotely free. This is what is meant by "Embrace Extend Extinguish", the business model of your employer.,

@will @jalcine Giving any entity the ability to re-license commits contributed to a free software or open source project is in blatant violation of the spirit of the original licenses which often explicitly prohibit this in the first place. Its a nasty use of contract law to negate the freedoms provided by copyleft.

@lunaterra @will @jalcine

Except that with any "or later" versioned license, you give the license author the right to relicense the commits.

CLA are bad because they are unbounded.

That's why I introduced a bounded upstream copyright assignment in the #HackingLicense:

@jalcine "CLA" is just an ambiguous term for any sort of legal contract that a contributor to a project might be obliged to agree to. The benign ones are the exceptions.

@lunaterra @jalcine Clojure has one. The author really didn't want to open-source Clojure-- he wanted to keep tight control of it-- but it was impractical to get anyone to adopt a language that wasn't open source. Instead, he went with a CLA.
@lunaterra @jalcine Linux (AFAIK) has no CLA, which actually came up during the GPLv2 vs v3 kerfluffle (in that it was impossible to relicense Linux to GPLv3, even if Linus had wanted to). The FSF on the other hand does use a CLA, which according to them helps them enforce the GPL on those projects.

@malacoda @jalcine Yeah, Linus hates CLAs and has criticized the FSF for using them (which seems fair to me).

@jalcine The kernel actually has quite a few licensing options:

I know the #FFmpeg licensing situation better, and there you are free to submit code under any license, but only #LGPL compatible code is enabled by default.

The kind of CLAs which @lunaterra refers to typically assigns the copyright to say Microsoft to do with as they please. You simply have to trust them. Forking is also often forbidden.

I'm going to note here that reassigning copyright is often the case with GNU projects, but there the GNU licenses ensure that GNU itself (the organization) cannot rescind licenses granted to its users for any of its project.

@lunaterra why couldn't they be forked, theoretically? It's still an open source license right?

@skybrian It depends on the CLA. Its contract law, you could sign your kids away lol.

@lunaterra but suppose I'm just forking the project and not sending a patch. Then I don't need to sign any agreement. I only care what the license says and if it's an open source license, then it says forking is okay.

If they change the license to not be open source, I can still fork the code at the commit before that, where the old license still applies.

@skybrian oh, I think I understand what you are asking. When you sign away the rights to your commit and agree to x, y, and z they can essentially either overwrite any terms of the original license agreement or make them irrelevant via other clever legal means.

@lunaterra Don't see the point in what you say. You can still fork VSCode. The CLA is not for editing and redistributing the code, but for having your code merged to MS's repository. In other free software projects your PRs won't be merged automatically either, and the lead devs will have sometimes have unreasonable preconditions for PRs.

As soon as MS f*s up VSCode etc. at some point and doesn't accept a fix, there'll be a VSCode community fork. And if it's better, people will switch.

@turion don't confuse legal stuff with project management because that's just a different ballgame.

Also as an aside, in the specific case of VSCode there has been a community fork already, but I haven't read through the CLA for that project and hired a legal team to decode what it entails (read: sarcasm). Not sticking to simple, known licenses and piling on a bunch of other stuff is bad faith which disempowers individual contributors (to be continued...)

@turion the point is, regardless of the specifics which varies contract to contract in all of this ridiculousness, that should the project be re-licensed its foolish to pretend like it isn't effectively being seized from the community since all the work of the community goes with it into the proprietary version/ Then the proprietary version will then be extended to make the old fork irrelevant as part of the Embrace Extend Extinguish strategy.

@lunaterra Just merge all the new features and fixes from what you call "the proprietary version". Can they prevent you from doing that?

@turion yes. that's the definition of proprietary. secret, no copying.

@lunaterra Aha. Well then VSCode is not proprietary AFAIK because you *CAN* just copy from it.

@turion yes, it is not proprietary yet. Read the previous messages in the thread I think you missed a few things.

@lunaterra No worries, I didn't miss anything. vscode is under an MIT license. You'll always be able to copy and redistribute all the code you find on today. If you worry about the binary that MS distributes
under the same name, well, just don't use it. Build vscode yourself.

Don't get me wrong, I don't like MS either and I'm not setting any hopes into vscode. The problem is not that it is not open source, the problem is the development structure.

@turion okay, I'll sum everything up again then. By using a CLA and a bunch of legalese it is possible to force contributors to give over the rights to license their commits as well as a bunch of other stuff which can effectively neuter whatever license the project supposedly has. As a result Microsoft decides what it is now and can change it tomorrow if they wanted.

@lunaterra Yep. Most OS licenses today are either too weak by allowing this kind of unethical behaviour, or too strong because too few people adopt them.

Yep, it's called "VSCodium" and I use it instead of VSCode.🙃

@lunaterra @ekaitz_zarraga CLAs make projects more corporate-contributor-friendly, which might make it a project one isn’t interested in. but it’s not accurate to say they can’t be forked. source: i developed the linux foundation’s CLA tool, and spent literal hours with their legal team trying to understand CLA vs DCO

@lunaterra @ekaitz_zarraga happy to discuss my experience with various contributor agreement systems (why they exist, what they are used for, blah blah).. it is the most boring project i’ve ever worked on but i will try if folks want

@alana @ekaitz_zarraga sure and they vary, but forks don't do much when somebody like Microsoft takes all your work and runs with it as a proprietary work.

Sign in to participate in the conversation

Mastodon instance for lains, by lains