"Derivative Work" for Software Defined

Ravicher, Daniel (x2826) dravicher at pbwt.com
Mon Jan 13 18:39:02 UTC 2003


Yes, but Section 0 of the GPL defines "a work based on the Program", as in
"when you distribute the same sections as part of a whole which is __a work
based on the Program__", as such:

"a "work based on the Program" means either the Program or any derivative
work under copyright law"

So, the GPL does appear to rely on the definition of derivative work under
copyright law for drawing the line between those works that are covered and
those that are not.  

Plus, for the GPL to impact the rights of folks with respect to programs
that are not derivative works, it must be a contract, something FSF
expressly says it is not (see:
http://www.nccusl.org/nccusl/meetings/UCITA_Materials/kunze-ucita.pdf).  If
its not a contract, then copyright law precludes the finding of any
infringement by the distribution of an independent (synonymous with not
derivative) work.

--Dan

Daniel Ravicher
Patterson Belknap Webb & Tyler LLP
1133 Avenue of the Americas
New York, NY 10036
212.336.2826 direct
212.336.7900 fax
mailto:dravicher at pbwt.com
http://www.pbwt.com/


-----Original Message-----
From: PETERSON,SCOTT K (HP-USA,ex1) [mailto:scott.k.peterson at hp.com]
Sent: Monday, January 13, 2003 1:30 PM
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

------------------------------------------------------------------------------
Privileged/Confidential Information may be contained in this message.  If you
are not the addressee indicated in this message (or responsible for delivery
of the message to such person), you may not copy or deliver this message to
anyone.  In such case, you should destroy this message and kindly notify the
sender by reply email.  Please advise immediately if you or your employer
do not consent to Internet email for messages of this kind.

==============================================================================

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



More information about the License-discuss mailing list