Dear discussion readers,
Today I stumbled on an argument for the use of the BSD-license, as hosted on the FreeBSD website, originating from 2013. [1]
[1] https://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html
Apart from accusing the GPL of intentionally keeping software "at the research and development stages", the argument is made to avoid helping competitors and to avoid license issues when developing.
I'd rather like to turn both these arguments around in that you get an inherent benefit from having competitors contribute to the equal playing field of free software as its value increases in relation to the non-free alternatives. Regarding the licenses it seems that for any large software project license considerations are real and hardly unavoidable.
As has been stated by the FSF many times over, there are cases where the GPL might not be the right license, and even copyleft might be undesirable. [2] The only indirect approval of the BSD license I have found was in that software licenses should adhere to current licensing practices in related projects.
[2] https://www.gnu.org/licenses/license-recommendations.html
Do you consider that there are still valid arguments to be made for the use of the BSD license in software projects other than license compatibility with existing projects?
I'm keen to hear from you.
Kind regards, Nico Rikken
Hi Nico,
Le dimanche 12 juillet 2015, 12:04:32 Nico Rikken a écrit :
Dear discussion readers,
Today I stumbled on an argument for the use of the BSD-license, as hosted on the FreeBSD website, originating from 2013. [1]
[1] https://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html
The article seems to make essentially three arguments:
The first 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.)
The second is that if a group of developers want to impose a software standard and see it become ubiquitous, the BSD license (or a similar license), which allows proprietary software companies and developers to use the code might be more efficient than the GPL license in spreading and imposing the standard.
The third is that if a free software project is abandoned by its developers and no new developers want to take on the project, a BSD license allows a proprietary software company to take on the project. This allows new versions of the software to remain available, even if they're no longer free.
The article also makes the point that the GPL license might not stand up in the courts (at least in some countries), but this doesn't seem to me to be much of an argument, more of an observation made in passing.
As has been stated by the FSF many times over, there are cases where the GPL might not be the right license, and even copyleft might be undesirable. [2]
To my knowledge, the FSF has only ever stated three reasons why copyleft might not be desirable:
1) For very short programs, where a simpler and much shorter license might be more appropriate from a practical point of view. The FSF web site gives a very short and simple license for such purposes.
2) When extending free software that already exists, to avoid using a license different from that used by the original developers.
3) As a more or less short term tactic, as a way of making free software more well known and better appreciated when it was not. For such cases, the LGPL was developed.
Do you consider that there are still valid arguments to be made for the use of the BSD license in software projects other than license compatibility with existing projects?
For software projects that have no desire to become proprietary in the future, I think the 3 reasons stated by the FSF cover most of the bases. It's possible there might be a very few exceptions where a BSD license might be a better choice than the GPL for such a project, such as in promoting a new software norm or standard. This would seem to be more of a short term tactic than a long term strategy, however.
Thanks J.B. and Darryl,
Thanks for the clear expositions, which confirm my thoughts.
As this statement was posted on the FreeBSD website, I'm assume mainly the 2-clause license is ment throughout the article, as is brought up in the 4th section. Although this is not clearly stated.
Considering the three reasons Darryl summarized, I can see the benefit for any of the BSD-licenses by adhering to the current licensing practice of a project (2), or if it might be required for adoption (3).
Even then the Apache license at least prevents royalty issues, whilst not providing copyleft. And I would assume preventing patent lawsuits will certainly help adoption, making the case for the Apache license.
Kind regards, Nico Rikken
Nico Rikken wrote:
Thanks J.B. and Darryl,
Thanks for the clear expositions, which confirm my thoughts.
You're welcome. If you're looking for more confirmation on how non-copyleft free licenses can be a ruse where derivatives take your freedoms away (even while non-copyleft free license advocates claim such licenses maximize freedom for all), check out today's clarification of Canonical's language about redistributing binaries in Ubuntu GNU/Linux.
As Matthew Garrett wrote in his blog[1], the Ubuntu Community Manager confirmed "that any binaries shipped by Ubuntu under licenses that don't grant an explicit right to redistribute the binaries can't be redistributed without permission or rebuilding" despite that Canonical's assertion is in clear violation of both GPLv2 and GPLv3 but probably not, as Brad Kuhn points out in his blog, non-copyleft free licenses[2], hence the concern about what that means for users of those programs.
Two years later, and with much effort by two non-profit groups (the Free Software Foundation[3] and the Software Freedom Conservancy[4]), Canonical has added a "trump clause" to its license terms which makes it clear that nothing found in Ubuntu's license modifies or reduces rights under each program's license.
Kuhn spells out the case against non-copyleft free licenses quite clearly[2]:
This whole situation seems to me a simple argument for why copyleft matters. Copyleft can and does (when someone like me actually enforces it) prevent these types of situations. But copyleft is not infinitely expansive. Nearly every full operating system distribution available includes a aggregated mix of copylefted, non-copyleft, and often fully-proprietary userspace applications. Nearly every company that distributes them wraps the whole thing with some agreement that restricts some rights that copyleft defends, and then adds a trump clause that gives an exception just for FLOSS license compliance. I have never seen a trump clause that guarantees copyleft-like compliance for non-copylefted programs and packages. Thus, the problem with Ubuntu is just a particularly bad example of what has become a standard industry practice by nearly every “open source” company.
This, as Kuhn rightly points out, is yet another practical instance of how software freedom differs from the inadequacy (when viewed from a user's perspective) of being "open source". You'll note that neither of the two groups working with Canonical on this bill themselves as "open source" organizations, even though both work with open source advocates. It's a defense of software freedom that motivates these organizations to push Canonical into GPL compliance.
[1] https://mjg59.dreamwidth.org/35969.html [2] http://ebb.org/bkuhn/blog/2015/07/15/ubuntu-ip-policy.html [3] https://www.fsf.org/news/canonical-updated-licensing-terms [4] https://sfconservancy.org/news/2015/jul/15/ubuntu-ip-policy/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 13/07/15 00:39, Darryl Plank wrote:
Hi Nico,
Le dimanche 12 juillet 2015, 12:04:32 Nico Rikken a écrit :
Dear discussion readers,
Today I stumbled on an argument for the use of the BSD-license, as hosted on the FreeBSD website, originating from 2013. [1]
[1] https://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html
The article seems to make essentially three arguments:
The first 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. Whether the entity is a non-profit structure or a company with shareholders becomes an interesting topic.
The second is that if a group of developers want to impose a software standard and see it become ubiquitous, the BSD license (or a similar license), which allows proprietary software companies and developers to use the code might be more efficient than the GPL license in spreading and imposing the standard.
This has worked will with reSIProcate, the VOCAL license is BSD-like.
Somebody can still make an application that is GPL licensed and uses reSIProcate as a library.
The third is that if a free software project is abandoned by its developers and no new developers want to take on the project, a BSD license allows a proprietary software company to take on the project. This allows new versions of the software to remain available, even if they're no longer free.
GPL also allows proprietary software companies to take on a project that has been abandoned. The vendor just has to make sure they observe the terms of the GPL.
Daniel Pocock daniel@pocock.pro 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 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.
GPL also allows proprietary software companies to take on a project that has been abandoned. The vendor just has to make sure they observe the terms of the GPL.
Thanks for clarifying that.
On 13/07/15 11:01, Ben Finney wrote:
Daniel Pocock daniel@pocock.pro 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.
* Darryl Plank darryl@darrylplank.com [2015-07-13 00:39:24 +0200]:
To my knowledge, the FSF has only ever stated three reasons why copyleft might not be desirable:
- For very short programs, where a simpler and much shorter license might
be more appropriate from a practical point of view. The FSF web site gives a very short and simple license for such purposes.
- When extending free software that already exists, to avoid using a license
different from that used by the original developers.
- As a more or less short term tactic, as a way of making free software more
well known and better appreciated when it was not. For such cases, the LGPL was developed.
I would add
4) If you want to push a standard (e.g. with Ogg Vorbis).
Regards, Matthias