

Is BSD the new GPL? - okal
http://zedshaw.com/essays/is_bsd_the_new_gpl.html

======
zdw
Fundamentally, understand the goals of a license before you pick it.

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:

<http://openssh.org/>

 _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).

~~~
nupark2
I think this is a fundamental misinterpretation of their position.

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.

~~~
click170
I think the op's point was that the perception of 'GPLers forking BSD licensed
code as being bad' is the fundamental misunderstanding of some people using
the BSD license.

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.

~~~
nupark2
_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.

------
adbge
I used to very much prefer BSD-style licenses on the grounds that freedom
means you're free to create a proprietary derivative. I assumed that a company
would rather contribute to a BSD'd project than a GPL'd project on these
grounds.

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.

~~~
icebraining
Well, that's the basis for most dual-licensed projects. For example, the MySQL
AB people used to say "If you're free, we're free, if you're proprietary,
we're commercial". I think Qt uses a similar mindset.

~~~
zokier
Qt pre-Nokia was GPL/proprietary dual-licensed. Re-licensing it as LGPL (and
thus allowing proprietary projects to link to it) was one of the first reforms
Nokia made.

------
zokier
On an unrelated note: here we are seeing the damage that url shorteners do.
The tr.im URLs in Zeds tweet are unavailable, even though the content probably
is still up. And there is no way for the reader to find out where the links
were pointing.

~~~
sixcorners
<http://urlte.am/>

------
arto
Some of the confusion here arises from not clearly differentiating between
legal and moral obligations. It's perfectly reasonable to ensure that the
legal strings attached to a piece of software are as few as possible
(BSD/MIT/ISC, the Unlicense, or the WTFPL), but still encourage the community
to hold themselves to higher moral standards regarding e.g. attribution and
contributing back to a project.

~~~
dwc
This is exactly correct. It is usual in other areas such as constitutional law
for organizations and groups to devote themselves to either legal xor moral
obligations. The US's ACLU seldom condemns the reprehensible acts of some of
its clients, for instance. Rather they limit themselves to furthering the rule
of law in general. But the BSD communities tend to be small and take on both
roles, for if they didn't there would be nobody else to do it. I do not think
major players in major BSD licensed projects are confusing these issues, but
onlookers and others often times do.

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.

------
huxley
FYI, this article is about 2.5 years old.

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.

------
skrebbel
Great article. It made me realize that BSD-licensing really does mean "others
can do next to _anything_ with your code". So they can sell it (yeah ok, I
knew about that one already). But they can also put it into a GPL project. Or
mix it with tabasco and blueberry jam.

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.

------
tzury
In my ladder, Public Domain is at the top, and proprietary is at the bottom,
all others are just in between, varies in some parts, identical in others.

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.

~~~
tikhonj
The usual argument is that the GPL encourages others to contribute back to the
free software ecosystem. If you write something cool and unique and release it
under the GPL, anybody who builds stuff off it will have to release their code
as well, leading to more code for everybody.

------
WayneDB
You are truly free according to the license and the law. That fact has nothing
to do with how people will treat you if you choose a decidedly less free
license like GPL.

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!

~~~
abrahamsen
He seems to be complaining about a double standard.

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.

------
codeslinger
IANAL, but: It would appear to me that the author doesn't understand the GPL
very well. If my code is BSD licensed and yours is GPL, I can submit pieces of
my code to your project but if I take pieces of your code into my project, my
project is now subject to the virality properties of the GPL and itself
becomes essentially licensed under GPL. This is where the author seems
confused: if I subsume GPL code into a BSD-licensed project, my project
_becomes_ licensed under GPL. Given that I chose the BSD license for my
project I'm assuming it would now be obvious to the OP why this might be
onerous.

~~~
rst
Zed starts with two tweets that make exactly that point. He understands
perfectly. You misunderstand _his_ point:

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.

~~~
nupark2
Proprietary forks are always able to submit pieces of their code back to the
originating BSD project. That's fine -- proprietary developers never claimed
to be anything other than what they are, and if they eventually submit
_something_ back, that's nice.

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.

~~~
zdw
The GPL is fundamentally a protection against companies distributing private
modified forks. It wasn't created to give BSD code creators a bad day -
basically what you're describing is collateral damage. I think most reasonable
non-zealot OSS developers totally understand where you're coming from.

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.

~~~
nupark2
> _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._

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.

