Hacker News Reader

Comment by Sanddancer | Hacker News Reader

There are plenty of licenses that are less viral than the GPL, such as BSD, MIT, etc. Furthermore, if you're pulling code from multiple sources, there are licenses, such as CDDL, that are mutually incompatible with the GPL. So yes, looking at virality very much does matter.

View on HN

Please define your use of "viral".

For most discussions about the GPL, people call the GPL "viral" from a misconception that it can't be combined with or depended on by non-GPL code. This belief is obviously wrong, but it persists.

Both the GPL and LGPL can be combined with and depended on by non-GPL code, so if the LGPL is not "viral", then neither is the GPL.

Viral as in requiring my code to be compatible with the GPL ecosystem, and in restricting my choice of licenses.

As I gave as my example, I can use a library licensed under the LGPL, and link it with code licensed under the CDDL. I cannot do that with a library licensed under the GPL. With that GPLed library, I'd have to use a license that the GPL is compatible with. So, if I had a product that I wanted to link with both sides, I would need to license my code under a license that is mutually compatible, such as BSD or MIT; I would be restricted from using certain other copyleft licenses.

  > Viral as in requiring my code to be compatible with the
  > GPL ecosystem, and in restricting my choice of licenses.

By that reasoning, all software licenses are viral. Even the 2-clause BSD license would be viral, because you're not permitted to distribute it combined with code that it's incompatible with.

  > As I gave as my example, I can use a library licensed
  > under the LGPL, and link it with code licensed under
  > the CDDL. I cannot do that with a library licensed
  > under the GPL.

That's simple license incompatibility. There are many licenses that are incompatible with the LGPL, and you wouldn't be able to distribute the combined work any more than you could a combined CDDL/GPL work.

  > So, if I had a product that I wanted to link with both
  > sides, I would need to license my code under a license
  > that is mutually compatible

Again, this is true of every copyright license ever created. That's what "incompatible" means.

> By that reasoning, all software licenses are viral. Even the 2-clause BSD license would be viral, because you're not permitted to distribute it combined with code that it's incompatible with.

You're reinventing definitions to suit your argument. The BSD license creates no restrictions on what you can combine it with. The restrictions are defined by to the GPL.

All licenses (except, in some jurisdictions, the public domain) have restrictions. They may be minor, they may be "common sense", but they are still restrictions. The BSD license has restrictions on how code may be redistributed, in particular its requirements regarding attribution and non-endorsement.

If I released some code with a license that said:

  This work may not be combined with any work which has a
  license containing more than twenty capitalized letters.

Then that license would be incompatible with the BSD license, and it would be illegal to combine the two works.

So if you define "viral" to mean "a license which can be incompatible with other licenses", then the GPL would fit that definition, but so would many other licenses (including the BSD license). Thus, it is not a useful definition.

There is no useful definition of "viral" which covers the GPL but excludes the LGPL.

You're engaging in standard GPL goal-post moving; somehow if you redefine all the words we'll all accept that the GPL isn't a restrictive viral license.

There's only one way compatibility where combination is concerned w.r.t the GPL. You can combine several different licenses, but the end result must be GPL licensed if it depends on GPL code.

This is absolutely wrong. If your code depends on GPL'd code, your code is not required to be under the GPL.

For example, I could write an application that uses GNU Readline, and release the source under the BSD license, and that would be perfectly legal.

Claiming that dependent code must be GPL'd is outright FUD.

I'm afraid you are wrong. I implore you to read section 5 of the GPL text. Particularly:

> You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

> c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.

Also, read this in the FAQ: https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

Your own citation invalidates your claim.

The linked FAQ is:

  > If a library is released under the GPL (not the LGPL),
  > does that mean that any software which uses it has to
  > be under the GPL or a GPL-compatible license?
  >
  > Yes, because the software as it is actually run
  > includes the library.

For this argument, the relevant part is "or a GPL-compatible license". The BSD license is GPL-compatible, therefore I can license my work under the BSD license, and not under the GPL.

For section 5, consider the implications of your quote, especially the final sentence:

  > This License [...] does not invalidate such permission
  > if you have separately received it.

Section 5 means that anyone who obtains a copy of the work is automatically entitled to a license under the terms of the GPL. It does not prevent additional licenses from being offered, and does not replace additional licenses present on a combined work.

> The BSD license is GPL-compatible

This isn't wholly true - the compatibility is only one way, which was back to my original point. "Compatibility" with the GPL is, according to the FAQ:

> In order to combine two programs (or substantial parts of them) into a larger work, you need to have permission to use both programs in this way. If the two programs' licenses permit this, they are compatible. If there is no way to satisfy both licenses at once, they are incompatible.

A BSD work which depends on a GPL work therefore, cannot be "Compatible" with the GPL because it fails to meet the criteria previously quoted: "You must license the entire work, as a whole, under this License ...".

What you are trying to claim is that you can write BSD code which is API compatible with readline, but if you are not distributing readline with it, it is not a dependent work. (ie, there are other works which are API compatible with readline). The condition here is that APIs cannot be copyrighted. In that case, you can distribute only your code which uses the API under your license of choice, but you cannot distribute the work as a whole under anything but the GPL.

The only point that matters about Readline is that if you link your BSD program to it, then when you distribute the binary, you also have to provide the source to your entire program. This makes it effectively GPL, because the BSD license has no such requirement. That is what the term "viral" refers to.

That's not the case: you cannot distribute the linked binary under any license other than GPL. You can only distribute the BSD code (or compiled, unlinked object code) which calls readline functions, only if you do not distribute readline with it.

If your code makes calls to readline functions, and you distribute readline with it, it is undoubtedly a "covered work" as described by the GPL, and is subject to section 5.c of the license which states that the whole work must be GPL if distributed

5.c says "This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it."

So you can distribute a BSD project with readline, and recipients are free to choose the BSD license for the BSD part and then distribute a closed source binary linked against a compatible readline replacement. The GPL does not invalidate the permissions granted by the BSD license.

The only goal of the FSF here is that the source code for anything distributed linked with readline be made available under the GPL. They don't stipulate that it only be made available under the GPL and not any other license.

Funny you should bring up Readline: http://en.wikipedia.org/wiki/GNU_readline#Implications_of_GN...

> For most discussions about the GPL, people call the GPL "viral" from a misconception that it can't be combined with or depended on by non-GPL code. This belief is obviously wrong, but it persists.

Debian obviously thinks this is a problem, or else they would not have any problems with the GPL incompatible OpenSSL license.

Source: https://lwn.net/Articles/428111/

The problem of license incompatibility isn't unique to the GPL. You could have software under a license that's incompatible with 2-clause BSD, but that doesn't mean the BSD license is "viral".

For example, the OpenSSL license is also incompatible with the LGPL; does that mean the LGPL is "viral"?

> For example, the OpenSSL license is also incompatible with the LGPL; does that mean the LGPL is "viral"?

I am not anti-GPL. My original and only point was that the distinction between GPL and LGPL is important to explain, and the situation with PostgreSQL at Debian shows there are real world implications of this.

> For example, the OpenSSL license is also incompatible with the LGPL; does that mean the LGPL is "viral"?

You have any source for this? LGPL was created to allow linking with any software. If you just copy paste source they are not compatible.

  > My original and only point was that the distinction
  > between GPL and LGPL is important to explain

It's actually pretty easy. The most important difference is that the LGPL permits bundling of your code with the LGPL'd code into a single combined work. The GPL would require your code to be open-sourced, but the LGPL has special provisions to permit bundling.

This is most relevant when using static linking, but also applies if you're distributing your program with a bunch of included dynamic libraries. The LGPL is important for proprietary applications because it lets them (for example) bundle a version of GTK+ that they know will work properly, so they don't have to depend on whatever version is installed on the user's system.

  > You have any source for this? LGPL was created to allow
  > linking with any software. If you just copy paste
  > source they are not compatible.

"Compatibility" is typically considered when there's going to be works under two licenses combined into a derived work. The OpenSSL license is incompatible with the GPL and LGPL because it has requirements (the advertising clause) that the GPL/LGPL prohibit. So if you want to take some OpenSSL code and some LGPL'd code and compile them both together, you wouldn't be permitted to distribute the result.

The LGPL offers a workaround, which is to separate out the LGPL'd code entirely into a separate library, and then set up your build system so users can relink against a modified version of the LGPL'd code. In this case, the OpenSSL code is being treated as if it were a proprietary blob. So it solves the problem of distribution, but with the hassle of maintaining that clean library separation.

Reply on news.ycombinator.com