Question Regarding GPL

Linus is not a lawyer, but he is a copyright holder and is
well-regarded by the other copyright holders who matter for
this.  If
he says, "The following is allowed" what that
means is, "I won't sue
for the following, and anyone who does will be in my bad
books."  Even
if his statements have no legal force, that significantly
reduces the
lawsuit risk.

However my understanding as a non-lawyer is that his
statements do
have legal weight.  If a judge finds that the GPL is unclear
on this
issue, the precedent of Linus' widely quoted and followed
guideline is
likely to affect a judge's decision.

And finally, and very importantly, the *reason* that Linus
gave his
opinion is worth looking at.  Linus' position is not "I
think this is
a grand thing to do."  Linus' position is that,
"my understanding of
the GPL says that this is OK."  If his understanding is
correct, then
it doesn't really matter what his legal standing is.

My understanding of his opinion is that in the case of a
loadable
module, there is no derived work until one is created by the
end-user
loading the module (which is within that user's rights to
do), and
after this derived work is created the GPL is not triggered
because
the user never does anything that touches on copyright law. 
That is
because the derived work (ie the running kernel) is not
copied,
distributed, etc.

My non-laywerly opinion is that Linus is mostly, but not
completely,
right.  The case where Linus is wrong comes up with virtual
machines -
if the running kernel is in a virtual machine which has a
snapshot
saved, that snapshot may be copied, given to someone else,
etc.  Which
would trigger copyright law and therefore the GPL.  However
this case
is fairly rare.  The overwhelming majority of people are not
running
their copies of Linux in a virtual machine.  And the
overwhelming
majority of times that people do use virtual machines, they
don't do
anything with them that would infringe on copyright law.

However even in those boundary cases, it isn't the author of
the
loadable kernel module who runs afoul of the GPL, it is the
end user
who loaded the module into a kernel and then redistributed
the derived
work.  So even in that case, it is OK to write a loadable
kernel
module that is proprietary.

IANAL, this is not legal advice, etc.  But if it is wrong
then I'd
hope that a real lawyer on the list would correct me.

Cheers,
Ben

On 1/20/06, Mark Kandianis <linux-manverizon.net> wrote:
>
>
> Note: forwarded message attached.
>
> ---------- Forwarded message ----------
> From: Mark Kandianis <linux-manverizon.net>
> To: Russell Nelson <nelsoncrynwr.com>
> Date: Fri, 20 Jan 2006 09:00:10 -0800 (PST)
> Subject: Re: Question Regarding GPL
> But Linus isn't a lawyer and if it can't be done, how
is IBMs db2 doing it?
>
> Ah the questions.............
>
> Mark.......www.x-oz.com
>
> Russell Nelson <nelsoncrynwr.com> wrote:
> Singh, Akshay writes:
> > > I have a question regarding GPL licensing for
Loadable Kernel Module.
>

Quoting Ben Tilly (btillygmail.com):

> My understanding of his opinion is that in the case of
a loadable
> module, there is no derived work until one is created
by the end-user
> loading the module (which is within that user's rights
to do), and
> after this derived work is created the GPL is not
triggered because
> the user never does anything that touches on copyright
law.

Whether one work is a "derivative" of another
within the meaning of
copyright law is a factual question that -- in USA legal
jurisdictions --
would be decided by reference to the "abstraction,
filtration, comparison"
test detailed in the ruling precedent, CAI v. Altai, Inc.,
FN53:
982 F.2d 693, 23 USPQ2d 1241 2d Cir. 1992), which was
further detailed
in Gates Rubber v. Bando Chemical, FN57: 9 F.3d 823, 28
USPQ2d 1503 10th
Cir. 1993.

For your leisure reading, here's the Altai decision:
http://www.bitlaw.com/source/cases/copyright/altai.html

> IANAL, this is not legal advice, etc.  

IANALOSCJ.  (I am not a lawyer or Supreme Court Justice.)

Oops, I forgot to also mention Micro Star v. FormGen, Inc.,
154 F.3d
1107 9th Cir. 1998, and had better do so before John Cowan
cluebats me
about it.  (Infringing software work incorporated original's
creative 
elemenets, even though they didn't share even a single line
of code.)
http://cyber.law.harvard.edu/openlaw/DVD
/cases/Micro_Star_v_Formgen.html

-- 
Cheers,                                        "He who
hesitates is frost."
Rick Moen                                                 --
Inuit proverb
ricklinuxmafia.com  

Rick Moen scripsit:

> Whether one work is a "derivative" of another
within the meaning of
> copyright law is a factual question that -- in USA
legal jurisdictions --
> would be decided by reference to the "abstraction,
filtration, comparison"
> test detailed in the ruling precedent, CAI v. Altai,
Inc., FN53:
> 982 F.2d 693, 23 USPQ2d 1241 2d Cir. 1992), which was
further detailed
> in Gates Rubber v. Bando Chemical, FN57: 9 F.3d 823, 28
USPQ2d 1503 10th
> Cir. 1993.
> 
> Oops, I forgot to also mention Micro Star v. FormGen,
Inc., 154 F.3d
> 1107 9th Cir. 1998, and had better do so before John
Cowan cluebats me
> about it.  

What, me cluebat a made man?  Heaven, as they say, forfend.

I will note, though, that both CAI and Micro Star are Court
of Appeals
circuit-court decisions, and as such aren't settled law in
all fifty
states, though the Tenth Circuit has followed the Second in
CAI.
(In Canada the test is abstraction-comparison-filtration,
FWIW.)

Also FWIW, I think Micro Star is obviously wrongly decided,
and if followed
scrupulously would make it impossible to sell libre programs
meant to
run on a non-libre interpreter.

-- 
Business before pleasure, if not too bloomering long before.
        --Nicholas van Rijn
                John Cowan <cowanccil.org>
                        http://www.ccil.org/~cowan
  http://www.reutershealth
.com

On 1/20/06, Rick Moen <ricklinuxmafia.com> wrote:
> Quoting Ben Tilly (btillygmail.com):
>
> > My understanding of his opinion is that in the
case of a loadable
> > module, there is no derived work until one is
created by the end-user
> > loading the module (which is within that user's
rights to do), and
> > after this derived work is created the GPL is not
triggered because
> > the user never does anything that touches on
copyright law.
>
> Whether one work is a "derivative" of another
within the meaning of
> copyright law is a factual question that -- in USA
legal jurisdictions --
> would be decided by reference to the "abstraction,
filtration, comparison"
> test detailed in the ruling precedent, CAI v. Altai,
Inc., FN53:
> 982 F.2d 693, 23 USPQ2d 1241 2d Cir. 1992), which was
further detailed
> in Gates Rubber v. Bando Chemical, FN57: 9 F.3d 823, 28
USPQ2d 1503 10th
> Cir. 1993.
>
> For your leisure reading, here's the Altai decision:
> http://www.bitlaw.com/source/cases/copyright/altai.html

I'm not sure whether you're agreeing or disagreeing with me.

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. 
Linus'
stated opinion is that it is possible.  My admittedly
uninformed
opinion is that he is right.  Many people have released
drivers that
depend on that opinion being correct.

What you've said is that the correct test to use is the one
described
in that decision.  I just read that decision, and I am left
no more
able to answer the fundamental question than I was before. 
I now know
that it can be legal to release a piece of software that
modifies
another piece of running software.  I have had it confirmed
that
saving the result in tangible form triggers copyright
considerations. 
Neither particularly surprises me.

The specific question of fact that I have is this: is code
that uses
Linux' public API for loadable modules necessarily going to
be
derivative under copyright?

> > IANAL, this is not legal advice, etc.
>
> IANALOSCJ.  (I am not a lawyer or Supreme Court
Justice.)

Then I won't blame you for our President.  I also know that,
living in
California, you had no say in the decision anyways.

> Oops, I forgot to also mention Micro Star v. FormGen,
Inc., 154 F.3d
> 1107 9th Cir. 1998, and had better do so before John
Cowan cluebats me
> about it.  (Infringing software work incorporated
original's creative
> elemenets, even though they didn't share even a single
line of code.)
> http://cyber.law.harvard.edu/openlaw/DVD
/cases/Micro_Star_v_Formgen.html

I don't see the relevance.  Unless SCO were to use it to
shortcircuit
the discussion by claiming that Linux infringes on Unix
copyrights
which (in some alternate universe) they own.

Cheers,
Ben

Quoting Ben Tilly (btillygmail.com):

> I'm not sure whether you're agreeing or disagreeing
with me.

Welcome to the law.  ;->

> 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.  My
admittedly
> uninformed opinion is that he is right.

To my knowledge, his most recent statement was on
2002-10-17, as follows
(in part):  

  The _only_ thing that allows for non-GPL modules is
copyright law, and
  in particular the "derived work" issue. A vendor
who distributes non-GPL
  modules is _not_ protected by the module interface per se,
and should
  feel very confident that they can show in a court of law
that the code
  is not derived.  [...]

  The original binary-only modules were for things that were
  pre-existing works of code, i.e., drivers and filesystems
ported 
  from other operating systems, which thus could clearly be
argued 
  to not be derived works, and the original limited export
table 
  also acted somewhat as a barrier to show a level of
distance.

By "derived work", Torvalds meant "derivative
work" as used as a term of
art within copyright law.

My point, in any event, was that the factual question would
be resolved
by a court not by consulting Torvalds's or anyone else's
opinions, but
(in USA jurisdictions) by applying the Altai test to the
allegedly 
infringing code.


> Many people have released drivers that depend on that
opinion being
> correct.

Note:  Torvalds's opinions on the matter have been known to
change
dramatically, without advance notice.  Compare his
1995-12-17 and
2002-10-17 proclamations on LKML, as archived here: 
"Proprietary Kernel
Modules" on http://linuxmafia.co
m/kb/Kernel/


> What you've said is that the correct test to use is the
one described
> in that decision.  I just read that decision, and I am
left no more
> able to answer the fundamental question than I was
before.

My old landlord and colleague Richard Couture had a saying
-- harsh, 
but relevant:  "Sorry to hear about _your_
problem."  ;->  The relevant
test is the one that will be applied.  I'm just telling the
truth.

[Micro Star decision:]

> I don't see the relevance.  U

Relevance is that non-literal copying can infringe, and that
copyright-encumbered content isn't necessarily limited to
code.

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. 

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;

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).)

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.

Does anyone besides me think that similar language in GPLv3
would be
helpful?

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices
(www.rosenlaw.com)
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) 
   [Available also at www.rosenlaw.com/oslbook.htm]
 
> -----Original Message-----
> From: Rick Moen [mailto:ricklinuxmafia.com] 
> Sent: Friday, January 20, 2006 3:59 PM
> To: license-discussopensource.org
> Subject: Re: Re: Question Regarding GPL
> 
> Quoting Ben Tilly (btillygmail.com):
> 
> > I'm not sure whether you're agreeing or
disagreeing with me.
> 
> Welcome to the law.  ;->
> 
> > 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.  My
admittedly 
> > uninformed opinion is that he is right.
> 
> To my knowledge, his most recent statement was on
2002-10-17, 
> as follows (in part):  
> 
>   The _only_ thing that allows for non-GPL modules is 
> copyright law, and
>   in particular the "derived work" issue. A
vendor who 
> distributes non-GPL
>   modules is _not_ protected by the module interface
per se, 
> and should
>   feel very confident that they can show in a court of
law 
> that the code
>   is not derived.  [...]
> 
>   The original binary-only modules were for things that
were
>   pre-existing works of code, i.e., drivers and
filesystems ported
>   from other operating systems, which thus could
clearly be argued
>   to not be derived works, and the original limited
export table
>   also acted somewhat as a barrier to show a level of
distance.
> 
> By "derived work", Torvalds meant
"derivative work" as used 
> as a term of art within copyright law.
> 
> My point, in any event, was that the factual question
would 
> be resolved by a court not by consulting Torvalds's or
anyone 
> else's opinions, but (in USA jurisdictions) by applying
the 
> Altai test to the allegedly infringing code.
> 
> 
> > Many people have released drivers that depend on
that opinion being
> > correct.
> 
> Note:  Torvalds's opinions on the matter have been
known to change
> dramatically, without advance notice.  Compare his
1995-12-17 and
> 2002-10-17 proclamations on LKML, as archived here:  
> "Proprietary Kernel
> Modules" on http://linuxmafia.co
m/kb/Kernel/
> 
> 
> > What you've said is that the correct test to use
is the one 
> described
> > in that decision.  I just read that decision, and
I am left no more
> > able to answer the fundamental question than I was
before.
> 
> My old landlord and colleague Richard Couture had a
saying -- harsh, 
> but relevant:  "Sorry to hear about _your_
problem."  ;->  
> The relevant
> test is the one that will be applied.  I'm just telling
the truth.
> 
> [Micro Star decision:]
> 
> > I don't see the relevance.  U
> 
> Relevance is that non-literal copying can infringe, and
that
> copyright-encumbered content isn't necessarily limited
to code.

On 1/20/06, Lawrence Rosen <lrosenrosenlaw.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_Formgen.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.h
tml#LinkingWithGPL 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

> > 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:btillygmail.com] 
> Sent: Friday, January 20, 2006 7:59 PM
> To: lrosenrosenlaw.com
> Cc: license-discussopensource.org
> Subject: Re: Re: Question Regarding GPL
> 
> On 1/20/06, Lawrence Rosen <lrosenrosenlaw.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/Mic
ro_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

On 1/20/06, Rick Moen <ricklinuxmafia.com> wrote:
> Quoting Ben Tilly (btillygmail.com):
>
> > I'm not sure whether you're agreeing or
disagreeing with me.
>
> Welcome to the law.  ;->

Is this where I break out my lawyer jokes?

[...]
> > Many people have released drivers that depend on
that opinion being
> > correct.
>
> Note:  Torvalds's opinions on the matter have been
known to change
> dramatically, without advance notice.  Compare his
1995-12-17 and
> 2002-10-17 proclamations on LKML, as archived here: 
"Proprietary Kernel
> Modules" on http://linuxmafia.co
m/kb/Kernel/

On the surface that's that looks like a pretty big jump. 
Though when
you squint at it sideways, he's at least somewhat
consistent.  The
following statements appeared in some form in both opinions.

- It should be possible to port a non-Linux driver to work
with Linux
without making it GPLed.

- He doesn't think people should write Linux-specific
drivers and not GPL them.

- He doesn't like non-GPLed drivers.

- Linux-specific drivers are arguably derivative works of
Linux.

- He sees the original limited kernel export table as
providing a
plausible copyright barrier.

- Maintaining a binary-only Linux driver is very
inconvenient.

When I look closely, the only actual inconsistency is that
in the
first one he talks about how the structure of the kernel
module
interface makes it possible to avoid copyright infringement,
while in
the second he says that the kernel module interface was
never
documented or meant for that purpose.  You can actually make
him
completely consistent if you add to his later statement the
understanding that by "module interface" he means
"current module
interface".  This is not entirely implausible since he
does draw a
distinction in the 2002 opinion between the original and the
current
interfaces.

Perhaps I'm just on a roll because I can vindicate a
personal hero
, but
a vague memory  that there was a significant factual change
there - his 1995 description of the kernel module interface
would not
be an accurate description of the 2002 kernel module
interface.  As
the facts change, his description of the consequences of the
facts
should change.

However I did have to stretch a bit to make him consistent. 
But when
I compare my understanding on key issues between now and 7
years ago,
I could forgive him a lot bigger inconsistencies than I had
then.

But while I see the inconsistency, I'd have to disagree with
your
characterization that Linus' opinions changed drastically. 
The
emphasis was different in both cases, but that was a pretty
long list
of very specific points that he made the same way both
times.  And ot
wasn't an accident that he made those points.  For instance
I just
googled and found the 1998 interview at
http://l
inuxgazette.net/issue32/rubini.html.  He again quickly
hits
all of those points except the last two technical ones. 
(Given the
forum, omitting technical details makes sense.)  I'd
therefore call
him very consistent in all of the points that I listed.

> > What you've said is that the correct test to use
is the one described
> > in that decision.  I just read that decision, and
I am left no more
> > able to answer the fundamental question than I was
before.
>
> My old landlord and colleague Richard Couture had a
saying -- harsh,
> but relevant:  "Sorry to hear about _your_
problem."  ;->  The relevant
> test is the one that will be applied.  I'm just telling
the truth.

That's like answering a kid who said, "When will I see
the house" with
a long treatise on optics.  Everything that you said is
true,
relevant, and useless. 

> [Micro Star decision:]
>
> > I don't see the relevance.  U
>
> Relevance is that non-literal copying can infringe, and
that
> copyright-encumbered content isn't necessarily limited
to code.

Ah.  Which makes it much harder to write loadable modules
without infringing.

Cheers,
Ben