RE: Re: Open Source Licensing

Mike,

I agree with you about the ambiguities and uncertainties of the GPL. That's one of the reasons I encourage the use of the Open Software License (OSL, www.rosenlaw.com/osl2.0.html). This is not to say that the GPL is unenforceable; I think SCO is dead wrong on that. But, like you, I prefer a license that is clean and clear.

/Larry Rosen
General counsel, Open Source Initiative

> -----Original Message-----
> From: CNI-COPYRIGHT -- Copyright & Intellectual Property
> [mailto:CNI-COPYRIGHT[_at_]cni.org] On Behalf Of Mike Oliver
> Sent: Wednesday, August 20, 2003 9:55 AM
> To: CNI-COPYRIGHT -- Copyright & Intellectual Property
> Subject: [CNI-(C)] Re: Open Source Licensing
>
>
> Lawrence E. Rosen wrote:
>
> >Perhaps what you're describing is the effect of the so-called
> >reciprocity provision in some licenses like the GPL and the Open
> >Software License (OSL, www.rosenlaw.com/osl2.0.html
> <http://www.rosenlaw.com/osl2.0.html>).
> >If your client's work is combined with another open source
> work so as
> >to create a derivative work, and if the other open source work is
> >licensed under a reciprocal license, your client's work will
> also have
> >to be so licensed.
>
> The GPL uses contract language that is not co-extensive with
> US law on
> the meaning of "derivative work" in software source code
> copyrights (IMO).
>
> The GPL defines "work based on the Program" to "mean[] 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**."
> (emphasis added)
>
> US law defines a derivative work as: "a work based upon one or more
> preexisting works, such as a translation, musical arrangement,
> dramatization, fictionalization, motion picture version, sound
> recording, art reproduction, abridgment, condensation, or any
> other form
> in which a work may be recast, transformed, or adapted."
>
> I do not believe that every non GPL'd program running in memory that
> "contains [the GPL'd] Program or a portion of it" is "based upon" the
> GPL'd code.
>
> Had the GPL simply stopped at "...derivative work under
> copyright law"
> it would be ok. But instead, it adds that next phrase which
> introduces
> ambiguity, because it is not the language used in the US
> Copyright law.
> So, what is the intention of the parties to a GPL license? To refer
> extrinsically to copyright law to define the scope of a derivative
> work? To use the copyright law as an aid but not a mandatory
> determinant of the scope of a derivative work? To redefine what is
> meant by derivative work?
>
> It would even had been better, but not optimal, if the GPL simply did
> not make a reference to copyright law, and used instead its
> own lexicon
> to define "work based on the Program." (also to note, it would be
> preferable not to use "program" and instead use "source code" or
> "compiled code.")
>
> The portion in asterisks above (or bolded) IMO is not
> consonant with US
> derivative work principles. Specifically: if a person
> statically links
> two programs (i.e. compiles two programs together from
> separate sources)
> is that a derivative work of both independent programs?
>
> Prof Moglen (the FSF enforcer) thinks it is: see (
> http://www.gnu.org/press/mysql-affidavit.html ) where he takes the
> position that a derivative work is any statically linked program. At
> the hearing the court was not convinced this was right (nor was the
> court convinced it was wrong), and the case settled before a
> ruling was
> issued. I have heard that the FSF also takes the position that
> dynamically linked programs can be derivatives as well (I guess the
> position is that when loaded into memory together, the new running
> program in memory is a derivative of the separate compiled codes).
>
> This is just one of many areas where the GPL, in the opinion of this
> lawyer, is woefully deficient as a license agreement.
> Indeed, there is
> so much ambiguity in some parts of it that I counsel nearly
> all of our
> clients not to use GPL'd software in proprietary coding
> unless they can
> negotiate a real license with the holder, get real reps and
> warranties,
> and get an indemnity at least to the extent of that parties
> contributions (which raises another problem: because of the
> nature of
> the GPL - if code you want to license under some non-GPL
> based license
> itself used GPL'd code of another developer, can that licensor modify
> the terms??)
>
> Though it may sound coarse to refer to the GPL as "viral" that is
> exactly what it is - once some code is licensed under the GPL, it can
> affect each successive layer in unpredictable ways, and often
> cannot be
> undone due to the number of contributors or "authors" of the
> copyrights
> embodied in the code. The last thing most of our clients want is
> uncertainty in their IP rights, which can affect everything from the
> ability to give a rep or indemnity, to the value of the
> company when it
> is sold.
>
> I think you would find a ton of articles on the net if you googled a
> search of GPL open source license issues or something
> similar. But it
> all boils down to uncertainty, to me (whether I am right or wrong).
>
> best regards, mike oliver
> Bowie & Jensen, LLC
>
>
>
>
>
>
> #############################################################
> This message is sent to you because you are subscribed to
> the mailing list <CNI-COPYRIGHT[_at_]cni.org>.
> To unsubscribe, E-mail to: <CNI-COPYRIGHT-off[_at_]cni.org>
> To switch to the DIGEST mode, E-mail to
> <CNI-COPYRIGHT-digest[_at_]cni.org> To switch to the INDEX mode,
> E-mail to <CNI-COPYRIGHT-index[_at_]cni.org> To postpone your
> subscription, E-mail to <CNI-COPYRIGHT-null[_at_]cni.org> Send
> administrative queries to <CNI-COPYRIGHT-request[_at_]cni.org>
>
> Visit the CNI-COPYRIGHT e-mail list archive at
> <https://mail2.cni.org/Lists/CNI-COPYRIGHT/>.
>
Received on Thu Aug 21 2003 - 01:45:00 GMT