hlandau
commented
9 months ago So here's my personal opinion...
I have some small open source projects of my own. Sometimes I licence those under MIT, sometimes GPLv3+. While these projects are too small to really worry about licencing too much, I have considered the issue at times.
My basic view is that if you're licencing under something like MIT, I'm not too concerned about getting a CLA because it's unlikely you will ever need to relicence, and MIT is so permissive it may not even be an obstacle if you do. On the other hand, when I've considered making a project GPLv3+, I'm much more concerned about the risk I may have to change the licence later and have sometimes considered whether I should require some sort of flexibility from contributors here. One possibility I have considered at times, but never actually implemented, is to commit to my own projects under GPLv3+ but require external contributions to be MIT. I hesitated to actually do that since it feels a bit hypocritical, but the practical aim of the idea was to ensure relicencing was possible in the future if it ever became necessary without making people go through the pain of a CLA, so in practice not that different from a CLA in aims and purposes but less potentially frictional to the contribution process.
That's just something I've thought about at times.
Of course OpenSSL has had an experience of a painful relicencing process due to a lack of a CLA. I have my own perspective... the really major factor which informs my perspective here and my anxiety about the need to potentially relicence when using what I will call "complex" licences (which the GPL definitely is) is the Linux kernel.
I have my own personal opinions on the Linux kernel's licence. I am certain many will find them controversial and disagree with them, but nonetheless, it's necessary to explain my perspective on it: my basic view is that the Linux kernel's GPLv2 licence is routinely violated in a way that is tacitly sanctioned by the Linux project. I believe the reason for this is that the Linux project has essentially realised that there are usages that violate the GPL which are overwhelmingly in the interests of the project to allow. I believe that the legal reality of the GPL is different and that a 'vigorous and total' enforcement of the Linux's kernel licence would do damage to much of the Linux community and the project itself. I believe that the Linux project is basically aware of this and has chosen to fudge the issue by spreading FUD and trying to prevent people from spotting the legal elephant in the room by articulating "interesting" legal theories about the GPL.
I believe the reason the Linux project has done this is because they are essentially trapped between a rock and a hard place: they accepted contributions from innumerate people under GPLv2 (without the "or later" even), and now you have ominous situation where you have a billion dollar software project which is tied up under a licence nobody has the power to change, even if a serious issue with it in relation to the project and its community is discovered. Faced with this dire situation in which billions of dollars of engineering effort might be tied up under a problematic licence nobody has the power to fix, the project, in my view, has taken the path of essentially obfuscating about what the GPL means and engaging in a kind of GPL revisionism and culture of tacitly understood selective underenforcement of the licence - or some parts of it, anyway.
This, to my mind, is a sign of how very dangerous it is to tie up a software project under a complex licence with no plan for changing it if it proves necessary. And in truth, the FSF sort of agrees — hence why they always included the "or later" mechanism, which is basically in real terms a backdoor in a licence for the FSF themselves, in case they find some dire issue that needs addressing. But Linus noticed that "backdoor" and removed it. I'm not sure I blame him for that, but it probably needed to be replaced with something else to allow relicencing in an emergency.
Ultimately, a "complex" licence like the GPL without the ability to relicence is like shipping a complex piece of software and committing to never changing it after shipping, ever — something few developers would willingly do and for good reason, yet for some reason we countenance the idea for licences.
So my basic view is this: there needs to be some way for a given project to relicence if it has chosen to go with a "complex" licence (like the GPL or MPL or CDDL — two of which are involved in the ZFS fiasco for instance). That usually means a CLA (not copyright assignment, just a CLA allowing relicencing.) On the other hand, I'm a lot less concerned by a lack of ability of a project to relicence if it is using a "simple" licence like MIT. In that situation, I'd lean much more heavily in favour of avoiding the frictional forces that a CLA poses — and they are real. I admit this situation is blurred by the fact that the previous, problematic OpenSSL licence was not actually a complex licence, and more a case of a simple but accidentally incompatible licence. But I would probably say that the legal understanding of the simple licences in the FOSS community has improved since then and such mistakes are now less likely to happen.
So, is the Apache 2 licence a "complex" licence? I would lean towards "no". Then again, it is the second version of the Apache licence — i.e., it did have to be fixed once.
Now as for my views as regards the OpenSSL project specifically, in terms of what we do now: My gut feeling is that, because we had this painful relicencing experience before, we are overly focused on making sure that doesn't happen again, and have imposed a CLA process as a result of this. My feeling is that this might be "organisational scar tissue": a way in which a bad thing in the past might be undermining our agility in a way that is not proportional to the actual risk of having to face another relicencing in future. It is human nature to overemphasise a painful experience which happened to you in the past and focus excessively on the risk of it happening again, to the exclusion of a more rational assessment of the real risks. Our present CLA policy obviously does cost us some contributions. I'd be open to a discussion of how we can reduce that "organisational scar tissue". I don't have a firm position at this time on what that solution might look like, or even whether we actually do want to make a change. But broadly, there is always a risk after some policy is introduced after one bad incident that it turns out to be an overreaction that becomes "organisatonal scar tissue" and acts as a frictional force forever after on the organisation's execution of its mission. That's my gut feeling — we would need to discuss these ideas in relation to OpenSSL specifically for me to come to a concrete position. But I'm open and by default supportive of ideas of how we can address the ways in which our current CLA policy does and might preclude some contributions from some parties.
One thing I will say is that I agree with the principle that we should not be granting ad-hoc exceptions to the process because we see a feature we like. We need to decide and adopt a principled position and be consistent about it.
@iamamoose @t-j-h
iamamoose
levitte
t-j-h
t8m
Sashan
mattcaswell
beldmit
Apache does not require every submitted commit to have an associated ICLA. And where a ICLA is required places the onus on the person to deal with CCLA if required. This is quite different to what OpenSSL does right now. We've had a number of occasions where the CLA burden has been an issue.
This ticket is to look at what Apache and others using the Apache License require, capture where it's been an issue, and recommend if we should or can make changes that could lower the barrier to participation.