Derivative Works

Many users of open-source software are
frightened by the term “derivative works”. They worry they might
accidentally create derivative works and put their own proprietary
software under an open-source license. This is a complex topic that
courts and lawyers disagree on, but I think we find definitions to
ease people's concerns.

First, a brief reminder of why the term derivative work is so
important. Here's what a typical license might say: “Licensor
hereby grants you a license...to prepare derivative works based
upon the original work and to distribute those derivative works
with the proviso that copies of those derivative works
that you distribute shall be licensed under this
License.” See, for example, the GNU General Public
License at
www.gnu.org/licenses/gpl.html
or the new Open Software License at
www.opensource.org/licenses/osl.php.

How can you tell when you've created a derivative work? The
Copyright Act, at 17 U.S.C. §101, is a little vague and
doesn't say anything at all about software:

A “derivative work” is a work based upon one or
more pre-existing works, such as a translation, musical
arrangement, dramatization, fictionalization, motion picture
version, sound recording, art reproduction, abridgment,
condensation or any other form in which a work may be recast,
transformed or adapted. A work consisting of editorial revisions,
annotations, elaborations or other modifications which, as a whole,
represent an original work of authorship, is a “derivative
work”.

Almost everyone agrees that if you take the copyrighted
source code of any program and physically modify it—actually
revise the program or translate it into another computer
language—you have created a derivative work of that program.
That's the simple case. If you do such a thing with a program
licensed under the GPL or the OSL, you must honor the reciprocity
provision and publish the source code of the derivative works you
distribute.

But what happens if you merely copy an original program as a
component in your own, perhaps larger, work? Does it make a
difference that you didn't actually modify the source code to
combine the original program into your larger work?

Does merely linking to a program without any change to the
original source code create a derivative work of that program?
Almost every program links to library routines. Surely, one doesn't
create a derivative work of a library simply by calling a sqrt
function in the library. Why should it be any different when you
link to something as complex as an enterprise server or database
engine? What about linking from a software program, such as when
linking your device driver into a GPL- or OSL-licensed program like
Linux?

Does it matter what technical form of linking you use? Or is
that analysis (e.g., static linking, dynamic linking, passing data
through an API, as an object contained within a larger object,
etc.) a technical morass that obscures the fundamental issue? How
can the law of derivative works keep up with technological change
in the world of software engineering?

These questions are important because some licenses require
you to publish the source code of your portion of the resulting
derivative work program, a burden you may not want to accept.
Here's how I would decide in the cases described above.

1) The primary indication of whether a new program is a
derivative work is whether the source code of the original program
was used, modified, translated or otherwise changed in any way to
create the new program. If not, then I would argue that it is not a
derivative work.

2) The meaning of derivative work will not be broadened to
include software created by linking to library programs that were
designed and intended to be used as library programs. When a
company releases a scientific subroutine library, or a library of
objects, for example, people who merely use the library,
unmodified, perhaps without even looking at the source code, are
not thereby creating derivative works of the library.

3) Derivative works are not going to encompass plugins and
device drivers that are designed to be linked from off-the-shelf,
unmodified, programs. If a GPL-covered program is designed to
accept separately designed plugin programs, you don't create a
derivative work by merely running such a plugin under it, even if
you have to look at the source code to learn how.

4) In most cases we shouldn't care how the linkage between
separate programs was technically done, unless that fact helps
determine whether the creators of the programs designed them with
some apparent common understanding of what a derivative work would
look like. We should consider subtle market-based factors as
indicators of intent, such as whether the resulting program is
being sold as an “enhanced” version of the original, or whether
the original was designed and advertised to be improvable “like a
library”.

You should care about this issue to encourage that free and
open-source software be created without scaring proprietary
software users away. We need to make sure that companies know, with
some degree of certainty, when they've created a derivative work
and when they haven't.

Legal advice must be provided in the course of an
attorney-client relationship specifically with reference to all the
facts of a particular situation and the law of your jurisdiction.
Even though an attorney wrote this article, the information in this
article must not be relied upon as a substitute for obtaining
specific legal advice from a licensed attorney.

Lawrence Rosen
is an attorney in private practice, with offices in Los Altos and
Ukiah, California
(www.rosenlaw.com). He
is also corporate secretary and general counsel for the Open Source
Initiative, which manages and promotes the Open Source Definition
(www.opensource.org).

but it does not pay the bills, and I'm nearly sure that intent of GPL/LGPL upon proprietary developers is FUD and dont get me started about "but GPL'ed software can be sold" bla bla, yes it can be sold, practically one time per software !
So as a proprietary software developer who need pay the bills I would not even think of include or link to GPL/LGPL'ed code in my software.

The real measure of the "derivative work", according to the author of the license, is that it be recognizable.

{

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.

}

If I borrowed the math function from a library that was included in an EKG program and used it as one or two functions in my stock analysis program, I have not made a derivative since the works "can be reasonably considered independent and separate works in themselves". But, If I were to make an EKG program and include a number of the mathematical functions from the GPL program I have, then I have made a derivative of the other program, or at least an argument that I have used "copywrited" material to produce its competition.

Now, if a developer creates a library of, say, 300 functions and routines and stipulated that any work created using my library, in part or in whole, would be required to submit their work under the GPL, then NO ONE would be allowed to use my library! That is the purpose of the library, to use one part, you had to use it as a whole, even though only one function was actually included or used in the program created. Again, that is the license for the library.

If, on the other hand, a programmer includes a library with a program and the programmer who acquires it discovers another product totally different from the original could be produced by using that library or some parts thereof, then it would depend on how much of the original were recognizable in code or in works or look and feel. If the EKG program plots a graph with a function that I use to calculate my buy-sell point, then side-by-side, the original function would not be recognizable, but if all my stock graphs were shown and based on the library math, then that section of my work might resemble enough of the original product to be "recognizable", especially if I use his TV screen design.

The GNU GPL is not a license meant to examine all the products to find a small amount of used code, it is designed to prevent one person from taking a product from the public and making it his private product.

The real issue in the license is a product with a recognizable section of code. As some mentioned the math libraries, they could hardly be recognized by the workings of the program. But the graphic display of the EKG on my stock program could very well give away that I used that section of code. Even then, if it were not another EKG program, it would be a completely different work and the author probably would not be concerned.

As for the courts, how they see it would be more determined by the people making the case more than how much of the code was "borrowed".

The nice thing about the GNU GPL is that it allows us to learn from each other freely. If we want to improve on someone else's work, thats great! And we can pass an improved version along. If we want to create something new, we can do that to and if we take a little of what we learned, we can call it our own.

* There are too many ambiguities. Terms like "derivative work" are too vague to be used. Further the GPL also uses "collective work" and "aggregation" without sufficient distinction. Legal documents normally take pains to define such terms for their own purposes. Unfortunately, the GPL does not, except by defering to copyright law (interestingly, the LGPL does define "derived work" but that is in a different legal statemnet and not part of the GPL).

The FSF does try to correct/explain some of this through the faq. Unfortunately the faq:

- is not part of the GPL and is thus likely not legally binding.

- is also ambiguous.

* if one reads FSF's documents, supposedly written to explain the GPL, there is much about what the FSF would like to achieve (to the extent of including the Preamble in the GPL). This confuses the issue further since there is a big difference between what the FSF would like the GPL to mean and a legal interpretation of what the GPL actually says. An example of this is the binding issue (static vs dynamic linking). FSF would like the GPL to cover all linking models (including static, dynamic, via java byte code etc).

Since the GPL defers to copyright law, I think a reasonable interpretation of the GPL is to use some analogy with the publishing world. Let us say Joe's writes his book called "Study guide for book X". This book does not include book X, but is makes quotes and gives reference and is meaningless unless read in conjunction with book X. I doubt Joe's study guide could be considered derivation. If Joe's study guide was sold bundled with book X, this would be aggregation rather than derivation.

Would that not be a valid analogy of a dynamically linked program?

If, however, Joe was to reprint the body of book X with his commentary as footnotes or in-line text, then clearly this would be a breach of copyright. This would be analogous to static linking.

More modern analogies might use hyperlinks or bookmarks.

In summary, I think two actions are required to make the GPL effective:

* The FSF must make a distinction between its goals and the GPL. Too oftem, rms starts spouting about what he wants to see rather than what the GPL actually says.

* Terms need to be cleared up to make the GPL an effective legal device.

I agree that the FSFs texts do not really distinguish between what it would like to see and the actual legal niceties of the situation, and that does make life difficult for some people. However it mostly makes life difficult for people wanting to write proprietary software but still use GPLed libraries. The FSF are not interested in making life easy for them, and neither are others who buy into the philosophy of free software (as opposed to the 'better development model' world view of Open Sourcers).

However I disagree with your assertion that the GPL needs to be clarified to make it effective. It has already been extremely effective, creating an enormous amount of quality software and changing the world-view of many people. It has also managed apparently 100% compliance with the license without a single lawsuit. Most proprietary licences have had plenty of lawsuits (or at least enforcement action from the BSA et al) but don't get anything like the same level of compliance.

That's because the power of the GPL is really as a social document, rather than a legal one. The legal aspects, whilst interesting, are secondary. Which is why all that preamble statement etc is in there and significant.

I agree with those who draw the line of 'derived work' between static and dynamic linking, insofar as that's probably where a court of law would draw it, although there are also good arguments for including either all, or no, linking too, so the outcome is not clear, which seems to be enough to stop people trying to abuse it. However, I'm also quite happy to accept the FSF's definition at face value so that proprietary software writers have to write their own libraries if they don't want to write free software. That seems to be a perfectly moral stance to take.

Another thing to consider when looking at the fine print of the 'derived work' definition is which law you are interpeting it under. I assume most people are looking at the US law definition, but I it is presumably different in other national and international laws, and this may well affect any legal interpretation of this aspect of the GPL which will no doubt one day come to pass.

Wookey, I disagree that the GPL has created any software. People create sw, not licenses :-).

Don't get me wrong, I beieve the goals of the GPL are great. However I believe the GPL is poorly written as a legal document.

The GPL is a legal document, though a society has taken to use it as a banner (rather like how libertarians use the American Constitution). Unfortunately, because the GPL is inclear, members of that society are liable to interpret the GPL differently and have different expectations. Also, the society potentially leaves itself open to exploitation from Evil Beings who can exploit loop holes in the GPL and thus use GPL'd code in ways not intended by the society.

I don't think that there has been 100% complaince (there have definitely been legal letters written telling people they are in breach), but maybe there have been no cases of GPL being used as a legal instrument in a court of law.I think the main reasons for this are:

* Generally us Open Source folks are nice guys who would like to sort out our differences outside of the courts.

* The copyright can only be enforced by the copyright holder. In most cases, GPL authors are not keen to put on a tie and go to court. Nor do they have the pot of cash - they'd rather get on to writing their next chunk of code.

* The GPL is fuzzy enough that the static vs dynamic linking case is too risky to take to court.

* The society is tolerant of different viewpoints and is aware that it is based on cooperation. Nobody wants to look like a thug. For the most part I believe people will tolerate dynamic linking even if they think it is wrong.

When it goe to court, the GPL will have to stand on its *legal* merits, not on what a society has chosen to associate it with.

The GPL puts no restrictions on how you can *use* the software, only on what you must do if you distribute (or redistribute) the software. So if you obtain a source-only distribution of GPL software and compile it for your own use, you're under no obligation to do anything - even if you modify the source.

However, if you distribute that compiled GPL software (modified or not), you are subject to the GPL terms of having to make the source available (including your modifications).

"Fair use" encompasses linking with whatever you want and running it. The GPL does not affect that. "Fair use" does not encompass redistribution of any kind. You are free not to accept the GPL (it's not a click through or shrink-wrapped license). If you don't, your rights are limited to "fair use". Since the GPL does not prohibit any "fair use", not accepting the GPL does not buy you anything,

That makes the GPL much more enforceable than the usual Mickysoft EULA which strives to restrict your rights beyond the copyright laws' defaults.

Look carefully at the first sentence of the definition of derived works:

"A `derivative work' is a work based upon one or more pre-existing works, . . ."

All the things after the comma are merely examples of kinds of derivative works. Some of those examples apply to software, and some don't. However, the part of the definition of "derived work" that applies to the relationship of programs to the libraries on which they depend happens to be right before the comma.

For example, a command interpreter that uses the readline library is clearly a work that is based upon that library. It builds upon the framework that the library provides, using its routines for command line editing, history, and so on.

Similarly, a program that uses the GTK+ or Qt libraries is a work based on those libraries, building on a framework of routines and functions that do work that the programmer doesn't want to have to do: design dialogs, menus, toolbars, buttons, etc. It''s more than just using a function or two.

The only thing in the GPL that even comes close to defining "Derivative" work is this:

"You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program"

as below it, conditions include the word "derive."

I also don't believe it to be the intent to limit linking per-se:

"Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program."

the GPL does not even include the word "Linking" in all of it (the official license, not at the bottom for the LGPL)

I think I know where the confusion is coming from. The GNU GPL was created for SOFTWARE and not LIBRARIES. As such it was NOT made to "protect" libraries from linking to as it includes absoloutly no statement preventing linking or making use of an application released under it.

the GPL was made for software, and as such can not be used to fully protect something it was never made for. It's like releasing an Oil Painting under the GPL. It just won't work correctly.

The LGPL was specifically made for software libraries and specifically deals with linking to them.

In the end, nobody (court of law) has ever defined weither linking to a library will be concidered "Derivative" of it. Which I highly doubt it would ever arrive at that as it never modifies it. Nor does any definition include "making use of" something else as part of its definition.

"formed or developed from something else; not original"

of course there is also this part of the definition:

determined by mathematical computation; "the calculated velocity of a bullet"; "a derived value"

Either way, the GPL only deals with modifying source code of an application (weither being software or a library) and never specifically denies linking to the application and as such does not limit weither dynamically or statically linking to something released under the GPL as the source code is never modified.

It is not that there is any desire to create an arbitrary distinction.

It is that with a statically linked executable, the compiled executable is a work that derives both from the included libraries and from the source-code. In a dynamically linked executable, the compiled executable is generally only derived from the source code and the knowledge that the library exists. The copy which mixes the two only exists in a transitory state within the computer running the program, and most people don't view that as copying.

To draw an analogy, a statically linked executable is like a book that carries references to an essay and then includes that essay in an appendix. A dynamically linked executable is like a book that only has references to the essay. Even though nobody can read the book without having the essay in front of them, there is a world of difference between including the essay in your book, and making the reader get they own copy of the essay out.

The key distinction here has to be between static and dynamic libraries.

The intent of GPL is that when you STATICALLY link a proprietary source to a GPL'ed library and distribute the resulting binary, the end user has no way to repair or replace that library - which is a clear violation of the end users' rights. In this case, you MUST provide source for the application in order that the end user can recompile it with replacement libraries.

On the other hand, if the library is DYNAMICALLY linked - then the library itself needn't even be distributed with the application and there cannot possibly be any requirement for the application writer to reveal any source code - after all, he may not be distributing one single byte of the library code - he may indeed have compiled his application against he own version of the library and may be completely unaware of the GPL'ed alternative. This isn't so far-fetched. I write OpenGL code - linking to the proprietary nVidia OpenGL library - how am I to be held responsible if the end use happens to use Mesa as his OpenGL library.

This latter circumstance is true for almost all Linux libraries - so there is generally no issue for software developers who merely use standard library components. It shouldn't dissuade people from using GPL'ed

libraries at all.

However, if you ARE statically linked then the resulting BINARY of your program is most certainly a derived work of the library - that's no different to writing a couple of new chapters at the start of a book and republishing

it as your own work. Under copyright law, that is clearly a derived work and isn't allowed under GPL unless you also GPL your application's source code.

Now, if you look at the dynamically linked case - that's more like writing a new pre-amble to an existing book and publishing it as a completely separate book - which it may make no sense to read without the original - but which is distributed without the original book being bound to it. Thats' a perfectly legal thing to do - although you might still run into trouble if you use the other book's characters, etc.

Existing copyright law appears to have exactly this distinction in mind.

The trouble with the original article is that it sweeps this key distinction under the rug and proceeds downhill from there.

The intent of GPL is that when you STATICALLY link a proprietary source to a GPL'ed library and distribute the resulting binary, the end user has no way to repair or replace that library - which is a clear violation of the end users' rights. In this case, you MUST provide source for the application in order that the end user can recompile it with replacement libraries.

You do not need to provide source code in order to link in a replacement library. Just the object code will allow that.

I'd have to agree with Rosen, though I think I can simplify things for the external library linking case. If the program (or library) dynamically uses something else (dynamic linking, client-server IPC, executing programs etc.), if the software allows for an end user to change what library, executable, server process the software talks to (by replacing the library file, changing LD_LIBRARY_PATH or /etc/ld.so.conf, changing PATH, or putting in symlinks to different executables, running a different server process etc.) Then the software is NOT a derivative work as the end user can change the dependancies as they see fit. Any library (server or executable) providing the same API (IPC or PROTOCOL API or executable arguments and output) would be a sufficient to allow anything to be used in its place. So if I use Motif or Lesstif - who cares? They provide the same (basic) API.

The libraries come with differing licenses, but If I write a program that uses Motif API, as long as I don't supply Motif (or Lesstif) along with it, then I see no reason why the software should be governed by any licenses on these libraries as the choice of who provides the API to the program is not mine to make when the program is installed and used on a users machine.

I KNOW the FSF disagrees - but why does dynamic linking to a GPL lib consititue derivative work, but executing the executable and providing arguments and reading output, does not? Or talking HTTP to a GPL web server... does this suddenly make my application a derivative work if I talk a protocol to some server that happens to be under a GPL license? What is different between dynamic linking and using dynamically linked API as opposed to an executable or protocol? The program has no control over what library it ends up being linked to (in practice) just as a program has no control over what web server or what executable it uses, if a user changes them, or provides any they like.

If I compile a library in statically - THEN yes, it's a derivative work as a user has no choice in changing the API the program/library uses, since it's included. Now the program would no longer work if I were to remove the GPL code that is now statically inlined in the program (or library). If it's dynamically linked, I can still make it work if I replace a simple .so file on my system with a compatible one that has LGPL or BSD or any other host of licenses other than GPL. If tomorrow I write a LGPL or BSD libreadline.so, and put it up for download - all programs that use readline can validly become proprietary or non GPL. If it is possible to do this, then in principle I don't see how derivative works can apply to programs dynamically linking.

Yes - the FSF disagrees but the FSF doesn't make a consistent logical case to me where dynamic linking is a derivative work, but exec() and talking a protocol over a socket or IPC mechanism (HTTP, FTP, RPC etc.) does not consititute a derivative work. If the FSF claimed these to be derivative works too, THEN I would happily agree with them on their licensing, because it would be consistent, as using the other software in ANY way woudl be a derivative work, but according to them using it one way is a derivative, but using it another, is not.

And if we introduce the idea of intent - if somethnig dynamically links, the intent is to allow the provider of the API it relies on to be able to be changed (updated, fixed, rewritten, re-licensed) independantly of the project that uses the API. This intent IMHO would be a pretty powerful argument if it ever came to court, though I am no legal expert so I couldn't say for sure.

I think this whole issue uncovered a problem in general with the logical framework for derivated works. I think you seem to indicate this. I myself fall into the camp where dynamic linking is a form of derived work(with the current framework). My primary problem is that linking introduces a loophole. Instead of using the code I want to use from a GPL program and thus be required to release the work via GPL; I create a "new" GPL work(which is fine to do under the GPL) which is now a library containing the function I wish to use in my software. Now if dynamic link was ok, I can now use the same code without releasing my software under the GPL. Which is contrary to the spirit of the GPL.

You are right, in order to be consistent, application level protocols must all be included; because the same loophole can exist. Instead of dynamic linking, use unix sockets with RPC, or XML-RPC via http and cgi. Some of what I hear about GPLv3 starts to address this, but I am not sure how far it goes.

Intent may well have to come into play. Achieving the goal of the GPL would be much simplier for the FSF if they could say:

If derived work is GPL, anything goes.

If not, only use interfaces whose primary purposes are not to make function calls.

Would do what they want(IANAL, I don't know). But then what constitudes a function call?

Perhaps, ultimately the only clear cut way to do this is to formally identify for each section of section which methods of linking are ok and for each section of code.. According to the specifications of the original author.. Argh...

You are claiming that the GPL prohibits a closed source application from dynamically linking to a GPL'ed library. However, the binary that the application developer distributes contains not one byte of the GPL'ed work...that linkage only happens at runtime.

How can the developer be held responsible for something that the end user might hypothetically do with the application?

I could write a program using a commercial library that implements some API (to take a concrete case - the nVidia OpenGL library). I may be totally unaware of the existance of a GPL'ed version of that same library. I ship my application (closed source) - and do not include the library. Now some end user runs my program with the Mesa library installed as libGL.so and my application is now linked to the GPL'ed library.

Am I (as application author) now in breach of the GPL? How could I be - I didn't enter into any contract - I may never even have heard of Mesa - I could (in principle) have distributed the application before Mesa ever existed.

Since there is no way to distinguish an application that was linked against the nVidia drivers and one that was linked against Mesa - there is no way that the GPL can be either applied or enforced when the application dynamically links to the library

(Incidentally, the Mesa example is currently a false one because Mesa is dual-licensed under GPL *and* Xfree - but that wasn't always the case.)

The Mesa example you provided is a good one. In fact, it is clear enough to demonstrate that the GPL is not a problem in this case. You are not DISTRIBUTING the GPL'ed work. The GPL license limits the *distribution*, not run-time execution. You would not be able to distribute the GPL work...since you have "never heard of Mesa", you would clearly not be distributing it. You have no issue in this case.
(BTW, I wish GPL were weak copyleft and would allow linking...I'm looking into this now and share your desires)

As a commercial software developer I make use of free software libraries where ever possible, its a good engineering decision and makes our products stronger. I've commited patches, bug fixes & performed ports for several free projects we use.

Theres no way well give away the IP that pays my wages but by building a robust common set of tools and libraries everyone is benefiting (including free projects). I get paid to code full time and I'm glad that some of my work goes to towards helping the general good.

The LGPL preamble recognises the benefits of wider adoption in addition to disagreeing with the authors views on derivative works as follows:

... We use this license for certain libraries in order to permit linking those libraries into non-free programs.

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library...

It seems pretty clear to me but IANAL, maybe the devil is in the fine print.

The LGPL states flatly that a program that dynamically links to a library is legally speaking a derivative of the original library, but nowhere to my knowledge does FSF cite case law to support that assertion...

The FSF notified our company that we were violating the GPL by providing binaries of their compiled source code linked with our proprietary library. There were no modifications to their source code. It was simply a case of tar -x, configure, and make. But... because the system library we used, was proprietary, and not normally distributed with the operating system, we were told we were in violation of the GPL. Under their threat of litigation, we scrapped the project.

How does Rosen propose to explain Micro Star v. Formgen? That case held that new map files for Duke Nukem, which included no portions of the original map files, were derivative works of DN because (among other reasons) they incorporated *BY REFERENCE* textures from DN. How is this different from dynamic linking?

The text of the decision is here. What is notable about the decision is that the .MAP files choreograph a visual display which is an infringement of the origional program because it appropriates the characters and visual elements of DN into a derivative work. The fictional elements of the DN character and the fictional elements of the objects placed in the scene by a .MAP file featured prominently in the decision. The decision notes that a written story featuring the elements of a DN game would be just as infringing even if no visual elements were reproduced. From this we conclude that there are factual elements of the case which apply to games in a way that may not apply to software in general.

Suppose that I am a movie maker, and decide to do a documentary on the art of painting. In my documentary, I'd of course show the Mona Lisa, the Nightwatch, ... Is my documentary a "derivative work" of these masterpieces?

From the definition in The Copyright Act, I'd say that it is not, because the documentary does not, as a whole, represent an original work of authorship.

In my opinion, using libraries in software engineering is very much like the above example: the libraries might be employed by an end-user software product, and yet, it is not their derivative work, and hence, not subject to licences such as GPL. The GPL neither says nor implies anything about libraries (at the bottom of the GPL licence page there is a notice regarding the issue, but it is no longer a part of the licence).

I tend to disagree. Say you make a song made completely out of samples of other songs. Are you in violation of the original copyrights? Yes, according to the courts. How about if you just use the bassline of one song as the foundation of an original work? Ask Vanilla Ice how well that goes over. I suppose both of these are analogous to static linking though. Would it violate copyright to tell someone that for the full enjoyment of a particular song, you have to play a different cd at the same time to fill in the missing parts? I doubt it...

So you're basically saying Linux can never have a component architecture?

I'll be damned if I will spend time developing software under Linux and be forced to release my source, just because I linked to some GPL'd library under Linux. That's nuts.

If I wrote a Windows program I wouldn't have that legal issue hanging over my head, worring about some f'in Linux GPL crackpot screaming bloody murder over the damn GPL. Get a life, and realize not everybody wants to release their code, but some just want to use the Linux environment for development.

Sorry, graduated, got a good job doing Linux work. If you wrote a Windows program that linked to 3rd party libraries that don't grant you that right and you do have a problem. People don't wan't to work for free and get nothing out of it (it is a misnomer that Linux programmers are a bunch of college kids doing it because it is the cool new thing). I program open source programs in the hope that others do the same so that we might build a better platform. My payment is this awsome system called Linux. It wouldn't be here nor be as popular as it is without the GPL. As a note I release most of my stuff under the LGPL because I often don't care what other projects use it for as long as the core functionality gets impoved. That is my choice. People who release under the GPL made the choice that only those who would respect their chosen licence and contribute back to the project as a whole (should they use it as part of another project or simply distribute it) are the ones they want using their software. If you don't like the licence the go with one of the BSD's. They are great projects that allow you to sponge the code to your hearts desire but there is a reason they are not a popular as Linux.

When you are using a library you are using its code end o discussion, however not all librarys under linux are GPLed indeed many (most?) are LGPLed, as for GPL crackpot if you dont respect your users freedoms dont disrespect those who do, that last comment was simply pathetic.

You should care about this issue to encourage that free and open-source software be created without scaring proprietary software users away. We need to make sure that companies know, with some degree of certainty, when they've created a derivative work and when they haven't.
A certain mistake. You should probably really read: without scaring proprietary software makers away. I believe this is an honest mistake, since the big majority of users do not have (neither should they ever) to care about the licenses of software. They should be able to use it for any purpose anyway, and the only people that have to care are coders/distributers.
Mistake corrected, now I can boldly disagree: we should incentivate free software, and firmly oppose proprietary software. Only with that can we show them that we're not interested in having the "blood sucked" out of our pockets and freedoms: please make something else (hopefully, more free software).

I see this article as an attack on the GPL, trying to turn it, essentially, into
the Lesser GPL. While this would be convenient for commercial exploiters
of GPLed code, it would also make businesses more reluctant to release their work under the GPL, for fear of having their work stolen by rivals.

The article disingenuously ignores cases where works were held to be
derived even when they did not include any part of the original work,
but only (e.g.) recycled characters from the original. When the second
work makes sense only in light of the original, it's derivative. A
program that works only when a GPLed library is present is derivative of
that library.

Claiming that dependency other than copying doesn't count is a disservice
to Mr. Rosen's clients, and to readers at large. An honest article would
have at least acknowledged that serious legal scholars disagree with him.

I think you're way off base. There's no conspiracy trying to turn the GPL into the LGPL. The LGPL, frankly, is just as flawed as the GPL from a commercial software developer point of view. Th eonly think the LGPL clearly gives you as a commercial developer over the GPL is the ability to offer your own code in binary and the LGPL'd code in source. The FSF did a piss-poor job of handling "linking" and "derivative work" definitions in both the GPL and LGPL. As a consequence of the ambiguities descrined in Larry's post, both GPL and LGPL are absolutely worthless to any entity desiring to commercially distribute (i.e., for money) any proprietary code together with any code licensed under either the GPL or LGPL.

The trend is that commercial developers are increasingly funding and supportng Apache-style projects. In the next 5 years you'll see little new technology covered by GPL/LGPL being broadly distributed and ever more Apache and similarly licensed technology proliferating. The market is choosing now. It's a shame too. The FSF could be far more relevant going forward were it to clean up its act on the licensing front.

Larry, this post you did (if that's really you, because I don't recognize any digital signature in here) is a graveous disservice to us ALL.
Please, allow me to technically shatter point number two:2) The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.
When you link to library, you can do it dynamically or statically. I suppose I really don't have to explain much about the static linking, since it's extremely obvious that the library code that is used is being distributed, so let's concentrate on dynamic linking.
When you link dynamically, you aren't distributing, as such, any linked code... however, dynamic linking is just a facilty to reduce memory size, and facilitate distribution: you are effectively including the code when you run the program. You just don't distribute it due to technical artifacts that make programming and distribution much simpler. It's a techincal feat, that changes nothing and is completely olrthogonal to copyright issues.
That said, when you use a function of a library, you are basing your work on that library (a third party's work); without it, the program won't run. So, unless you carry your own version of those certain functions you need, yes, you are making a work based upon one or more pre-existing works, HENCE: DERIVATIVE, as you, yourself, quoted.
Please, don't add to the confusion. You are a recognized person who has the power to form opinions. Casting such graveous comments only adds power to a confusion that would certainly be usefully exploited by big powers unfriendly to Free Software. Or "open source", or whatever you rather call it.
Posted anonymously because I don't bother to make an account here, Rui

That said, when you use a function of a library, you are basing your work on that library (a third party's work); without it, the program won't run.

I would argue that's not true. Just because an application has been written to use one particular library, it does not mean it cannot work without that particular library. Anyone could create an alternative library, presenting the same interface, but released under an entirely different licence.

Take the AMD/Intel, for example. One does the same as the other. They are equivalent. But when AMD made their chips, ONLY the interfaces of the Intel processors were copied. The way they worked internally was completely different and one was not derived from the other in any way, except by locking a group of people in a room and asking them to write a spec for a processor that did the same thing as the existing Intel processor. This got around the copyright laws.

When you use a CPU instruction, we in the computer industry claim that you are not making a derivative work of that CPU. A called library routine (or any abstraction, for that matter) is exactly the same--the library function is an "instruction" in that abstraction, just like a CPU instruction. Therefore, if we are to claim that dynamically (or even statically, in some cases) linking to a code library is creating a derivative work, then we have to claim that any program compiled on a specific CPU architecture is a derivative work of that CPU. Please think before you make assumptions about derivative works. Just because I may quote or make an allusion to another work in or by an encyclopedia or an author does not mean that I am necessarily making a derivative work of their original. I am meerly implementing an abstraction of theirs to help form my idea--so long as I have my own idea to formulate.Drew Northup, N1XIMdrew[dot]northup2{at}gte[dot]net

I think the point is that library functions are often commodities. A standard C library (libc) is a commodity (there are many which exist glibc, uClibc, BSD libc, etc). The standard C math library (libm) is another example. Those things should be considered commodities. If you write a program which plays chess or draws fractals or does network communications, just because you use a standard sqrt(), printf() or qsort() , your program should not be considered a "derivative" of sqrt(), printf() or qsort().

The writer of the program has no control whether the library dynamicly linked to by the program is a GPL, LGPL, OSS, proprietary or end user written library. A library must be present for the execution but the program using the dynamic library is not a derivative work of the library as the actual source of the library is completely unknown to the writer of the program. The program is dependant on a library with the proper functions to be linked to but not a derivative of the particular dynamic library linked to. The user of the program is free to use the library of his choice with out any control of the program creator. To hold otherwise, if I link a GPL program with a proprietary library would make the GPL program a derivative work of the proprietary library. And how can a program be a derivative work of a library that hasn't been written yet.

Static libraries do make it a derivative work of whatever library is linked as the creator is in complete control of the linking process.

It can be argued that creating the required library is a derivative work of the existing library, as well as any program that duplicates another programs functionality being a derivative work of the existing program. But this is allowed as long as certain boundries are not crossed. The fact that an end user uses GPL, LGPL, OSS, user written, or proprietary libraries or a mixture, does not modify the license the program that links to them is released under. The end user is responsible to ensure that all dynamic libraries are present and all licenses are obeyed. Most of the restrictions are for distribution not execution and until the binary is completely linked, all components are under their respective licenses as distributed, not any one overall license.

So the use of static vs dynamic libraries split point 2 into two cases.

I'm afraid you're mistaken.The problem is not "basing your work" on other work, the problem is "when is something a derivative work"The author provides the legal definition of derivative work:

A ``derivative work'' is a work based upon one or more pre-existing works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation or any other form in which

a work may be recast, transformed or adapted. A work consisting of editorial revisions, annotations, elaborations or other modifications which, as a whole, represent an original work of authorship, is a "derivative work''.

To understand a legal definition, you have to look at all of it. The definition says based upon and then proceeds to list 9 examples and a rule that attempts to capture the essence of those examples. The essential attribute of 7 of those 9 examples is modification of form (without particular modification of essence), and the other 2 are types of subtractive change, and the rule emphasizes that change is the key criteria - "any other form in which a work may be recast, transformed or adapted." The 2nd sentence of the definition is consistent with that view, listing 3 examples of additive change.The author's essential point is that use and reference are not the same as change; don't change it and you haven't created a derivative work...The problem with such legal analysis is that, until the courts do it and establish the case law, no one knows if the courts will agree... The problem with software is that, practically speaking, you can't do use or reference without some flavor of incorporation, which can arguably considered as some sort or re-presentation of the work, which has led people into hair-splitting exercises trying to decide what's "safe".

If I link statically to a library, then the library code is included and distributed along with my product in the same binary file.

If I link dynamically to a library I still have to distribute the dynamic library binary with it if I want my program to work. Fortunately I am allowed to do this under the GPL.

Why should it make any difference which way I do it. Who cares about slightly different linking glue code being different? The difference is so minor.

If this was "traditional copyright", you're saying that it's OK for me to have a page that says "See included copy of Tom Clancy novel.", but that's it's not OK for me to bind the exact same pages directly into the same book. Traditional copyright law already has provisions for such collected works.

I can and do distribute software without distributing the libraries it depends on. I avoid distributing GPL'd libraries because my lawyer told me that if I didn't distribute the libraries, he felt I had high probablity of winning a case against if the library copyright owner sued me (I do not GPL this code).

That said, when you use a function of a library, you are basing your work on that library (a third party's work); without it, the program won't run.

No, you are not. You are basing your work on the existence of code that implements an interface. A program that uses strcmp is not derivative of every implementation of strcmp out there. Consider the following thought experiment: I write my code using a free library. I don't ship the library, i use dynamic linking. My customer installs it on a machine with a PROPRIETARY implementation of that library. My code now operates on his machine using that proprietary library. Does the developer of that proprietary library now have claim on my work as derivative of his?

I think you're both right, in some cases. Linking against a C library, or any library for which there exists more than one implementation, obviously should be permitted (although distributing the library itself as part of the runtime may be restricted).

On the other hand, if you never considered works linking against a library derivatives of the library, you could work around the GPL simply by turning the GPL'd product into a library, which you distribute under the GPL, and then create your own proprietary product that uses that library.

There inevitably exists a gray area between these two extremes, unless you decide to use e.g. the existence of multiple, differently licensed implementations of an interface as the criterion for determining whether a library can be considered generic enough that it will never make a product a derivative work.

Most likely, the courts would consider things on a case-by-case basis based on more difficult issues such as apparent intent (modifying a GPL'd product into a library and creating a proprietary product using that quite obviously demonstrates intentionally trying to get around licensing restrictions and would likely be considered illegal).

I think that this is a particularly insightful comment. In the long run, judges will use these ambiguities in the law to attempt to do the "right thing". If there is no standard for what constitutes a "derivative work" with respect to software,

I've argued in other forums that the lack of legal challanges to the GPL strongly argues that lawyers think it is enforcable in general. There are a large number of obvious infringements to the GPL for which the courts will enforce it. It is these difficult corner cases where the GPL may not stand for everything that the people who use it to license their work think that it stands for.

Some argue that even dynamic linking performed by the user, not the distributor, can constitute an infringement. The authors of Gnumeric claim that all plugins for Gnumeric must be GPLed. (Do the authors of the Gimp make the same claim?) That claim may not stand even if there are inline functions which get compiled into a Gnumeric plugin when a crucial include file is used. Certainly the claim should not stand if someone writes a compatible include file which inplements the same interface.

If you link to a library, you use it. There's no other way how you can use a library, than to link to it.

What you, the creator of alleged derivative work, do when you use a library is communication with the library through some well-defined interface. You may look at the library code, but you usually don't, unless some problems occur. In case of static linking you actually distribute the original work with your program, so this has to be treated separately. But I don't see any significant difference between dynamic linking, RPC, ..., and executing some FS program as a separate process (fork(), execve(), pipe(), ...). In all cases you exclusively communicate with the FS code through some well-defined interface.

So do you think I cannot create a commercial shell script wrapper around a FS program (stupid example, but simple), because it doesn't work without it and thus it's a derivative work? OK, this is also a valid position, but this would make a way too many [existing] things illegal.

And there are finer issues. E.g. I distribute my TeX macros under GPL. What legal effect it has on documents typeset using these macros? Are they derivative works? And the resulting DVI or PostScript files? And when they are printed on paper?

Well, the FSF apparently disagrees, otherwise they would not make a distinction between the GPL and the LGPL. Are you saying that it's okay to link to, for example, the Readline library? (which was GPLed for the explicit purpose of only allowing free software to use it)