"Derivative Work" for Software Defined

Tue Jan 14 04:13:10 UTC 2003

Scott,

I think your response would be appropriate if the GPL were a contract
rather than a mere copyright license.  The GPL is intended by its
authors to be interpreted and enforced under copyright law.  There is no
basis in that law for the definition of "derivative work" that is
implied by the GPL language you quoted.  How can you assume that a
licensee accepted such a broadened definition of "derivative work"
absent his assent to a contract?

The MPL also attempts to apply to more than derivative works.  While I
don't particularly understand its reach, at least it is to be enforced
as a contract and thus the definitions in that contract are relevant.
That, for me, is the essential difference between a copyright license
and a contract.

The GPL can't do more than copyright law allows -- because that's how
its authors want it to be treated.  I don't understand how GPL licensors
can benefit from contract provisions.

/Larry

> -----Original Message-----
> From: PETERSON,SCOTT K (HP-USA,ex1) [mailto:scott.k.peterson at hp.com] 
> Sent: Monday, January 13, 2003 10:30 AM
> To: 'lrosen at rosenlaw.com'; 'Andre Hedrick'; 'Ian Lance Taylor'
> Cc: dravicher at pbwt.com; license-discuss at opensource.org
> Subject: RE: "Derivative Work" for Software Defined
> 
> 
> Larry --
> 
> I think that you place too much emphasis on the concept of 
> "derivative work". It seems clear that section 2 of the GPL 
> is about more than merely derivative works. If all that 
> matters is whether something is a derivative work, then what 
> does the following paragraph from section 2 mean:
> 
> "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."
> 
> -- Scott
> ______________________________
> Scott K. Peterson
> Corporate Counsel
> Hewlett-Packard Company
> One Cambridge Center
> Cambridge, MA 02142
> scott.k.peterson at hp.com
> 
> 
> -----Original Message-----
> From: Lawrence E. Rosen [mailto:lrosen at rosenlaw.com]
> Sent: Monday, January 06, 2003 7:36 PM
> To: 'Andre Hedrick'; 'Ian Lance Taylor'
> Cc: dravicher at pbwt.com; license-discuss at opensource.org
> Subject: RE: "Derivative Work" for Software Defined
> 
> 
> I continue to believe that these confusing messages about 
> "derivative works" entirely miss the mark.  Where in the 
> statutory or case law can one find support for such 
> conclusions as are reflected in these messages? 
> 
> If you don't create "a work based upon one or more 
> preexisting works" then you have simply not created a 
> derivative work.  17 U.S.C. §101. How in the world does an 
> independently-written piece of software that communicates 
> with another independently-written piece of software through 
> a published API ever become a derivative work of that other 
> software?  Where in the GPL does it say that it can become a 
> derivative work?  
> 
> Nothing in the Copyright Act addresses the *use* of software 
> in this way.  If the GPL is enforced under the copyright law, 
> then how could a court ever conclude that it reaches to such 
> API-connected pre-existing works that merely get used together?
> 
> /Larry Rosen
> 
> > > > One of the questions about "Derivative Work" as it
> > relates to binary
> > > > only loadable objects, is the creation of a boundary layer of
> > > > execution. Specifically, the design and publishing an API which 
> > > > properly glues into an open source gpl program or 
> > kernel(ie loadable
> > > > modules services) designed to provide an execution layer
> > between the
> > > > GPL and Commerial private code. Where as no GPL code in
> > any form is
> > > > allowed to touch the Commerial code. The converse is true,
> > > > obviously.  The execution layer or boundary. Now using this 
> > > > reference from 1995, many companies have gotten legal positions 
> > > > about binary modules.
> > > > 
> > > > 
> > http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaav
> a.hels
> > > inki.fi
> > 
> > What Linus says presumably is valid for Linux.  RMS agrees with that
> > in the message you forwarded.  It doesn't necessarily apply to any 
> > program other than Linux.  Note in particular the last paragraph in 
> > Linus's message.
> 
> If all one is using are headers or .h files and everything 
> else is from scratch, does using the headers under the 
> statement above comply with the intent?
> 
> I am not seeking an opinion without paying for it.
> 
> > > I ship and sell binary only products, so I have an interest in not
> > > restricting people.
> > 
> > Other than your customers, presumably.  Restrictions cut both ways.
> 
> In what way would a restrict cut both ways here?
> 
> I am a little naive, but always try to do the right thing.
> 
> Regards,
> 
> Andre
> 
> --
> license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
> 
> --
> license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
> 

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3