On 4/6/21 9:40 PM, Adam Nielsen via Freedos-user wrote:
A lot of people complain about the viral nature of the GPL but that's
its greatest asset. It stops people from making use of open source
code in such a way that you can't get access to it yourself. The viral
nature is specifically designed for cases where someone designs a
product, uses some open source code to get started, and then builds on
it. Without the GPL only the original code would be available, and then
nobody would be able to modify your product because they don't have
access to all the pieces. The intention behind the GPL being viral is
to ensure all those pieces are available such that a user of your
product is able to modify the code if they choose to, without being
hindered by the lack of code availability of some parts of the system.
I have no problem with viral copyleft licenses, but being viral when
code is *linked* against code under the GPL has problems. I can see two
rationales for this:
A) Make people release their code under the GPL if they want to use your
library.
B) Prevent people from library-laundering non-libary GPLed code.
To explain what I mean by library-laundering, it's this: Alice releases
a program called Foo. Bob wants to release a derivative of Foo called
Bar under a proprietary license, but can't because Foo is GPLed. So he
makes a derivative of Foo called FooLib, which is a GPLed library
containing all the code from Foo that he wants to use (most of it). He
then writes a proprietary program that links against FooLib. But the GPL
counts linking as a means of creating a derivative work. Blast! Bob's
evil plan is foiled!
B is a legitimate reason to want to prevent proprietary code from
linking against FOSS code willy-nilly. But, in my view, A is not. First
of all, because when you're writing a library, your users are the devs
that use that library, and you're now restricting their freedom to use
that library. Secondly, because it has lots of really nasty corner
cases. E.g, what if there are existing implementations of an API, not
all of which are GPLed? If I write a program with a non-GPL-compatible
FOSS license against the POSIX API, and then somebody compiles it for
Windows using Cygwin, which is GPLed, what happens then? Does a
userspace program with a non-GPL-compatible license that is compiled to
run on Linux violate the GPL license on Linux (answer: IANAL, but
depending on your definition of "linking", I think that there's a good
argument that a program compiled to run on Linux links against the
kernel and does violate a strict reading of the GPL. However, Linus has
made clear that he does not count userspace Linux programs as being
linked against the kernel and will not enforce the GPL license on Linux
against userspace programs).
As I see it, restricting linking for purpose A creates confusion and
could even jeopardize the FOSS ecosystem. For example, if an API is
first implemented as a GPLed library, then somebody creates a
proprietary implementation that shares no source code with the GPL
implementation, and then a third party writes a proprietary program that
can link against either implementation, and then a fourth party links
the program against the GPL implementation, and then the person that
wrote the original GPLed library sues the fourth party (and maybe the
third too) in order to enforce the GPL for purpose A, I can imagine an
outcome where the original author of the library wins, but the case is
later used as precedent in a case where the copywritability of APIs is
at issue, and the decision in that latter case ends up being that APIs
are copywritable, which would be a disaster. (But again, IANAL, take
that with a grain of salt)
Of course, if you want to prevent B, which I think is a real concern,
but don't want to prevent A, you have to be a bit cleverer than the GPL
is. You need language something like:
"Header files in the 'path/to/public/includes' directory are part of the
external interface of this library, and including them in a program that
links against this library is not considered to create a derivative
work. Header files in the 'path/to/private/includes' directory, or
elsewhere in the source tree, are considered internal to this library,
and including them in software that links against this library is
considered to create a derivative work".
You already see this in router firmware, as the nature of the licence
means that manufacturers have to release the Linux source code, but
they don't need to release the source code of all their custom drivers.
So you frequently end up with the case where sure, you can install your
own firmware on the router, but you lose WiFi and DSL functionality
because those drivers are closed source. Which makes installing your
own firmware a bit pointless if you lose most of the functionality of
the product. This is why version 3 of the GPL was created, to try to
stop this from happening, but alas the Linux kernel is still on version
2 so is not protected and we're in this situation where although the
code is open and available under the GPL, it still can't be used.
This probably has more to do with the attitude of the kernel team than
with the GPL 2 vs 3. AFAIK, the GPL2, as intended by the FSF, *would*
consider kernel modules to be derivative works of the kernel, and thus
require them to be GPLed. I'm not sure of all of the intricacies here,
legal or in the attitude of the kernel team, but if the kernel team
wanted to enforce the GPL against such modules, they probably could (and
the same attitude that makes them not want to enforce it against modules
is also why they aren't moving to the GPLv3). The biggest loss I see in
the kernel not being under GPLv3 isn't in proprietary modules being a
thing, it's the fact that the anti-Tivoization clauses of the GPLv3
don't apply to the kernel.
Frankly, my ideal copyleft license wouldn't necessarily even include a
requirement to release sources. However, it would:
1) Require any derivatives have a license applied to whatever does get
released.
2) Require that the end user be allowed to use the software, copy it,
and redistribute it, as received without restriction.
3) Require that reverse-engineering of binaries be allowed (since we
aren't requiring release of sources).
4) Require that if the software, or a derivative work, is
cryptographically protected from modification, the owner of the device
have ultimate control of the keys.
5) Specify that no attack on the software, or a derivative work, by the
device owner in order to obtain control of a device that does not comply
with 3 may be considered a circumvention of a technical protection
measure under the DMCA (preferably written to cover similar laws in
other countries as well).
6) Specify that nobody that creates a derivative work and distributes it
may bring a copyright or patent action against any user or distributor
of the original work, or any derivative, except to enforce the terms of
the copyleft license.
7) Provide language like I used above for distinguishing between
internal and external interfaces of a program, and excluding use of the
external interfaces from creating a derived work. The author of a given
bit of software could then fill those sections in with the actual
interfaces covered.
Jon Brase
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
