Have licenses ever stopped you from combining two FOSS programs?

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.

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.

For a long time, Debian/Ubuntu shipped unusable ruby packages due to the ruby/OpenSSL licenses being incompatible.

Still struggling from this famous fallout:

https://librearts.org/2012/01/whats-up-with-dwg-adoption-in-...

I'm the maintainer, the FSF owns the code, and I'm very fine that it's GPLv3. Others not so, but we don't care. GPLv3 is the only possibility.

Yes, but it mainly has come up when combining libraries and releasing something else as OSS. For example, the ASF has a good examination of the effect of combinations with the AL2: https://www.apache.org/legal/resolved.html

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

If I'm not modifying the source and just using the built application, then I have nothing to worry about regarding mixing programs.

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