They didn't publish their reasoning, but I'm going to go with actual lawyers who specialize in copyright but don't publish their reasoning, over non-lawyers who do publish their reasoning
The faith based argument then? Based on the speculation of lawyers who are not confident enough to set let it see the light of day?
I would like to see your citations, from lawyers, that say that they have no prayer of succeeding.
I would like to see you citations, from anybody, that demonstrates (or makes even a shred of an argument) that they do.
Which is a district court case, thus not binding precedent anywhere. The arguments presented to it were likely different from the ones that would be presented in a GPL case, too.
Legal decisions are based on actual legal arguments. Baystate v. Bentley Systems explains the issues and precedents clearly enough that it is enormously influential, whether it is binding or not.
But most important, it doesn't really cover the same issue.
Sure it was. See below.
At stake there was the similarity of two programs that were meant to read the same data format. The court concluded that there was no copyright infringement, because any similarity (including the use of identical data structures) was a necessary result of the fact that they had to accomplish the same function, so it was permitted under the merger doctrine.
And a plugin must likewise make use of the technical interfaces of the host program, which requires making use of all necessary meta data about that interface in its construction. There is no logical distinction between a plugin's use of the interface provided by a host program and an application programs use of the interface provided by an operating system.
The essential elements of technical interfaces have been held to be unprotectable in multiple court cases, including the Ninth Circuit Court of Appeals case, in Sega v. Accolade (1992), not to be protectable by copyright. Baystate v. Bentley systems is just the most recent and most detailed one. See also the scènes à faire doctrine laid out in Computer Associates v. Altai (1992) and Gates Rubber v. Bando Chemical (1993), Second Circuit and Tenth Circuit decisions, respectively.
A plugin's sole purpose is to incorporate into the larger work; it has no function without it.
So what? Utility doesn't have _anything_ to do with whether someone has copied protectable elements into the plugin. That is just plain stupidity, wishful thinking, opportunism, etc.
As to the idea that the _end user_ has created a legally restricted derivative work, you can see my other comment in this thread, but generally there (1) is no creativity exercised, meaning the combination is not a "work" (2) the combination is ephemeral, meaning the combination is not "tangible" (3) this is an excellent case of the sort of thing Congress intended to fall under the category of "fair use" (4) Anyone who doubts that should refer to 17 USC 117(a) about the specific exemption for "adaptations" necessary to make use of a program, and of course the general stupidity of thinking that for example, a user has created a legally prohibited derivative work by making two separately distributed modules interact on any level whatsoever, something that would make the software industry impossible.
[re: the FSF attorneys actually "determining" anything.] Well, yes. A lot of lawyers contribute to the FSF's position on these things, and they have professional opinions on what they believe the correct reading of the law is
Lawyers don't "determine" anything. They present _arguments_ on behalf of their clients, grasping at any straw available, no matter how specious, in an attempt to defend the position of their clients, no matter how silly.
Remember here, so far as reference to either organization's website is concerned, or any available court case, none of the lawyers here have actually made any sort of legal argument on this point at all. If this particular issue ever actually went to trial, the burden of proof would be upon them to establish the proposition that such a ridiculous position has any legal foundation whatsoever. _All_ the available legal precedents run in exactly the opposite direction. Baker v. Selden (1879) and Baystate v. Bentley Systems (1996) for example.
The reason why issues like this rarely go to trial is because the attorneys when staring reality in the face realize they cannot win arguments without a legal foundation to stand on. Several statutory provisions (e.g. 17 USC 107 and 117(a)) and half a dozen court cases tend to be rather intimidating to an attorney thinking of actually going beyond the bluster stage.
Including a specific, unique copyrighted file, with intention to include just that file, is more than using a technical interface. It's using a specific implementation of that interface. Remove the original part, and new part ceases to be what it is intended, marketed and sold as. The new part is clearly derived from the original, expanding on it. If the new part is distributed alone, but with the intention of a specific original work being combined with it (as proven by eg. installation instructions telling how to get the original work required by the new work), then I think copyright law does view that as distributing a derived work.
You should read the Baystate decision. "Including" a file when compiling a program doesn't generally cause a "copy" of the information in that file to be included in the resulting binary. The compiler merely "refers" to it, and gathers out facts necessary to use the proper technical interface. The "protectable elements" are not copied into the resulting binary at all.
Copyright does not protect ideas, it protects expression. In general, referring to a "include" file is about as relevant as looking up something in an encyclopedia when preparing a research paper. cf. Baker v. Selden (1879).
Reasonable people unfamiliar with the law imagine it protects all sorts of things which both the statutory law and the case law specifically exclude. This is one of them.
If you put a copyrighted work to the cloud storage (can't get much more intangible than that), it's no longer under copyright? And I'd say both the original code, and the new code using it, and their combination in memory, are original works. How could they not be?
In the copyright sense, "tangible" means physically recorded in a durable manner. If you want to sue someone over a copyright violation your work must be physically recorded on a medium you can submit as evidence. Just because you _can_ transmit or represent something in an ephemeral manner does not mean it is _incapable_ of tangible representation (such as a printout or on a compact disk). Cloud storage is more than tangible enough, although you would have to copy your work onto separate durable media to properly establish that you actually created something protectable by copyright.
"Original", on the other hand, means demonstrating creative expression. "Sweat of the brow" does not demonstrate originality, nor does mere aggregation. If someone loads an application program plus a plugin into memory, they have not created a derivative work in the copyright sense of the term, because no creativity has been exercised. That doesn't mean the copyrights of the individual components have been invalidated, just that strictly speaking no "derivative work" has been created.
Even if the considerations of originality and durable representation were held not to apply, such that a potentially restricted "derivative work" had been created by the end user merely by loading two programs onto the same computer or into memory simultaneously, the latter (which would be the party that would have to be sued) has two defenses. The first is fair use, and the second is "use necessity".
17 USC 117(a) specifically exempts the preparation of "adaptations" of computer programs by an end user to the degree such adaptation is necessary to for them to use the program. That includes making durable adaptations, not just ephemeral ones (e.g. in memory).
A lot of copyright lawyers worked on the FSF's determination of what's a derivative work in software. Have any lawyers supported your opposite conclusion? If not, why do you think you know more than copyright lawyers about how to apply the case law on derivative works to software?
You think the FSF actually "determined" something? It is much more likely that they are grasping at straws trying to come up with anything that supports their position, because their idea of a derivative work has no trace in statutory or case law, at least in the United States. In fact the case law runs in the _opposite_ direction, holding (for example) that technical interfaces are not protectable by copyright (cf. Baystate v. Bentley Stems (1997)).
And if they are not grasping at straws, how is it that the FSF website has no trace of a legal argument on the subject? The only thing the SFLC website appears to say on the subject is the following footnote:
FOSS licenses differ explicitly or customarily in how they define the scope of derivative works. For example, GPL licensors usually have an expansive view of what a derivative work is, or assume that the underlying copyright system supplies the appropriate expansive definition (A Legal Issues Primer for Open Source and Free Software Projects, SFLC, 2008)
The reason I suspect there isn't any legal argumentation in favor of the FSF's dubious conception of derivative works is there isn't an argument with a prayer of succeeding. If anyone has any citations to the contrary, I would very much like to see them.
Having your work explicitly include/import/require (using that scripting language command) a file that has unambiguous copyright held by somebody else sure sounds like deriving from that file.
The end user, in memory, mayble. Unfortunately copyright only applies to original works of authorship fixed in a tangible medium of expression, and an in memory combination is neither tangible nor original.
If there are several version of the file available (like C stdio.h or something) then I think the copyright holder of the original would have to prove that derived work derives from his version of the original and not somebody else's. But in many cases, the imported file is available from only one source, and there's no ambiguity like this.
In Baystate vs. Bentley Systems (1997) a U.S. district court ruled that "technical interfaces" are not covered by copyright. There are good reasons for that. See here [pdf].
I'm not so sure that can be considered "safe". Courts tend to frown on technicalities, and might not see any real distinction between your shim version and the equivalent code without the shim. The need for license compatibility may end up being transitive.
I see it less like a "technicality" and more like "safe harbor". If it were a technicality, every Win32 program would be a derivative of Microsoft Windows, for example.
I don't know what the Win32 terms are but I doubt they are as infective as GPL.
This wouldn't matter if the FSF/SFLC were right about derivative works. By mere compatibility, every Win32 program would become a derivative work of Windows, and Microsoft would have to _grant_ you a license if you wanted to distribute it.
In addition, with the possible exception of non-trivial inline functions and macros, no amount of header file inclusion is going to affect the derivative work status of a program compiled using those files, on the grounds of triviality and functional necessity.
With the above mentioned exception, a compiler does not "include" the contents of a header file into a produced binary, it merely refers to the information contained to produce a compatible object file.
When you choose to include a library in your product and therefore depend on it, you are agreeing to the terms. If you don't agree with the terms, that doesn't mean you can still use the library
I agree you can't "include" a library with incompatible licensing terms in your product. That doesn't mean you can't _depend_ on it though, if the customer can acquire a legitimate copy by any other means.
And by the way, a "license" gives you permission to do things that you do not otherwise have the right to do. No license can take away rights you already have. You need a "contract" for that.
So if you acquire a legitimate copy of any software library, you can use it any way you want that is not otherwise restricted by law. No license is required to use that which you own. If you want to restrict use, you need a patent or a contract, not a copyright or license.
This does not necessarily contaminate the source itself, which only references the header files by name, but the resulting binary would incorporate at least some kernel code (e.g. macros, inline functions).
Copyright only applies to creative expression. To the degree the contents of the header file are a representation of simple facts (e.g. manifest constants), mere use of those facts does not apply. Copyright has also been held to exclude functional necessity, which means that use of function declarations and other similarly trivial macros isn't a problem either.
The problem arguably comes when one references inline functions or macros that aren't trivial. If they are necessary aspects of the interface one might be able to raise a legitimate defense of functional necessity. But certainly the safe method in this case is would be to write a shim that does include the kernel header files and a separate module that only talks to the shim that does not.
Not that I am a big fan of binary blobs by any means - I think all customers should get source code to things like non-standard kernel modules as a matter of principle. That doesn't necessarily mean they should necessarily be able to give copies away, but they should at least have the source code wherever possible. The federal government requires it.
Finally - all this academic stuff aside, American copyright law doesn't clearly define what a derivative work is. Much like fair use, in cases of dispute it's up to the court to decide where the line is drawn so quite frankly
Courts have rules of statutory construction, and one of them is that they can't just make a term mean anything they want it to mean, but rather must interpret it generally as the ordinary, common meaning of the term at the time time the legislation was enacted _and_ in accordance with the meaning implied by the text of the legislation itself.
The FSF / SFLC wants the line to be drawn so far away from the ordinary and common meaning of the term derivative work or that which can be gathered from the statutory text that they don't have a plausible legal foundation to stand on.
In the Anglo-American system of common law courts do make potentially binding clarifications of the meaning of laws within those intrepretive constraints, and guess what: what the U.S. courts have decided about the meaning of derivative work is the obvious "copy with modification" meaning, not the legal fantasy promoted on occasion by the FSF and the SFLC.
Here is the U.S. Copyright Office on the subject:
A derivative work is a work based on or derived from one or more already existing works. Also known as a "new version," a derivative work is copyrightable if it includes what copyright law calls an "original work of authorship." Any work in which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship is a derivative work or a new version. A typical derivative work registered in the Copyright Office is a primarily new work but incorporates some previously published material. The previously published material makes the work a derivative work under copyright law. (See here [pdf]).
There are definite advantages to such a system: firstly it's a LOT more democratic. You need a lot of lobying to get a law changed by the legislative branch but anybody can bring a court case, including on a matter that was not previously IN the law (here that is possible) and if you win - it BECOMES law.
There are a lot to be said for the advantages of judicial supremacy, but "democracy" is not one of them. More like government by wise men. Of course some countries have constitutions or unwritten legal traditions that give some justification to such rulings beyond the exercise of raw power, but anything that a court can do or prevent that is not in principle overridable by popular vote (by constitutional amendment perhaps) is not democratic, but rather the opposite.
The fact that all your legal experts who actually understand the GPL, including people like professors Eben Moglen and Larry Lessig thinks it's what the law says ANYWAY kind of makes your questions... well rather silly. I think they know the law better than you and they have full confidence that the GPL's interpretation is entirely accurate.
Eben Moglen consults for the FSF. That means he is duty bound to try to protect the interests of his client, even if it means grasping at straws. That said, I would like to see him try to make an actual _legal_ argument in favor of the FSF's position on this point. I don't think Lessig has addressed this particular issue either, but if you have any citations I would like to see them.
Is that so ? The windows API is ALSO a proprietary library. It just happens to come with a license that specifically permits derivative works from linking.
Yes. First of all an "API" is an interface, not a library. People can and do make alternative implementations of an interface, which is one of the reasons why mere compatibility does not a derivative work make. A derivative work is basically a copy with modification.
Second, a "license" cannot take away rights you already have. By definition, a license can only give you permission to do what you did not have the right to do previously. No license to Windows is required to use a legitimate copy of it, for example, nor can any such license restrict what you can do with a copy that you own, beyond that otherwise prohibited by law.
If you want to restrict what people can do with your software you need a _contract_, not a license. Alternatively, you can lease a copy of the software to them, instead of selling them a copy.
I speak of U.S. law in particular, but the law of most other countries on the matter is similar. U.S. copyright law was changed in 1978 in part to match an agreement called the Berne Convention.
Due to the nature of PHP, yes. The PHP interpreter could not interpret the theme in the absence of WordPress code. It is incorporated in the most explicit manner.
Sorry, no. Utility / ability to use has nothing to do with whether something is a derivative work. Nor does a plug-in in and of itself necessarily incorporate any of the code of what it is capable of being "plugged" into. A Win32 program is not a derivative work of Windows, for example.
Now there is perhaps a vaguely reasonable argument to the effect that a temporary derivative work is created in memory by the end user when running the two components together. However, copyright only covers "original works of authorship fixed in any tangible medium of expression" and a temporary combination of the two is neither tangible nor original.
This is like the GPL libraries. If your project uses a GPL product, does it become GPLed too (and you want distribute it)? Yes, it does
Not even close. No license has the magical power to infect something that uses it. A license may affect your ability to distribute the original work and/or a clear derivative (i.e. copy with modification). Use dependency does not make something a derivative. Interface compatibility does not make a derivative.
Any claim to the contrary is wishful thinking on the FSF's part. The FSF and the SFLC are basically propagating a fiction with no legal foundation whatsoever, the sort of nonsense that would make any Win32 program a derivative of Windows, or my desk clock a derivative of the power grid.
2. If software S links with G, in the conventional static or dynamic way (i.e., incorporating a.a or.lib file into an executable when the executable is built, or loading a.so or.dll along with the executable at the time it is run), does mean that S must be GPL'ed, too
Not true. It is necessary to license S as GPL if you want permission from the authors of G to distribute S and G together. It is not necessary if you plan to distribute S by itself (no G). I have yet to see a trace of a _legal_ argument otherwise.
Now that may very well be something the license to G attempts to restrict, but the license to G has no bearing on the distribution of S by itself.
If YOU were write there wouldn't be any business proposition to develop ANYTHING but complete apps - there go all the companies in the world that make money out of licensed libraries. Including free software companies that dual-license and let you pay for the privilege of creating non-free apps - MySQL did that, QT still does.
That is an argument for how the law should be, but does not have anything to do with the law as it stands. I agree that the issue (were it a question of law instead of wishful thinking) would be interesting for producers of open source libraries, but not really for proprietary ones.
There are also thousands of commercial developers who create and sell LIBRARIES - by your logic this is impossible since there is no reason to buy a library -just make sure your customer has the same one and you can link it to write apps from all you want.
Commercial applications must generally be distributed with the libraries they require, or the end user must legitimately acquire a copy by other means, so this doesn't affect the proprietary application / proprietary library business at all. It certainly affects the prospects of the dual licensed library business, but not all that much, for the same reason.
It's very clear that no court in the world will accept THAT as a tenable scenario - that a programmer who writes a library is worthy of lesser copyright protection than one who writes an application. Because you effectively destroy all copyright protection for basing your app on a library written by anybody else - thus removing all motivation to every write libraries for anybody but the hobyists.
What you describe isn't _copyright_ protection at all. Copyright governs copying, distribution, public performance, and the preparation of derivative works. Outside those restrictions copyright has absolutely nothing to do with how someone uses what he or she has legitimately acquired.
In addition, Courts are supposed to decide what the law is, not what it should be. Otherwise they are acting as an unelected legislative branch. Legislators might take that into consideration if they were undertaking a _major_ revision of copyright law (starting with a repeal of the first sale doctrine, for example, and the idea that one can actually legitimately _own_ a copy of anything) but it is not a question the courts can decide.
The legally established concept of "derivative work" is as clear as a bell, and interface compatibility isn't it. If the dual licensed library folks think a sane interpretation of the law will defeat their business model, they should petition Congress to have the law changed.
Considering that Congress is probably sane enough not to make every Win32 application a derivative work of Windows, for example, the petitioners should suggest some other alternative that doesn't cause far more harm than good when taken seriously.
You have no rights to use the GPL code, unless you agree to the GPL licence and thus its provisions regarding the derrived works. This is well established in legal precedents.
I seriously doubt this is actually the case, but you can feel free to start quoting some legal precedents. There are pending court cases about "copy ownership" that pertain to questionable propositions about "use rights", i.e. the suggestion that a manufacturer can dictate what you can do with a copy of something like a CD after you purchase it, beyond the restrictions provided for in copyright law itself.
That said, the question of use rights is largely irrelevant. If the plugin is not legally speaking a "derivative work" (and the claim that it is is ridiculous), and the plugin developer is not him or herself distributing WordPress, then the license to WordPress is irrelevant, because the plugin developer doesn't need to accept it to do what he is doing, because he is not violating anyone's copyright.
Just because the GPL is clear doesn't mean it is enforceable against people who aren't actually distributing your software. The enforceability of the GPL relies primarily on copyright law, where the established definition of a derivative work is light years removed from the fiction that the FSF and the the SFLC would like it to be.
One cannot call this a derivative work, because the pluging doesn't really depend on the parent program at all.
The idea that "use dependency" has anything whatsoever to whether a work is derivative of another is specious in the extreme. Derivative works are derivative in part because they are "substantially similar" to a pre-existing work. Functional necessity does not apply.
Use dependency (utility) doesn't even register. It is basically a legal fiction promoted on the basis of wishful thinking. Maybe if we say it enough times people will start to believe it, etc. Amazingly successful in that respect, I am sad to say.
On the other hand, you can hardly argue that your module would be of much use to anyone without a Linux kernel to run it in, and you must have referenced the kernel source, or documentation derived from it, during the implementation, since the APIs don't exist anywhere else.
A derivative work must be _substantially similar_ to a pre-existing work to be considered derivative. Interface compatibility, no matter how obscure the interface, no matter how much access, no matter how much documentation, does not in and of itself make your work substantially similar to another work.
If you were making a clone of an existing module, or an entire application, source code access and substantial internal similarity would be prima facie evidence that you have created a derivative work. Interface compatibility without substantial internal similarity isn't even _relevant_.
17 USC 102(b) seems relevant here: "In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."
That is your opinion. Others have argued differently, in the event that your module was written specifically to be used as part of a Linux kernel image and makes use of its internal APIs.
Unfortunately, such arguments appear to be based on nothing but wishful thinking. I have yet to see _any_ kind of legal argument to the contrary. Unless you count the sort of thing engaged in by the lawyers of SCO as a "legal" argument.
If the FSF's "interpretation" were to stand, the software industry would be dropped in its tracks. Every Win32 program a derivative of Windows? Or what if I plug in my television into the wall outlet? Does that make it a derivative of the power grid? Is JFS a derivative of Unix System V just because it was ever linked with it? Is Samba a derivative of Windows Server just because it is compatible? Wine? Foxit? OpenOffice? Linux?
Basically the FSF and the SFLC are either clueless or opportunistic on this issue or more likely, both.
If you modify GPL source code, your modification becomes GPL.
Not true. Neither your modification nor the derived work as a whole automatically becomes licensed under a new license. What really happens is you retain copyright to your _modification_ as such and can license it (to the degree it can be separated from the base work) under any terms you please (as a patch file, for example).
As for the derivative work, once modified, as a whole it becomes subject to _both_ the copyright of the original author and your copyright. So you can't distribute it without their permission, and neither can they (unless your modification is trivial).
Strictly speaking the idea of a "viral" license is a fiction. There is no such thing. Licenses like the GPL behave exactly the same as any proprietary license in this regard. Permission of both copyright holders is required, unless the modification is immaterial.
Slashdot Mirror
They didn't publish their reasoning, but I'm going to go with actual lawyers who specialize in copyright but don't publish their reasoning, over non-lawyers who do publish their reasoning
The faith based argument then? Based on the speculation of lawyers who are not confident enough to set let it see the light of day?
I would like to see your citations, from lawyers, that say that they have no prayer of succeeding.
I would like to see you citations, from anybody, that demonstrates (or makes even a shred of an argument) that they do.
Which is a district court case, thus not binding precedent anywhere. The arguments presented to it were likely different from the ones that would be presented in a GPL case, too.
Legal decisions are based on actual legal arguments. Baystate v. Bentley Systems explains the issues and precedents clearly enough that it is enormously influential, whether it is binding or not.
But most important, it doesn't really cover the same issue.
Sure it was. See below.
At stake there was the similarity of two programs that were meant to read the same data format. The court concluded that there was no copyright infringement, because any similarity (including the use of identical data structures) was a necessary result of the fact that they had to accomplish the same function, so it was permitted under the merger doctrine.
And a plugin must likewise make use of the technical interfaces of the host program, which requires making use of all necessary meta data about that interface in its construction. There is no logical distinction between a plugin's use of the interface provided by a host program and an application programs use of the interface provided by an operating system.
The essential elements of technical interfaces have been held to be unprotectable in multiple court cases, including the Ninth Circuit Court of Appeals case, in Sega v. Accolade (1992), not to be protectable by copyright. Baystate v. Bentley systems is just the most recent and most detailed one. See also the scènes à faire doctrine laid out in Computer Associates v. Altai (1992) and Gates Rubber v. Bando Chemical (1993), Second Circuit and Tenth Circuit decisions, respectively.
A plugin's sole purpose is to incorporate into the larger work; it has no function without it.
So what? Utility doesn't have _anything_ to do with whether someone has copied protectable elements into the plugin. That is just plain stupidity, wishful thinking, opportunism, etc.
As to the idea that the _end user_ has created a legally restricted derivative work, you can see my other comment in this thread, but generally there (1) is no creativity exercised, meaning the combination is not a "work" (2) the combination is ephemeral, meaning the combination is not "tangible" (3) this is an excellent case of the sort of thing Congress intended to fall under the category of "fair use" (4) Anyone who doubts that should refer to 17 USC 117(a) about the specific exemption for "adaptations" necessary to make use of a program, and of course the general stupidity of thinking that for example, a user has created a legally prohibited derivative work by making two separately distributed modules interact on any level whatsoever, something that would make the software industry impossible.
[re: the FSF attorneys actually "determining" anything.] Well, yes. A lot of lawyers contribute to the FSF's position on these things, and they have professional opinions on what they believe the correct reading of the law is
Lawyers don't "determine" anything. They present _arguments_ on behalf of their clients, grasping at any straw available, no matter how specious, in an attempt to defend the position of their clients, no matter how silly.
Remember here, so far as reference to either organization's website is concerned, or any available court case, none of the lawyers here have actually made any sort of legal argument on this point at all. If this particular issue ever actually went to trial, the burden of proof would be upon them to establish the proposition that such a ridiculous position has any legal foundation whatsoever. _All_ the available legal precedents run in exactly the opposite direction. Baker v. Selden (1879) and Baystate v. Bentley Systems (1996) for example.
The reason why issues like this rarely go to trial is because the attorneys when staring reality in the face realize they cannot win arguments without a legal foundation to stand on. Several statutory provisions (e.g. 17 USC 107 and 117(a)) and half a dozen court cases tend to be rather intimidating to an attorney thinking of actually going beyond the bluster stage.
Including a specific, unique copyrighted file, with intention to include just that file, is more than using a technical interface. It's using a specific implementation of that interface. Remove the original part, and new part ceases to be what it is intended, marketed and sold as. The new part is clearly derived from the original, expanding on it. If the new part is distributed alone, but with the intention of a specific original work being combined with it (as proven by eg. installation instructions telling how to get the original work required by the new work), then I think copyright law does view that as distributing a derived work.
You should read the Baystate decision. "Including" a file when compiling a program doesn't generally cause a "copy" of the information in that file to be included in the resulting binary. The compiler merely "refers" to it, and gathers out facts necessary to use the proper technical interface. The "protectable elements" are not copied into the resulting binary at all.
Copyright does not protect ideas, it protects expression. In general, referring to a "include" file is about as relevant as looking up something in an encyclopedia when preparing a research paper. cf. Baker v. Selden (1879).
Reasonable people unfamiliar with the law imagine it protects all sorts of things which both the statutory law and the case law specifically exclude. This is one of them.
If you put a copyrighted work to the cloud storage (can't get much more intangible than that), it's no longer under copyright? And I'd say both the original code, and the new code using it, and their combination in memory, are original works. How could they not be?
In the copyright sense, "tangible" means physically recorded in a durable manner. If you want to sue someone over a copyright violation your work must be physically recorded on a medium you can submit as evidence. Just because you _can_ transmit or represent something in an ephemeral manner does not mean it is _incapable_ of tangible representation (such as a printout or on a compact disk). Cloud storage is more than tangible enough, although you would have to copy your work onto separate durable media to properly establish that you actually created something protectable by copyright.
"Original", on the other hand, means demonstrating creative expression. "Sweat of the brow" does not demonstrate originality, nor does mere aggregation. If someone loads an application program plus a plugin into memory, they have not created a derivative work in the copyright sense of the term, because no creativity has been exercised. That doesn't mean the copyrights of the individual components have been invalidated, just that strictly speaking no "derivative work" has been created.
Even if the considerations of originality and durable representation were held not to apply, such that a potentially restricted "derivative work" had been created by the end user merely by loading two programs onto the same computer or into memory simultaneously, the latter (which would be the party that would have to be sued) has two defenses. The first is fair use, and the second is "use necessity".
17 USC 117(a) specifically exempts the preparation of "adaptations" of computer programs by an end user to the degree such adaptation is necessary to for them to use the program. That includes making durable adaptations, not just ephemeral ones (e.g. in memory).
A lot of copyright lawyers worked on the FSF's determination of what's a derivative work in software. Have any lawyers supported your opposite conclusion? If not, why do you think you know more than copyright lawyers about how to apply the case law on derivative works to software?
You think the FSF actually "determined" something? It is much more likely that they are grasping at straws trying to come up with anything that supports their position, because their idea of a derivative work has no trace in statutory or case law, at least in the United States. In fact the case law runs in the _opposite_ direction, holding (for example) that technical interfaces are not protectable by copyright (cf. Baystate v. Bentley Stems (1997)).
And if they are not grasping at straws, how is it that the FSF website has no trace of a legal argument on the subject? The only thing the SFLC website appears to say on the subject is the following footnote:
The reason I suspect there isn't any legal argumentation in favor of the FSF's dubious conception of derivative works is there isn't an argument with a prayer of succeeding. If anyone has any citations to the contrary, I would very much like to see them.
Having your work explicitly include/import/require (using that scripting language command) a file that has unambiguous copyright held by somebody else sure sounds like deriving from that file.
The end user, in memory, mayble. Unfortunately copyright only applies to original works of authorship fixed in a tangible medium of expression, and an in memory combination is neither tangible nor original.
If there are several version of the file available (like C stdio.h or something) then I think the copyright holder of the original would have to prove that derived work derives from his version of the original and not somebody else's. But in many cases, the imported file is available from only one source, and there's no ambiguity like this.
In Baystate vs. Bentley Systems (1997) a U.S. district court ruled that "technical interfaces" are not covered by copyright. There are good reasons for that. See here [pdf].
I'm not so sure that can be considered "safe". Courts tend to frown on technicalities, and might not see any real distinction between your shim version and the equivalent code without the shim. The need for license compatibility may end up being transitive.
I see it less like a "technicality" and more like "safe harbor". If it were a technicality, every Win32 program would be a derivative of Microsoft Windows, for example.
I don't know what the Win32 terms are but I doubt they are as infective as GPL.
This wouldn't matter if the FSF/SFLC were right about derivative works. By mere compatibility, every Win32 program would become a derivative work of Windows, and Microsoft would have to _grant_ you a license if you wanted to distribute it.
In addition, with the possible exception of non-trivial inline functions and macros, no amount of header file inclusion is going to affect the derivative work status of a program compiled using those files, on the grounds of triviality and functional necessity.
With the above mentioned exception, a compiler does not "include" the contents of a header file into a produced binary, it merely refers to the information contained to produce a compatible object file.
When you choose to include a library in your product and therefore depend on it, you are agreeing to the terms. If you don't agree with the terms, that doesn't mean you can still use the library
I agree you can't "include" a library with incompatible licensing terms in your product. That doesn't mean you can't _depend_ on it though, if the customer can acquire a legitimate copy by any other means.
And by the way, a "license" gives you permission to do things that you do not otherwise have the right to do. No license can take away rights you already have. You need a "contract" for that.
So if you acquire a legitimate copy of any software library, you can use it any way you want that is not otherwise restricted by law. No license is required to use that which you own. If you want to restrict use, you need a patent or a contract, not a copyright or license.
This does not necessarily contaminate the source itself, which only references the header files by name, but the resulting binary would incorporate at least some kernel code (e.g. macros, inline functions).
Copyright only applies to creative expression. To the degree the contents of the header file are a representation of simple facts (e.g. manifest constants), mere use of those facts does not apply. Copyright has also been held to exclude functional necessity, which means that use of function declarations and other similarly trivial macros isn't a problem either.
The problem arguably comes when one references inline functions or macros that aren't trivial. If they are necessary aspects of the interface one might be able to raise a legitimate defense of functional necessity. But certainly the safe method in this case is would be to write a shim that does include the kernel header files and a separate module that only talks to the shim that does not.
Not that I am a big fan of binary blobs by any means - I think all customers should get source code to things like non-standard kernel modules as a matter of principle. That doesn't necessarily mean they should necessarily be able to give copies away, but they should at least have the source code wherever possible. The federal government requires it.
Finally - all this academic stuff aside, American copyright law doesn't clearly define what a derivative work is. Much like fair use, in cases of dispute it's up to the court to decide where the line is drawn so quite frankly
Courts have rules of statutory construction, and one of them is that they can't just make a term mean anything they want it to mean, but rather must interpret it generally as the ordinary, common meaning of the term at the time time the legislation was enacted _and_ in accordance with the meaning implied by the text of the legislation itself.
The FSF / SFLC wants the line to be drawn so far away from the ordinary and common meaning of the term derivative work or that which can be gathered from the statutory text that they don't have a plausible legal foundation to stand on.
In the Anglo-American system of common law courts do make potentially binding clarifications of the meaning of laws within those intrepretive constraints, and guess what: what the U.S. courts have decided about the meaning of derivative work is the obvious "copy with modification" meaning, not the legal fantasy promoted on occasion by the FSF and the SFLC.
Here is the U.S. Copyright Office on the subject:
There are definite advantages to such a system: firstly it's a LOT more democratic. You need a lot of lobying to get a law changed by the legislative branch but anybody can bring a court case, including on a matter that was not previously IN the law (here that is possible) and if you win - it BECOMES law.
There are a lot to be said for the advantages of judicial supremacy, but "democracy" is not one of them. More like government by wise men. Of course some countries have constitutions or unwritten legal traditions that give some justification to such rulings beyond the exercise of raw power, but anything that a court can do or prevent that is not in principle overridable by popular vote (by constitutional amendment perhaps) is not democratic, but rather the opposite.
The fact that all your legal experts who actually understand the GPL, including people like professors Eben Moglen and Larry Lessig thinks it's what the law says ANYWAY kind of makes your questions ... well rather silly. I think they know the law better than you and they have full confidence that the GPL's interpretation is entirely accurate.
Eben Moglen consults for the FSF. That means he is duty bound to try to protect the interests of his client, even if it means grasping at straws. That said, I would like to see him try to make an actual _legal_ argument in favor of the FSF's position on this point. I don't think Lessig has addressed this particular issue either, but if you have any citations I would like to see them.
Is that so ? The windows API is ALSO a proprietary library. It just happens to come with a license that specifically permits derivative works from linking.
Yes. First of all an "API" is an interface, not a library. People can and do make alternative implementations of an interface, which is one of the reasons why mere compatibility does not a derivative work make. A derivative work is basically a copy with modification.
Second, a "license" cannot take away rights you already have. By definition, a license can only give you permission to do what you did not have the right to do previously. No license to Windows is required to use a legitimate copy of it, for example, nor can any such license restrict what you can do with a copy that you own, beyond that otherwise prohibited by law.
If you want to restrict what people can do with your software you need a _contract_, not a license. Alternatively, you can lease a copy of the software to them, instead of selling them a copy.
I speak of U.S. law in particular, but the law of most other countries on the matter is similar. U.S. copyright law was changed in 1978 in part to match an agreement called the Berne Convention.
Due to the nature of PHP, yes. The PHP interpreter could not interpret the theme in the absence of WordPress code. It is incorporated in the most explicit manner.
Sorry, no. Utility / ability to use has nothing to do with whether something is a derivative work. Nor does a plug-in in and of itself necessarily incorporate any of the code of what it is capable of being "plugged" into. A Win32 program is not a derivative work of Windows, for example.
Now there is perhaps a vaguely reasonable argument to the effect that a temporary derivative work is created in memory by the end user when running the two components together. However, copyright only covers "original works of authorship fixed in any tangible medium of expression" and a temporary combination of the two is neither tangible nor original.
This is like the GPL libraries. If your project uses a GPL product, does it become GPLed too (and you want distribute it)? Yes, it does
Not even close. No license has the magical power to infect something that uses it. A license may affect your ability to distribute the original work and/or a clear derivative (i.e. copy with modification). Use dependency does not make something a derivative. Interface compatibility does not make a derivative.
Any claim to the contrary is wishful thinking on the FSF's part. The FSF and the SFLC are basically propagating a fiction with no legal foundation whatsoever, the sort of nonsense that would make any Win32 program a derivative of Windows, or my desk clock a derivative of the power grid.
2. If software S links with G, in the conventional static or dynamic way (i.e., incorporating a .a or .lib file into an executable when the executable is built, or loading a .so or .dll along with the executable at the time it is run), does mean that S must be GPL'ed, too
Not true. It is necessary to license S as GPL if you want permission from the authors of G to distribute S and G together. It is not necessary if you plan to distribute S by itself (no G). I have yet to see a trace of a _legal_ argument otherwise.
Now that may very well be something the license to G attempts to restrict, but the license to G has no bearing on the distribution of S by itself.
If YOU were write there wouldn't be any business proposition to develop ANYTHING but complete apps - there go all the companies in the world that make money out of licensed libraries. Including free software companies that dual-license and let you pay for the privilege of creating non-free apps - MySQL did that, QT still does.
That is an argument for how the law should be, but does not have anything to do with the law as it stands. I agree that the issue (were it a question of law instead of wishful thinking) would be interesting for producers of open source libraries, but not really for proprietary ones.
There are also thousands of commercial developers who create and sell LIBRARIES - by your logic this is impossible since there is no reason to buy a library -just make sure your customer has the same one and you can link it to write apps from all you want.
Commercial applications must generally be distributed with the libraries they require, or the end user must legitimately acquire a copy by other means, so this doesn't affect the proprietary application / proprietary library business at all. It certainly affects the prospects of the dual licensed library business, but not all that much, for the same reason.
It's very clear that no court in the world will accept THAT as a tenable scenario - that a programmer who writes a library is worthy of lesser copyright protection than one who writes an application. Because you effectively destroy all copyright protection for basing your app on a library written by anybody else - thus removing all motivation to every write libraries for anybody but the hobyists.
What you describe isn't _copyright_ protection at all. Copyright governs copying, distribution, public performance, and the preparation of derivative works. Outside those restrictions copyright has absolutely nothing to do with how someone uses what he or she has legitimately acquired.
In addition, Courts are supposed to decide what the law is, not what it should be. Otherwise they are acting as an unelected legislative branch. Legislators might take that into consideration if they were undertaking a _major_ revision of copyright law (starting with a repeal of the first sale doctrine, for example, and the idea that one can actually legitimately _own_ a copy of anything) but it is not a question the courts can decide.
The legally established concept of "derivative work" is as clear as a bell, and interface compatibility isn't it. If the dual licensed library folks think a sane interpretation of the law will defeat their business model, they should petition Congress to have the law changed.
Considering that Congress is probably sane enough not to make every Win32 application a derivative work of Windows, for example, the petitioners should suggest some other alternative that doesn't cause far more harm than good when taken seriously.
You have no rights to use the GPL code, unless you agree to the GPL licence and thus its provisions regarding the derrived works. This is well established in legal precedents.
I seriously doubt this is actually the case, but you can feel free to start quoting some legal precedents. There are pending court cases about "copy ownership" that pertain to questionable propositions about "use rights", i.e. the suggestion that a manufacturer can dictate what you can do with a copy of something like a CD after you purchase it, beyond the restrictions provided for in copyright law itself.
That said, the question of use rights is largely irrelevant. If the plugin is not legally speaking a "derivative work" (and the claim that it is is ridiculous), and the plugin developer is not him or herself distributing WordPress, then the license to WordPress is irrelevant, because the plugin developer doesn't need to accept it to do what he is doing, because he is not violating anyone's copyright.
"The GPL is infact VERY clear."
Just because the GPL is clear doesn't mean it is enforceable against people who aren't actually distributing your software. The enforceability of the GPL relies primarily on copyright law, where the established definition of a derivative work is light years removed from the fiction that the FSF and the the SFLC would like it to be.
One cannot call this a derivative work, because the pluging doesn't really depend on the parent program at all.
The idea that "use dependency" has anything whatsoever to whether a work is derivative of another is specious in the extreme. Derivative works are derivative in part because they are "substantially similar" to a pre-existing work. Functional necessity does not apply.
Use dependency (utility) doesn't even register. It is basically a legal fiction promoted on the basis of wishful thinking. Maybe if we say it enough times people will start to believe it, etc. Amazingly successful in that respect, I am sad to say.
On the other hand, you can hardly argue that your module would be of much use to anyone without a Linux kernel to run it in, and you must have referenced the kernel source, or documentation derived from it, during the implementation, since the APIs don't exist anywhere else.
A derivative work must be _substantially similar_ to a pre-existing work to be considered derivative. Interface compatibility, no matter how obscure the interface, no matter how much access, no matter how much documentation, does not in and of itself make your work substantially similar to another work.
If you were making a clone of an existing module, or an entire application, source code access and substantial internal similarity would be prima facie evidence that you have created a derivative work. Interface compatibility without substantial internal similarity isn't even _relevant_.
17 USC 102(b) seems relevant here: "In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."
That is your opinion. Others have argued differently, in the event that your module was written specifically to be used as part of a Linux kernel image and makes use of its internal APIs.
Unfortunately, such arguments appear to be based on nothing but wishful thinking. I have yet to see _any_ kind of legal argument to the contrary. Unless you count the sort of thing engaged in by the lawyers of SCO as a "legal" argument.
If the FSF's "interpretation" were to stand, the software industry would be dropped in its tracks. Every Win32 program a derivative of Windows? Or what if I plug in my television into the wall outlet? Does that make it a derivative of the power grid? Is JFS a derivative of Unix System V just because it was ever linked with it? Is Samba a derivative of Windows Server just because it is compatible? Wine? Foxit? OpenOffice? Linux?
Basically the FSF and the SFLC are either clueless or opportunistic on this issue or more likely, both.
If you modify GPL source code, your modification becomes GPL.
Not true. Neither your modification nor the derived work as a whole automatically becomes licensed under a new license. What really happens is you retain copyright to your _modification_ as such and can license it (to the degree it can be separated from the base work) under any terms you please (as a patch file, for example).
As for the derivative work, once modified, as a whole it becomes subject to _both_ the copyright of the original author and your copyright. So you can't distribute it without their permission, and neither can they (unless your modification is trivial).
Strictly speaking the idea of a "viral" license is a fiction. There is no such thing. Licenses like the GPL behave exactly the same as any proprietary license in this regard. Permission of both copyright holders is required, unless the modification is immaterial.