HN Explorer

Ask HN: Have licenses ever stopped you from combining two FOSS programs?

23 points by josephcsible ↗ HN
Not all FOSS licenses are compatible with each other. The best-known example is that the CDDL and GPL are incompatible, which is why the mainline Linux kernel doesn't have ZFS. I'm curious how common this actually is, though. Aside from the ZFS-on-Linux case, has anyone else wanted to combine two FOSS programs but been unable to because of a license incompatibility?

31 comments

[ 4.9 ms ] story [ 89.8 ms ] thread
Xylakant
For a long time, Debian/Ubuntu shipped unusable ruby packages due to the ruby/OpenSSL licenses being incompatible.
kazinator
I put code under a BSD license, so on many occasions I've been prevented from using GPLed code. BSD and GPL are not incompatible. BSD and GPL pieces can be combined into a single program, while retaining their individual licenses; the problem is that the combination has to be redistributed under the GPL. Compatibility is not the only question, but what kind of compatibility: what must the master license be if the combination is made.

Cygwin changing to the LGPL back in 2016 enabled me to distribute BSD code with Cygwin DLL's without having to GPL the code. When I learned from the Cygwin mailing list about this change, I immediately set to work to create a fork of the Cygwin DLL which provides more native-like behaviors, to be used as run-time library for programs. Had they not announced a licensing change, I'd not have done anything of the sort.

torstenvl
Have you considered releasing your code under both BSD and GPL?
kazinator
No; it makes no (logical) sense.
torstenvl
It obviously does. You wish to use a permissive license; the GPL requires that you provide distributes your code under the GPL; dual-licensing meets both of these requirements. Care to explain the thinking behind you reaching the opposite conclusion?
kazinator
If I offer you a program under the BSD license, and then offer you exactly the same program under the GPL licnese, I have effectively offered you the program under the BSD license. Everything you could want to do with the program is granted by the BSD license maximally; the GPL doesn't grant you anything new. And the BSD offer nullifies all restrictions imposed by the GPL.

There is no benefit in such a dual licensing idea, and so if there is any nonzero harm, there is a net harm.

What are you going to do if a contributor sends you a significant patch that you would like? Only, oops, their contributions are under the GPL because they are working with your GPL offering?

Suppose that person believes in the GPL and won't switch to the BSD.

If you accept that, you will have to fork the program into two.

If you make it clear that all contributions must be dual-licensed, then there isn't really any meaning. Those who favor the GPL aren't going to contribute to a project that requires them to BSD-license their contribution alongside the GPL, because it negates the GPL.

If you don't agree with the redistribution terms of the GPL, then just don't use it. BSD, MIT or whatever. It's clear to all potential contributors that they must use the same license in order to get their changes merged, and that's it; no ambiguity, no confusions leading to forking.

[deleted]
(comment deleted)
[deleted]
(comment deleted)
satvikpendem
If I'm not modifying the source and just using the built application, then I have nothing to worry about regarding mixing programs.
josephcsible
It doesn't matter whether or not you modify the source. The thing that makes you not have to worry about licenses is if you don't distribute the result.
torstenvl
I have serious doubts that this is true, because (a) the text of the GPL itself is insufficiently clear on this IMHO; and (b) dynamic linking is literally just a declaration of an API you want to use and where the dynamic linker should look for that API provider, but APIs are, at least in some cases, fair use. See Google LLC v. Oracle America, Inc., 593 U.S. ___ (2021) available at https://supreme.justia.com/cases/federal/us/593/18-956/

You can easily make a binary that will use GNU libreadline, if it exists, without ever installing GPL software on your machine, let alone using it in compiling your distributable binary.

    freebsd% ls
    readlineshim.c readlineshim.h test.c
    freebsd% cat test.c
    #include <stdio.h>
    #include "readlineshim.h"
    
    int main(void) {
        char *name;
        name = readline("What's your name? ");
        if (name) printf("Hello, %s!\n", name);
        return 0;
    }
    freebsd% cat readlineshim.h
    char *readline(const char *p);
    freebsd% cat readlineshim.c
    char *readline(const char *p) {
        return ((void *)0);
    }
    freebsd% cc -c -fPIC readlineshim.c -o readlineshim.o
    freebsd% cc -shared readlineshim.o -o libreadline.so
    freebsd% cc test.c -o test -Wl,-rpath-link=. -L. -lreadline
    freebsd% ./test
    ld-elf.so.1: Shared object "libreadline.so" not found, required by "test"
At this point, test.c has been compiled into a distributable binary without linking any GNU software, but it requires GNU software to run...

    freebsd% sudo pkg install -qy readline
    freebsd% ./test                       
    What's your name? Lee
    Hello, Lee!
    freebsd%
Since GNU software is only required to run the program, then either (a) FSF's claim to cover dynamically-linked programs is false, or (b) the GPL isn't a free software license because it places restrictions on use.
josephcsible
> the text of the GPL itself is insufficiently clear on this

The text of the GPL doesn't matter. You aren't required to accept the license of a program if you don't redistribute copies or derivative works of it.

torstenvl
That is emphatically incorrect, and it's difficult to imagine how you could possibly have come to believe that to be the case. It's also irrelevant to the discussion.
galleywest200
I do not believe that I have to accept a GPL license for private projects that will never leave my home boxes. Even if I do I will just ignore it since nobody else will use that mess.
torstenvl
Yes, you absolutely have to abide by the GPL when you are using GPL-licensed code.

The text of the GPL does not require you to relicense your modifications under the circumstances you describe; however that is because of what the text of the GPL says, not because "[t]he text of the GPL doesn't matter."

josephcsible
What part of copyright law gives the copyright holder any power other than limiting distribution of copies and derivative works? If you get an "all rights reserved" program, are you allowed to run it?
torstenvl
> If you get an "all rights reserved" program, are you allowed to run it?

Only if you have a license... otherwise that's piracy...

> What part of copyright law gives the copyright holder any power

What exactly are you installing, if not a copy?

josephcsible
> What exactly are you installing, if not a copy?

That's a copy, but installing it on your own computer isn't distribution.

[deleted]
(comment deleted)
torstenvl
You say that as if it matters. It does not. Copyright is the exclusive right to copy; the exclusive right to create derivative works; and the exclusive right to distribute the copy or derivative work. 17 U.S.C. § 106.

If you do not have a license from a copyright holder, you may not copy the software to your computer (or anywhere else), you may not modify it, and you may not distribute the original or any modifications. Doing any of those without a license is software piracy.

(Note, however, that once properly licensed software is on your storage device, copying it into RAM or otherwise copying it "as an essential step in the utilization of the computer program" is always permitted. 17 U.S.C. § 117.)

josephcsible
Hasn't it been established that the copying necessary to run a program on your own computer is covered by fair use?
rolenthedeep
A very long time ago I took over a FOSS project under GPL. It had pretty good support for plugins, a lot of demand for plugins, and exactly zero third-party plugins that were even remotely maintained.

I don't think we ever got many direct complaints about GPL, but our main assumption was that copy left contamination was pushing developers away. We wanted more open licensing to encourage wider adoption, so we started a replacement project under MIT license, I believe.

Once the replacement project was in a good state, suddenly plugin developers started crawling out of the woodwork.

My estimation is that about 30% of our trouble was due to licensing concerns, and the rest was down to the original project being in a very, very bad way. It was very old, had been abandoned by six developers, and about 70% of the code was unused and unusable.

The new project had bells and whistles and was more attractive, but I think the open license definitely helped.

You probably could have built a plugin without needing to use the GPL, but it would have been a lot more difficult. That whole project was a disaster, and I never once regretted letting it finally die.

lloydatkinson
What project is this?
lloydatkinson
Guess we will never know. How OP expects anyone to maintain said project when being secretive about it, I've no idea.
psacawa
It happens all the time for software that is copyleft-licensed in projects that are unwilling to also adopt a copyleft license. For example, it blocks linking the node interpreter to libreadline [0]. On the other hand, cpython is also permissively licensed, yet it does link to the same library, so who knows what the legality of linking against a GPL lib really is.

[0] https://github.com/nodejs/node/issues/5608

josephcsible
This isn't quite the kind of conflict I meant, since the licenses are compatible and the maintainer just doesn't want to do it.
nubinetwork
In the Linux space, it doesn't really bother me... Packages in distros use all kinds of licenses, and as long as you're up front with what you're using and provide the source or license as required.

If "this product is made from a combination of domestic and foreign components" is good enough for physical goods, then it should be good enough for software.

But IANAL. :)

[dead] Haga
[dead]