Re: comparison of public licenses?

On Thu, Jan 27, 2000, Rod Dixon <rod[_at_]cyberspaces.org> wrote:
>
> 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:
> > >
> > > 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. I would personally
> > appreciate if someone could clarify the what is and is not derivative
> > in regards to code 'linking.' For example, to complise 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?
> >
> > These are elusive issues for me....
>
> I think you are asking two different questions, but you are definitely
> on to a pivotal issue regarding the GPLs. I think the GNU GPL sweeps
> more broadly than how copyright law defines a derivative work... broad
> enough, infact, to claim your linking modules as part of the open source
> project. The GPL only excludes programs that are entirely functional,
> separate, and independent of the open source project...and distributed
> that way. In my opinion, this is exactly why one could craft a good
> argument that the GNU GPL has a troubling modification provision under
> Art. 2. If an open source project were ambitious enough (let's say
> an Operating System, wink, wink), the GPL would have the effect of
> allowing the project organizer or original copyright holder implacably
> acquire copyright interests in the so-called derivative works
> subsequently created using the "original" source code. This is so
> because "orginal source code" is a moving target under the GPL.

No.

The GPL specifically excludes the OS from its definition of source code the operating system, in section 3:

    [A]s a special exception, the source code distributed need not     include anything that is normally distributed (in either source     or binary form) with the major components (compiler, kernel, and     so on) of the operating system on which the executable runs,     unless that component itself accompanies the executable.

http://www.fsf.org/copyleft/gpl.html

Further, in the case of one extremely popular operating system (wink, wink yourself), certain modules (device drivers) are further excluded from falling under the definition of the work itself (Linus Torvalds's special exception to the GPL in the Linux kernel).

IMO the discussion of "derivative works" is a bit misplaced. It's not what the GPL considers to be a derivative work, but what it considers to be the work itself.

In section 0:

    The "Program", below, refers to any such program or work, and     a "work based on the Program" means either the Program or any     derivative work under copyright law: that is to say, a work     containing the Program or a portion of it, either verbatim or     with modifications and/or translated into another language.

I'd say that this is fairly orthodox usage.

However, the definition of "source code" is interesting, and is, I believe the source of the breadth of claims over what is considered a derivative work of the program:

    The source code for a work means the preferred form of the work     for making modifications to it. For an executable work, complete     source code means all the source code for all modules it contains,     plus any associated interface definition files, plus the scripts     used to control compilation and installation of the executable.

(OS exclusion ommitted, quoted above).

In other words, the definition of source includes everything required to run *and build* the program. The question of just where the boundaries around "all modules it contains" are drawn is an interesting one. It is the definition of "the work", and not of its derivatives, which captures libraries. Not to mention Makefiles....

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