ploum
Hey open source contributors,
I’m looking for examples of license agreements from big open source projects.
What are, according to you, the best license agreements? What is an important thing to check before signing a license agreement? What would be your advice to an organization drafting a license agreement to contribute to an #agpl3 project?
Thanks for sharing my question. This is something I will probably add in my open source teaching at university.
ploum
@benoitb @jonmsterling @albertcardona : I believe that there are many cases where CLA could be beneficial for the project on a long term scale (what if, for example, you wanted to switch from GPL to AGPL because it suddenly become available over a network?)
That’s why I’m investigating the subject.
Benoît B.
@jonmsterling @ploum @albertcardona
Totally agree.
Plus a CLA can be a hell to manage for the organization (maintaining and updating the list of all corporate and individual contributors)
And from the contributor pov, if only one clause is a stopper, he / she would be stuck between the willingness to contribute and the rejection of one small unacceptable condition.
Jon Sterling
@ploum @albertcardona I don't think we should have contributor license agreements, which seem to exist only to ensure that the (often corporate) steward of the project can unilaterally change to a non-free license in the future. Having copyright diffused among all the contributors (many of whom would be unreachable in the future) makes this completely impossible, and this is a feature rather than a bug.
ploum
@jonmsterling @benoitb @albertcardona : you have to if you want to give rights to the users acceding your software through the network. (that’s why the AGPL was created)
Jon Sterling
@ploum @benoitb @albertcardona This is not true: you don't have to switch from GPL to AGPL to make your software available over a network.
Richard Levitte
@ploum
So for the example I see you mention, changing the project license from GPL to AGPL, I actually think that you can change the _project_ license, just as long as the license in each file remains unchanged, and as long as license compatibility remains.
ploum
@levitte : Indeed, you could technically change from GPL to AGPL without approval from contributors because there’s a one way compatibility (in fact, I did it myself by changing a project license from BSD to AGPL).
So my example doesn’t work. But does that mean that CLA are always bad?
Richard Levitte
@ploum
On the subject of license changes, BTW... this is also something to carefully think about.
I'm coming from the perspective that there's a project license, and then there are licenses in each file. They do not have to be the same, all that's needed is that they are compatible.
Richard Levitte
@ploum
It all really depends what you want a CLA for.
Some want it primarily to increase their own freedom over the project, like license changes.
Some want it primarily for assurance of provenance.
Some want it only from the maintainers (I know that exactly this has been argued for in Apache circles), which then essentially constitutes a permanent sign-off on everything they do.
Richard Levitte
@ploum
Personally, I've come to the conclusion that CLA are pretty much bullshit.
We have other tools for provenance, with the Sign-off trailer in commit messages. Maintainers need to pay attention either way, and in that respect, the Sign-off trailers in front of you are just as easy to deal with as any commit author.
As for increasing the freedom of the maintainers, the creates a power imbalance which isn't very palatable when you thinkg about it.
ploum
@ohubaut : that’s very interesting, thanks!
Olivier Hubaut
@ploum The Spring project recently switched from requesting a CLA to a simpler DCO, if that’s interesting to you.
https://spring.io/blog/2025/01/06/hello-dco-goodbye-cla-simplifying-contributions-to-spring
Alfred M. Szmidt
@ploum I think there might be confusion, unless you're the copyright holder(s) you're not allowed to change the license from "BSD" to AGPL. What you can do is license any new changes under the AGPL ... but the old license still sticks around.
Similar if you combine GPL to AGPL (see section 13 of the #GNU GPL -- you're not changing the license of the old code).
ploum
@amszmidt @levitte : of course the old license stick around but if you release new version of the code under AGPL, your AGPL changes will taint the code and there’s no going back.
(I forked a BSD app and made a AGPL app based on the BSD code. The BSD codebase still exists in parallel)
Alfred M. Szmidt
@ploum Nothing gets tainted, and you can go back if you can untangled the changes that are licensed under one or the other license.
Often when people say "change the license" they mean that, when you combine to licenses, you ever change the license, which is the point I want to clarify. There was one instance when some Linux hackers "changed the license" as an earnest mistake ..
feld
Charles Flèche
@ploum two CLA from an open source framework from Pixar: https://github.com/PixarAnimationStudios/OpenUSD
One is for individuals, the other for corporate contributors. I've signed both.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.