"Derivative Work" for Software Defined
PETERSON,SCOTT K (HP-USA,ex1)
scott.k.peterson at hp.com
Wed Jan 15 15:23:13 UTC 2003
Andre --
The only point that I really want to make in these messages is the
following:
I observe interpretations of the GPL have been offered that appear to me to
be inconsistent with the language of the GPL. I'm trying to understand how I
might be misreading that apparently inconsistent language in the GPL. As in
an earlier message, "I want to become a believer ...". But, I can't embrace
an interpretation of the GPL that I can't reconcile with the language of the
GPL.
For more detail, see the message to David Johnson that I sent a few minutes
ago.
-- Scott
______________________________
Scott K. Peterson
Corporate Counsel
Hewlett-Packard Company
One Cambridge Center
Cambridge, MA 02142
phone: 617-551-7612
mobile: 978-764-8615
scott.k.peterson at hp.com
-----Original Message-----
From: Andre Hedrick [mailto:andre at linux-ide.org]
Sent: Tuesday, January 14, 2003 5:32 PM
To: PETERSON,SCOTT K (HP-USA,ex1)
Cc: 'lrosen at rosenlaw.com'; dravicher at pbwt.com;
license-discuss at opensource.org; 'Ian Lance Taylor'
Subject: RE: "Derivative Work" for Software Defined
Scott--
> My critique of Larry's analysis is to say that considering whether A is a
> derivative work of B is not necessarily the end of the analysis. What I
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Provide one does not introduce subjective points, but where are the points
of fact and not beliefs?
> failed to point out in my previous message (and what I'll try to make
> explicit here) is the following: I believe that one should also consider
the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Where is your proof in the equation of facts.
A+B == AB == BA == A^B == B^A or ~= Ae^B ~= e^AB
> question of whether A+B is one program. In that case, A+B is a "work based
> on the Program" and A+B is a derivative work of the Program, even though A
> might not be a derivative work of B. I see this as being wholly consistent
> with sections 0 and 2.
What you do not have is a test to discriminate.
What you have not addressed is A+C == A' and C+B == B'.
C == the abstraction between the two items or their communication path.
C may be the resulting derived work, but the copyright is own by the
author of the original work A.
A has the legal right to use C however it wishes.
C also complies with any issues B has in the tainting by GPL.
So we have both A and B disassociated, and C is joint operation.
Comments?
Andre Hedrick
LAD Storage Consulting Group
IANAL, but Storage Technologist.
On Tue, 14 Jan 2003, PETERSON,SCOTT K (HP-USA,ex1) wrote:
> Larry --
>
> You keep returning to contract obligations. But, I'm not relying on any
> contract obligations. Any distribution that includes copyrightable
material
> from B needs the permission of B's copyright owner. The hypothetical that
> I've presented includes distribution of B. Thus, B's permission is needed.
> I'm trying to understand the conditions the copyright owner has attached
to
> the copyright owner's offer of permission to distribute B (the conditions
in
> the GPL). So, the conditions specified in the GPL are relevant to what
> someone needs to do in order to legally distribute A+B, without regard to
> whether A+B is has some special status as a protected copyrightable work
> (B's protectable status is enough).
>
> I think you may be saying that if A is not a copyright infringement of B,
> then there is no copyright problem and thus the GPL is not relevant.
That's
> fine for distribution of A by itself. However, the person who wants to
> distribute A and B together (even if only as a mere aggregation) still
needs
> the permission of the B's copyright owner and thus, needs to know what
> conditions the GPL might require. (Look up both sleeves. No contract
> obligation in sight. Really!)
>
> I may not be understanding what you are saying, and we may be talking in
> circles. Perhaps we should await some opportunity when we can sit back in
> the comfort of some overstuffed chairs, possibly with a beverage in hand,
> and have a relaxing interactive discussion.
>
> -- Scott
>
> I can now see how confusing my use of A+B is. That is based on a
> hypothetical in a parallel discussion branch - I introduced it in my reply
> to David Ravicher:
> ---------------------
> It is apparent that I have been unclear about what I meant, so let me try
a
> hypothetical.
>
> Assume some code A and some code B. Assume that B is licensed under the
GPL
> and that one is trying to answer the question, "When I distribute A and B
> together, must A be distributed under the GPL?"
> My critique of Larry's analysis is to say that considering whether A is a
> derivative work of B is not necessarily the end of the analysis. What I
> failed to point out in my previous message (and what I'll try to make
> explicit here) is the following: I believe that one should also consider
the
> question of whether A+B is one program. In that case, A+B is a "work based
> on the Program" and A+B is a derivative work of the Program, even though A
> might not be a derivative work of B. I see this as being wholly consistent
> with sections 0 and 2.
>
> What I don't understand is that, if all one needs to do is to answer the
> question, "Is A a derivative work of B?", then what is the point of the
> paragraph in section 2 that I quoted in my earlier message (below).
> ---------------------
> ______________________________
> 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: Tuesday, January 14, 2003 12:24 PM
> To: 'PETERSON,SCOTT K (HP-USA,ex1)'
> Cc: dravicher at pbwt.com; license-discuss at opensource.org; 'Andre Hedrick';
> 'Ian Lance Taylor'
> Subject: RE: "Derivative Work" for Software Defined
>
>
> Scott,
>
> I never suggested that a software license (speaking generally, now)
> "only requires a determination of whether A is a derivative of B."
> Contracts set their own law, and definitions matter. Theoretically one
> can write a license that sets reciprocity conditions that apply to works
> that link to each other in any way at all, or that merely coexist on the
> same medium. I won't prejudge whether such a license would be
> compatible with the OSD, but at least it would be legally effective to
> do so.
>
> But when a license purports NOT to be a contract and intends to be
> interpreted in the same way worldwide under copyright law alone, then I
> don't understand how you can go beyond what that law provides. Does the
> "legal rule of construction" that you refer to have any application
> outside of contract law? For a copyright license that is to be
> interpreted under copyright law, why would a court construct anything
> more than what the statutory or case law requires? How can a licensee
> be bound to interpretive language in a *mere* copyright license?
>
> I don't think it is true that "if A+B is one work under copyright law,
> then it is a derivative work of both A and B." (I'm not quoting you
> precisely because your email is slightly garbled; have I misquoted you?)
> What does the "+" mean in your mathematical expression "A+B"? Suppose A
> is Windows and B is Excel. Are either of those programs derivative
> works of the other simply because thay are "plussed" together onto the
> same disk, or even link to each other in the course of their execution
> on a computer?
>
> What SHOULD the courts do with the language you quoted from section 2 of
> the GPL? I'm not really sure. Perhaps a broader interpretation of the
> term "derivative works" as applied to software will be accepted
> ultimately by the courts because of a community concensus that such an
> interpretation is appropriate. But I'd sure like to offer more than
> precatory language in a copyright license itself to support such an
> interpretation, such as one or more decisions by one or more federal
> courts. Nobody, including the most fervent advocates of the GPL, have
> ever provided such authority.
>
> /Larry
>
> [to avoid more message bloat, I'll clip down to the hypothetical]
> > -----Original Message-----
> > From: PETERSON,SCOTT K (HP-USA,ex1) [mailto:scott.k.peterson at hp.com]
> > Sent: Tuesday, January 14, 2003 6:52 AM
> > To: 'lrosen at rosenlaw.com'
> > Cc: dravicher at pbwt.com; license-discuss at opensource.org;
> > 'Andre Hedrick'; 'Ian Lance Taylor'
> > Subject: RE: "Derivative Work" for Software Defined
> >
> >
> > Larry --
> >
> > I want to become a believer that the appropriate analysis
> > only requires determination of whether A is a derivative of
> > B. But I just don't see how that analysis squares with that
> > paragraph of section 2. I am stuck on that legal rule of
> > construction that says that in judging various possible
> > interpretations, one should weigh more heavily those
> > interpretations that give meaning to all of the provisions.
> >
> > Is this a point on which you think that the authors of the
> > GPL were wrong in their understanding of copyright law? Or,
> > what is your understanding of the meaning of the paragraph of
> > section 2 that I quoted?
> >
> > I am not assuming that the GPL does more than leverage the
> > copyright law. If
> > A+B is one work under the copyright law, then A+B is a
> > derivative of B
> > A+and
> > requires B's permission for distribution. Thus, it is
> > unnecessary to find a contractual obligation to restrict the
> > distribution of A+B.
> >
> > -- 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 13, 2003 11:13 PM
> > To: 'PETERSON,SCOTT K (HP-USA,ex1)'; 'Andre Hedrick'; 'Ian
> > Lance Taylor'
> > Cc: dravicher at pbwt.com; license-discuss at opensource.org
> > Subject: RE: "Derivative Work" for Software Defined
> >
> >
> > 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
More information about the License-discuss
mailing list