Use LGPL v2.1 instead of v3 about os HOT 4 CLOSED

Hi IBPX.

I'm not a lawyer, so I could be way off here (and the official word on this is still the license itself), but this is my understanding:

You are indeed allowed under most common open source licenses to compile, link, and run programs created with incompatible open source licenses on your own machine. The GPL does not seek to limit your use of its software, it only moderates the distribution of software (or rather, it attempts to prevent others from limiting its distribution). The second paragraph of section 2 covers your ability to "do whatever you want in private".

So if you are someone looking to either 1) distribute our C library headers with your own sources or 2) distribute binary versions of programs linked using our headers, AND you've licensed your own software under "GPL2 only" (rather than GPL2 or later), our LGPL3'ed headers prohibit that. If the code you're compiling was licensed with "GPL2 or later", or any other compatible license, then you're still free to distribute binaries and source under GPLv3.

I think I'm comfortable with that limitation. I'm happy to work out exemptions on a case by case basis. But I'd be interested to understand why binaries need to be distributed rather than source, and why the GPL2-only license cannot be upgraded.

If there's a specific goal you're trying to achieve, let's talk about it. We're pretty flexible here.

from os.

MySQL is GPLv2-only, so shipping binaries for Minoca OS is a violation of its license.

GPLv2-only cannot generally be upgraded because most FOSS projects do not have a CLA or specify a proxy who can accept a newer version.

Not being able to ship binaries means someone can't ship a device running GPLv2 software on Minoca OS. In this case, I think most would just use a different OS that allows this, such as Linux, *BSD, or MINIX.

Why restrict what programs can legally be shipped for Minoca OS? What is the benefit of using LGPLv3 instead of v2.1?

from os.

You're bringing up some good points here, and I'm not familiar with the intricacies of copyright law. It does appear that others seem to view the C library headers as a clean line of separation, and don't seem to be worried about their license as it relates to the GPL.

• Apple's C library headers are licensed under APSL, which the FSF explicitly considers to be incompatible with the GPL.
• Microsoft's CRT headers and libraries are also not licensed under the GPL (in fact they seem to just say "All Rights Reserved"), and yet Oracle has provided documentation for how to build MySQL on Windows. Perhaps you could say that Oracle might come after you for distributing the binaries you've built for Windows, but so far I've yet to see any indication anyone's worried about that.
• I'm unable to find any projects that redistribute the C library headers they've used to compile a binary, as would be theoretically required by this reading of the GPL.

So for now I think I'm still satisfied taking my cues from other major OSes. But I don't mean to brush off your concerns. If you're building and planning to distribute something specific and are worried about the licensing implications, we're happy to talk. If you want to take this offline, my email is evan at minocacorp.

from os.

I meant to comment this yesterday: GPL's "system libraries exception" seems to allow linking to any system libraries, even entirely non-free ones.

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

See What legal issues come up if I use GPL-incompatible libraries with GPL software? in the GPLv2 FAQ.

So it seems my concerns are pretty baseless. They would only apply to libraries other than system libraries.

from os.