10 ms·

It's a great point to be aware of, but the title and the tone implies that you as a contributor should be a FOSS maximalist. As they say, not all open source i

It's a great point to be aware of, but the title and the tone implies that you as a contributor should be a FOSS maximalist. As they say, not all open source is FOSS. And some people are OK with that. Let them contribute, as long as they are aware of the implications. When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork. > Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors. This is not the case of all open source licenses. And that is fine. Don't assume all my work has to be part of your crusade. I will save that for the parts of my life where it makes sense - I am all-for the FOSS movement but there is no need to go full Stallman and say that everything but GPL is evil. If I believed that, I wouldn't be working on a closed-source project in the first place and then this piece would be fully relevant. A much better title would be "Why I don't sign CLAs" or "The dangers of signing CLAs".

rqs 8y ago
> the title and the tone implies that you as a contributor should be a FOSS maximalist. But what if somebody was changed the license from BSD to proprietary after you've contributed to the project? Would you still be happy about it then? I think the idea was: I have my code contributed under BSD, so you cannot re-license my code without clearance from me.
- Legogris 8y ago
  No, but I would be just as upset if I wouldn't have done that contribution. There is no way they can change the past - my contribution is still open source and so is the project up until the version where they introduced the license change. The version I made my contribution to is still BSD but the current upstream master might not be.
  - Sir_Cmpwn 8y ago
    Yes, but now that version is quickly becoming stale, growing CVEs and perhaps becoming incompatible with the new upstream, with a community left in disarray that more often than not fails to support a fork.
    - toast0 8y ago
      Software goes stale all the time for many reasons. If you're not prepared to fix it or replace it yourself, you really shouldn't be using it. In my experience, a lot of the projects with large numbers of CVEs also have a rather sprawling project with lots of things that can (and should) be disabled if they don't apply to your environment; most of the CVEs will happen in parts you don't use. (That's clearly not the case for all projects, openssl is a joy to have as a critical dependency, but there are some options now)
    - chipotle_coyote 8y ago
      I don't see how a CLA materially affects this possibility, though. If my company sponsors a BSD-licensed open source project without enforcing a CLA and then decides that starting with the next major version, we're taking it closed source, the exact same thing you describe is just as likely to happen as with a CLA -- the deciding factor seems to me to be whether most of the development activity happening on the codebase is community-driven or driven by paid developers at the company. Conversely, if the community is active and doing a lot of major work already, and there are enough non-company developers with the time, interest, and skill to start and sustain a fork, they're going to do that with or without a CLA.
- sparkie 8y ago
  Changing from BSD to proprietary does not invalidate any prior BSD license on work that has been published. In such event, you can still distribute the existing source code, or fork the project in order for it to remain BSD-only.
- jerf 8y ago
  To have contributed under BSD means that you have contributed under a license that permits relicensing. To contribute under the "BSD license but secretly I'm not going to let you relicense" means that you have not in fact contributed under the BSD license in the first place, but your secret license. If you want to contribute under your secret license, what it means is that you don't want to spend any time in the first place contributed to the BSD-licensed project. Make your changes and use them, but don't contribute them back. The BSD license permits this fully, including your ability to distribute and sell the resulting software, subject to the advertising clause as appropriate. So it's not like there's anything onerous about this idea.
  - dec0dedab0de 8y ago
    "BSD license but secretly I'm not going to let you relicense" means that you have not in fact contributed under the BSD license in the first place, but your secret license. I understand what you're saying, but even if you do release BSD software along with code under a different license, you are still bound by the (very minimal) requirements of the BSD license.
- mikeash 8y ago
  That’s a bizarre idea. If you don’t want people doing things the license allows, don’t contribute under that license. If you don’t want people relicensing your code without your specific permission, then the BSD license is not the one you want, and you shouldn’t contribute to projects that use it.
  - JdeBP 8y ago
    Actually, it is you that have the bizarre idea. BSD licences do not permit people relicensing code without permission of the copyright holder. Copyright licences cannot do so. No copyright licence could do this. To do this, the actual copyright ownership has to be transferred. A copyright licence is a grant of permission by a copyright owner who retains that ownership. It is not a transfer of ownership. * http://uscode.house.gov/view.xhtml?path=/prelim@title17/chapter2&edition=prelim http://uscode.house.gov/view.xhtml?path=/prelim@title17/chap...
    - mikeash 8y ago
      You don't need ownership to relicense. You just need a license which permits relicensing, which BSD does (as long as the new license is compatible, and they usually are).
      - justincormack 8y ago
        It does not permit relicensing. You may use it in an aggregate work with other pieces that have a different license, including proprietary or GPL, but that does not mean your code is relicensed.
        mikeash 8y ago
        Is there an actual difference there, or is this just semantics?
        newacctjhro 8y ago
        You can't take the code as-is and turn it into proprietary code. You need to build a derivative work that contains the permissive code plus some other proprietary stuff.
- crdoconnor 8y ago
  >But what if somebody was changed the license from BSD to proprietary after you've contributed to the project? Would you still be happy about it then? If you signed a CLA then presumably you're either happy about it or you've just signed a contract you had literally zero understanding of. If you're more concerned about getting your fix in upstream or the kudos that comes with being a committer to "x project" then yeah, you probably wouldn't mind. I personally view Microsoft's use of CLAs as a trap that highlights just how disingenuous their "turning over a new open source leaf" was but I don't really have a problem with open source projects using them in general. The maximalist approach to open source would mean a lot of really great open source would never get written. Authors have gotta eat.
syrrim 8y ago
>not all open source is FOSS >This is not the case of all open source licenses. false. open source is literally just a friendlier name and otherwise rebranding of free software. all open source is free software and all free software is open source. if you are contributing to FOSS qua FOSS, then you want it to remain FOSS. FOSS refers to that software which guarantees your right to change it, so if you are making changes, you clearly benefit from it remaining FOSS. note further the game theoretic implications: if a minority of projects use CLAs, it is possible to avoid contributing to such projects. If people are willing to contribute to such projects, then their number might expand. Those interested in the continuation of FOSS, which should be anyone, especially those interested in software development, should therefore be interested in not signing CLAs.
- Legogris 8y ago
  > false. open source is literally just a friendlier name and otherwise rebranding of free software. This is not how anyone I have ever talked to thinks about it. You are probably confusing Free Software[0] with open source software[1]. If you still hold your point we are arguing semantics and stating that your interpretation (a minority interpretation) is right and that most of the software industry and open source community is wrong. > if you are contributing to FOSS qua FOSS, then you want it to remain FOSS Not necessarily. > note further the game theoretic implications: if a minority of projects use CLAs, it is possible to avoid contributing to such projects. If people are willing to contribute to such projects, then their number might expand. Those interested in the continuation of FOSS, which should be anyone, especially those interested in software development, should therefore be interested in not signing CLAs. You're completely right. Important factor to be aware of as a contributor for sure. [0]: https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html [1]: https://opensource.org/osd https://opensource.org/osd
  - syrrim 8y ago
    >> if you are contributing to FOSS qua FOSS, then you want it to remain FOSS >Not necessarily. Perhaps you missed the "qua FOSS"? This is latin for "because it is", in this context "contributing to FOSS because it is FOSS". the osd guarantees the relevant right for an individual to change the software. if you apreciate this right, then you should work to preserve it.
dec0dedab0de 8y ago
As they say, not all open source is FOSS... > Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors. This is not the case of all open source licenses... Wrong. FOSS = Free Open Source Software, which is really redundant, because all Open Source Software is Free Software. Open Source is essentially the marketing branch of Free Software. The Open Source Definition, and the Four Freedoms are basically the same thing. The only difference is that Open Source cares more about being practical, and Free Software is trying to save the world. EDIT: I am always surprised by the number of people on HN who seem to not understand this. I know there has been a push the last 10 years or so against copyleft, and specifically the GPL. I didn't think it extended to forgetting what these words in our industry actually mean.
- calcifer 8y ago
  > because all Open Source Software is Free Software It's exactly the opposite: All Free Software is open source, but not vice versa [1]. [1] https://www.gnu.org/philosophy/open-source-misses-the-point.en.html https://www.gnu.org/philosophy/open-source-misses-the-point....
  - dec0dedab0de 8y ago
    I guess I stand corrected. I never heard of the “Open Watcom” license before. But if it really does not allow modified copies to run locally then it is violating criteria 1, and 3 of the Open Source Definition. I am surprised the OSI approved it.
    - JdeBP 8y ago
      Here's the licence. * http://perforce.openwatcom.org:4000/@md=d&c=GxS@//depot/openwatcom/license.txt http://perforce.openwatcom.org:4000/@md=d&c=GxS@//depot/open... As you can see, it says the opposite. Per §2 you must publish your modified source if you deploy it per §1 in ways including "any and all internal use or distribution of Covered Code within Your business or organization except for R&D use and/or Personal Use". Richard Stallman dislikes the idea of being forced to publish source code when the modified application is being published internally within a business. Ironically, and rather confusingly, being required to publish source in such additional circumstances he deems "too restrictive", right after calling open source licensing "looser" than free software. (Pick one direction for the metaphor and stick with it, M. Stallman. (-:) This oddity comes about because freedom is also the freedom to not give one's software source code to other people. Whereas the Sybase licence makes it mandatory to publish modified source even when the compiled modified software is not being given to the public at large. It's not hard, furthermore, to see why terms that require giving people the source code in more circumstances remain compatible with the principles of open source.
craigsmansion 8y ago
> to go full Stallman and say that everything but GPL is evil. Can you provide a quote where he says or implies such a thing?
- dllthomas 8y ago
  If so it would be cherry-picked, as I'm pretty sure that's not his position.
  - icebraining 8y ago
    In fact, he has advocated for the use of a non-copyleft free license over the GPL, in the case of libogg.
- Legogris 8y ago
  I wasn't necessarily referring to the author here, it is more of a straw-man really. Could have worded that better.
  - dllthomas 8y ago
    I interpreted the comment above as speaking of Stallman's positions, not the author's. I still suspect that's the case, although I now see that there's ambiguity I missed on first read.
    - craigsmansion 8y ago
      I did refer to rms with "he", as I found it hard to believe rms would refer to non-GPL Free Software licenses as "evil", but the OP already admitted it was a straw-man either way.
ddevault 8y ago
Author here. Thanks for writing up your thoughts. >As they say, not all open source is FOSS This isn't true - you mean "not all open source is copyleft". >> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors. >This is not the case of all open source licenses This is also not true. You should review the open source definition: https://opensource.org/osd https://opensource.org/osd >I am all-for the FOSS movement but there is no need to go full Stallman and say that everything but GPL is evil I did not say that, nor do I believe it, nor is it really related. >When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork. This is definitely a valid position to hold, and I have signed CLAs on behalf of my employer before for this very reason. I suppose my article is targeted more at people contributing in their spare time, and to discourage maintainers from adopting a CLA in the first place.
- Legogris 8y ago
  Good points, thanks for the clarifications. > I did not say that, nor do I believe it, nor is it really related. Sorry for putting words in your mouth, but that's kind of how it came across as I read it.
  - hitekker 8y ago
    Don’t be sorry. Tone is the tinge of the subconscious.
- lmm 8y ago
  > I did not say that, nor do I believe it, nor is it really related. What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself? In both cases the project's ability to "go closed source" seems substantially the same, so it seems to me that your arguments against signing a CLA apply equally to contributing to non-GPLed software projects.
microcolonel 8y ago
The title is a literal command, it doesn't need to "imply" anything, because it is what he is telling you [not] to do.
tomxor 8y ago
>> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors. > This is not the case of all open source licenses. And that is fine. Don't assume all my work has to be part of your crusade. Indeed, I've contributed to one open source project with a CLA, it had an Apache v2 license... So It didn't really seem to make any practical difference to that license. The very short agreement basically just made it explicit that they are not responsible of a contributor submitting code they don't own copyright to - which seems a little overly defensive but fair enough as Apache doesn't explicitly protect against that. That said, I don't like the barrier CLAs impose on open source projects. Has anyone seen GPL+CLA in the wild?
- sparkie 8y ago
  Mono used to have a CLA to Novell. There were GPL and LGPL parts. It turned out to be beneficial because it enabled Xamarin (made up of mono developers) to acquire licensing rights to redistribute and relicense it after Novell dropped support for the project.
- mixedCase 8y ago
  Yes, Qt: https://www1.qt.io/contributionagreement/ https://www1.qt.io/contributionagreement/
- ATsch 8y ago
  > The very short agreement basically just made it explicit that they are not responsible of a contributor submitting code they don't own copyright to This is often times called a "DCO" — Developer Certificate of Origin. I think that is a better name for these, as the term "CLA" is very much associated with the controversial copyright reassignment/relicensing clauses.
- __david__ 8y ago
  > Has anyone seen GPL+CLA in the wild? Does FSF copyright assignment count? They do that on many of their projects (including Emacs).
jiveturkey 8y ago
Come on. It's a personal blog. It's understood to be a personal opinion. The title and message is quite fine as-is. He even concludes: "if you are contributing to open source and you want it to stay that way, you should not sign a CLA." if, if, if. I generally agree with you (!), BTW, but the author does a great job justifying the when and why of his own opinion, and I find it sound. IOW, if I want to contribute back because I don't want to maintain a private fork or spearhead a public fork, I just want to be done with it, totally fine, even by the author's opinion, which is fully qualified with the statement "and you want it to stay that way". This is reasonable and not at all forceful like Stallman. You are reacting to something that isn't written nor implied.
hoistbypetard 8y ago
> When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork. And this, regardless of how you weigh the post's other objections to a CLA, is a very good reason to sign one for many contributions.

rqs 8y ago

> the title and the tone implies that you as a contributor should be a FOSS maximalist. But what if somebody was changed the license from BSD to proprietary after you've contributed to the project? Would you still be happy about it then? I think the idea was: I have my code contributed under BSD, so you cannot re-license my code without clearance from me.

Legogris 8y ago
No, but I would be just as upset if I wouldn't have done that contribution. There is no way they can change the past - my contribution is still open source and so is the project up until the version where they introduced the license change. The version I made my contribution to is still BSD but the current upstream master might not be.
- Sir_Cmpwn 8y ago
  Yes, but now that version is quickly becoming stale, growing CVEs and perhaps becoming incompatible with the new upstream, with a community left in disarray that more often than not fails to support a fork.
  - toast0 8y ago
    Software goes stale all the time for many reasons. If you're not prepared to fix it or replace it yourself, you really shouldn't be using it. In my experience, a lot of the projects with large numbers of CVEs also have a rather sprawling project with lots of things that can (and should) be disabled if they don't apply to your environment; most of the CVEs will happen in parts you don't use. (That's clearly not the case for all projects, openssl is a joy to have as a critical dependency, but there are some options now)
  - chipotle_coyote 8y ago
    I don't see how a CLA materially affects this possibility, though. If my company sponsors a BSD-licensed open source project without enforcing a CLA and then decides that starting with the next major version, we're taking it closed source, the exact same thing you describe is just as likely to happen as with a CLA -- the deciding factor seems to me to be whether most of the development activity happening on the codebase is community-driven or driven by paid developers at the company. Conversely, if the community is active and doing a lot of major work already, and there are enough non-company developers with the time, interest, and skill to start and sustain a fork, they're going to do that with or without a CLA.
sparkie 8y ago
Changing from BSD to proprietary does not invalidate any prior BSD license on work that has been published. In such event, you can still distribute the existing source code, or fork the project in order for it to remain BSD-only.
jerf 8y ago
To have contributed under BSD means that you have contributed under a license that permits relicensing. To contribute under the "BSD license but secretly I'm not going to let you relicense" means that you have not in fact contributed under the BSD license in the first place, but your secret license. If you want to contribute under your secret license, what it means is that you don't want to spend any time in the first place contributed to the BSD-licensed project. Make your changes and use them, but don't contribute them back. The BSD license permits this fully, including your ability to distribute and sell the resulting software, subject to the advertising clause as appropriate. So it's not like there's anything onerous about this idea.
- dec0dedab0de 8y ago
  "BSD license but secretly I'm not going to let you relicense" means that you have not in fact contributed under the BSD license in the first place, but your secret license. I understand what you're saying, but even if you do release BSD software along with code under a different license, you are still bound by the (very minimal) requirements of the BSD license.
mikeash 8y ago
That’s a bizarre idea. If you don’t want people doing things the license allows, don’t contribute under that license. If you don’t want people relicensing your code without your specific permission, then the BSD license is not the one you want, and you shouldn’t contribute to projects that use it.
- JdeBP 8y ago
  Actually, it is you that have the bizarre idea. BSD licences do not permit people relicensing code without permission of the copyright holder. Copyright licences cannot do so. No copyright licence could do this. To do this, the actual copyright ownership has to be transferred. A copyright licence is a grant of permission by a copyright owner who retains that ownership. It is not a transfer of ownership. * http://uscode.house.gov/view.xhtml?path=/prelim@title17/chapter2&edition=prelim http://uscode.house.gov/view.xhtml?path=/prelim@title17/chap...
  - mikeash 8y ago
    You don't need ownership to relicense. You just need a license which permits relicensing, which BSD does (as long as the new license is compatible, and they usually are).
    - justincormack 8y ago
      It does not permit relicensing. You may use it in an aggregate work with other pieces that have a different license, including proprietary or GPL, but that does not mean your code is relicensed.
      - mikeash 8y ago
        Is there an actual difference there, or is this just semantics?
        newacctjhro 8y ago
        You can't take the code as-is and turn it into proprietary code. You need to build a derivative work that contains the permissive code plus some other proprietary stuff.
crdoconnor 8y ago
>But what if somebody was changed the license from BSD to proprietary after you've contributed to the project? Would you still be happy about it then? If you signed a CLA then presumably you're either happy about it or you've just signed a contract you had literally zero understanding of. If you're more concerned about getting your fix in upstream or the kudos that comes with being a committer to "x project" then yeah, you probably wouldn't mind. I personally view Microsoft's use of CLAs as a trap that highlights just how disingenuous their "turning over a new open source leaf" was but I don't really have a problem with open source projects using them in general. The maximalist approach to open source would mean a lot of really great open source would never get written. Authors have gotta eat.

syrrim 8y ago

>not all open source is FOSS >This is not the case of all open source licenses. false. open source is literally just a friendlier name and otherwise rebranding of free software. all open source is free software and all free software is open source. if you are contributing to FOSS qua FOSS, then you want it to remain FOSS. FOSS refers to that software which guarantees your right to change it, so if you are making changes, you clearly benefit from it remaining FOSS. note further the game theoretic implications: if a minority of projects use CLAs, it is possible to avoid contributing to such projects. If people are willing to contribute to such projects, then their number might expand. Those interested in the continuation of FOSS, which should be anyone, especially those interested in software development, should therefore be interested in not signing CLAs.

Legogris 8y ago
> false. open source is literally just a friendlier name and otherwise rebranding of free software. This is not how anyone I have ever talked to thinks about it. You are probably confusing Free Software[0] with open source software[1]. If you still hold your point we are arguing semantics and stating that your interpretation (a minority interpretation) is right and that most of the software industry and open source community is wrong. > if you are contributing to FOSS qua FOSS, then you want it to remain FOSS Not necessarily. > note further the game theoretic implications: if a minority of projects use CLAs, it is possible to avoid contributing to such projects. If people are willing to contribute to such projects, then their number might expand. Those interested in the continuation of FOSS, which should be anyone, especially those interested in software development, should therefore be interested in not signing CLAs. You're completely right. Important factor to be aware of as a contributor for sure. [0]: https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html [1]: https://opensource.org/osd https://opensource.org/osd
- syrrim 8y ago
  >> if you are contributing to FOSS qua FOSS, then you want it to remain FOSS >Not necessarily. Perhaps you missed the "qua FOSS"? This is latin for "because it is", in this context "contributing to FOSS because it is FOSS". the osd guarantees the relevant right for an individual to change the software. if you apreciate this right, then you should work to preserve it.

dec0dedab0de 8y ago

As they say, not all open source is FOSS... > Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors. This is not the case of all open source licenses... Wrong. FOSS = Free Open Source Software, which is really redundant, because all Open Source Software is Free Software. Open Source is essentially the marketing branch of Free Software. The Open Source Definition, and the Four Freedoms are basically the same thing. The only difference is that Open Source cares more about being practical, and Free Software is trying to save the world. EDIT: I am always surprised by the number of people on HN who seem to not understand this. I know there has been a push the last 10 years or so against copyleft, and specifically the GPL. I didn't think it extended to forgetting what these words in our industry actually mean.

calcifer 8y ago
> because all Open Source Software is Free Software It's exactly the opposite: All Free Software is open source, but not vice versa [1]. [1] https://www.gnu.org/philosophy/open-source-misses-the-point.en.html https://www.gnu.org/philosophy/open-source-misses-the-point....
- dec0dedab0de 8y ago
  I guess I stand corrected. I never heard of the “Open Watcom” license before. But if it really does not allow modified copies to run locally then it is violating criteria 1, and 3 of the Open Source Definition. I am surprised the OSI approved it.
  - JdeBP 8y ago
    Here's the licence. * http://perforce.openwatcom.org:4000/@md=d&c=GxS@//depot/openwatcom/license.txt http://perforce.openwatcom.org:4000/@md=d&c=GxS@//depot/open... As you can see, it says the opposite. Per §2 you must publish your modified source if you deploy it per §1 in ways including "any and all internal use or distribution of Covered Code within Your business or organization except for R&D use and/or Personal Use". Richard Stallman dislikes the idea of being forced to publish source code when the modified application is being published internally within a business. Ironically, and rather confusingly, being required to publish source in such additional circumstances he deems "too restrictive", right after calling open source licensing "looser" than free software. (Pick one direction for the metaphor and stick with it, M. Stallman. (-:) This oddity comes about because freedom is also the freedom to not give one's software source code to other people. Whereas the Sybase licence makes it mandatory to publish modified source even when the compiled modified software is not being given to the public at large. It's not hard, furthermore, to see why terms that require giving people the source code in more circumstances remain compatible with the principles of open source.

craigsmansion 8y ago

> to go full Stallman and say that everything but GPL is evil. Can you provide a quote where he says or implies such a thing?

dllthomas 8y ago
If so it would be cherry-picked, as I'm pretty sure that's not his position.
- icebraining 8y ago
  In fact, he has advocated for the use of a non-copyleft free license over the GPL, in the case of libogg.
Legogris 8y ago
I wasn't necessarily referring to the author here, it is more of a straw-man really. Could have worded that better.
- dllthomas 8y ago
  I interpreted the comment above as speaking of Stallman's positions, not the author's. I still suspect that's the case, although I now see that there's ambiguity I missed on first read.
  - craigsmansion 8y ago
    I did refer to rms with "he", as I found it hard to believe rms would refer to non-GPL Free Software licenses as "evil", but the OP already admitted it was a straw-man either way.

ddevault 8y ago

Author here. Thanks for writing up your thoughts. >As they say, not all open source is FOSS This isn't true - you mean "not all open source is copyleft". >> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors. >This is not the case of all open source licenses This is also not true. You should review the open source definition: https://opensource.org/osd https://opensource.org/osd >I am all-for the FOSS movement but there is no need to go full Stallman and say that everything but GPL is evil I did not say that, nor do I believe it, nor is it really related. >When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork. This is definitely a valid position to hold, and I have signed CLAs on behalf of my employer before for this very reason. I suppose my article is targeted more at people contributing in their spare time, and to discourage maintainers from adopting a CLA in the first place.

Legogris 8y ago
Good points, thanks for the clarifications. > I did not say that, nor do I believe it, nor is it really related. Sorry for putting words in your mouth, but that's kind of how it came across as I read it.
- hitekker 8y ago
  Don’t be sorry. Tone is the tinge of the subconscious.
lmm 8y ago
> I did not say that, nor do I believe it, nor is it really related. What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself? In both cases the project's ability to "go closed source" seems substantially the same, so it seems to me that your arguments against signing a CLA apply equally to contributing to non-GPLed software projects.

microcolonel 8y ago

The title is a literal command, it doesn't need to "imply" anything, because it is what he is telling you [not] to do.

tomxor 8y ago

>> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors. > This is not the case of all open source licenses. And that is fine. Don't assume all my work has to be part of your crusade. Indeed, I've contributed to one open source project with a CLA, it had an Apache v2 license... So It didn't really seem to make any practical difference to that license. The very short agreement basically just made it explicit that they are not responsible of a contributor submitting code they don't own copyright to - which seems a little overly defensive but fair enough as Apache doesn't explicitly protect against that. That said, I don't like the barrier CLAs impose on open source projects. Has anyone seen GPL+CLA in the wild?

sparkie 8y ago
Mono used to have a CLA to Novell. There were GPL and LGPL parts. It turned out to be beneficial because it enabled Xamarin (made up of mono developers) to acquire licensing rights to redistribute and relicense it after Novell dropped support for the project.
mixedCase 8y ago
Yes, Qt: https://www1.qt.io/contributionagreement/ https://www1.qt.io/contributionagreement/
ATsch 8y ago
> The very short agreement basically just made it explicit that they are not responsible of a contributor submitting code they don't own copyright to This is often times called a "DCO" — Developer Certificate of Origin. I think that is a better name for these, as the term "CLA" is very much associated with the controversial copyright reassignment/relicensing clauses.
__david__ 8y ago
> Has anyone seen GPL+CLA in the wild? Does FSF copyright assignment count? They do that on many of their projects (including Emacs).

jiveturkey 8y ago

Come on. It's a personal blog. It's understood to be a personal opinion. The title and message is quite fine as-is. He even concludes: "if you are contributing to open source and you want it to stay that way, you should not sign a CLA." if, if, if. I generally agree with you (!), BTW, but the author does a great job justifying the when and why of his own opinion, and I find it sound. IOW, if I want to contribute back because I don't want to maintain a private fork or spearhead a public fork, I just want to be done with it, totally fine, even by the author's opinion, which is fully qualified with the statement "and you want it to stay that way". This is reasonable and not at all forceful like Stallman. You are reacting to something that isn't written nor implied.

hoistbypetard 8y ago

> When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork. And this, regardless of how you weigh the post's other objections to a CLA, is a very good reason to sign one for many contributions.