> The userspace ABI is stable and intended not to cause anything targeting it to become a derived work. But once again, this seems to be a way in which the kernel project seems to think it has the power to interpret the GPL. In their minds, targeting the userspace ABI doesn't make a derived work, but writing a module does, unless it only targets GPL_ONLY symbols, in which case for some reason it isn't.
I think this whole part applies as much to the text of the GPL itself as to the common Linux explanation. The GPL draws a distinction between dynamic linking, static linking, and use over a network or through a CLI style interface to decide if a work is a derived work of the GPL program. But, this distinction is just a novel legal theory proposal at best - there is nothing in copyright law that would make the GPL distinctions authoritative.
A license simply doesn't get to decide what constitutes a derived work - that's entirely up to copyright law itself and the court system to decide.
On the other hand, unless and until Congress decides to explicitly legislate how copyright should apply to software, the courts can very well take common industry practice into consideration for judging what is and is not a derived work of a program, and in this sense the Linux kernel developers' opinion is in no way less impactful than the proposals in the GPL itself.
Furthermore, in a matter of contract law (so assuming that the work is indeed judged to be derived according to copyright law, but now judging whether the GPL may offer some relevant exemptions), the stated intentions and interpretations of the parties of the contract are indeed relevant. If there is a long history of kernel developers publicly stating that as long as you are not using GPL_ONLY symbols, your work should not be considered to be under the purview of the GPL, and if this has not been commonly publicly contested, I think that in an actual trial this will matter much more than other interpretations of the GPL.
The relevant "derived work" definition for the purpose of linking isn't one stemming from copyright law, it's the one in the GPL itself. This is because the GPL defines what licensees are permitted to do with the licensed work, and it imposes restrictions on those rights. Copyright law by default lets you make very little use of the software - the GPL broadens that out to include various forms of use, if (and only if) "derived works" fall within its scope.
You could ignore the GPL and static-link a piece of software to a GPLed library, but if you did so, you'd legally need a different right to use the GPLed library, because you hadn't complied with its license terms and so only have your minimal rights to use someone else's intellectual property.
Said differently, the GPL doesn't try to apply itself to "derived works" because of some contralegal dictum they don't have a different creative origin. It merely says "you have two choices - license the things you link with OUR stuff under OUR terms, or you don't have the right to use our stuff".
Let's imagine the following scenario. I am creating and distributing a program that, when run on a user's system, will dynamically link with a copy of libc. I am not distributing this copy, but my program will fail to run if no such copy exists. Furthermore, I tell my customers that the only lib C I officially support is FictitiousLibC, released under the full GPL (not the LGPL like the real GNU Libc).
The question is now: am I breaking any laws by delivering my program this way? According to the FSF, which believes an explicit linking exception to the GPL is needed - the LGPL - for such uses, then YES, I am breaking the copyright of FictitiousLibC, and so would need a license from FicititiousLibC to be allowed to distribute my code. But, if copyright law actually says "no, your program is NOT a derived work of FictitiousLibC", then the license is not needed. I don't know if this has ever been tested in court, but nothing would stop Congress from explicitly legislating this way and basically removing the difference between GPL and LGPL.
For an example of where this sort of logic applies is building programs to be run on an OS. If I build a program that only runs on Windows, but don't include any of Microsoft's code in my program, it is well established that my program is not a derived work of the Windows OS, so I can freely distribute it under any terms I want (not that Windows is special, the same is true of Linux or iOS or any other OS). I am not claiming that running on an OS is the same as dynamically linking with a library, just that in general something can be related to a copyrighted work without becoming a derived work by virtue of copyright law, not license terms.
Edit: note that if I want to distribute a bundle of my program + FictitiousLibC, that may infringe on FLC's license even if my program alone wouldn't, as FLC's license's terms of what constitutes a derived work could, in that case, go beyond copyright law definitions, and I would obviously need that license to be allowed to re-distribute FLC.
Let's remove the license and just look at what copyright says in order to understand your example. You have some copyrighted work and you want to make copies, and you do not have a copyright license from the author of said work. It this legal? Answer is mostly going to be no, especially if you are going to sell the copies. Commercially exploiting someones else's copyrighted work without a license is very often illegal.
Now let's say you do have a license, and the license is GPL. The license says that you have permission as long you do not combine the library using a linker with other programs that is not GPL. Do you have permission to copy the work if you disregard the conditions of the license? Likely answer: no.
Copyright do have a few exceptions. If you bought a copyrighted work like say Microsoft Word, there is an exception that says that you can also make a copy in memory in order to run it. Copyright law in some countries needed to be updated to do this, while in other places it occurred through precedents, but it was something that needed to occur. There might also exist a similar exception for running the program under Microsoft Windows, including using libraries called DLLs. Exceptions to the exclusivity of copyright is sometimes needed in order for the world to make sense.
The legal question then that remain is if the situation with FictitiousLibC has such an exception. That is less certain. There might be a copyright law exception, or there might not exist. What do you think?
The main point of my argument, and the main concern I feel with GPL-style licenses, is the notion of "do I have to distribute my work under the terms of the GPL even if I don't distribute any GPL code directly; in other words, when is my program a derived work of a GPL work?". If instead I am distributing GPL code directly, the question is more clear - as you say, copyright law makes few exceptions there.
But again, if my program doesn't directly include any code at all from a GPL work, but it does depend on such code to exist on the end-user system, knowing in what circumstances my code is a derived work and thus can only be distributed under the terms of the GPL is much harder.
This is exactly the case of the kernel modules: the people distributing the kernel modules are often NOT distributing Linux itself. But, can their modules be considered derived works of the Linux kernel?
Note that this kind of question can also arise in traditional copyright. I can make a play that very much resembles a novel, and depending on many ultimately subjective factors my play may or may not be considered a derived work of that novel. If I am directly including substantial parts of the novel, then the answer is pretty clear, but a work that doesn't have a single word of the original can still be a derived work (most obviously, a translation is a derived work, but it likely literally doesn't include a single word in common with the original work).
Unfortunately the FSF's idea of what a derivative work is largely something they made up with no basis in statutory law and which has never been tested in court. It basically consists of wishful thinking on their part.
In the US, a derivative work has a legal definition in Title 17 of the United States Code, and anything that is purportedly a derivative work that doesn't clearly fall under the legal definition or established common law on the subject is of little matter. Lawyers love to engage in wishful thinking on behalf of their clients and rarely get anywhere because they are not neutral arbiters but rather advocates for a one sided position of one kind or another.
In this case FSF associated lawyers appear to be completely out of touch with reality, but are incredibly influential in persuading others to be equally out of touch. And what more could you ask of an advocate for your position than that? A reality distortion field for hire.
This used to be true, but arguably the GPL has been tested in court in the infamous Oracle v Google case. (Java is licensed under the GPL among other licenses)
It looks like the Supreme Court said "sure... whatever, Fair Use, I guess". Are APIs copyrightable in general? God knows. But at least you have a case from a top court deciding that in some cases you can actually copy all the APIs in a GPL'ed Java library.
Totally agree with FSF making stuff up though. The reality distortion field they have is pretty legit. I don't think people even realized how the Java case could have impacted the interpretation of GPL and that it was actually a high profile allegation of GPL violation.
The claims that have never been tested in court here aren't part of the license, but rather commentary as to what constitutes a derivative work under copyright law. If true, they would affect the legality of a number of practices that apparently do not require distributing or modifying licensed components or accepting the license at all.
If loading and running a program with dynamically linked modules with incompatible licenses creates a legally prohibited derivative work in memory, that is a reasonable claim that the author copyright holders of some of the code could pursue the users in question about. That is not what is controversial though.
The controversial claim is that by merely making a module that is link or use compatible with another module a legally prohibited derivative work has been created. Not by incorporating inline code, or copying the structure, sequence, or organization of another module, but merely by making something that is compatible in the abstract. Where is the legal basis for this claim? It is apparently nowhere, little more than wishful thinking.
> commentary as to what constitutes a derivative work under copyright law
That's part of my point actually. The question of API copyrightability in the Java case has a lot to do with whether copying APIs/ABIs in the code (whether from headers or binary symbol tables) is copyright infringement.
That said, it's unfortunately true that the conclusion is far from clear. (Sidenote -- given that the Supreme Court dodged the question, does it mean that the Court of Appeals decisions still hold? [I'm not familiar with the US legal system])
The Supreme Court conclusively established that Google's use of the APIs was fair use under copyright law, so they did not need to reach the underlying question. I believe it would be safe to conclude that API descriptions such as header files are protected by copyright even in their essentials, that fair use is necessary to reproduce them without a license, and that Congress would need to act to create a more reliable exemption for that sort of thing.
Court of Appeals decisions are only binding precedents within the corresponding regions, but they generally have persuasive force throughout the country until and unless the Supreme Court overrules them.
I don't think Google v Oracle had anything to do with the GPL. The Java API is not licensed under the GPL, even if the main implementation, OpenJDK is. Alternate JDKs (Microsoft's old JDK, Visual J++, for a famous case) had to obtain special licenses from Sun and later Oracle, that included terms which are very different from the GPL (in particular, these JVMs had to be fully compatible with Java, you were not allowed to create a partially compatible JVM; and there were further restrictions on JVMs that targetted mobile/embedded devices).
The whole trial also stopped at the copyight-ability and fair-use grounds, it never looked at any license Google might have had (they didn't have any license to use the Java API, but the SC finally found that no license was needed, as even if the API may be copyrightable, Google's use would fall under fair use exemptions).
If you persuade enough people to be "out of touch with reality", they're not out of touch with reality anymore, because it's the reality that got changed.
That may be true, but in this case the relevant parties to be persuaded are federal appellate judges before it can fairly be said that reality has changed on the ground. How likely they are to be persuaded by a position that has no apparent basis in the statutory text is a real question. As far as I can tell, no one making these rather unusual claims has even tried to outline such an argument.
Why should anyone be persuaded by a legal position that has internal logic that has never been explicated anywhere? If lawyer A writes to lawyer B claiming that B's client is creating a derivative work but cannot explain why, lawyer B is more than justified in laughing them to scorn.
Even if B did create a derivative work according to some unknown and unheard of legal argument acceptable to the courts, fair use could apply anyway. But one can hardly begin to look at the fair use factors if lawyer A could not even identify how a legally cognizable derivative work is being created in the first place.
"do I have to distribute my work under the terms of the GPL even if I don't distribute any GPL code directly"
That is an interesting question that have a handful court case in the US, however the result has gone both way. The primary example of that has been cheat software that injects into copyrighted games, which both goes again the copyright and EULA of the game. In the example of blizzard, there is cases when they won against the cheat software on copyright grounds, as you can read here: (https://massivelyop.com/2020/02/28/lawful-neutral-cheating-c...).
Basically, the art of work that get created when you run software is also a kind of copyrighted work, and a bit like how movie character is copyrighted as well as an actually movie itself. If a second company make a new movie with the same characters, story and so on, even if its all "original" code, it is still a derivative work. The article above describe those as "non-literal elements", the graphics, sounds, animations and characters produced by the literal code.
So to answer the question "when is my program a derived work of a GPL work", it would seem to be when the non-literal elements of the GPL is changed in ways that require copyright permissions by the GPL author.
It should be noted however that in practically all cases involving the linux kernel, companies that distribute non-gpl kernel modules are also distributing the kernel as part of products.
> I am not claiming that running on an OS is the same as dynamically linking with a library
In pretty much any case, it literally is: you're dynamically linking against the libc. This is a little fuzzier on Linux (because, as you mention, multiple libc implementations exist), but on Windows, macOS, and the BSDs, the only supported way to make syscalls is to make calls into a dynamically linked libc, provided by the operating system.
Well, theoretically you could make a (pretty useless) Windows program that doesn't do any syscalls itself. It would mostly be limited to heating up the processor, but it would be a valid program. In fact, you could probably actually do some basic syscalls without linking to NTDLL by using very old DOS syscalls for things like printing to the console, perhaps with a compatibility mode.
Also, being pedantic, in Windows libc is a wrapper over Win32, which is partly itself a wrapper over NTDLL. For example, msvc's malloc() simply calls HeapAlloc() or some variant thereof.
> The FSF have actual copyright lawyers on hand. Where have they said this?
It is part of the official GPL FAQ [0].
Does the GPL have different requirements for statically vs dynamically linked modules with a covered work? (#GPLStaticVsDynamic)
No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. [...]
> The example is not very easy to understand. In general copyright law isn't really applicable to your own right to distribute your own original work.
The very question is if my work is original. If I create a program that only works when (dynamically) linked with a (GPL) library, is my program an original work, or is it a derived work of that (GPL) library? This is a question that has not really been settled in court; the official opinion of the FSF is clear: it is a derived work.
If the explicit question in the GPL FAQ is not engouth, note again that the whole purpose of the LGPL (and other GPL+exemptions licenses, such as Java's and GCC's) when compared to the GPL is to allow this type of use, which they clearly would not have created unless they believe it would not be allowed for a full GPL library.
The main problem with the interpretation that the GPL sets conditions for use of software is that it specifically claims it does not:
> Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted,
Now there are some ways to try to do an end-run around this clause, it does raise some questions about how you get the right to run the program without "this License". But if we take the text seriously, it disclaims any restrictions on use.
This is the part where the derivative work standard comes in. Because if the GPL doesn't set conditions on use, your use of the software doesn't require complying with that license. The GPL would only enter in if you are going beyond mere use, e.g. are you making a legal derivative work (not the GPL definition)
I find it difficult to imagine a situation in which you could use the library without copying the library. How would you obtain the code to execute it? Someone must distribute it to you, and/or you must copy it. Those are the governed actions.
EDIT: note that the GPL broadly doesn't impose restrictions on interacting with a program over a network ("using" a server), which is why the AGPL exists.
So, one answer (not necessarily the right one!) to how you can use software without copying it is that "the license says you can". In other words the license definitely views "running" and "copying" as distinct, regardless of you, me, or federal law.
The other, maybe more familiar idea to lawyers, and maybe more plausible to you, is the one in MAI v. Peak, that running is copying by definition. (The argument is based on the idea that running a program copies it into RAM, so we don't even need to talk about how you obtained the software.)
The way this shakes out is as follows:
a. If running the program is "not covered by this License", then we can stop reading the license and return to copyright law. But copyright law says we need a license to run (that is, to copy, MAI v. Peak) the program, so where do we get it, if not from "this license"? Bit of a puzzler.
b. If "running the Program is not restricted", maybe that sentence is by itself some kind of license to "run" the program, even though that contradicts the "not covered" part? If so, we need to understand what the license means by "run" which is evidently something different than "copy".
Very probably, what this clause originally meant was that people who think like MAI v. Peak are wrong and nobody should need a license to run software. If so, it's pretty challenging to turn around and argue "just kidding, they do"
Congress has changed the law since MAI v. Peak specifically to allow users to create copies and adaptations of software programs as an essential step in running or utilizing the program in question on a machine, or for limited archival purposes (i.e. backups).
"Adaptation" is another name for "derivative work". So it would appear that it is not a copyright violation for an end user to load or dynamically link modules with incompatible licenses into ram, or statically link them together, or make binary modifications, as long as what they are doing is necessary to use the program.
It might still be a license violation of course, but it is probably a fruitless exercise to go after users who are exercising what are ordinarily considered to be well established rights necessary to use the software, the very thing that made MAI v. Peak an unfortunate ruling that Congress had to fix. Surely that sort of thing - even by third party technical support - should have been considered fair use from the beginning.
> Congress has changed the law since MAI v. Peak specifically to allow users to create copies and adaptations of software programs as an essential step in running or utilizing the program in question on a machine, or for limited archival purposes (i.e. backups).
That's not entirely true, as far as I understand. The rule that a user may copy the work to RAM as a fair-use exemption already existed at the time of MAI v Peak. However, it was found not to apply, since the person that loaded the program into memory was not MAI's client, but a Peak employee, who was fulfilling a separate contract with MAI's client, and who had never legally obtained a copy of the work from MAI (which would have entitled them to load it in memory themselves).
Basically, the court at the time found that if I have a copy of Windows from MS, I am allowed to copy it into memory and run it. But, a repairman I hire is not allowed to load my copy into memory and run it themselves, unless they also legally own a copy of Windows.
However, Congress did amend copyright law in light of MAI v Peak, to extend the existing fair use exemption for copying into RAM to people acting as service/repair contractors.
Thanks for the clarification on that. Either way, MAI v. Peak was kind of a disastrous decision that presumably could have easily been resolved under fair use for the service contractor. Congress included Section 107 for a reason, and no doubt part of the logic is that courts use it instead of creating a make work program for Congress on the subject.
That would seem to go double for whichever court decided that ephemeral copies in RAM are "fixed" in a "tangible medium of expression", in direct contradiction of the plain meaning of the term.
> The other, maybe more familiar idea to lawyers, and maybe more plausible to you, is the one in MAI v. Peak, that running is copying by definition.
That is a bit over-simplified. The important part in MAI v. Peak was that Peak was a third party to the license between MAI and their client. The court recognized that MAI's client had the right to load/copy the program that they had acquired from MAI into memory without any additional license from MAI - there was already an explicit exemption in copyright law for this. However, they decided that this right can't be extended to a 3rd party (Peak, who as acting as a support technician), even if on the same machines.
In its’ very basic form a license has two distinct purposes:
a) limit whatever rights are granted by copyright law
b) grant new rights that go beyond copyright law
> Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted
I don’t see a contradiction
here.
The first part states that anything being granted by this license (purpose b) only applies to copying and distributing.
The second part simply states that no new restrictions (in the sense of purpose a) are made.
To be more explicit, the paragraph should be read as:
> The act of running the Program is not additionally restricted
If true then this means before you even download the program you must agree to its license. only then are you allowed to download which in turn copies the program to ram and then to a FS.
It's ridiculous to expect that you can go after individual users for making single copies while not following your terms. You're going to sue someone for zero damages? For bruising your ego? Good luck with that.
For the same reason, an AGPL item could be enforceable, but only if the violator is juicy enough.
> Copyright law by default lets you make very little use of the software
That’s not what the statutory law says. Once you’ve legally obtained the software you’re free to use it, including specifically the right to make copies for backups and necessary purposes, like copying from disk to memory[1].
Note that the GPL doesn’t attempt to limit how you use the software. The copyleft only matters when you start distributing copies rather than using the one you already have, which is where copyright law matters.
Does the GPL(v2) actually say you can't static link anywhere in its text?
IIRC the static link thing was a FSF interpretation that is not incorporated in the license text. The GPL only stipulates that derivative works must be GPL'd without going into specifics what kind of linking constitutes a derivative work. In case of dispute a court would likely interpret "derivative work" according to standard copyright law (after all it's a legal term) unless there is evidence that the parties intended to use the FSF interpretation.
Static linking creates a work that incorporates another work, in a way that does not appear to be mere aggregation and which usually requires at least a modicum of creativity.
I imagine end users might statically link things together all day long without getting in much trouble - 17 USC 117 practically exempts that sort of thing. But it seems like it would be pretty dangerous ground for a vendor to distribute a statically linked executable in violation of the license of one of its components in large part because a valid license is necessary to distribute the component in the first place.
Might be a bit hair splitting (probably appropriate to do so in this context?), but the GPLv2 states that "mere aggregation of another work... does not bring the other work under the scope of this License". But it technically does not imply the converse is true, i.e. if it is not mere aggregation it must be a derivative work.
Since "derivative work" does not seem to be clearly defined in GPLv2, I would say it's hard to argue that statically linking creates a "derivative work" in the GPLv2 without showing that this is the general legal position of copyright law as opposed to a specific stipulation in the GPL.
I think that is correct. "Derivative work" is a legal term in copyright law that the framers of the GPL were wise not to try to redefine in the text of the license. They seem to like the term "derived work", but do not define that either, probably for the same reason.
According to the U.S. Copyright Office, copyright only subsists in derivative works as such to the extent they show some independent creativity, which suggests that a non-mere-aggregation that is a mechanical or near mechanical combination of works may not be a legally protected derivative work at all, i.e. may be the sort of work you can prepare without permission from the copyright holder under Section 106 or some other legal allowance. All assuming you own legitimate copies of or have a proper license for the component works, of course.
>Said differently, the GPL doesn't try to apply itself to "derived works" because of some contralegal dictum they don't have a different creative origin. It merely says "you have two choices - license the things you link with OUR stuff under OUR terms, or you don't have the right to use our stuff".
The GPL doesn't restrict use, and says so. When people say that the GPL only lets you use the work under the author's terms, "use" means things that you'd need copyright licenses for. If you aren't creating something that is a derivative work according to the legal definition, you may not be using (in this sense) the author's work at all.
This also fails for interpretations like "you can link to GPL_ONLY symbols". This isn't directly written in the license, and any kernel contributor can deny it whenever they want.
Making a copy of a copyrighted work (duplication) is one of the fundamental actions that usually requires a license. It is difficult to find a way to take another action with the work without first duplicating it.
I think there's a misunderstanding here on what "use" means.
> You could ignore the GPL and static-link a piece of software to a GPLed library, but if you did so, you'd legally need a different right to use the GPLed library, because you hadn't complied with its license terms and so only have your minimal rights to use someone else's intellectual property.
Before we get into anything particular to the GPL, Galoob v. Nintendo established that modifying copyrighted programs for personal use is covered under fair use [1], so you could use, i.e. run, that newly linked program without any regard to license.
Even if the GPL could establish such restrictions, I don't think that it would. That seems to run entirely opposite to the spirit of the license. The point of the GPL is to preserve the freedoms of the end user, and freedom 0 is to freedom to run the program [2]. When you link that program and run it, you are the user. The author of the GPL work wants you to be able to run the GPL code "as you wish, for any purpose", and they also want the same freedom to be given to whomever you give that code to. If you give that linked program to someone else, they're the user, you're the distributor. Your freedoms as a user are the same as they've always been, and that user that you gave the code to needs those same freedoms.
> Said differently, the GPL doesn't try to apply itself to "derived works" because of some contralegal dictum they don't have a different creative origin. It merely says "you have two choices - license the things you link with OUR stuff under OUR terms, or you don't have the right to use our stuff".
You have the right to use the stuff by virtue of freedom 0, literally "the freedom to run the program as you wish, for any purpose". You don't have the right to license "OUR" stuff to other people without also ensuring they have the same freedoms that "we" gave you.
See also another commenter discussing freedom vs. power [3].
Everything you said is correct. I was not sufficiently careful in my... uh... use... of the word "use".
I meant "use" in the sense of "allow to form part of your whole work which you then distribute". Anything that happens on your own local machine and never leaves isn't the intended target of the GPL.
To those clicking on link [1] and finding it broken: you need to add a full stop at the end, as Hacker News's software has seen fit to exclude it from the link.
b) You must cause any work that you distribute or publish, that in whole or
in part contains or is derived from the Program or any part thereof, to
be licensed as a whole at no charge to all third parties under the terms
of this License.
[...]
These requirements apply to the modified work as a whole. If identifiable
sections of that work are not derived from the Program, and can be
reasonably considered independent and separate works in themselves, then
this License, and its terms, do not apply to those sections when you
distribute them as separate works. But when you distribute the same
sections as part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License, whose
permissions for other licensees extend to the entire whole, and thus to
each and every part regardless of who wrote it.
The post on which we're commenting says that "derived" comes from copyright law, and not from the text of the GPL, because the GPL cannot supercede copyright law. What I'm pointing out is that's incorrect - the definition of "derived" comes from what the license itself considers derived. This is because the license puts conditions on "derived from" works in the above term. This is true even if the license says "see copyright law for definition of term X".
When trying to determine what "derived works" means, the intent of the license is relevant. The license cannot restrict your rights beyond what copyright law allows it to do, but it can grant you additional rights on terms of its own choosing, including very restrictive terms.
Importantly for this conversation, something that is derived from "any part" of the program may or may not be a "derived work" of the whole under US copyright law, but may be a "derived work" for the purposes of the above clauses regardless. Plus the latter paragraph has an AND addendum - "AND can be reasonably considered independent and separate works in themselves" - which can restrict beyond the referenced legal definition of "derived".
That is not necessarily the part I was thinking of - I had indeed made some confusion between what the GPL says and what the LGPL and other exceptions-to-the-GPL licenses say.
I have detailed this more in another post, but basically my argument is that the very existence of the LGPL makes sense only if we take the GPL's definition of derived works to include programs which dynamically link with the GPL work (and this is indeed what e.g. Stallman believes).
There are also some similar exemptions in the GPL license for GCC, to make sure that the binary resulting from compiling a program with GCC does not have to be distributed under GCC's license terms even if it might be a derived work of GCC itself (e.g. when the compiler includes bits of code that it does consider copyrighted, such as replacing calls to the library function memcpy with an optimized version that is defined in GCC's source code).
I absolutely agree with you that, when distributing a combined work including GPL code very directly (say, a CD with Linux + some proprietary software), the GPL may well impose extra restrictions even on parts that are not considered derived works under copyright law. You are free to not accept those extra restrictions, but then you have no right to distribute the GPL works at all (though you can still distribute the parts that are not derived works independently).
Courts are supposed to balance the bargaining power of the parties when considering the enforceability of terms. So for the GPL which is a boilerplate clickwrap contract where the parties have not necessarily even communicated before, a court may take a narrow interpretation of such terms. So the unsatisfying answer (to programmers) may be: it depends who you are.
It's not at least in the US a contract at all its a license. As the text says you don't have to agree to it but have no right to distribute said software if you don't agree and no you can't ask a judge for better terms.
In Europe unless the law has changed, in most jurisdictions the typical US style licenses are considered void unless the consumer of such software has been given and agreed to the license before acquisition.
That is why most ship wrapped software started putting a reference to the license on the box.
Yes, but copying a piece of software from a CD into program memory or onto my own hard-drive for archival purposes has been established as a fair-use exemption. So, if I legally acquire a copy of a program (say, I buy a CD), it can't impose extra restrictions after-the-fact through an EULA that only appears when I run it, and I am well within my rights to use my copy (e.g. by copying it into RAM/CPU icache to run it) even if I don't abide by the EULA, according to European Union jurisprudence.
For example, many game EULAs (used to?) impose a restriction on lending the CD to others (you had to seek explicit permission from the copyright holder to do so). If this clause is only knowable after buying the game, then in the EU it is null and void, and I can still use the software and lend it to others per regular copyright law.
If, however, the license must be accepted before purchase/download, my purchase/download can be considered acceptance of this clause and I then have no right to use the software if I don't abide by the license agreement, since the copy was distributed to me only under specific conditions.
This is just like if I buy a book, I have every right to read it, lend it or re-sell it; but we can also sign a contract under which you give me the book but with no right to read past page 87, and no right to lend it to others.
> Yes, but copying a piece of software from a CD into program memory or onto my own hard-drive for archival purposes has been established as a fair-use exemption. So, if I legally acquire a copy of a program (say, I buy a CD), it can't impose extra restrictions after-the-fact through an EULA that only appears when I run it, and I am well within my rights to use my copy (e.g. by copying it into RAM/CPU icache to run it) even if I don't abide by the EULA, according to European Union jurisprudence.
We're talking about the GPLv2 though. It imposes no restrictions that copyright does not impose, so voiding the license is strictly a detriment to the licensee. The people who wrote it were very clever, using the power of copyright that is lobbied-for by the proprietary software industry.
The GPL is a license that applies only to software code and not to the end-user software.
A book allegory is more like an author decides to embed the several chapters of one of Rowling's "Harry Potter" books verbatim in a fanfic novel. You could buy or download the novel and have every right to read it, lend it, or re-sell it but the original fanfic author is in copyright violation. If Rowling had published her books under something akin to the GPL, there might be a legal question as to what constitutes a "derived work" (and this is a real thing in the book publishing world, complete with legals precedents) but at every point the license to use the copyrighted characters, locations, etc. applies only to the author of the derived work, not to their readers.
> The GPL is a license that applies only to software code and not to the end-user software.
I don't know what you are trying to say with this. Binary code distributed to end users is a derived work of the source code, so there is no difference between distributing source code or binary code, from any point of view. And if I illegally create a copy of X's work and sell that copy to Y, X has a right to ask for Y's copy to be destroyed.
And again, I was explicitly talking about the fact that work A can be a derived work of work B even if A includes no amount of B directly. If I re-tell Harry Potter in my own words, replacing every single phrase, name etc., but otherwise keeping the story identical in every way, then my work is almost certainly a derived work of Harry Potter and J.K. Rowling is the only one who has a legal right to distribute the work I created - which also means she has a right to ask for the destruction of all copies of said work that I illegally distributed (not that this would be too easy to enforce).
Similarly, the question arises: if I create a program that has a GCC-shaped hole in it, and distribute to end-users under a proprietary license, to be used with a copy of GCC that they obtain separately, is my work a derived work of GCC or not? This is a real legal question that the GPL has no bearing on.
> I think this whole part applies as much to the text of the GPL itself as to the common Linux explanation. The GPL draws a distinction between dynamic linking, static linking, and use over a network or through a CLI style interface to decide if a work is a derived work of the GPL program.
I just rechecked and it does not seem the GPLv2 does such things. I've not rechecked for v3, but from memory it does not do that either.
I completely agree with you that clear intent is important though.
I explained more in another comment, but you're right, I had some confusion. The GPL itself makes no such claims, but the FSF does; also, the LGPL directly implies that programs that dynamically link an LGPL library are derived works of that library, but makes an exemption from the normal GPL requirements for such programs.
Further, the FSF draws a distinction between linking (either statically or dynamically, which they believe makes your program a derivative work) and calling through a CLI or over a network (which they believe does not make your program a derivative work, except if the data structures exchanged through the CLI/network are complex enough).
I think she/he's trying to say -- the FSF draws such distinctions, but I think you're right the GPLv2 doesn't, and these are all just post-hoc rationalizations.
[Incidentally this issue is at the heart of Oracle v Google. I find it fascinating how the tech community in general seems to not realize these are the same things.]
Quote:
But that aside, does the Open Source community really want to push for
the legal principal that just because you write an independent program
which uses a particular API, the license infects across the interface?
That's essentially interface copyrights, and if say the FSF were to
file an amicus curiae brief support that particular legal principle in
an kernel modules case, it's worthwhile to think about how Microsoft
and Apple could use that case law to f*ck us over very badly.
It would mean that we would not be able to use Microsoft DLL's in
programs like xine. It would mean that programs like Crossover office
wouldn't work. It would mean that Apple could legally prohibit people
from writing enhancements to MacOS (for example, how do all of the
various extensions in Mac OS 9 work? They link into the operating
system and modify its behaviour. If they are therefore a derived work
of MacOS, then Apple could screw over all of the people who write
system extensions of MacOS.)
Linux is licensed under GPLv2 with an additional permission (or exception):
> NOTE! This copyright does not cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does not fall under the heading of "derived work".
All the contributors license their work under this license with this additional permission. So in that sense it's not really Linus interpreting the GPL, and I don't think there's a risk of a contributor revoking this permission.
But maybe this doesn't apply to kernel modules and doesn't address the GPL_ONLY symbols thing.
(1) The text of the GPLv2 does legitimately restrict user programs as derivative works of the kernel, and therefore a license exception is needed from the licensors in order avoid violating the license or copyright law.
(2) User programs are not legitimately derivative works of the kernel, and therefore a license exception is not required, and anything said on the subject is mere commentary about the prevailing legal state of affairs.
In my opinion, the idea that user programs are - in general - derivative works of the kernel is nonsense, but for people who worry that they are or might be, the clarification or exception (whichever) is quite convenient. A court is not going to enforce a requirement on the licensees that the licensors and copyright holders explicitly deny and disavow, no matter what any third party thinks about the subject.
The situation with in kernel modules is more complicated, because there the licensor copyright holders appear to be convinced that nearly any kernel module is legitimately classified as a derivative work, so estoppel doesn't apply and whether a kernel module is actually a derivative work depends such things as how much kernel inline code was included in the compilation process, if not other apparent legal nonsense like compatibility and purpose which appears to have no basis in copyright law as something that in and of itself makes for a derivative work at all.
> Actually, it gets worse. Here's what the GPLv2 says about termination:
> So if you violate the licence, it is terminated. That's it. Given that “you” may refer to a corporation, this creates the following disturbing possibility:
This is called the GPL death penalty, has actually happen in the past even before the article was written.
Can we slow down with the FUD please? GPLv3 is extremely lenient with license violations and GPLv2 is not. Yet, calling it "death penalty" is absurd.
Millions of contracts have clauses for immediate termination, and often with less clear reasons than copyright violation. Plenty of free services like HN can close an account at any time and nobody calls it "death penalty".
Do we see thousands of companies suddenly losing millions because of a GPLv2 breach? Nope.
GPLv3 isn’t a useful license because it makes the use of software in automotive devices effectively impossible. And I think this is a security issue as well because the vendors still rely on very old GPLv2 versions of software and can’t update even if they wanted to.
> Linus Torvalds seems to speak as though he has the power to interpret the GPL.
IANAIPL but intent of the parties does generally matter to any legal analysis of an agreement. This is especially true when discussing written evidence of intent. Arguably, the discussion of GPL_ONLY could be taken to mean that those without such a marking are being granted an exception by the authors, which is perfectly well within their power to do.
But parole evidence is trickier to apply here than you might imagine. It only applies where there is an ambiguity in the text, and probably matters much less where 3rd parties are to be bound by a license, instead of two parties to a contract.
Imagine, say, Microsoft (bogeyman) explaining what we really meant is that "Licensees shall give us their first born child."
"We want companies and individuals to use, modify and distribute this software. We want to work with users in an open and transparent way to eliminate any uncertainty about our expectations regarding compliance or enforcement that might limit adoption of our software. We view legal action as a last resort, to be initiated only when other community efforts have failed to resolve the problem.
Finally, once a non-compliance issue is resolved, we hope the user will feel welcome to join us in our efforts on this project. Working together, we will be stronger."
>It is rather ironic that in some ways, one has more freedom in how one licences a kernel driver for Windows than the freedom one supposedly has in writing a kernel module for Linux.
it is not ironic at all: freedom in Free Software is the freedom of USERS of the software to be able to see and modify the source. This is a freedom granted by the writers of the software, and copyleft means that this right is ensured through any chain of modifications by additional authors.
In this same way, the GPL and like licenses are the most permissive licenses from the perspective of every eventual user
> the GPL and like licenses are the most permissive licenses
This is a deliberately confusing statement. It's fine to prefer the GPL over MIT/BSD-style licenses, but the term "permissive" is well-understood in reference to non-copyleft licenses. Misapplying that term just muddles the issue unnecessarily.
you are creating more confusion by selectively quoting me out of context. You left out "from the perspective of the eventual users"
You are saying that from the perspective of developers, taking open source software and not permitting users to see the source is... permissive. It's like the right to put people in jail is extra freedom, because you get the freedom to do that! I can't believe that's not in the bill of rights! I find that to be confusing.
I did not create the confusion that surrounds licensing, I'm trying to clarify it.
There is no irony, I think there is just confusion. The Windows license is much more restricting, you are never going to be able to ship Windows for your customers alongside your Windows kernel module unless you/they pay for Windows.
GPL allows you to distribute Linux for your customers at your behest as long as you satisfy certain requirements, namely, source. The way I view it, it is not adding restrictions whatsoever, it is actually adding allowances. More permissive licenses add even more allowances.
It's one of the core tenets of modern freedom, for example: you're free to say what you want (Positive Liberty) as long as it's not a threat of violence that would silence someone else, so that other person is free from your threat of violence (Negative Liberty).
That is not what the word "permissive" habitually means in the English language, especially if you consider a more broad view of users including those who are writing the software and integrating it into their products.
Not to say GPL is bad, just that the VAT-style "only the last user counts" view of things is playing with semantics.
> writing the software and integrating it into their products
That's distribution, not use. (Except for when they're testing it or running local instances, and GPL doesn't get in the way of those things.)
> Not to say GPL is bad, just that the VAT-style "only the last user counts" view of things is playing with semantics.
By my understanding VAT doesn't work that way. Once a user pays VAT and starts using something, that's it. The taxes are done with, and VAT doesn't pass on to later users.
> By my understanding VAT doesn't work that way. Once a user pays VAT and starts using something, that's it. The taxes are done with, and VAT doesn't pass on to later users.
VAT works something like this: when you buy X, you pay VAT on X. If you then sell X, you reclaim the VAT on X from the government. The last "user", the one that didn't sell X to anyone else (or integrate it into a larger product that they sell to anyone else) is the only one that effectively pays any tax once you draw the line.
I'm making a distinction between "user" in scare quotes and actual user.
If you did nothing but buy it, hold it, and sell it on, you didn't use the product. If you integrated it and sold it on, you didn't use the product.
Once you start actually using it, once it becomes a 'used product', selling it has no VAT and you cannot reclaim VAT. At least that's what google results told me. Were they wrong?
The whole point of VAT is that there is no such definition of "used product" or "end user". If you buy a book from a store, and have a receipt showing that you paid 1$ + 10 cents VAT, then you later sell the book to someone else for 2$, you owe the government 20 cents VAT on your sale - 10 cents which was already paid, so a total of 10 cents.
The exact law may be more complicated (you may have to pay the full 20 cents now and file for a 10 cents tax rebate; you may not be eligible for this if you are an individual and not a registered organization, etc.) but that shouldn't affect the basic principle.
For example, if you buy a computer for 100$+10$ VAT, and you then use that computer in you back office to keep your accounting, and you sell 1000$+100$ VAT worth of haircuts in the month where you bought the computer, you only owe the government 90$ of VAT even though you are an end user of the computer by any reasonable definition.
If you later sell the computer on to a refurbisher for 50$+5$VAT, and the refurbisher sells it on for 75$+7.5$ VAT, they will only owe the government 2.5$ VAT.
Oh, I think this explains why I was being lied to: "There is VAT on second-hand goods if the seller is VAT registered. Generally, businesses are required to register for VAT with HMRC once their taxable turnover reaches a certain threshold, which for the tax year 2021/2022 is £85,000"
So normal people don't have to pay VAT when selling used things, but larger entities do.
the VAT reference is that businesses don't pay VAT, only end consumers do. If you buy something and then integrate it into another product, then re-sell it you are exempt from VAT (details are more complicated, but it's _not_ like sales tax)
if you resell items, then you don't pay sales tax on them, so that part fits your description
VAT is not a sales tax because it's an income tax. That's what value added means, profit, income, the measure of the value you've added. Wether it gets hidden in the price or tacked on to a fake price makes little difference.
My understanding (based off a French accounting class from many many years ago) is that VAT also can be deducted for things like factory equipment or, say, desks for your office workers. It's not purely a "if it's for resale you don't pay sales tax" thing, but a "if this is used for business then you can get a deduction for your VAT" (with some exceptions).
I would not really describe VAT as an income tax. It's not a tax on an income, it's a tax on the value add. Income tax means something specific, and perhaps VAT is one degree away from that, but money is fungible! On a long enough time scale everything is inheritence tax and income tax I guess!
EDIT: rereading my original post at the start of this thread I now feel a bit silly saying the explanation is "VAT-like". Metaphors and similes are bad!
well, you have to admit its a little confusing. its so free, that by accepting it, I can constraint your future behavior (making it less free really), so that other people have the same freedom with respect to your contributions (being constrained) as you did
The philosophical stance of GPL is freedom at the individual human level - the only thing that actually matters if you are part of mankind. Yes, a society where you cannot "choose" to be enslaved is semantically less free than one where you can, but hopefully everyone agrees that for definitions of "freedom" which matter for human beings, the first society is a better choice.
>In this same way, the GPL and like licenses are the most permissive licenses from the perspective of every eventual user
No, take for example the real world use case of distributing ZFS on Linux in binary form. Users are unable to distribute it due to conflicting copyleft licenses. Copyleft licenses limits people by creating their own exclusive ecosystems which can't be mixed.
Good writeup on the intricacies and consequences of the Linux kernel being GPLv2 licensed.
The actual headline is debatable.
However, It seems to me that the license doesn't matter that much, since everyone has a vested interest in Linux being exactly the way it is, GPL_ONLY weirdness and all. It's unlikely that someone will show up and fork Linux and explicitly break the license (using GPL_ONLY symbols in a non-GPL context), because that person or company would be excommunicated from the Linux fold.
How feasible is it to avoid using GPL_ONLY symbols? Because if you for sure need GPL modules for some use cases[1], then I believe the point still stands.
[1] This is, being unable to even reimplement the functions yourself in a self-contained module.
Korg ships a module with their Kronos workstation that re-exports some GPL symbols as non-GPL.
They also ship the source for the kernel itself, but "conveniently" forgot to include a patch they added for DRM that makes their synthesizer module (yes the synth runs in kernel space) fail to work properly if missing. Some obfuscated change to the CD-ROM subsystem (yes really, they stuck some unrelated protection in there as obfuscation)
Wouldn't it just be better to reimplement whatever functionality they require themselves without recurring to GPL modules that break the license and expose them to legal risk?
zfs and nvidia work around it by requiring user intervention to apply the patch. Once the kernel is tainted by zfs or nvidia code, the user can't share it without violating the GPL (IANAL but that's my understanding).
In the era of always-on internet connections, this is a feasible solution, except it's the kernel, so perhaps ethernet and wifi drivers might have a bit of a catch-22 using this method :)
FSF is full of baloney about how static or dynamic linking is different than communicating for example through sockets. To be able to use the program I have to link it. What manner I choose to do that or available to me should not matter. I should also be able to reproduce portions of a program necessary for linking. Interoperability does not interfere with the legitimate interest of the licensor, or conflict with normal usage.
What? The FSF and copyright in general does not worry about static vs dynamic linking. They focus on "derivative works.".
The only question that matters is "does this piece of software derive from this other piece.". How they are linked together has no meaning. Hackers like to misunderstand that and think they can work around the GPL by how they bundle the two pieces together.
The CLISP case is a classic example. It bundled and dynamically linked readline, and as a result it got a significantly better command line interface. The author argued that this didn't make it a derivative works and didn't need to licence his code as GPL as a result. But that violated the terms of readline, which plainly says if you want to use readline to provide a powerful command line interface then you have to license your code as GPL.
You can always opt not to use the useful libraries and code that exist as GPL, but you can't take your cake and eat it too.
LGPL absolutely does care about linking. Section 4d specifically talks about shared libraries and requires you to be able to "re-link" the application with a modified version of the library, if dynamic linking is not used.
When people talk about how the LGPL isn't a good license, it's largely because A) C and C++ are really the only two systems languages for which dynamic linking is even an option and B) header-only libraries, templates/generics, and heavy use of inlining can make "re-linking" a statically linked executable basically impossible.
Yeah the LGPL gets a little technical, but at ita core it's really just saying there needs to be a way for the user to replace the LGPL library that is used.
If it was statically linked on then some sort of relink ability needs to be provided.
It's more like advice for people who want to incorporate LGPL software.
It wouldn't be? If the software was built for libedit then I'm sure that's fine.
In the clisp case it was clearly built for libreadline, and trying to unbundle and repackage it differently doesn't erase that fact.
What the courts will ask and what you need to ask yourself is, was the distribution model for a software done in a way to try to circumvent the spirit of the license?
Law and contracts are not code. They are not interpreted in the strictest reading of the words, but in a reasonable interpretation of their meaning.
Both libraries provide the same API and ABI. From application’s point of view there is no difference: it depends on the user’s choice which package is installed. Also, there is no intent to circumvent: it’s just that there are two implementations of the same thing, one GPL, one BSD.
You may not be able to distribute the combined work without violating the copyright of the GPL part, even if the other part is not a derivative work of the GPL part. If you really just distribute your part and let the user go and fetch the GPL part by his own means, the FSF has absolutely no say (and this is kind of what most propietary .ko kind of do); but if you also distribute the GPL part to the user...
I.e. if you never distribute/reproduce the GPL part, then the GPL obviously can not apply; if you distribute the GPL part, then the GPL terms apply to you, even if your work is not derivative, and even if those terms are "you must do the chicken dance so that we give permission to reproduce our software"; after all, that is how most EULAs are enforced. It just happens that in this case the chicken dance comprises some fancy definitions of linking and some extra things you may have to distribute rather than a exchange of money.
I wish the FOSS community would rally around this idea.
Re: GNU/FSF, I think they've done a real disservice to the FOSS community misrepresenting the state of American copyright law. I wish someone with credibility with devs/FOSS users would finally say: "This is such an illusion, it's mostly a joke."
The europa.eu articles (this is only one of them BTW) are about the case in EU where, indeed, copyleft goes only as far as MPL/LGPL/etc and of course EUPL - and note that this isn't 100% certain, it is just the most likely interpretation based on previous cases about interoperability.
However this only valid for the EU itself. When software is not confined inside the EU, e.g. one (even a member of EU) cares about distribution outside of it, then the difference between GPL and LGPL can matter. For example even if EU does not see a difference, US might do and unless your software isn't to be used outside of EU the distinction still exists.
The conditions you put in a software license must work within a legal framework. It appears that your license can't relicense my code, it only applies to your code. However linking or reproducing portions of your code for interoperability don't create a derivative work. This is of course not a legal advice.
FSF licenses are trying to take away rights from you that cannot be taken away.
No legal reality? After 30 years of numerous court cases, in various jurisdictions, all holding up the GPL? After many legal scholars weighing in on the matter?
That's potentially true with respect to dynamic linking, but if it's statically linked then you are literally distributing somebody else's code alongside your own so I can't imagine how that could be anything but a derived work.
It does mater the way the creator of the software licensed it. If the creators of the GPL specifically made a distinction between static and dynamic linking, then you're constrained by the distinction they made, if you agree or not.
There is a major distinction between static and dynamic linking, with dynamic linking you are releasing the work as is, with static linking and various optimizations you are clearly creating a derivative work.
It is the difference between a book citing another, and pasting large portions in.
Tldr; I see a distinction but probably disagree with fsf on dynamic linking.
> purveyors of proprietary modules have engaged in a number of tricks to get around GPL-only exports
There are many technical workarounds possible still. You could scan the kernel binary for byte patterns and build your own export list. How will the kernel maintainers plug that hole? (Maybe they can implement compile-time binary obfuscation, and sacrifice performance to stop proprietary code, wouldn't that be funny?)
I think that these efforts to prevent (what the kernel developers see as) "license infringement" through technical means sort of reveals that they don't really think that the line of reasoning would hold up in court.
I agree: neither Linus nor FSF have authority to interpret the GPL. The way you find out if a license is enforceable is if you take it to arbitration or court. There's not enough case law in this area to smooth out our understanding of what is and isn't allowed.
I'm hoping Software Freedom Conservancy's Vizio lawsuit will enable Linux users to sue over Linux GPL violations and get compliance. Currently only Linux copyright holders can sue, but Conservancy believes that users are third-party beneficiaries of the GPL and thus should have standing to sue for GPL compliance.
> You have use cases for binary kernel modules which need to be accommodated
I can't think of a single reason that binary-only kernel modules would ever need to be distributed. There are some cases when out-of-tree modules make sense, but in all of these cases, they could be distributed with source code, in compliance with the GPL.
> The userspace ABI is stable and intended not to cause anything targeting it to become a derived work.
> the only thing forcing modules to be GPLv2-compatible is the rate of change of the kernel mode ABI making it impractical to target it via cleanroom methods.
What is licensed is a specific source code version, not the history of previous versions. For a specific revision, there is no meaning to "more stable".
>> What makes userspace programs non-derived work is the syscall exception
And with the Google vs Oracle decision we know that APIs are not copyrightable anyway. If I can clone an API and create my own implementation then surely someone else can write programs that use my cloned implementation or the original.
If this were taken to an extreme then nothing proprietary could run on this kernel. That is not the intent of the code authors in many cases and frankly the wording of GPLv2 being so vague here is as Linus has said part of it's strength.
Given the very open context of how it's taken by the community the worst that will ever happen is the kernel eventually getting relicensed under GPLv2+Legal_Pedantry rather than nVidia or vmware being forced to open up their product codebases.
Frankly this then gets even messier when considering copyright law, frankly given the weird status of an ABI/API in legal definitions this is the fault of the courts not the linux-kernel or the software devs...
Is GPL even significant nowadays other than annoying programmers? A lot of commercial software are provided as cloud services and GPL has no effect on them anyway. If you are really a fan of the viral nature of GPL, you should be using AGPL anyway.
Several of the points in this article are either flat-out wrong, or are correct but being read in the wrong context.
> The licence is specifically GPLv2 and not “GPLv2 or later”, which is the default when applying the GPLv2 to software.
Because Linus didn't and doesn't want the FSF relicensing Linux with new restrictions to fit their specific political goals[0], on the basis that adding any further restrictions to GPL violates the spirit of the GPL. He's not opposed to using v3 software, he just doesn't like upgrade clauses on Linux.
> Linus Torvalds seems to speak as though he has the power to interpret the GPL. He does not; nor does the FSF.
Linus is a copyright holder. So is the FSF. While a judge would ultimately be interpreting the GPL in an enforcement case, the words of the copyright holder have significant weight when interpreting a license. So, if you write LKMs that infringe the GPL, the court will listen to Linus to determine where the boundary is. Likewise if you wrote infringing GPL plugins the court would listen to the FSF.
> Supposedly, the requirements of the GPLv2 do not apply to the userspace ABI.
Yes, because Linus said so. This isn't even an implied license thing; Linux has always had an explicit exception for the ABI.
It is actually an open question whether or not bundling an application with some GPL host program trips the GPL copyleft. The word "program" in the GPL is strategically vague here; it does not correspond to an address space. Two or more processes with IPC could be considered to be one program[1].
Related note: emulator developers writing GPLv2 or v3 emulators should seriously consider clarifying that bundling a game with an emulator doesn't make the game itself part of the same program as the emulator.
> Conversely, the Linux kernel project claims that the GPLv2 conditions do apply to the kernel-mode ABI.
No, quite the opposite. The Linux kernel project has claimed that kernel-mode symbols equivalent to the userspace ABI do not trip the GPL copyleft. That's why they have the GPL_ONLY DRM[2]; it's to distinguish between "running two programs in the same address space" and "merging a module into the same GPL program".
> If modules are derived works, then every non-GPL non-cleanroomed module is violating the GPLv2. This creates a ticking time bomb for companies which rely on this ability, because they could get sued by any contributor at any time.
> If modules are not derived works, the “GPL_ONLY” provision is meaningless and unenforceable.
Well, first off... clean room is not a legal requirement, it's a defense against the access prong of substantial similarity in an infringement lawsuit. This would apply if you were writing your own kernel that can run Linux programs[3] - you would need to defend against claims that you just copied Linux instead of writing a workalike.
Loadable kernel modules are not workalikes; they are additional programs that can modify how the Linux kernel works. To the extent that a loadable module modifies the original program or incorporates it into itself, it can be considered to be a derivative work. But since the userspace ABI has been explicitly opted out of the GPL copyleft, those modules can still use it. GPL_ONLY exists purely to technically enforce what Linus believes the license on Linux is.
>It is rather ironic that in some ways, one has more freedom in how one licences a kernel driver for Windows than the freedom one supposedly has in writing a kernel module for Linux. (...) Under such a model of copyright, the IBM PC could never have been reverse engineered and cloned, and the computer on which I am typing this would not exist.
Oh boy.
You're allowed to write kernel drivers for Windows because Microsoft explicitly said that you could. Linus does the same thing with GPL_ONLY. I'm pretty sure the NT kernel has it's own internal symbols you're not allowed to link with, and Microsoft could allege in court that doing so creates an infringing derivative work. The confusion doesn't come from the GPL, it comes from copyright law.
This, again, has nothing to do with cloning; Compaq didn't need to ship code that links with the IBM PC BIOS. They needed to ship code that replaced it entirely. There is a difference between replacing a program and linking with it.
The article also alleges that a single Linux contributor could pull an SCO and sue every company that's ever written non-GPL kernel code. I don't think that would actually work, because the userspace ABI exception that spawns all this is part of the license that the contributor implicitly agreed to when they modified Linux and sent that code upstream. Furthermore, every contributor is downstream of precisely one copyright holder: Linus Torvalds.
If you don't have a license from Linus to modify Linux, then you own nothing and cannot sue. So you're arguing that Linus gave you permission to modify and sublicense under specific rules he selected, but that he's not allowed to interpret those rules at all because you made a small part of Linux? That's probably not going to fly in court.
Also, related note: at one point the FSF was seriously mulling rolling AGPL into GPLv3, which is insane.
[1] Most browsers are structured as IPC process networks nowadays, and contain loads of permissively licensed, LGPL, and proprietary code all mixed together. If GPL "programs" were just address spaces, then they could spawn GPL code in a subprocess to evade the copyleft.
[2] Digital Rights Management, not Direct Rendering Manager.
[3] Examples of such programs would include iSH and Windows Subsystem for Linux (version 1; v2 actually runs the Linux kernel).
> No, quite the opposite. The Linux kernel project has claimed that kernel-mode symbols equivalent to the userspace ABI do not trip the GPL copyleft. That's why they have the GPL_ONLY DRM[2]; it's to distinguish between "running two programs in the same address space" and "merging a module into the same GPL program".
> Compaq didn't need to ship code that links with the IBM PC BIOS. They needed to ship code that replaced it entirely. There is a difference between replacing a program and linking with it.
Does the Linux license (with the GPL_only thing) allows you to replace open source modules with self-contained proprietary ones? For this I mean, let's say I want to build a proprietary network stack tailored for a given hardware I'm building. In such case, may I do it as long as I write it from scratch and run it in kernelspace as a module? If that's the case, why do kernel infringements occur? Why wouldn't everybody just reimplement in their own proprietary way whatever they have to? Why is closed source DRM/anticheat non-existent on Linux?
> Linus is a copyright holder...So...the court will listen to Linus to determine where the boundary is
This seems completely insane. If I become a programmer on Monday, and download the Linux source on Tuesday, and read the license file on Wednesday, and publish code on Thursday, and Linus sues me on Friday, am I going to be penalized by the judge because I didn't read random LKML posts by Linus? Surely the license is self-contained and provides me with all of then information I am reasonably required to have.
In this particular case, we're talking about a license clarification that gives you more rights than you otherwise could. So, if you hadn't read Linus's interpretation of his own license, you would think that you always had to GPL your LKMs. So there's no point in which Linus could actually sue you for not reading his LKML rants - they strictly increase what you are allowed to do under the license.
If this was the opposite case - say, Linus saying that the GPL required something that the text of the license said it didn't - then a judge would probably be inclined to not listen to Linus.
There's two fallacies engineers commonly get tricked by when talking about the law:
- "Code is law"[0]: the belief that legal protections, contractual clauses, and so on can be replaced with technical protection measures and "smart contracts".
- "Law is code": the belief that judges are merely human interpreters for an English-language-shaped virtual machine that contracts and laws are written in.
These fallacies are dual to one another; the root cause is a fundamental misunderstanding of how laws work. Judges are not merely tasked with executing a computer program in their heads; they are allowed and expected to actively comprehend and rewrite the law based on the facts at hand. "Legislating from the bench" is a deliberate feature, especially in "common law" jurisdictions where prior rulings are allowed to be treated as good as actual passed-by-Congress laws.
A good example of how this works would be Oracle v. Google. Strictly speaking, as much as we hate Oracle, they had the most meritorious argument, and they were trying to enforce the GPL. If you take copyright as a given on software, then that copyright can be applied to the thinnest sliver of creativity present in that software. Yes, even lists of function names and signatures alone should be copyrightable, and the GPL copyleft should trip if you copied them. However, the entire software industry did not actually consider these to be copyrightable, and acted as if they weren't. In fact, even Oracle's own cloud division was busy doing to Amazon what they were suing Google for doing to them. When SCOTUS saw this, they actively decided to change the law in favor of Google because it was the interpretation that most actual copyright holders in the industry had been operating on.
Actually, if you only read the license files included with the kernel source, you'll be very confused and unsure of what you can actually do. The GPL is painfully vague, and there have been endless debates about how it applies to kernel modules, programs, etc. (such as this very one we're having now). (And I'm taking into account the clarification files in the source). Linus' LKML clarifications are post-hoc and not linked in the kernel files anywhere. I do agree with you that the GPL_ONLY "code is law" theory has some merit - and certainly a judge could use that as part of a ruling to uphold that interpretation. But I don't think that this aspect of the kernel license is going to be tested in court any time soon, so it's all speculation at this point.
The insane words are ones that you made up. The documentation is literally in the source code. If courts need to understand precisely what it means as it applies to a particular case, yes they can call Linus as an expert witness.
I remember watching this years ago and getting really pissed at Linus. At the time I didn't actually get what he was getting at, and just assumed he was just standing in the way of Stallman grabbing half the computer industry by the balls/ovaries and demanding they never lock down a CPU ever again.
I rewatched this about a month ago and it has aged like a fine wine. As much as I personally like GPLv3, Linus was in the right to reject it. GPL has a no-further-restrictions clause for a reason, and the license upgrade mechanism should not be used to circumvent the intent of that clause just to make a stronger copyleft. In fact, I'm starting to sour on the concept of supra-GPL-strength copylefts in general, because going any stronger than GPLv3 requires interfering with freedom zero in some way.[0] This is supposed to be a software commons, after all.
[0] AGPL is designed to force users to retain what may be an antifeature to them. SSPL tries to force users to embed said antifeature into anything remotely related to the program. "Ethical Source" licenses try to enforce moral restrictions with economic rights.
> "The SCO–Linux disputes were a series of legal and public disputes between the software company SCO Group (SCO) and various Linux vendors and users. The SCO Group alleged that its license agreements with IBM meant that source code IBM wrote and donated to be incorporated into Linux was added in violation of SCO's contractual rights. Members of the Linux community disagreed with SCO's claims; IBM, Novell and Red Hat filed claims against SCO."
Is there any legal significance to "clean-room" reverse-engineering? I hear this term a lot from engineers who seem to think that they're entitled to claim ownership over distinct works created by people who read their source code (and in extreme cases their documentation or even disassembled binaries), but that's not how any other form of intellectual property works.
Yes, there is significant legal precedent for the practice. Sony v. Connectix, Inc. comes to mind. Team A directly reversed Sony's PS1 BIOS and gave the resulting specifications to team B, which then implemented those in source code form.
This is the difference between patents and copyright.
A mechanism that is patented can not be implemented by anyone. It doesn't matter if they did or did not read your source, they cannot implement it. It doesn't even matter if they knew the patent existed or that even that it had been done before.
Copyright is a lot more forgiving. It only covers the exact implementation. Doing a clean room implemation means you will write different code that does the exact or very similar thing.
While it's not ideal to have Linux being used in ways that aren't permitted by the license, it's not necessarily a violation of anyone's rights. These license-incompatible uses of Linux are ongoing and readily apparent. There's a decent argument to be made that anyone contributing to Linux should have reasonably expected that their contributions would be used in this way, even if it wasn't in the license. Courts have to deal with resolving disputes where the terms of agreement weren't clearly documented all the time.
Obviously that's a bit flimsy and it'd be preferable that the license be bulletproof, but it is what it is. It only becomes a problem if someone gets litigious. If that happens, and it's someone who's made a small contribution, then their code can probably just be purged and rewritten. If it happens with a bigger contributor, then the argument that they should have known what was going on becomes stronger.
The problem (for me) is that nowadays most of our IT infrastructure depends on Linux. Depending on an operating system hoping that nobody ever gets litigious because it's licensed in such a way that it creates this risk is, for me, a bit problematic.
This has always been the case. Most operating systems are based on UNIX technology and SCO once tried to sue almost everyone based on that. These things don't happen often in practice because big companies want to support customers, not to sue them. And in case someone like SCO appears, big companies have deep pockets to make agreements with them.
> So if you violate the licence, it is terminated. That's it. Given that “you” may refer to a corporation, this creates the following disturbing possibility:
GPLv3 fixed this, after being notified of a violation, you have 30 days to remedy it
Firmware of TP-link routers is licensed under GPL. But would anyone of you get the source code? They say they provide machine-readable source code. I don't quite understand what it means.
GPL 2 says "machine-readable", which I read as meaning on a tape or ftp site or something in a useful form, not handwritten on paper or similarly useless form. Also, I doubt obfuscated code would comply with the "preferred form" part.
I read that as minified/obfuscated. Which is not gpl compliant (not going to quote directly but there's language in there about having to provide the source in is preferred form for editing).
by using copyright law as an enforcement mechanism, these licenses make terms which govern behavior controlled by users -- terms which are practically unenforceable
this article is a ridiculous charade, starting out saying that
people like Linus don't have the power to interpret the GPL then he goes on for many paragraphs with a more outlandish interpretation of the GPL than i've seen in a long time.
There is a difference between derivative works and composite works. Please learn it. (This specifically applies to the userspace boundary discussions in this article, but for modules it's not 100% clear-cut either.)
I'm not going to try to explain it here because I'm not a lawyer and don't want to propagate what could be my flawed understanding. I do think I've understood it and that it matters here. There's probably a few good explainers from legally versed people out there on the WWW.
Never mind a clean room interpretation; if we can get one project to wrap the ABI and everyone build against that project then there's only project that can be sued :-)
It's just the convention on HN to put the year in the title when it's an older story. Users often point it out as a hint to whoever can add it to the title. No criticism is implied!
GPL is a nice idea...but you need lawyers lots of money and time. I hate lawyers and i don't have time for that bs nor do it have/want money to spend for lawyers, i was a diehard gpl evangelist in my 20`s, now it's BSD/MIT/ISC (and not diehard anymore...more like IDGAS)...and i really don't care for religion anymore...just quality and real freedom.
> and i really don't care for religion anymore...just quality and real freedom.
The freedom that GPL is about isn't about the developer's freedom to do whatever they please but about the user's freedom from the developers' whims. This isn't some arbitrary nebulous religion-like dogma but comes from the very practical issue of developers inherently having power over the programs they write and, by extension, power over the users who rely on those programs.
Remember that the entire free software thing didn't start because the Emacs god visited Stallman in his sleep but because he was denied access to the source code that would help him fix his lab's printer.
>GPL is a nice idea...but you need lawyers lots of money and time.
This applies to any license. BSD/MIT/ISC rules can be broken as well and the only means to rectify it in the case that the other party refuses to cooperate is to resort to litigation.
That was probably done because of laziness or incompetence and not for financial gain. The financial loss of attributing someone is very tiny compared to having to release all of your source.
My company does whatever it can to comply with GPL requirements and it is nothing short of a goddamn nightmare. Nothing like sitting in a conference room for hours with lawyers while we poured through the licenses for 250 different packages; we would have been better off just burning the money. My conclusions are that most Linux distributions are an amalgam of software packages with licenses that are fundamentally incompatible with each other; the GPL is extremely poorly written with lots of vagaries. I don't think there is a path to 100% compliance; you just make sure your heart is in the right place and hope for the best.
Ultimately, we concluded we are moving to BSD on future projects where possible. Not because of some overwhelming need to keep source closed from customers, rather just to avoid the mess.
So why don't you just use commercial software and skip all this? I will answer this question: because you and your company don't want to pay for it! If your company had to pay for every library and application that you now use for free because of GPL software, you probably wouldn't be on a job in the first place. So, yes, I think GPL is doing a good job, and I'll never write a single line of code that is at least not GPL.
>So why don't you just use commercial software and skip all this?
Because commercial software have even worse licenses than the gpl is.
And btw, developers are much more expensive then software, linux is not everywhere because it's free but because it need's less maintenance then windows (serverside that is). And exactly because of that VMware is still making lots of money.
Those 250 packages likely don't have custom forks of the GPL license. Handling of legal requirements for each package should be templatable by management based on whether a particular package is GPLv2, GPLv3 or AGPLv3 and has a linking exception.
>Ultimately, we concluded we are moving to BSD on future projects where possible. Not because of some overwhelming need to keep source closed from customers, rather just to avoid the mess.
It makes sense that developers or slave owners want different freedoms then users or slaves. If your code was BSD or GPL do you still need a layer ? If you are not a slave owner you are not affected by the fact there is a law that does not allow owning slaves.
I will not stop, that exact thing was used to justify that America is the land of the free because you have the freedom to own slaves, the same way BSD is the land of the free because you can take all the freedoms from the users.
Am much much older, but I won't stop because you don't like a perfect valid thing, do you want to censor me or the books where that phrase was printed?
I will also not stop using it each time some dev or software publisher attempts to use a the word "free" in a undefined way to promote something that takes freedom away from others. If you want people stopping doing this you need to be honest and clear, say "BSD gives developers and publishers more freedoms" , or "from a developer popint of view BSD is offering freedom where GPL puts restriction on taking away those "pesky users/products" freedoms" .
I could do an analogy with order relations and ordered/unordered sets but might be too complex so previous well knows quote does the job done, your are the first that got offended so far, maybe you can reflect on why you are so special.
> Am much much older, but I won't stop because you don't like a perfect valid thing, do you want to censor me or the books where that phrase was printed?
You compare a free license with slavery....no one forces you to work on a project that uses BSD/MIT/ISC, also no one forces you to live in the US, that's the "small" difference, no one takes your freedom away.
>You compare a free license with slavery....no one forces you to work on a project that uses BSD/MIT/ISC, also no one forces you to live in the US, that's the "small" difference, no one takes your freedom away.
No, I am not comparing that. You are doing the "comparing" of things that are not comparable. and I am failing to explain , maybe if you know math you understand this
(1,-1) and (-1,1) are not equal but you can't define a natural comparison, if you ignore a component of the vectors you can compare them or if you invent your custom subjective comparison rule you might,
Replace those 2 vectors with BSD and GPL, they are not the same and you can't compare them because there are 2 dimensions, user freedom and dev freedom.
If you ignore a component you can compare them, or if you define your own metric then you can say "from a dev point of view BSD is better" and if you say this I will say "True". What people do is something like "BSD is more free then GPL" but ignore the user, the GPL requires you do the decent thing as when you use a GPL code you don't make it less free. so you are not free to make something free less free, you are not allow to remove freedom from something.
The other way to avoid this would be to lean copyleft for your own codebase(s). If they're made public and you include the appropriate source code references for the dependencies you rely on, then you should be in the clear legally (and perhaps morally, although that's a separate topic).
I believe there may be some reasons why you may want proprietary (or incompatibly licensed) kernel modules. In such cases, as long as you didn't take code from the Kernel, I believe it shouldn't be considered a derivative work. I believe my opinion is quite unpopular and not share within the FOSS community.
I honestly speaking prefer BSD or MIT for the linking purposes. I believe forbidding linking makes it too restrictive for some use cases.
Particularly striking to me is this sentence: "It is rather ironic that in some ways, one has more freedom in how one licences a kernel driver for Windows than the freedom one supposedly has in writing a kernel module for Linux. "
It makes me believe there's something wrong in the current state of things.
> I believe it shouldn't be considered a derivative work
Isn't the point of the majority of this document, that nobody, not individual rightsholders, nor the FSF, not even the Linux Kernel Project, has the legal authority or knowledge to interpret the LGPLv2. That fundamentally the LGPLv2 is a legal document and therefore the only people able to create an interpretation of this document are lawyers, and even then, their interpretation is subject to how a judge might decide in a court of law?
So therefore, your beliefs, my beliefs, anyone's beliefs on this are mere conjecture or supposition, and can be considered essentially worthless. Ultimately, how it plays out depends on legal precedence, jurisdiction, judge, hell- the weather on the day of the trial and the specific circumstances in which it is brought up in the court system.
Ergo, isn't it more than a little presumptuous to debate on this matter? To put forth your opinion and opine it as what you believe, and therefore as some degree of possibility or fact, despite there being essentially no reference point unless a lawyer was actually contacted and was able to provide an interpretation?
Sure, but when I was a kernel dev I considered it a reasonable line: it's not that hard to create your own kernel if you want a different licence.
It was one reason I worked on the kernel: that all your software should be hackable. I probably would have found something else to do if the licence were different.
I think this whole part applies as much to the text of the GPL itself as to the common Linux explanation. The GPL draws a distinction between dynamic linking, static linking, and use over a network or through a CLI style interface to decide if a work is a derived work of the GPL program. But, this distinction is just a novel legal theory proposal at best - there is nothing in copyright law that would make the GPL distinctions authoritative.
A license simply doesn't get to decide what constitutes a derived work - that's entirely up to copyright law itself and the court system to decide.
On the other hand, unless and until Congress decides to explicitly legislate how copyright should apply to software, the courts can very well take common industry practice into consideration for judging what is and is not a derived work of a program, and in this sense the Linux kernel developers' opinion is in no way less impactful than the proposals in the GPL itself.
Furthermore, in a matter of contract law (so assuming that the work is indeed judged to be derived according to copyright law, but now judging whether the GPL may offer some relevant exemptions), the stated intentions and interpretations of the parties of the contract are indeed relevant. If there is a long history of kernel developers publicly stating that as long as you are not using GPL_ONLY symbols, your work should not be considered to be under the purview of the GPL, and if this has not been commonly publicly contested, I think that in an actual trial this will matter much more than other interpretations of the GPL.