It's not uncommon to see BSD developers upset that someone takes their project, does a few modifications, and then releases the resulting work under GPL, such that the resulting improvements can no longer be incorporated back upstream BSD, creating a one-way street.

From undeadly.org:

KernelTrap has an interesting article in which Theo de Raadt discusses the legal implications of the recent relicensing of OpenBSD's BSD licensed Atheros driver under the GPL. De Raadt says, "it has been like pulling teeth since (most) Linux wireless guys and the SFLC do not wish to admit fault. I think that the Linux wireless guys should really think hard about this problem, how they look, and the legal risks they place upon the future of their source code bodies." He stressed that the theory that BSD code can simply be relicensed to the GPL without making significant changes to the code is false, adding, "'in their zeal to get the code under their own license, some of these Linux wireless developers have broken copyright law repeatedly. But to even get to the point where they broke copyright law, they had to bypass a whole series of ethical considerations too."

I've recently noticed that the licence under which SSLeay was released, on which OpenSSL is based, on which LibreSSL is based, has the following addendum after what looks like a standard original 4-clause BSD licence with the advertising clause (which, I must add, is already incompatible with the GPL due to the presence of the aforementioned advertising clause).

From bxr.su:

 * The licence and distribution terms for any publically available version or
 * derivative of this code cannot be changed.  i.e. this code cannot simply be
 * copied and put under another distribution licence
 * [including the GNU Public Licence.]

To avoid the problem at its root:

  • Why don't the BSD developers add back the advertising clause, to make sure that their licence is incompatible with the GPL Public Licence without saying so explicitly?

  • Or, alternatively or additionally, why don't they add an addendum as above to their own BSD/ISC/MIT/etc BSD-compatible licence?

  • 1
    Just standard inconsistency. The license explicitly allows it; if they don't like that, choose another one. – vonbrand Oct 27 '15 at 18:27
  • 3
    Part of the annoyance I have observed is related to the fact that there is inconsistency on the other side of the interaction. When someone claims that a more-restrictive license should be used to guarantee that changes are shared with the original project, but that very license prevents sharing changes with a project from which it borrows code, the people work on the project from which it borrowed code may become annoyed with the apparent hypocrisy of advocates for the more-restrictive license who preach to them about license choice for purposes of code sharing then refuse to share code. – apotheon Nov 9 '15 at 18:03

The 4 clause BSD license is not OpenSource compliant as it contains two contradicting claims:

  • All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors.

  • Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

So it requires advertizing and forbids it at the same time.

But there is no need to add a clause like the one from SSL either as the BSD license does not permit to relicense the code.

The reason why you cannot relicense BSD code is that this is something that would need an explicit written permission from the Copyright owner that is obviously not part of the BSD license.

Legally, there are two options with vanilla BSD licensed code:

  • keep the actual source private.

  • publish the actual source under the original terms and conditions.

BTW: as a result from the letter from Theo de Raadt, the linux kernel sources have been modified to contain additional GPL headers only for those files where the original author did enter the code into the Linux kernel project and thus has the right to do so.

  • Comments are not for extended discussion; this conversation has been moved to chat. – ArtOfCode Oct 22 '15 at 13:11
  • 2
    Can you provide a source for your definition of endorse or promote ? In normal english, an endorsement would be similar to "The University of California thinks that FoorBar by Acme, Inc is good software". This is a far stronger statement than "Some of the code in Foobar was written by the University of California`" – MSalters Nov 9 '15 at 10:31

Because adding that phrase turns the license into a viral copyleft license not unlike the GPL. When you add that phrase, you could just as well use the GPL.

Those who propose the BSD over the GPL usually do so because they intentionally want to avoid the viral nature of the GPL and instead want their work to be usable by anyone under any license. The resulting one-way relicensing road is an unfortunate drawback of this, but one which can not be avoided.

You can't have the cake and eat it.

  • Well, usable by anyone under any licence except the GPL, or at least sometimes it so appears. – MadHatter Oct 23 '15 at 18:57
  • 2
    The "copyleft" as defined by the FSF has a requirement that source code always be provided; here, SSLeay licence has no such requirement, so, the comparison with GPL doesn't fit. Also, as evidenced by the OpenSSL library itself, its combined licence is still more accepted by the Linux-averse corporations than the GPL is. Moreover, unlike GPL, SSLeay does not preclude work licensed under the SSLeay licence to be incorporated into larger work licensed under other licences, as is evidenced by the OpenSSL library itself, which is additionally licensed by an extra licence. – cnst Oct 30 '15 at 9:56

There are a couple of problems with the advertisement clause — the most obvious one can be witnessed firsthand at http://BXR.SU/NetBSD/distrib/notes/common/legal.common:

This product includes software developed by Charles Hannum.
This product includes software developed by Charles M. Hannum, by the
University of Vermont and State Agricultural College and Garrett A.
Wollman, by William F. Jolitz, and by the University of California,
Berkeley, Lawrence Berkeley Laboratory, and its contributors.
This product includes software developed by Charles M. Hannum.
This product includes software developed by Christian E. Hopps,
Ezra Story, Kari Mettinen, Markus Wild, Lutz Vieweg
and Michael Teske.
This product includes software developed by Christian E. Hopps.
This product includes software developed by Christopher G. Demetriou
for the NetBSD Project.
This product includes software developed by Christopher G. Demetriou.
This product includes software developed by Christos Zoulas.
This product includes software developed by Chuck Silvers.

And that only covers Ch! And doesn't even cover the extra variations like:

This product includes software developed for the NetBSD Project
by Christopher G. Demetriou.

So, even the estimate at http://www.gnu.org/philosophy/bsd is probably off:

When people put many such programs together in an operating system, the result is a serious problem. Imagine if a software system required 75 different sentences, each one naming a different author or group of authors. To advertise that, you would need a full-page ad.

As for adding the addendum from SSLeay to the standard BSD/ISC licence, I would guess that it goes in violation of the overall principles of the BSD philosophy — the BSD authors want as many users as possible to use the code in question, and the authors would rather you use a correct and open-source implementation than reinvent the wheel with an inferior solution.

As such, even though BSD developers would prefer to receive back the improvements (and most commercial companies, even the likes of Apple, Netflix and Oracle, do officially send a lot of their contributions back upstream to the BSD projects, since it decreases their own cost of maintaining their own software), officially adding such as a mandatory requirement to preclude a one-way street with some in the GPL community would be a violation of the spirit of the BSD-compatible licences and the BSD philosophy.

  • 1
    This addendum makes the resulting license almost GPL-like, in that derivatives have to be distributed under the same terms. In such a case, better go directly with a commonly used copyleft license (e.g. GPLv2) and be done. Doing otherwise just creates gratuitous license compatibility issues. – vonbrand Oct 22 '15 at 1:20
  • @vonbrand, not really — ANY licence is there to stay as long as the copyright does (just that with the BSD, adding an extra more-restrictive licence is not prohibited once significant new code is introduced to warrant an additional copyright claim); your comparison would perhaps have been move valid had you been suggesting LGPLv2 instead of GPLv2, because GPLv2 has way too many restrictions to be compared to the SSLeay. – cnst Oct 22 '15 at 5:12

Allow me to offer some insight:

First of all, it seems odd for developers to be more concerned that their work is being forked under the GPL, where they can look at the code, and replicate the features freely, as long as they don't copy the exact changes, than they are concerned that their code would be forked as proprietary, where they can't even see the changes to begin with. So right off the bat, I'm going to say that any developers with this concern do not understand what they are doing.

But they exist, and there are lawyers at big companies who had the same irrational fear of the GPL, so they developed weird licenses, like the CDDL, where you had to license your source code under the CDDL, but you could license your object code under any (proprietary) license you wanted to license it under. Of course, this is very incompatible with business models that license source code, but it's also incompatible with the GPL. Eventually, though, they realized that this only made it harder to combine the open source packages they wanted to use, and didn't help them in any real way at all. The CDDL is number 15 on Black Duck's list: https://www.blackducksoftware.com/top-open-source-licenses. Above it is the MPL, which the CDDL is based on, except it explicitly added GPL compatibility. So yeah, the whole "manually make this GPL incompatible" thing didn't really work out.

But you asked why people don't use the old 4-clause BSD license for these purposes. Well, this license is not only incompatible with the GPL, it's also incompatible, even more so than the GPL, with business uses. I don't want to shove five hundred acknowledgements onto every magazine ad I use for my software! That's insane! As explained above, clauses 3 and 4 are also pretty inconsistent, and there are a few other sloppy issues with the license... Whether or not it's GPL compatible, the license itself is just a poorly written proprietary license, and there's no good reason to use it.

If you want your software to be used by businesses, without restriction, you should probably license it the same way those businesses license it -- under Apache 2.0 (or, if you're Facebook, some douchey hodgepodge of a 2-clause BSD and weird patent grant, but don't do that, Facebook patent licensing is a whole different mess).

  • Your whole premise is wrong. BSD developers don't mind if someone forks their code to a proprietary solution -- it'd be better compared to an "evil corporation" reinventing the wheel, and doing things wrong. Chances are, this big corporation will donate all code back to reduce their maintenance costs anyway. But if someone forks over GPL, it creates a one way street -- the GPL project could pick up any changes from the BSD one, but the BSD one would be precluded from doing same. Very big difference. Also, you're wrong about who copied who -- CDDL is based on MPL, not the other way around. – cnst Oct 21 '16 at 22:45
  • You say "BSD Developers don't mind..." as though they're one set of people, and as though the BSD license is one license. OP asked a specific question about a specific type of BSD license, and its use for a specific purpose. And the packages using BSD licenses with advertising clauses are just as incompatible with BSD 2- or 3-clause-licensed packages as the GPL is. So you're wrong on that point. – Daniel Nov 15 '16 at 18:23
  • You got me on the CDDL vs MPL though -- I momentarily confused the CDDL with the CDL, which the EPL is based on -- they're another pair of weak copyleft licenses that have mostly fallen out of use, as IBM (and I believe the Eclipse Foundation) now largely prefer the Apache license. – Daniel Nov 15 '16 at 18:27
  • 2
    That is absolutely incorrect, and a dangerous lie. The advertising clause is completely incompatible with every open source license -- it is, itself, a proprietary software license. BSD (and Linux) systems frequently contain some files licensed, separately, under these licenses, but they are separated from the open source code sufficiently that the advertising clauses do not cause direct conflict. They're scarcely better than binary blobs. – Daniel Nov 16 '16 at 20:34
  • 1
    @cnst, noone forbids GPL users of BSD code to grant back their changes upstream either... and with GPL code publicly visible, upstream is in position to nudge downstream to be civil, which they aren't for closed source. – vonbrand Feb 20 '20 at 12:45

Adding such a clause results in creating a new licence which isn't the BSD licence anymore. And that can create a bunch of new problems. For example, if someone wants to reuse the code in a BSD-licenced software, it wouldn't be legal. So the benefits of using an existing licence would be lost.

  • This is not true. OpenSSL has been included in the OpenBSD base tree for years, and not even in the gnu directory (which is absent from bxr), where all the non-BSD stuff lives in OpenBSD. Likewise, bringing back the advertising clause makes the licence go back to the original BSD licence, and, again, people in the BSD world don't really have much of a problem with that. It's only the GPL that makes itself incompatible with other licences depending on various conditions. – cnst Nov 1 '15 at 12:48

This clause doesn't do anything more than state what is already the fact. When code with a GPL-compatible license is included in a project under the GPL as a whole, it doesn't lose its original license (or copyright). The only cases where you can do that are when the code is public domain to begin with, or when the license itself explicitly allows relicensing.

  • Hm, I see your point, but I somehow feel that you're answering a bit of a different question... – cnst Oct 26 '15 at 10:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.