Derivative Works

When is one program a “derivative work” of another?
______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What about Source vs Binary?

Anonymous's picture

What if I download a source only version of a GPL work?

Is the compiled binary a derived work (a translation?) or is it simply "fair use" of the GPL work?

If it is not "fair use", what else are you supposed to do with source code? Just read it?

If it is "fair use", are source only packages shooting themselves in the foot?

U R Confused--Linked in what way!!

Anonymous's picture

Only dynamic linking is legal to GPL'd libraries because that does not include the source code in the work. Static linking is not allowed by the GPL because that does include the source code in the resulting work. LGPL is meant to allow static linking into new works. Stallman allows this sometimes for different reasons--for example, when alternative proprietary libraries are all ready freely available and already allow this... such as with flex and bison.

Re: Derivative Works

Anonymous's picture

While the FSF's disagreement might indicate at what point the FSF, in enforcing it's own copyrights, might decide that filing a suit is necessary, it is not necessarially the interpretation which a court, applying the pronciples of Copyright law, might give to the same provision.

The great strength of the GPL is also the great weakness of the GPL. The GPL utilizes the exclusive rights granted by copyright law to the author of a piece of software to perform a kind of legal jiu jitsu. The strength of copyright law is used to subvert copyright law.

On the other hand, where copyright law is weak, the GPL is also weak. And Copyright law is weak in the area of derived works when it comes to software. That's because a "method of operation" is not copyrightable.

Recently there was a discussion on the Linux Kernel Mailing List about the NVidia graphics drivers for Linux. These drivers are distributed as a closed source binary object and a GPLed interface module which intergaces between the (GPLed) kernel and the closed source binary object. The question raised was is NVidia in violation of the GPL by distributing such a work. The correct answer is remarkably complex but it revolves around what constitutes a derivative work.

Is a driver a derivative work of the kernel? That depends. It may very well incorporate an include file or two and perhaps even some inline functions which are required to interface with the Kernel. The FSF position is that linking is determinative. But here's an example which might convince you otherwise.

What if the binary object was written for a completely different OS? It's a object file with functions and metadata so that it can be loaded and relocated. Is it a dervied work of the Linux kernel? Does writing an interface, using the generally accepted "methods of operation" for modules make it a derived work of the Kernel?

These legal questions are difficult. We also have to be careful not to overspecify when software becomes a derivative work of the OS it runs under or else we give Microsoft too much control over what software can me written and used on MS operating systems.

I think that the answer is clear, if you use published (or even undocumented) interfaces to an Operating SYstem, you are utilizing uncopyrightable "methos of operation" and are not creating derived works.

What does this say about incorporating GNU Readline? It tells you when the FSF is likely to sue you for doing so, not whether doing so makes you liable for creating a derived work.

Re: Derivative Works

Anonymous's picture

Even linking dynamically to a library requires using an include file of function prototypes in the C and C++ languages and that include file, being part of the GPL protected work, is now part of your source code, and thus, your work is now GPL.

So, in practical terms, there is no way to "link" to a GPL library without transferring the terms of the GPL to your own work.

I have never seen any C or C++ program that did not include some of the standard headers like stdio.h etc.

QED

No. The #include is

Anonymous's picture

No.

The #include is incorporated within an image in RAM when I compile, and there's explicit permission in the copyright law to make such copies if it's a necessary step in running the program.

Re: Derivative Works

Anonymous's picture

You really don't "need" header files with function prototypes to link c code. It's foolish not to use them, but they are not mandatory

Re: Derivative Works

Anonymous's picture

But it goes to the intent. Clearly the FSF has spelled out the intent of the GPL by creating the LGPL to address such circumstances as proprietary linking (with supporting documents that spell out their intent). Version 2 of the GPL was specifically written to deal with linking. There are stronger copyrights such as the Affero GPL which close the loophole for web services. Any other loopholes would be cleared up in version 3 of the GPL. It comes down to what the author of the library or program intended. If they wish proprietary programs to be able to link to their program then they would put it under the LGPL or a number of other OSI liscences. If however they intend any program linking or using their code to recontribute then there is the GPL.

Re: Derivative Works

Anonymous's picture

Sure it goes to the intent of what the author intended to accomplish with the license, but that does not address whether the author has the right to make that kind of restriction.

If I try to use a license which attempts to take away your right to make Fair Uses of my copyrighted work, I should expect such an attempt to fail because I'm not granted the right to restrict Fair Uses by copyright law. Sure my intent is clear, but unless I'm exercising an exclusive right guaranteed by Copyright Law, then I don't have the right to do that which I intend.

Consider this scenario.

Anonymous's picture

Suppose someone writes a library that implements a standard API - for which commercial versions already exist - and he GPL's it. Both libraries are dynamically linkable.

Now, I write an application that uses that standard API. Are you telling me

that if I link my binary against the GPL'ed library - then my application must be GPL'ed - but if I link it against the commercial version, it doesn't?

Bear in mind that the resulting binary will be bit-for-bit identical in those two cases.

Suppose - you are right - and I link against the commercial one - and distribute my application (without the library code). Now someone runs my application (without my knowledge) against the GPL'ed code. Is my application *now* caught in the GPL trap? What if I didn't even know the GPL'ed version of the library existed? What if it didn't even exist when I wrote my application?

If dynamic linking fell legally under the GPL, we could force Microsoft to release the entire source code to WORD - by simply writing a GPL'ed plug-compatible DLL that matched one of the DLL's that WORD links to!

That's just silly.

Hence, one absolutely MUST distinguish the dynamically linked case from the static case.

The difference between the intent of LGPL and GPL is mainly to cover that statically linked case. LGPL provides the application author with an alternative to releasing his source code when statically linking to the library.

Instead of GPL'ing the entire application source code, he may provide some means to re-link the application against alternative versions of the library. This could include shipping source code under some non-GPL license - or it could mean shipping partially compiled ".o" files with instructions on how to statically link against new versions of the library.

This provision allows library authors to provide statically linkable versions of their libraries that can still be used by closed source commercial applications - albeit with some difficulty. ..yet it still gives the end user most of the benefits of full GPL for the library code.

Without these provisions, there would also be terrible difficulties with linking applications to multiple libraries - some under GPL, others under some commercial license.

Re: Consider this scenario.

Anonymous's picture

but maybe the only problem is that you can't distribute it..

e[at]videocatwalk.com

NOT TRUE

Anonymous's picture

Dynamic linking, as Stallman himself puts it, "unfortunately cannot force the GPL upon the derrivative work".

Only static linking applies to what you are saying because only static linking includes parts of the library in the resulting work. As for dynamic linking, it could link to any compatible library. It doesn't necessarilly have to be the GPL'd one. The GPL'd one is separate and therefore cannot possibly have any legal rights over anything that links to it.

If you write a letter and save it in a format compatible with Microsoft Word, does that mean Microsoft can put a copyright on your letter?

Well...

Counsel's picture

I am not familiar with Word's license so, a hypothetical might be best...
If (1) the license under which "WordProcessingSoftware" (WPS) is released states that anything you write with the software is in the public domain; and (2) you agree to the license, use the software, and write a novel, is the novel in the public domain?

Is the "Novel" copyrighted by you? Is the copyright limited by the license under which you wrote the "Novel?"

Licenses may be binding, and I think good lawyers should work to make the license clear. The problem is that some companies can "make money" by having "unclear" licenses. I advice everyone to read the license(s) they agree to be bound by and attempt to understand their reach...

not quite

Anonymous's picture

If a license is on its face illegal under copyright law (e.g. does not allow fair use), then even if you agree to the license you are not bound by it. In much the same way that a contract that violates existing law is not binding (i.e. even if you sign a contract to become someone's slave, you obviously are not bound by it).

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix