Re: comparison of public licenses?

From: <kmself[_at_]ix.netcom.com>
Date: Thu, 27 Jan 2000 10:46:02 -0800

On Wed, Jan 26, 2000, Nate Puri <natepuri[_at_]office.ompages.com> wrote:
>
> On Mon, Jan 24, 2000, Rod Dixon <rod[_at_]cyberspaces.org> wrote:
> >
> > On Thu, Jan 20, 2000, Nate Puri <natepuri[_at_]office.ompages.com> wrote:
> > >
> > > What is uncertain is the manners in which copyright will render
> > > one or more provisions of the GPL type licenses moot.
> >
> > I have a narrow disagreement with these assertions.
> >
> > While whether the GPL or some of its iterations could be enforced is
> > an open question, the assertion that derivative works are the copyright
> > of the author of the derivative work is dead wrong.
>
> I understand this, but I wasn't clear about the subject matter of what
> programmers are calling 'derivative.' What I hear most commonly from
> them is not who owns a derivative, but what is a derivative, where the
> purported work is not a merging of code (i.e., where the UNIX 'diff'
> files are merged on a line by line basis with a program that 'patches'
> code, but where the program is 'compiled against' a 'lib' or library of
> code, and the resulting compilation is a new work that depends on two
> separate code bases but is not 'based on' them.

IANAL. Following is my read of several licensing issues.

The reason for emphasis on "what is" rather than "who owns" in many free software discussions is that the concern is over whether or not a particular work falls under the terms of the license of another work or works. Establishing ownership is often a secondary concern, particularly ownership of specific code segments when all are known to be covered under specific licensing terms.

My own understanding, concerning the GPL, is that the definition of "derived work" is based as closely as possible on the concepts of copyright law. This essentially means reading "fixed in a tangible medium" and the various media and forms in which a program may be fixed: source or object code; disk, hardcopy, or RAM; static and "runtime" images. The concept of linked libraries leading to derived works is generally understood to function as follows:

More interesting cases emerge from non-compiled languages, databases, scripted languages, and the like. Not all of the boundaries are well defined.

> I would personally appreciate if someone could clarify the what is
> and is not derivative in regards to code 'linking.' For example,
> to compile the Secure Shell ("SSH"), one needs RSAREF library, libc,
> and the compiler gcc. If I wrote SSH, B wrote libc, C wrote gcc,
> and R wrote RSAREF, what is legal status of the the binary module
> named ssh that could not have been compile without the other three
> dependencies?

As a standalone, probably none, though issues of contributory infringement may be raised if subsequent linking is assumed.

As a runtime image, probably a derived work of you, B, C, and R.

Depending on licensing terms of various components, this might or might not be allowed. In the specific instances of libc and gcc, the LGPL applies, which allows linking to works not licensed under LGPL or GPL. Not sure about RSAFER or your SSH program.

Licensing the SSH module under the GPL would require each of the component modules be licensed or licensable under the GPL, unless they met the GPLs exception rules.

> These are elusive issues for me....

You're in good company.

> "Anonymity is a shield from the tyranny of the majority."
> --McIntyre v. Ohio Campaign Commission, 514 U.S. 334 (1995)

Anonymity raises its own host of issues as well.

-- 
Karsten M. Self (kmself[_at_]ix.netcom.com)
    What part of "Gestalt" don't you understand?

SAS for Linux: http://www.netcom.com/~kmself/SAS/SAS4Linux.html
Mailing list:  "subscribe sas-linux" to mailto:majordomo[_at_]cranfield.ac.uk
Received on Thu Jan 27 2000 - 18:48:30 GMT

This archive was generated by hypermail 2.2.0 : Mon Mar 26 2007 - 00:35:38 GMT