Subject: RE: Re: Question Regarding GPL
From: "Lawrence Rosen" <lrosen@rosenlaw.com>
Date: Fri, 20 Jan 2006 20:36:16 -0800

 Fri, 20 Jan 2006 20:36:16 -0800
> > 1(b): to translate, adapt, alter, transform, modify, or 
> > arrange the Original Work, thereby creating derivative works
> > ("Derivative Works") based upon the Original Work;
>
> According to the Microstar case it is possible to wind up 
> with a derivative work even though they did not translate, 
> adapt, alter, transform, modify, or arrange the Original 
> Work.  Are those derivative works banned by your license?

Read the OSL 3.0 language carefully. Actions other than those simply aren't
allowed by the license at all. Other verbs not listed aren't allowed, and
those verbs that are listed "thereby" create derivative works.

Of course, 1(a) says you can also copy the work [e.g., without any
changes!] into collective works.

In this respect, OSL 3.0 resembles the LGPL and the MPL.

> My understanding of Galoob says that there should be no 
> copyright issues involved with linking as long as the result 
> is not saved. 

Wonderful. 

> 2. The change runs counter to the stated goals of the FSF.

One of which appears to be license ambiguity about linking. That is their
right. But as I read statements by Linus, that is not his goal with Linux.
That's where we started this, trying to understand the goal being enunciated
by Linus' exception to the GPL. I'm asking if different license language
could better satisfy the goals for Linux.

/Larry

** Lawrence Rosen
** Rosenlaw & Einschlag, technology law offices
** Stanford University School of Law, Lecturer in Law
** 3001 King Ranch Road, Ukiah, CA 95482
** 707-485-1242  *  fax: 707-485-1243
** Author of "Open Source Licensing: Software Freedom
**    and Intellectual Property Law" (Prentice Hall 2004)
** [www.rosenlaw.com]  

> -----Original Message-----
> From: Ben Tilly [mailto:btilly@gmail.com] 
> Sent: Friday, January 20, 2006 7:59 PM
> To: lrosen@rosenlaw.com
> Cc: license-discuss@opensource.org
> Subject: Re: Re: Question Regarding GPL
> 
> On 1/20/06, Lawrence Rosen <lrosen@rosenlaw.com> wrote:
> > Previous emails wrote:
> > > > It is obvious that a loadable module can be derivative of the 
> > > > Linux kernel.  Just start with a piece of the Linux kernel and
> > > make it into
> > > > a loadable module.  The question is whether it is 
> possible for a 
> > > > loadable module to not be derivative of the Linux kernel.
> > >
> > > Yes, very succinctly put.
> > >
> > > > Linus's stated opinion is that it is possible.
> > <snip>
> >
> > I'm turning this back into a question more challenging for 
> license-discuss:
> >
> > This entire issue of linking independent modules to Linux 
> has bothered 
> > us all for way too long, and from what I read GPLv3 won't 
> solve it--at 
> > least not yet. The GPL is ambiguous about such combinations, and 
> > regular pronouncements about it from the mountain top don't really 
> > help us achieve a common understanding among all the 
> licensors and licensees in the world.
> 
> I don't see how the GPL can possibly address it given its 
> current structure.  The GPL is not a contract, it only 
> applies if you do something that requires permission under 
> copyright law.  The question is whether creating and using 
> proprietary loadable modules is something that requires 
> permission under copyright law.
> 
> Rick's pointed to the decision at
> http://cyber.law.harvard.edu/openlaw/DVD/cases/Micro Star v Fo
> rmgen.html
> which references Galoob, 964 F.2d at 967 saying that a 
> derivative work must exist in a "concrete or permanent form." 
>  Apparently that precedent found that copyright law did not 
> apply to a situation where a derivative work was created by 
> modifying a program in memory.  My understanding of that 
> precedent says that if it is legal to create and distribute a 
> loadable module, copyright does not restrict one's ability to 
> load it into a running kernel.  (Though copyright would come 
> into play if one then saved a system image including the 
> current state of the modified kernel.)
> 
> Therefore end users do not generally need copyright 
> permission to use a loadable module that someone else has 
> written.  The question therefore comes down to whether 
> copyright permission is needed to write the loadable module 
> in the first place.  If permission is required then the GPL 
> can and does address this - proprietary loadable modules are 
> not allowed.  If permission is not required then the GPL 
> can't possibly restrict this without completely changing the 
> logic of how it works.
> 
> > The language of OSL 3.0  1(a) and 1(b) attempts to solve 
> the problem 
> > by separately granting a license to copy the Original Work and a 
> > license to create Derivative Works. These are the specific 
> things you 
> > are authorized to
> > do:
> >
> >    1(a): to reproduce the Original Work in copies, either 
> alone or as part
> >          of a collective work;
> >
> >    1(b): to translate, adapt, alter, transform, modify, or 
> arrange the
> >          Original Work, thereby creating derivative works 
> ("Derivative
> > Works")
> >          based upon the Original Work;
> 
> According to the Microstar case it is possible to wind up 
> with a derivative work even though they did not translate, 
> adapt, alter, transform, modify, or arrange the Original 
> Work.  Are those derivative works banned by your license?
> 
> > So if Linux were licensed under OSL 3.0, linking a device 
> driver to it 
> > would create either a collective work containing a copy of 
> Linux and a 
> > copy of the driver or, if the driver was created by translating, 
> > adapting, altering, transforming, modifying, or arranging Linux, a 
> > derivative work of Linux. If the latter, source code would 
> have to be 
> > disclosed. (See  1(c).)
> 
> My understanding of Galoob says that there should be no 
> copyright issues involved with linking as long as the result 
> is not saved.  But I'm sure that Rick will come along shortly 
> with a list of links to a series of cases where judges looked 
> at linking and came to the opposite decision.
> 
> > Note that with such language, you'd never get into silly legal 
> > problems with pre-existing, independently-written 
> copyrighted modules 
> > being declared derivative works of Linux simply because the 
> works are linked together.
> 
> You'd still have the silly legal question we are discussing 
> about whether writing a work that uses Linux' published API 
> for loadable modules results in a derivative work.
> 
> Also your fix does the opposite of RMS and Eben want.  They 
> want the answer they gave at 
> http://www.fsf.org/licensing/licenses/gpl-faq.html#LinkingWith
GPL to be true.
> 
> IMO licenses should do exactly what the authors want them to 
> do to the full extent allowed under the law.  That means that 
> the GPLv3 should satisfy the goals of the FSF.  Since it is 
> their desire to provide maximum encouragement to make 
> software free (by their definition of freedom), the GPLv3 
> should do exactly that.
> 
> I think that other people should use it only if the result 
> meets their needs.
> 
> > Does anyone besides me think that similar language in GPLv3 
> would be 
> > helpful?
> 
> No, for both reasons that I gave.
> 
> 1. As long as there is a factual question about when 
> something is a derivative work, there is a factual question 
> about what the GPL says. 
> In particular the question that I had is whether programming to Linux'
> published API for creating a loadable module was sufficient 
> to make your code into a derivative work.  If it does, then 
> your suggestion does not make loadable modules legal.  It 
> makes *loading* them legal, but not the act of creating the 
> thing to load.
> 
> 2. The change runs counter to the stated goals of the FSF.
> 
> Cheers,
> Ben