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.

#floss #freeLicense

@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.

@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
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.

@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
... And yeah, I know, license compatibility comes with its own set of issues, to be pondered over as well.

/end

@ploum
P.S. I expect that some will pound on me and tell me I'm wrong. I'm up for a continued conversation on the topic.

@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?

@ploum
Calling them anything is a matter of perspective and what your objectives are as a maintainer.

I know contributors who do call them bad, mainly because of the power imbalance they introduce. There's a sense of losing one's stake that you may have to grapple with.

I'm myself at the very least ambivalent, and am very apprehensive of signing a CLA, these days.

@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).

@levitte

@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)

@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 ..

@levitte