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)
@lunaterra Don't trust "open source"
@lunaterra Doesn't the Linux kernel have this?
"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. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
@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.
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.
@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 To expand on this, here is Linus Torvalds calling any CLA fundamentally broken: https://web.archive.org/web/20141224205055/http://www.muktware.com:80/2014/01/linus-torvalds-cla-fundamentally-broken/19811
@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 github.com/microsoft/vscode 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.
@lunaterra they're still not even part of whatwg, right?
@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
Mastodon instance for lains, by lains