Is BSD the new GPL?
zedshaw.com
zedshaw.com
Sometimes people pick a license, and are unhappy when they don't get the results they want - for example, there's this paragraph at the bottom of the BSD licensed OpenSSH page:
Please take note of our Who uses it page, which list just some of the vendors who incorporate OpenSSH into their own products -- as a critically important security / access feature -- instead of writing their own SSH implementation or purchasing one from another vendor. This list specifically includes companies like Cisco, Juniper, Apple, Red Hat, and Novell; but probably includes almost all router, switch or unix-like operating system vendors. In the 10 years since the inception of the OpenSSH project, these companies have contributed not even a dime of thanks in support of the OpenSSH project (despite numerous requests).
(not that I think that the OpenBSD project ever expected renumeration, but imagine if you had a project that was as successful as OpenSSH and nobody ever flipped you a dime).
OpenBSD can both complain about lack of contributions AND still believe that the BSD license is most amenable to their goals.
If I put a bowl of candy out at my restaurant, I will probably complain about a customer that takes all the candy in the bowl. However, I will still leave the candy out, and there's no fundamental incompatibility between my complaint and my choice to make the candy available.
I would reserve special invective for a customer that took the entire candy bowl and then -- claiming to be a liberator -- passed it out on the street outside my restaurant alongside a coupon for their own restaurant.
In my mind, the first example (takes all the candy) is the example of a commercial organization that doesn't give anything back. It's unfortunate, but it's the cost of doing business, and their decision doesn't directly negatively impact me (other than losing some cheap candy).
The second example ("liberates" the candy and then uses it in a way that causes direct material damages to my restaurant's business) is how GPLers that fork BSD licensed code are perceived.
If they want contributions back, they are welcome to add a clause to the BSD license or use the GPL (or write their own), but they choose the BSD license in its current form and then get upset when someone stays within compliance of the license while doing something they don't like.
The costs inherent in legally enforcing positive social behavior are exactly why BSD authors don't choose the GPL to begin with, and instead attempt to achieve their goals through social rather than legal means.
Objecting to GPLers re-licensing their forks of BSD projects is part of that social mechanism, and is entirely consistent with the choice of license.
Something like a work of art might be better. Let's say you sculpt a statue, and you allow anybody to view it for free, including the right to take pictures of it for free. You have an optional donation box next to the statue, but nothing mandatory.
Now, someone takes a picture of it, retouches it photo-editing software, and then sells that photo to millions of people and makes billions of dollars off of it.
Is it a 'cost of doing business'? No, because the cost had already been assumed by the time you'd decided to license the statue the way you did. Is it illegal? Of course not, because that's how you licensed it. Are you worse off for it? No, because you lost nothing - viewing the statue is not a rival good.
When viewed in this light, it certainly seems like a rather rude thing to do, but the artist knew that this was a risk when licensing his/her statue in that way.
It recently occurred to me, though, that some companies may prefer to contribute to GPL'd projects over BSD'd ones. When Red Hat contributes to the Linux kernel, they know that their competitors will not be able to create a derivative without also releasing it under the GPL. Red Hat's competitors can't create proprietary derivatives that would compete with Red Hat so, in essence, it's safer for a company to contribute to a GPL'd project than a BSD'd project.
This is a really interesting and non-obvious property of the GPL that I never see mentioned.
If someone contributes to your GPLed project, then you cannot 'make propriatary' that contribution, unless they assign copyright to you./
The position seems clear: 1) You can use BSD licensed software as per the generous license, and 2) FOSS developers should facilitate sharing code, including sharing reciprocally with other FOSS developers. No violation of item 2 will interfere with item 1.
By far the largest part of the past kerfuffle between OpenBSD and Linux developers had to do with violating the BSD license. This isn't easy to do, as there's not a whole lot to violate. I believe the violations were simple mistakes, due to ignorance/unfamiliarity. They were rectified after a time.
Zed Shaw has in the interim released some projects under a BSD license (like Mongrel2) while other projects like Lamson (I believe) are licensed under GPLv3.
If you don't want that anyone can do anything with your code, anything (as long as they keep the sticker that it came with), don't use the BSD license.
I do not see how SQLite could have done any better with any other license for instance.
If someone on this earth is low enough to remove credits from code, or even worse, ship it under own name, there is nothing to prevent him/her from doing so, not even lawyers GNU will never hire to to sue this cracker.
Honestly, this is like complaining that people got upset at you for bringing a crying child into a restaurant, despite the fact that it's perfectly legal!
Some people (proprietary software) are applauded for bringing crying children into the restaurant, while others (copyleft software) are criticized for the same act, to use your (weird) analogy.
I think his intention was for BSD licensors to accept that as an inherent "danger" of their chosen licence. Like he pointed out, you wouldn't be able to use proprietary code from Google or Apple simply because it incorporates your BSD licensed code, so why should it be a problem when the aggressor - in a manner of speaking - is using a copyleft license?
He's releasing Lamson under GPL, so the Django folks can't use it. But if he was releasing Lamson under a proprietary license, they couldn't even look at it. The GPL leaves them better off. But while BSD projects generally don't complain about proprietary forks, some of them whine bitterly about the GPL (which, again, leaves them better off).
Choosing the BSD license for your code is, in effect, choosing to allow others to rerelease under more restrictive terms. If you made that choice, I'm not sure it makes a whole lot of sense to complain when people do that.
GPL developers claim to be open, but then take the originating code and place it under onerous "open" terms. This triggers the classic "hypocrite" response: they claim to be open, but they're actually attaching a viral license to my work. Any improvements they make can NEVER be sent back to us without all the contributors agreeing to license under the BSD license.
In real terms, the GPL fork is a dead-end one for a BSD licensed project. The commercial fork is, actually, not -- the company is quite able to push back changes at any time.
No contributions will ever result from the GPL fork, and given that the BSD license provides a superset of the freedoms of the GPL license, it's clear that the GPLers are only licensing under the GPL to enforce their own politics on the BSD licensed code.
An interesting twist would be a BSD style license that states that if the code is incorporated into a GPL style licensed project, patches to your specific code subset must also be BSD licensed. Kind of like incorporating a LGPL library into a commercial product.
I've used mixed licenses to achieve this in the past. The individual source files remain BSD licensed. The whole work, in aggregate, is GPL licensed.
It only works if the dependencies are one-way, though, and you keep the BSD code fairly isolated.
So are the authors of the GPL project.
> Any improvements they make can NEVER be sent back to us without all the contributors agreeing to license under the BSD license.
You have a very poor understanding of the GPL and copyright law. I'm afraid you've been infected by the "viral" meme.
BSD-licensed code that is incorporated into a larger GPL project is still under the BSD license, even though the larger assemblage may be viewed as being under the GPL. Any improvements made to your code may be licensed under the BSD by the people making the improvements if they so choose.
There may come a point where the code has changed so substantially that GPL'd and BSD'd portions are inseparable, but at that point, what good is their code to you, anyway?
Oh, I'm sorry, did you just want to take all their work and use it under whatever terms you like? Odd, then, that you don't want to give them the same freedom...
If the code they add is under the GPL, and the aggregate is the GPL, then the only new code retrievable from that project that is GPL code.
> Oh, I'm sorry, did you just want to take all their work and use it under whatever terms you like? Odd, then, that you don't want to give them the same freedom...
It seems like GPL advocates are so focused on the legal enforcement of ideals that there's a systemic failure to recognize the underlying nuanced social contracts.
Re-licensing forked BSD code under the GPL to make it "more open" is simply spiteful -- and is the linchpin of the BSD developers' objections.
The GPL fork will continue to integrate improvements to the BSD code base, and possibly siphon off open-source interest in the project to their fork, but the GPL licensed code will never move in the reverse.
Which is as it should be. You gave them the right to use your code as part of a larger, differently-licensed work. You claim it is because you want people to have freedom. But now you want to beat up on them for exercising that freedom.
> It seems like GPL advocates are so focused on the legal enforcement of ideals that there's a systemic failure to recognize the underlying nuanced social contracts.
Claiming unwritten social contracts should guide behavior is asking to be disappointed. Not everyone will have the same view of what those contracts are. I certainly don't share your views on the subject. What, objectively, makes you right and me wrong?
> Re-licensing forked BSD code under the GPL to make it "more open" is simply spiteful
Please provide some examples of GPL projects claiming that they have made BSD code "more open".
This nuance is why the BSD license relies on social contracts. Attempting to codify the OSS social contract as license would result in something rather like the GPL, and is at the core of why we disagree.
This is a fundamental disagreement of principles, not a disagreement about proper enforcement mechanisms. You and I have utterly different views of what the "OSS social contract" is even about, much less says.
It's not a double standard. The purpose of the BSD license to encourage widespread adoption which will hopefully lead to widespread contribution, under the assumption that the best way to encourage adoption and contribution is to not enforce it.
If a commercial vendor uses BSD licensed code for a proprietary product, they can and do still donate code back. If they fail to do so immediately, they might do so in the future -- this often occurs as vendors build larger systems on top of a BSD licensed code base.
The GPL, however, is purpose-built to break the social mechanisms by which BSD licensed code propagates by implementing an irreversibly viral one-way licensing OSS ecosystem. RMS has stated repeatedly that he won't be happy until all software is GPL and it's simply not possible to compete with GPL software due to the network effects of large, interconnected GPL-only software stack.
Finally, legal codification of behavior often has large unintended consequences. Choosing to use social pressure to discourage certain uses of your software while not legally forbidding it does not create a double standard.
Social contracts are, by their very nature, a reflection of some sort of societal consensus. The societal consensus is not in (full) agreement with you on this matter.
You could advocate your views of what the social contract should be, that's OK, too, but claiming that your minority views are the social contract and that everybody else has to follow them or be somehow "wrong" is, at best, disingenuous.
In his article, Zed actually said "we're both on the same damn side". However -- barring the use of open hardware reference information across OSS implementations -- that's not really the case.
The GPL and BSD licenses are competitive memes, and the ultimate success of the GPL (as per the FSF's goals) would be at the expense of the BSD and proprietary licenses.
While I periodically hear whining from some people, particularly the OpenBSD crowd, about other open-source projects using their code, I've seen no evidence of it constituting "the BSD viewpoint".
By the way, the only significant open source software I ever released was under the BSD license. I chose BSD because it made the most sense for what I was trying to accomplish, and specifically did not want to prevent anyone from using the code in any way they saw fit. It would never occur to me to whine about somebody doing just that.
GPL is not about openness to everybody. GPL is not about maximizing contributions.
GPL is all about end-users' freedom, even over developers' freedom where those two collide (i.e. developer can't have freedom to take freedom away from users).
GPL is about preventing software becoming non-free and deliberately not helping those which want to have ability to control what users can and cannot do, like add DRM, unremovable crapware, etc.
GPL is deliberately open only to those who prioritize end-users' (not developers'!) freedom over everything else.
I understand the GPL. However, compared to the alternatives, I don't believe the GPL/FSF are optimally beneficial to my interests, the interests of consumers, or the interests of corporations.