Just to note: the OpenLDAP Project has never required copyright assignment - code you contribute is yours, forever. The Project only requires that your contribution be made available under the terms of the OpenLDAP Public License, or compatible terms.
This also means the code the Project distributes can never be unilaterally relicensed by the Project itself, since it doesn't own all of the code.
You should never agree to sign away ownership of your creations.
#Redis just confirms that "permissive" #OpenSource licenses should be understood as "permission to exploit".
A #CLA is a red flag (unless perhaps to a NGO/charity).
Look for projects that chose strong Free, Libre, Open Source protections - such as the #GPL / #AGPL / #EUGPL and a Developer-Certificate-of-Origin (#DCO) rather than setting yourself up.
... do we want to take a bet on how long it takes for #redis to get forked and their business to fold anyway, having caused the damage?
Hm, @logseq requires a contributors license agreement (CLA #cla ) to sign over all contributor's code to the company, so does the @joplinapp, with @joplinapp also having the server component source-available.
@obsidian is closed-source, wants $50/yr for a commercial license, paired with their $10/mo for sync - that's a lot of dollars for note taking.
Alternatives, anyone? Ideally open source to which I can contribute financially, without a CLA that will inevitably mean a change in licensing.
it's simple: i don't want to "register" or read your legalese right now; it's bad enough with license proliferation, now we're served with a proliferation of project-specific CLAs that are often longer than the original licenses #wtf#cla
:matrix: So the dev teams of two major #Matrix homeservers, #Synapse and #Dendrite, have announced that they will fork their work to change from the non-reciprocal #Apache license to the reciprocal #AGPLv3. That is a good step in the right direction. #Copyleft is the only effective way to ensure software public goods remain open.
However the effect is not much change yet, because they will require a #CLA for contributions to be merged. Revert to a #DCO would ensure future protection.
The #Matrix project is re-licensing its servers (synapse, dendrite, ..) from #Apache to #AGPL, following the spate of similar measures by many other projects. Good that they didn't choose a non-FOSS license.
But they're also changing the sign-off from #DCO to #CLA. That is very disappointing.
PS: If you are starting a FOSS project, consider adopting a #copyleft license. It should be abundantly clear by now that the push for permissive licenses is an attempt to extract free labour.
📣⚠️📣 Announcing a new home and license (AGPLv3) for Synapse and friends: going forwards Element’s work on Synapse, Dendrite & related server-side projects is going to be released as AGPLv3 rather than Apache.
@element AGPL: Great. CLA: Required to be able to relicense for specific customers, understandable. But allows you to "go closed source".
Not sure if it is possible to codify in legal terms that Element is indefinitely required to distribute a version of the software under the AGPL, maybe the one hosted at matrix.org? That would nerf the CLA by preventing you to fully go closed and in turn preserve trust in the community.
#opensource question: if a project has a #cla but an otherwise proper #floss license (not like BSL), besides the amount of work, would anything be in the way of maintaining a fork which merges upstream patches, but keeps its own additional patches on top, for contributions not under the cla?
When you find a promising Open Source project that fits your need, and then you find out it's a corporate-backed one that requires a CLA, and you have to go look for an Open Source project that fits your need 💔
"We're going to make you sign all the rights to your code over to us but we promise not to abuse it, or do a rug pull and change the license." aka #CLA (Contributor License Agreement) sounds kind of insane when I put it like that, huh? #osspodcasthttps://opensourcesecurity.io/2023/10/08/episode-396-clas-are-bad-mkay/ TL;DR: it is clearly insane and something from a bygone era that we should probably stop doing. Like putting onions on our belt.
> While the Jitsi projects are released under the Apache License 2.0, the copyright holder and principal creator is 8x8. To ensure that we can continue making these projects available under an Open Source license, we need you to sign our Apache-based contributor license agreement as either a corporation or an individual.
I am wondering if the CLAs are OK to stop an incident like one on #hashicorp from happening.
When a (VC backed) Open Source project demands from you, a community member, to sign a CLA (Contributory License Agreement) that forces you to give up your rights on your code - RUN. #Hashicorp et all who unfortunately, really sorry, kudos, love you switch their licenses to proprietary whenever they feel like it.
@jwildeboer
CLA MUST state under which license it is made and which kind of licenses it can be moved to (OSI-approved and/or GPL type, if you intend it to remain Open Source).