On 13/07/15 11:01, Ben Finney wrote: > Daniel Pocock <[email protected]> writes: > >> On 13/07/15 00:39, Darryl Plank wrote: >>> The first [argument from the article] is that if a group of >>> developers think they might later wish to make a proprietary version >>> of their software, the BSD license will allow them to do so without >>> facing legal obstacles while the GPL license can sometimes impose >>> such obstacles. (The main problem with making a proprietary for >>> theGPL license is when one or more contributors disagrees to such a >>> move.) >> >> However, choosing the BSD license is not the only way out of this >> problem. An alternative is to set up some entity to own the >> intellectual property and all the developers then sign a CLA giving >> the entity the right to decide on licensing changes in the future. > > Yes. An argument against CLAs is precisely that it sends a strong signal > to potential contributors: this organisation exerts significant effort > to, at some unknown future time, take your contributions and make them > proprietary. >
That is an exaggeration. There are good CLAs and bad CLAs. A bad CLA is basically an employment contract without a salary. You make some contribution and you give up all rights and you get nothing in return (except the hope the project remains open source). A better CLA may put the intellectual property in the hands of a non-profit with a suitably democratic committee and maybe a strongly worded constitution setting limits on just how far the committee can go. > That makes it another reason for the GPL, in my view. Choosing the GPL > (or some other strong copyleft) sends a clear signal that the > organisation actively intends to *always* have the software freely > licensed to all recipients. That signal will encourage contributors who > want to promote software freedom. > I agree there are cases where this is the simpler or more desirable approach. Choosing a license is a strategic decision that should not be made without also considering other issues like a CLA. _______________________________________________ Discussion mailing list [email protected] https://mail.fsfeurope.org/mailman/listinfo/discussion
