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