Re: Implied exceptions to GPL?
On Sun, 2002-05-26 at 06:21, peter@horizon.com wrote:
> One is that this is in the "user does the link" territory.
> The executing image may be undistributable, but nobody wants to
> distribute that anyway. Unless there's enough contamination
> of the library caller that the library vendor can claim an interest
> in the binary, the calling software is not a derivative work.
When you have a plugin situation, then the status of the interpreter and
the library are not in doubt; it's the plugin itself you have to worry
about.
So, for example, an OpenSSL-enabled plugin for a GPLed interpreter would
not be distributable, even if the interpreter and OpenSSL are by
themselves.
The only time this affects the interpreter is if it distributes the
plugin in the same package; then, the only way to remove the offending
plugin is to remove the interpreter (or rebuild the interpreter with the
plugin turned off, or build a separate package for the plugin and
discard it, or whatever).
> The FSF has claimed that writing against a particular
> single-sourced library interface does create a derivative work (libgmp),
> but that wasn't widely accepted.
Huh? Maybe I'm not understanding what you're saying, but this sounds
completely wrong.
Anyone who links against GNU readline or GNU TLS (for example) must make
sure that the licenses on all linked code are compatible with the GPL,
since those two libraries are GPL. I don't know of anyone who disputes
this.
> And if there are multiple library
> implementations (say, Postgresql and Oracle), it kind of evaporates.
> What if I claim to have an alternate library implementation which I have
> just chosen not to release? After all, one of the points of the GPL
> is that I don't have to release.
Yes, but if you do release, you must release according to its terms.
Specifically, if you distribute a binary linked against a GPLed library,
then you must provide the complete source for the binary as well as the
library.
If the only library that satisfies a particular ABI is GPL, then all
binaries that use that library must be GPL-compatible, period. If you
have a library you haven't released that exports the same ABI, and you
want to release your binary, you must either release your library as
well or license the binary under GPL-compatible terms.
The idea is that, as distributed, the licensing terms are compatible
with each other. It doesn't really matter what's possible; what matters
is what you actually distribute. The existence of an ABI-compatible
library that's not GPL doesn't matter if you distribute the GPLed one
with your binary.
> Even if it *is* considered a derivative work, there's a provision in
> the GPL to allow linking with "standard" binary-only libraries like a
> vendor libc:
>
> # 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.
>
> I believe that interpreter run-time libraries *that normally come with the
> interpreter*, including a lot of Java libraries, clearly fall into this
> category. The interpreter is the (virtual) machine and operating system
> on which the executable runs, and the run-time is obviously a major
> component normally distributed with it.
That may or may not be the case. For Java it is, since Java is
distributed with Solaris and some older versions of Windows. For most
free interpreters, it is because it's part of Debian or some other Linux
distribution.
The problem is that the interpreter is not assumed to be a part of the
OS, and isn't defined to be an OS in its own right. So, an interpreter
can be counted as "part of the OS" only if it actually is. No
interpreter falls into this category just by virtue of being an
interpreter.
> However, you don't want to use this in Debian, because of the uncertainty
> surrounding the word "accompanies". This is obviously a more inclusive
> term than "derivative work", and we need a definition that is consistent
> with the earlier use in the same section for "accompanying" the binary
> with the machine-readable source code. Unfortunately, the GNU GPL
> doesn't define it, so we have to look to the dictionary and common
> practice for guidelines.
>
> Certainly, "mere aggregation on a volume of a storage or distribution
> medium" *does* count as "accompanying", because that's usually how the
> obligation to provide "accompanying" source is usually met. Indeed,
> putting it on a separate CD in the same bundle, or on the same FTP
> server is standard practice for "accompanying".
Mere aggregation is explicitly mentioned as an exception, so it's
clearly OK. See section 2 of the GPL, last paragraph.
No link, no foul.
> But then there are interesting issues. What about separate directories
> on the same FTP or web server? What if the proprietary code is
> in http://www.miskatonic.edu/~billg and the GPL-ed software is
> in http://www.miskatonic.edu/~rms?
>
> What about separate virtual servers sharing the same physical hard drive?
>
> What if they're separately sold CDs sold in the same store? What if a
> customer buys them both and puts them in the same plastic bag? What if
> he copies them to the same hard drive? What if the store has a combo
> discount offer? What if the clerks helpfully rubber-band the combo
> together for the convenience of the customers?
Again, "mere aggregation" is granted an explicit exemption, so all of
these are OK.
> The general idea appears to be to prevent a proprietary "major component"
> vendor abusing the exception, but it leads to a lot of problems for
> large distributions such as Debian or even a typical shovelware CD.
Well, I won't dispute that there are problems. It seems, however, that
most of the problems that arise amount to upstream authors not
explicitly spelling out their real wishes in their licenses. In some
cases, it would seem that the authors themselves don't really know what
their wishes are. Some are even violently opposed to the idea that they
must state their wishes clearly.
Of course, not all upstream authors are that way. Thank goodness!
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: