Re: Linux GPL and binary module exception clause?

Re: Linux GPL and binary module exception clause?

[Paul Adams]

--- In linux-kernel@yahoogroups.com, Linus Torvalds
<torvalds@o...> wrote:
> - anything that was written with Linux in mind
(whether it then
> _also_ works on other operating systems or not) is
clearly
> partially a derived work.

I am no more a lawyer than you are, but I have to
disagree.  You
are not free to define "derivative work" as you
please.  You
must use accepted legal definitions.  At least in the
U.S., you
must consider what Congress had to say on this.  They
said, "to
constitute a violation of section 106(2) [which gives
copyright
owners rights over derivative works], the infringing
work must
incorporate a portion of the copyrighted work in some
form; for
example, a detailed commentary on a work or a
programmatic musical
composition inspired by a novel would not normally
constitute
infringements under this clause."
http://www4.law.cornell.edu/uscode/17/106.notes.html

A work that is inspired by Linux is no more a
derivative work than
a programmatic musical composition inspired by a
novel.  Having
Linux in mind cannot be enough to constitute
infringement.

Remember also that U.S. copyright law states:
"In no case does copyright protection for an original
work of
authorship extend to any idea, procedure, process,
system, method
of operation, concept, principle, or discovery,
regardless of
the form in which it is described, explained,
illustrated, or
embodied in such work."
http://www4.law.cornell.edu/uscode/17/102.html
Thus you cannot claim infringement because a work
merely shares
ideas or methods of operation with Linux.

The standard used in U.S. courts for determining if
software
violates a copyright includes a filtering procedure to
eliminate
unprotected aspects as described above.  A standard
filter is that
you eliminate an element if "The element's expression
was dictated
by external factors, such as using an existing file
format or
interoperating with another program."  Computer
Associates v.
Altai specifically discusses the need to filter
elements related
to "compatibility requirements of other programs with
which a
program is designed to operate in conjunction."
http://www.bitlaw.com/source/cases/copyright/altai.html
Code needed to interoperate with the Linux kernel thus
cannot be
considered as a factor in determining if the Linux
copyright is
infringed.

Unless actual Linux code is incorporated in a binary
distribution
in some form, I don't see how you can claim
infringement of the
copyright on Linux code, at least in the U.S.



__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Linux GPL and binary module exception clause?

[Nick Piggin]

Paul Adams wrote:

>--- In linux-kernel@yahoogroups.com, Linus Torvalds
><torvalds@o...> wrote:
>
>>- anything that was written with Linux in mind
>>
>(whether it then
>
>>_also_ works on other operating systems or not) is
>>
>clearly
>
>>partially a derived work.
>>
>
>I am no more a lawyer than you are, but I have to
>disagree.  You
>are not free to define "derivative work" as you
>please.  You
>must use accepted legal definitions.  At least in the
>U.S., you
>must consider what Congress had to say on this.  They
>said, "to
>constitute a violation of section 106(2) [which gives
>copyright
>owners rights over derivative works], the infringing
>work must
>incorporate a portion of the copyrighted work in some
>form; for
>example, a detailed commentary on a work or a
>programmatic musical
>composition inspired by a novel would not normally
>constitute
>infringements under this clause."
>http://www4.law.cornell.edu/uscode/17/106.notes.html
>
>A work that is inspired by Linux is no more a
>derivative work than
>a programmatic musical composition inspired by a
>novel.  Having
>Linux in mind cannot be enough to constitute
>infringement.
>

Of course not, thought police aren't any good until a mind reader
is invented ;)

Seriously:
What about specifically a module that includes the Linux Kernel's
headers and uses its APIs? I don't think you could say that is
definitely not a derivative work.

Re: Linux GPL and binary module exception clause?

[Kendall Bennett]

Nick Piggin <piggin@cyberone.com.au> wrote:

> What about specifically a module that includes the Linux Kernel's
> headers and uses its APIs? I don't think you could say that is
> definitely not a derivative work. 

You cannot copyright an API - people have been down that path before in 
the proprietry software community and have not succeeded. You can 
copyright the code in the header files, but does simply using the header 
files to build a program mean that the driver is now infected? If the 
header files include lots and lots of inline functions that ended up 
compiled into the code, then maybe.

Then again, it appears that most developers are using wrapped to avoid 
this situation, such that their private code does not include any Linux 
headers, only the GPL'ed wrapper.

So we go in circles again.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: Linux GPL and binary module exception clause?

[Thierry Vignaud]

"Kendall Bennett" <KendallB@scitechsoft.com> writes:

> Then again, it appears that most developers are using wrapped to
> avoid this situation, such that their private code does not include
> any Linux headers, only the GPL'ed wrapper.

wrappers are gpl-ed.
i do not think they offer so much "work" that their authors have the
right to tell "here's there's a boundary; our binary module can
legally use our wrapper".

Re: Linux GPL and binary module exception clause?

[Peter Chubb]

>>>>> "Nick" == Nick Piggin <piggin@cyberone.com.au> writes:

Nick> Paul Adams wrote:


Nick> Seriously: What about specifically a module that includes the
Nick> Linux Kernel's headers and uses its APIs? I don't think you
Nick> could say that is definitely not a derivative work.

As far as I know, interfacing to a published API doesn't infringe
copyright.

Note:


Paul>   A standard filter is that you eliminate an element if "The
Paul> element's expression was dictated by external factors, such as
Paul> using an existing file format or interoperating with another
Paul> program."  Computer Associates v. Altai specifically discusses
Paul> the need to filter elements related to "compatibility
Paul> requirements of other programs with which a program is designed
Paul> to operate in conjunction." 
Paul> http://www.bitlaw.com/source/cases/copyright/altai.html


If you don't accept this, then maybe you have to start accepting SCO's
claims on JFS, XFS, &c.

(Disclaimer: I am not a lawyer)
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: Linux GPL and binary module exception clause?

[Nick Piggin]

Peter Chubb wrote:

>>>>>>"Nick" == Nick Piggin <piggin@cyberone.com.au> writes:
>>>>>>
>
>Nick> Paul Adams wrote:
>
>
>Nick> Seriously: What about specifically a module that includes the
>Nick> Linux Kernel's headers and uses its APIs? I don't think you
>Nick> could say that is definitely not a derivative work.
>
>As far as I know, interfacing to a published API doesn't infringe
>copyright.
>

So binary modules don't infringe copyright and aren't derived works?
If so then the way to control access to the kernel is to control the
"published API" ie. the api/abi exported modules, and exceptions for
GPL modules are useless. Hmm.

>
>Note:
>
>
>Paul>   A standard filter is that you eliminate an element if "The
>Paul> element's expression was dictated by external factors, such as
>Paul> using an existing file format or interoperating with another
>Paul> program."  Computer Associates v. Altai specifically discusses
>Paul> the need to filter elements related to "compatibility
>Paul> requirements of other programs with which a program is designed
>Paul> to operate in conjunction." 
>Paul> http://www.bitlaw.com/source/cases/copyright/altai.html
>
>
>If you don't accept this, then maybe you have to start accepting SCO's
>claims on JFS, XFS, &c.
>

Not quite sure what you mean here. As far as I was aware, SCO doesn't
have any copyrights or patents on any code in the Linux Kernel so it is
not a similar situation. I haven't followed the SCO thing closely though.

Re: Linux GPL and binary module exception clause?

[Peter Chubb]

>>>>> "Nick" == Nick Piggin <piggin@cyberone.com.au> writes:

Nick> Peter Chubb wrote:

Nick> Not quite sure what you mean here. As far as I was aware, SCO
Nick> doesn't have any copyrights or patents on any code in the Linux
Nick> Kernel so it is not a similar situation. I haven't followed the
Nick> SCO thing closely though.

As I understand it, SCO is/was claiming that JFS and XFS are derived
works of the UNIX source base, because they were developed to match
the internal interfaces of UNIX, and with knowledge of the internals
of UNIX -- and they hold the copyrights of and are the licensor of UNIX.

I may be misunderstanding their points.  And I am not a lawyer.

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Fri, 5 Dec 2003, Peter Chubb wrote:
>
> As I understand it, SCO is/was claiming that JFS and XFS are derived
> works of the UNIX source base, because they were developed to match
> the internal interfaces of UNIX, and with knowledge of the internals
> of UNIX -- and they hold the copyrights of and are the licensor of UNIX.

Yes, and I'm not claiming anything like that.

I claim that a "binary linux kernel module" is a derived work of the
kernel, and thus has to come with sources.

But if you use those same sources (and _you_ wrote them) they do not
contain any Linux code, they are _clearly_ not derived from Linux, and you
can license and use your own code any way you want.

You just can't make a binary module for Linux, and claim that that module
isn't derived from the kernel. Because it generally is - the binary
module not only included header files, but more importantly it clearly is
_not_ a standalone work any more. So even if you made your own prototypes
and tried hard to avoid kernel headers, it would _still_ be connected and
dependent on the kernel.

And note that I'm very much talking about just the _binary_. Your source
code is still very much yours, and you have the right to distribute it
separately any which way you want. You wrote it, you own the copyrights to
it, and it is an independent work.

But when you distribute it in a way that is CLEARLY tied to the GPL'd
kernel (and a binary module is just one such clear tie - a "patch" to
build it or otherwise tie it to the kernel is also such a tie, even if you
distribute it as source under some other license), you're BY DEFINITION
not an independent work any more.

(But exactly because I'm not a black-and-white person, I reserve the right
to make a balanced decision on any particular case. I have several times
felt that the module author had a perfectly valid argument for why the
"default assumption" of being derived wasn't the case. That's why things
like the AFS module were accepted - but not liked - in the first place).

This is why SCO's arguments are specious. IBM wrote their code, retained
their copyrights to their code AND THEY SEVERED THE CONNECTION TO SCO'S
CODE (and, arguably the connections didn't even exist in the first place,
since apparently things like JFS were written for OS/2 as well, and the
Linux port was based on that one - but that's a separate argument and
independent of my point).

See the definition of "derivative" in USC 17.1.101:

	A "derivative work" is 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. A work consisting
	of editorial revisions, annotations, elaborations, or other
	modifications which, as a whole, represent an original work of
	authorship, is a "derivative work".

And a binary module is an "elaboration" on the kernel. Sorry, but that is
how it IS.

In short: your code is yours. The code you write is automatically
copyrighted by YOU, and as such you have the right to license and use it
any way you want (well, modulo _other_ laws, of course - in the US your
license can't be racist, for example, but that has nothing to do with
copyright laws, and would fall under a totally different legal framework).

But when you use that code to create an "elaboration" to the kernel, that
makes it a derived work, and you cannot distribute it except as laid out
by the GPL. A binary module is one such case, but even just a source patch
is _also_ one such case. The lines you added are yours, but when you
distribute it as an elaboration, you are bound by the restriction on
derivative works.

Or you had better have some other strong argument why it isn't. Which has
been my point all along.

			Linus

Re: Linux GPL and binary module exception clause?

[Jeremy Fitzhardinge]

On Fri, 2003-12-05 at 09:19, Linus Torvalds wrote:
> But when you use that code to create an "elaboration" to the kernel, that
> makes it a derived work, and you cannot distribute it except as laid out
> by the GPL. A binary module is one such case, but even just a source patch
> is _also_ one such case. The lines you added are yours, but when you
> distribute it as an elaboration, you are bound by the restriction on
> derivative works.
> 
> Or you had better have some other strong argument why it isn't. Which has
> been my point all along.

I tend to agree, but there is a counter-argument:

You can't copyright "facts".  A header file contains facts about the
kernel within it, particularly once it has been compiled into machine
code.  In machine code, it is simply things like integers (the sizes and
offsets of things, other constants), and encoded entrypoints (however
function calls back into the kernel end up looking).  A binary
containing facts about the kernel is not a derived work of the kernel,
even if those facts came from headers in the kernel source.  

To argue against this, you'd have to demonstrate that the original
author of the header file had some creative input into the machine code
of the module, on order for the module to be considered a derived work
of the header.  

You could so far as saying that if every header put a chunk of text
(say, a piece of poetry) into each .o file which used that header, then
there'd be a much stronger case for saying the .o is derived from the
header. 

I've had long complex arguments with legal types over whether function
names are creative ("flumulate_my_greeble" is the best function name
ever!) or mere facts (the function name is simply a cookie you need to
refer to to call a function - it doesn't matter what the name actually
is).

	J

Re: Linux GPL and binary module exception clause?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

On Fri, 05 Dec 2003 15:23:10 +1100, Peter Chubb said:

> As far as I know, interfacing to a published API doesn't infringe
> copyright.

Well, if the only thing in the .h files was #defines and structure definitions,
it would probably be a slam dunk to decide that, yes.

Here's the part where people's eyes glaze over:

% cd /usr/src/linux-2.6.0-test10-mm1
% find include -name '*.h' | xargs egrep 'static.*inline' | wc -l
   6288

That's 6,288 chances for you to #include GPL code and end up
with executable derived from it in *your* .o file, not the kernel's.

More to the point, look at include/linux/rwsem.h, and ask yourself
how to call down_read(), down_write(), up_read(), and up_write()
without getting little snippets of GPL all over your .o.  

And even if your module doesn't get screwed by that, there's a
few other equally dangerous inlines waiting to bite you on the posterior.

I seem to recall one of the little buggers was particularly nasty, because it
simply Would Not Work if not inlined, so compiling with -fno-inline wasn't an
option.  Unfortunately, I can't remember which it was - it was mentioned on
here a while ago when somebody's kernel failed to boot because a gcc 3.mumble
had broken inlining.....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

RE: Linux GPL and binary module exception clause?

[Hua Zhong]

> Here's the part where people's eyes glaze over:
> 
> % cd /usr/src/linux-2.6.0-test10-mm1
> % find include -name '*.h' | xargs egrep 'static.*inline' | wc -l
>    6288
> 
> That's 6,288 chances for you to #include GPL code and end up
> with executable derived from it in *your* .o file, not the kernel's.

What's so fundamentally different about inline functions, or, IOW, a
finer format of macros?

It doesn't matter if the API is inline or not. What matters is if using
this API makes your program a derivative work. From this perspective,
it's just an interface, no matter how it's implemented.

Let's be frank: how many people really try to read the header file when
they use these APIs? They don't care if they are inlined or not. To them
they are just _APIs_.

RE: Linux GPL and binary module exception clause?

[David Schwartz]

> On Fri, 05 Dec 2003 15:23:10 +1100, Peter Chubb said:
>
> > As far as I know, interfacing to a published API doesn't infringe
> > copyright.
>
> Well, if the only thing in the .h files was #defines and
> structure definitions,
> it would probably be a slam dunk to decide that, yes.
>
> Here's the part where people's eyes glaze over:
>
> % cd /usr/src/linux-2.6.0-test10-mm1
> % find include -name '*.h' | xargs egrep 'static.*inline' | wc -l
>    6288
>
> That's 6,288 chances for you to #include GPL code and end up
> with executable derived from it in *your* .o file, not the kernel's.

	I'm sorry, but that just doesn't matter. The GPL gives you the unrestricted
right to *use* the original work. This implicitly includes the right to
peform any step necessary to use the work. (This is why you can 'make a
copy' of a book on your retina if you have the right to read it.) Please
tell me how you use a kernel header file, other than by including it in a
code file, compiling that code file, and executing the result.

> More to the point, look at include/linux/rwsem.h, and ask yourself
> how to call down_read(), down_write(), up_read(), and up_write()
> without getting little snippets of GPL all over your .o.

	Exactly, it's impossible. So doing so is a necessary step to using the
header file.

> And even if your module doesn't get screwed by that, there's a
> few other equally dangerous inlines waiting to bite you on the posterior.

	No problem. If you can't avoid them, then you're allowed to do them.

> I seem to recall one of the little buggers was particularly
> nasty, because it
> simply Would Not Work if not inlined, so compiling with
> -fno-inline wasn't an
> option.  Unfortunately, I can't remember which it was - it was
> mentioned on
> here a while ago when somebody's kernel failed to boot because a
> gcc 3.mumble
> had broken inlining.....

	So you're argument is that it's impossible to use the header file without
creating a derived work, hence permission to use the header file is
permission to create the derived work. This supports my argument that you
can create a derived work without agreeing to the GPL. Thanks.

	DS

RE: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Thu, 4 Dec 2003, David Schwartz wrote:
>
> The GPL gives you the unrestricted right to *use* the original work.
> This implicitly includes the right to peform any step necessary to use
> the work.

No it doesn't.

Your logic is fundamentally flawed, and/or your reading skills are
deficient.

The GPL expressly states that the license does not restrict the act of
"running the Program" in any way, and yes, in that sense you may "use" the
program in whatever way you want.

But that "use" is clearly limited to running the resultant program. It
very much does NOT say that you can "use the header files in any way you
want, including building non-GPL'd programs with them".

In fact, it very much says the reverse. If you use the source code to
build a new program, the GPL _explicitly_ says that that new program has
to be GPL'd too.

> Please tell me how you use a kernel header file, other than by including
> it in a code file, compiling that code file, and executing the result.

You are a weasel, and you are trying to make the world look the way you
want it to, rather than the way it _is_.

You use the word "use" in a sense that is not compatible with the GPL. You
claim that the GPL says that you can "use the program any way you want",
but that is simply not accurate or even _close_ to accurate. Go back and
read the GPL again. It says:

	"The act of running the Program is not restricted"

and it very much does NOT say

	"The act of using parts of the source code of the Program is not
	 restricted"

In short: you do _NOT_ have the right to use a kernel header file (or any
other part of the kernel sources), unless that use results in a GPL'd
program.

What you _do_ have the right is to _run_ the kernel any way you please
(this is the part you would like to redefine as "use the source code",
but that definition simply isn't allowed by the license, however much you
protest to the contrary).

So you can run the kernel and create non-GPL'd programs while running it
to your hearts content. You can use it to control a nuclear submarine, and
that's totally outside the scope of the license (but if you do, please
note that the license does not imply any kind of warranty or similar).

BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.

Comprende?

		Linus

RE: Linux GPL and binary module exception clause?

[David Schwartz]

> On Thu, 4 Dec 2003, David Schwartz wrote:

> > The GPL gives you the unrestricted right to *use* the original work.
> > This implicitly includes the right to peform any step necessary to use
> > the work.

> No it doesn't.
>
> Your logic is fundamentally flawed, and/or your reading skills are
> deficient.

	I stand by my conclusions.

> The GPL expressly states that the license does not restrict the act of
> "running the Program" in any way, and yes, in that sense you may "use" the
> program in whatever way you want.

	Please tell me how you use the Linux kernel source code. Please tell me how
you run the Linux kernel source code without creating a derived work.

> But that "use" is clearly limited to running the resultant program. It
> very much does NOT say that you can "use the header files in any way you
> want, including building non-GPL'd programs with them".

	Huh? What "resultant program"? Are you talking about an executable that's a
derived work of the Linux kernel source code?

	Modules are derived works of the Linux kernel source code, not the kernel
executable. So the license that would be relevent would be a license that
restricts how you can use the source code or derived works of the source
code. License to run a program, when you have source code, is license to
compile that source code.

	For example, 2b says:

    b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.

	You don't seriously think that's talking about derived works that are
derived from *executables*, do you?

> In fact, it very much says the reverse. If you use the source code to
> build a new program, the GPL _explicitly_ says that that new program has
> to be GPL'd too.

	I download the Linux kernel sources from kernel.org. Please tell me what I
can do with them without agreeing to the GPL. Is it your position that I
cannot compile them without agreeing to the GPL? If so, how can running the
program be unrestricted? How can you run the linux kernel soruce code
without compiling it?

> > Please tell me how you use a kernel header file, other than by including
> > it in a code file, compiling that code file, and executing the result.
>
> You are a weasel, and you are trying to make the world look the way you
> want it to, rather than the way it _is_.

	That is a serious example of projection.

> You use the word "use" in a sense that is not compatible with the GPL. You
> claim that the GPL says that you can "use the program any way you want",
> but that is simply not accurate or even _close_ to accurate. Go back and
> read the GPL again. It says:
>
> 	"The act of running the Program is not restricted"
>
> and it very much does NOT say
>
> 	"The act of using parts of the source code of the Program is not
> 	 restricted"

	You run a piece of source code by compiling it. If a header file is
protected by the GPL, permission to "run" it means permission to include it
in files you compile.

	The GPL says:

  0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License.  The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,

	The work that was placed under the GPL is the Linux kernel source. The
"program" is the source code. Please, tell me how you "run" the Linux kernel
source code other than by compiling it to form a derived work.

	Perhaps you misunderstand the GPL to mean that a 'program' must be an
executable? Not only does section zero clearly refute that, but if it were
true, it would mean that a module is not a derived work from a GPL'd work!
It is a program that's placed under the GPL, and a module is not a derived
work from any other executable.

> In short: you do _NOT_ have the right to use a kernel header file (or any
> other part of the kernel sources), unless that use results in a GPL'd
> program.

	The phrase "results in a GPL'd program" is one that I cannot understand. I
have no idea what you mean by it. You have the right to "run" the header
file, the GPL gives it to you. The way you "run" a header file is by first
compiling a source code that includes it into an executable.

> What you _do_ have the right is to _run_ the kernel any way you please
> (this is the part you would like to redefine as "use the source code",
> but that definition simply isn't allowed by the license, however much you
> protest to the contrary).

	How can I run the kernel without compiling it? And how can I compile it
without creating a derived work? The GPL says:

  5. You are not required to accept this License, since you have not
signed it.  However, nothing else grants you permission to modify or
distribute the Program or its derivative works.  These actions are
prohibited by law if you do not accept this License.  Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.

	Of course, the second sentence is utterly false. Fair use and necessary
step provisions do just that.

> So you can run the kernel and create non-GPL'd programs while running it
> to your hearts content. You can use it to control a nuclear submarine, and
> that's totally outside the scope of the license (but if you do, please
> note that the license does not imply any kind of warranty or similar).
>
> BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.
>
> Comprende?

	I have no idea what you mean by a "NON-GPL'D BINARY". *Any* binary you
create from a kernel header file is, at least to some extent, a derived work
of that header file. However, the question for whether it would be covered
by the GPL is whether you exercised a privilege in creating that work that
you were only granted by the GPL.

	Again, what I'm trying to say is that the term "program" in the GPL means
whatever it is that's placed under the GPL (which can be an executable
and/or source code). Of course, placing an executable under the GPL
effectively places its source code under the GPL (as soon as you distribute
it to someone else, as you are required to do, who is limited only by the
GPL).

	In the case of the Linux kernel, the source code was initially placed under
the GPL. Once source code is placed under the GPL, your right to "run the
program" means a right to compile the source code. In the case of header
files, this means the right to include the header file in code files and
thereby produce and use derived works. (Whether or not you can distribute
those derived works is, of course, a whole different argument.)

	So my point is that the GPL isn't really even relevant here. You have all
the rights you need without agreeing to it. "Activities other than copying,
distribution and modification are not
covered by this License; they are outside its scope." Including a header
file in your own class file is not copying, distribution, or modification of
that header file. It is use, mere use.

	DS

RE: Linux GPL and binary module exception clause?

[Anders Karlsson]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

Afternoon/Evening/Whatever,

However interesting a debate about the legal status of the GPL is, its
applications to various works, including but not limited to the Linux
Kernel, perhaps a forum like 'linux-legal' could be created to remove
such discussions from the more technical list that linux-kernel is.

I am surprised such a discussion flared up in the LKML as I normally
associate such discussions with the lower scoring threads on SlashDot
(no offence intended to SlashDot itself).

Just my $0.45... (inflation and currency devaluation taken into account)

-- 
Anders Karlsson <anders@trudheim.com>
Trudheim Technology Limited

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux GPL and binary module exception clause?

[Ryan Anderson]

On Fri, Dec 05, 2003 at 03:16:27AM -0800, David Schwartz wrote:
> > The GPL expressly states that the license does not restrict the act of
> > "running the Program" in any way, and yes, in that sense you may "use" the
> > program in whatever way you want.
> 
> 	Please tell me how you use the Linux kernel source code. Please tell me how
> you run the Linux kernel source code without creating a derived work.

You "use" the Linux source code by feeding it to a compiler.  Or maybe
as a hideous fortune file.  The output of that compiler is *clearly* a
derived work, and thus bound by the GPL.

So far, I don't see any reason why a module that uses an inline function
provided via a kernel header could be distributed in binary format without 
being a "derived work" and thus bound by the GPL.

[snipping a bit]

> > In fact, it very much says the reverse. If you use the source code to
> > build a new program, the GPL _explicitly_ says that that new program has
> > to be GPL'd too.
> 
> 	I download the Linux kernel sources from kernel.org. Please tell me what I
> can do with them without agreeing to the GPL. Is it your position that I
> cannot compile them without agreeing to the GPL? If so, how can running the
> program be unrestricted? How can you run the linux kernel soruce code
> without compiling it?

Compile it.
Run the resulting executable (ignoring the case law that says copying
into ram is a copy under copyright law)
Read the source code.
Write a module using the source code (i.e, via headers)

If you want to distribute that module, you must, of course, follow the
GPL.

> 	You run a piece of source code by compiling it. If a header file is
> protected by the GPL, permission to "run" it means permission to include it
> in files you compile.

You don't run source code.  Not even in Perl programs (though there, at
least, the distinction is more complicated.)

You compile source code.  The resultant object code is then run.

> > In short: you do _NOT_ have the right to use a kernel header file (or any
> > other part of the kernel sources), unless that use results in a GPL'd
> > program.
> 
> 	The phrase "results in a GPL'd program" is one that I cannot understand. I
> have no idea what you mean by it. You have the right to "run" the header
> file, the GPL gives it to you. The way you "run" a header file is by first
> compiling a source code that includes it into an executable.

Repeat after me: The GPL is a copyright license.  It covers
distribution, not use.  Distribution of any part of the "work" is
covered.  Inline functions in headers are clearly part of the "work".

If you have a module that uses an inline function, there are two
options (note: not two legal options):
	Distribute source
	Distribute a binary

If you distribute a binary and refuse to provide the source under the GPL, 
ask yourself this: What gave you the right to distribute the
compiled form of the inline functions you use?

Note: My use of "inline functions" as a bludgeoning device should not be
interpreted as an acknowledgement that the rest of the header files
constitute a published "API".

-- 

Ryan Anderson
  sometimes Pug Majere

Re: Linux GPL and binary module exception clause?

[Shawn Willden]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 December 2003 07:03 am, Ryan Anderson wrote:
> Compile it.
> Run the resulting executable (ignoring the case law that says copying
> into ram is a copy under copyright law)

That case law can be safely ignored in the US, since it was superseded by 
real law, passed in 1980.  Per section 117 of Title 17 of the US Code:

- ----------------
(a) Making of Additional Copy or Adaptation by Owner of Copy. — 
Notwithstanding the provisions of section 106, it is not an infringement 
for the owner of a copy of a computer program to make or authorize the 
making of another copy or adaptation of that computer program provided:

	(1) that such a new copy or adaptation is created as an essential step
	in the utilization of the computer program in conjunction with a machine
	and that it is used in no other manner, or
- ----------------

So copies to disk and RAM that are "an essential step in the utilization of 
the computer program" are non-infringing.

	Shawn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0LRwp1Ep1JptinARAjrbAJ0RAa2axjrFABHgG1loqmxa6KTn0ACcCz1s
Q+DC9COjk+uv+FqdZ8kTg+g=
=N1sB
-----END PGP SIGNATURE-----

Re: Linux GPL and binary module exception clause?

[Arjan van de Ven]

> So copies to disk and RAM that are "an essential step in the utilization of 
> the computer program" are non-infringing.

probably true for the US, most definitely not true in europe... it's
explicit in law here that copying from disk-to-ram and ram-to-cpu is
distributing in the "need a license" sense...

Re: Linux GPL and binary module exception clause?

[Shawn Willden]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 December 2003 09:54 am, Arjan van de Ven wrote:
> probably true for the US, most definitely not true in europe... it's
> explicit in law here that copying from disk-to-ram and ram-to-cpu is
> distributing in the "need a license" sense...

That's very interesting.  Thanks.

	Shawn. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0LpTp1Ep1JptinARAnaWAJ4493In8CAp0p+yMlCAb2pmyXYbbQCeN0Cy
KUV+3WM27hGEHFPTTYHN/uI=
=x1pq
-----END PGP SIGNATURE-----

Re: Linux GPL and binary module exception clause?

[Derek Fawcus]

On Fri, Dec 05, 2003 at 05:54:50PM +0100, Arjan van de Ven wrote:
> 
> > So copies to disk and RAM that are "an essential step in the utilization of 
> > the computer program" are non-infringing.
> 
> probably true for the US, most definitely not true in europe... it's
> explicit in law here that copying from disk-to-ram and ram-to-cpu is
> distributing in the "need a license" sense...

Wrong  (assuming you want to include the UK as part of Europe :-)

UK Copyright Designs and Patent Act,  1988 (as ammended)

50C.--(1)  It  is not an infringement of copyright for a lawful user of
           a copy of a computer program to copy or adapt it,  provided
           that the copying or adapting-
   
   (a) is necessary for his lawful use; and
   (b) is  not  prohibited under any term or condition of an agreement
       regulating the circumstances in which his use is lawful

   (2)  It  may, in particular, be necessary for the lawful use of a
        computer program to copy it or adapt it for the purpose of
        correcting errors in it.

... and the above is from a copyright regime which is in general quite
draconian.

OK - So now you get to argue about EULAs,  but that's a seperate issue.

DF

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Fri, 5 Dec 2003, Shawn Willden wrote:
>
> So copies to disk and RAM that are "an essential step in the utilization of
> the computer program" are non-infringing.

Absolutely. But you don't have the right to distribute them.

Put another way: nVidia by _law_ has the right to do whatever essential
step they need to be able to run Linux on their machines. That's what the
exception to copyright law requires for any piece of software.

And in fact you should be damn happy for that exception, because that
exception is also what makes things like emulators legal - software houses
can't claim that you can't use an emulator to run their programs (well,
they may _try_, but I don't know if it ever gets to court).

But what they do NOT have the right to do is to create derivative works of
the kernel, and distribute them to others. That act of distribution is not
essential _for_them_ to utilize the kernel program (while the act of
_receiving_ the module and using it may be - so the recipient may well be
in the clear).

So in order for nVidia to be able to legally distribute a binary-only
kernel module, they have to be able to feel damn sure that they can
explain (in a court of law, if necessary) that the module isn't a derived
work. Enough to convince a judge. That's really all that matters. Our
blathering matters not at all.

Now, personally, I have my own judgment on what "derivative works" are,
and I use that judgement to decide if I'd complain or take the matter
further.

And so _I_ personally think some binary modules are ok, and you've heard
my arguments as to why. That means that _I_ won't sue over such uses,
since in my opinion there is no copyright infringement IN THOSE CASES due
to me not considering them derivative.

My opinions are fairly public, and the stuff I say in public actually does
have legal weight in that it limits what I can do (if I say in public that
I think something is ok, I have a much harder time then making the
argument that it _isn't_ ok in front of a judge - this is what the
"estoppel" thing is all about).

But the thing is, my public opinions don't bind anybody else. So if Alan
Cox, or _any_ other kernel copyright holder, disagrees with me (and trust
me, people do), they have the right to complain on their own. Their case
would be weakened by my stance (simply because a defendant could point to
my opinions and the judge might be swayed by that).

And quite frankly, my largest reason for not complaining loudly has often
been that I'm lazy, and in several cases of sme people using GPL'd work
improperly I have been ready to join a lawsuit that somebody else
initiates. So far people have tended to back down.

			Linus

RE: Linux GPL and binary module exception clause?

[Hua Zhong]

> So far, I don't see any reason why a module that uses an 
> inline function provided via a kernel header could be distributed in
binary 
> format without being a "derived work" and thus bound by the GPL.

Yeah, the same reason that XFS, NUMA, etc are derived works from Unix
since they must include Unix header files.

What, maybe there are no inline functions there? No problem. SCO could
make stuff like spinlocks inline. And suddenly you are derived works
now.

I just don't see how this actually works as you said.

Re: Linux GPL and binary module exception clause?

[Filip Van Raemdonck]

On Fri, Dec 05, 2003 at 09:35:52AM -0800, Hua Zhong wrote:
> > So far, I don't see any reason why a module that uses an 
> > inline function provided via a kernel header could be distributed in
> > binary 
> > format without being a "derived work" and thus bound by the GPL.
> 
> Yeah, the same reason that XFS, NUMA, etc are derived works from Unix
> since they must include Unix header files.

Nope, they #include Linux header files - at least in their Linux version.
Even if one version does #include Unix headers, that does not mean
copyright to the rest of the code automatically belongs to the Unix
copyright holder.

And we're not even talking about source code; we're talking about
_binary modules_. Which do include object code which comes from GPLed
(inline) code; and are thus derived works.


Regards,

Filip

-- 
We have joy, we have fun,
we have Linux on our Sun.

RE: Linux GPL and binary module exception clause?

[Hua Zhong]

> Nope, they #include Linux header files - at least in their 
> Linux version. 

So what? By the same argument they are derived work of Linux too.

This is exactly the flaw of "once you include my code, you are derived
work of mine".

> Even if one version does #include Unix headers, that 
> does not mean copyright to the rest of the code automatically belongs 
> to the Unix copyright holder.

This is not a matter of copyright. This is a matter of "being derived or
not".

> And we're not even talking about source code; we're talking about
> _binary modules_. Which do include object code which comes from GPLed
> (inline) code; and are thus derived works.

I disagree. 

It all depends on how significant the inlined code is compared to the
whole work of the module. For inline functions, I don't see why using
them would be a significant part - by definition "inline" means
"small/trivial", otherwise you would not have inlined them.

Otherwise, since SCO found a few lines of code copied from Unix in Linux
source, are we saying the whole million lines of code is derived from
Unix?

> Regards,
> 
> Filip

Re: Linux GPL and binary module exception clause?

['Filip Van Raemdonck']

On Fri, Dec 05, 2003 at 10:37:51AM -0800, Hua Zhong wrote:
> > Nope, they #include Linux header files - at least in their 
> > Linux version. 
> 
> So what? By the same argument they are derived work of Linux too.
> 
> This is exactly the flaw of "once you include my code, you are derived
> work of mine".

I'll rephrase what I wrote and what people have been saying all the time:

"Once you build a binary module, it contains our (inlined) code and thus
 the binary module is a derived work."

> > And we're not even talking about source code; we're talking about
> > _binary modules_. Which do include object code which comes from GPLed
> > (inline) code; and are thus derived works.
> 
> I disagree. 
> 
> It all depends on how significant the inlined code is compared to the
> whole work of the module. For inline functions, I don't see why using
> them would be a significant part - by definition "inline" means
> "small/trivial", otherwise you would not have inlined them.
> 
> Otherwise, since SCO found a few lines of code copied from Unix in Linux
> source, are we saying the whole million lines of code is derived from
> Unix?

We have yet to see if they actually found code.

And no; we're not saying all code is a derived work. We're saying that if
there is a few lines of copied code, then the compiled kernel which
contains object code coming from these lines is a derived work. If.


Regards,

Filip

-- 
<rcw> debian comes in behind redhat, slackware, suse, and mandrake when
      searching google for 'linux distribution'
<asuffield> try "best linux distribution"

RE: Linux GPL and binary module exception clause?

[Hua Zhong]

> I'll rephrase what I wrote and what people have been saying 
> all the time:
> 
> "Once you build a binary module, it contains our (inlined) 
> code and thus the binary module is a derived work."

Understood and that's what we disagree.

By the way, what's so different between code and data, anyway?

Are inline functions more important than macros and defs?

> > Otherwise, since SCO found a few lines of code copied from 
> Unix in Linux
> > source, are we saying the whole million lines of code is 
> derived from
> > Unix?
> 
> We have yet to see if they actually found code.

We have. Some malloc function as I remember, and has been removed from
current Linux sources.

> And no; we're not saying all code is a derived work. We're 
> saying that if there is a few lines of copied code, then the 
> compiled kernel which contains object code coming from 
> these lines is a derived work. If. 

You are trying to hide the fact that the kernel "sources" actually
contained copyrighted code.

Binary modules do not _contain_ copyrighted (GPL'ed) code, they merely
_include_ it (by #inlucde), but the _compiled_ binary modules contain
compiled copyrighted (GPL'ed) code.

So you are saying, binary modules contain compiled GPL'ed code, so it's
derived work of GPL'ed code. But kernel sources contained copyrighted
(non-GPL'ed) code, but the sources were not derived work of that code,
only the compiled form was?

> Regards,
> 
> Filip

Re: Linux GPL and binary module exception clause?

[Filip Van Raemdonck]

On Fri, Dec 05, 2003 at 12:26:39PM -0800, Hua Zhong wrote:
> > 
> > "Once you build a binary module, it contains our (inlined) 
> > code and thus the binary module is a derived work."
> 
> Understood and that's what we disagree.
> 
> By the way, what's so different between code and data, anyway?

For one, as long as it's code, you are clearly the only copyright holder
and you can more or less do what you want (including distributing).[1]
Once compiled it includes object code to which others have copyright, so
you must take care not to violate their rights.

> > > Otherwise, since SCO found a few lines of code copied from 
> > Unix in Linux
> > > source, are we saying the whole million lines of code is 
> > derived from
> > > Unix?
> > 
> > We have yet to see if they actually found code.
> 
> We have. Some malloc function as I remember, and has been removed from
> current Linux sources.

Which was OK to include as it was released previously under a BSD license.

But, to answer the "million lines of code" question: most of that code was
written before that inclusion. And may not even have had anything to do
with the included lines, afterward. So, no, that does not make all of it
(in code form) a derived work.

There may or may not have been developed code related to these lines
afterwards, for which one might argue that that part of the code is a
derived work. It mostly depends on how badly the later code needs the
included lines - but not much I guess since these lines are not even there
anymore.

> > And no; we're not saying all code is a derived work. We're 
> > saying that if there is a few lines of copied code, then the 
> > compiled kernel which contains object code coming from 
> > these lines is a derived work. If. 
> 
> Binary modules do not _contain_ copyrighted (GPL'ed) code, they merely
> _include_ it (by #inlucde), but the _compiled_ binary modules contain
> compiled copyrighted (GPL'ed) code.
> 
> So you are saying, binary modules contain compiled GPL'ed code, so it's
> derived work of GPL'ed code. But kernel sources contained copyrighted
> (non-GPL'ed) code, but the sources were not derived work of that code,
> only the compiled form was?

Binary modules are by their very nature already compiled, so they already
include the GPLed object code.

And the aggregate kernel sources with the ancient unix code included is
indeed a derived work. But the kernel source, apart from that ancient
unix code and which does not need it, is not.

Neither is the source code for binary modules, as long as it doesn't
actually contain kernel code itself. But once compiled, the rules of the
game are set.


Regards,

Filip

[1] Depending on how the code looks. For example, if it needs to patch
    kernel source code it is modifying GPLed code, and in that case it is
    a derived work even in source code form.

-- 
Hardware, n.:
	The parts of a computer system that can be kicked.

RE: Linux GPL and binary module exception clause?

[David Schwartz]

> On Fri, Dec 05, 2003 at 03:16:27AM -0800, David Schwartz wrote:

> > > The GPL expressly states that the license does not restrict the act of
> > > "running the Program" in any way, and yes, in that sense you
> > > may "use" the
> > > program in whatever way you want.
> >
> > 	Please tell me how you use the Linux kernel source code.
> > Please tell me how
> > you run the Linux kernel source code without creating a derived work.

> You "use" the Linux source code by feeding it to a compiler.  Or maybe
> as a hideous fortune file.  The output of that compiler is *clearly* a
> derived work, and thus bound by the GPL.

	So, if you are permitted to "use" the Linux source code, you are permitted
to create derived works of it. Do we agree on that one simple issue?

> So far, I don't see any reason why a module that uses an inline function
> provided via a kernel header could be distributed in binary
> format without
> being a "derived work" and thus bound by the GPL.

	Because the GPL can only bind a derived work if you had to agree to the GPL
to *make* that derived work. The law (at least in the United States) does
not give a copyright holder a separate right to restrict the distribution of
derived works, only to restrict their creation.

> > 	I download the Linux kernel sources from kernel.org. Please
> > tell me what I
> > can do with them without agreeing to the GPL. Is it your position that I
> > cannot compile them without agreeing to the GPL? If so, how can
> > running the
> > program be unrestricted? How can you run the linux kernel soruce code
> > without compiling it?

> Compile it.

	The only way to compile a header file is to include it into a C file and
use that C file to make a derived work from that header file.

> Run the resulting executable (ignoring the case law that says copying
> into ram is a copy under copyright law)
> Read the source code.
> Write a module using the source code (i.e, via headers)
>
> If you want to distribute that module, you must, of course, follow the
> GPL.

	Only if you needed rights granted under the GPL in order to create it. I
think you're missing my point. My point is that *if* you can create the
derived work without having to agree to the GPL, then you can distribute the
derived work without having to agree to the GPL.

> > 	You run a piece of source code by compiling it. If a header file is
> > protected by the GPL, permission to "run" it means permission
> > to include it
> > in files you compile.

> You don't run source code.  Not even in Perl programs (though there, at
> least, the distinction is more complicated.)
>
> You compile source code.  The resultant object code is then run.

	The way you "run" a program, if that program is in C, is you compile it and
then execute it. If you have the right to "run" a header file (because it
was placed under the GPL), then you have the right to include it in C files
and compile them.

> > 	The phrase "results in a GPL'd program" is one that I
> > cannot understand. I
> > have no idea what you mean by it. You have the right to "run" the header
> > file, the GPL gives it to you. The way you "run" a header file
> > is by first
> > compiling a source code that includes it into an executable.

> Repeat after me: The GPL is a copyright license.  It covers
> distribution, not use.

	Right.

> Distribution of any part of the "work" is
> covered.  Inline functions in headers are clearly part of the "work".

	I'd rather not address two complex issues at once. If we agree that you can
include a header file that is (or is part of) a GPL'd work without to accept
the GPL's terms, we can then go on to address whether you need to accept the
GPL to distribute it. Without the first question understood, it's impossible
to address the second.

> If you have a module that uses an inline function, there are two
> options (note: not two legal options):
> 	Distribute source
> 	Distribute a binary
>
> If you distribute a binary and refuse to provide the source under
> the GPL,
> ask yourself this: What gave you the right to distribute the
> compiled form of the inline functions you use?

	The facts that: Distributing a derived work is not a separate right. I had
the unrestricted right to create the derived work. The recipient of the
derived work is has unrestricted rights to use the original work. The
creation of the derived work is a necessary step in using the original work.

> Note: My use of "inline functions" as a bludgeoning device should not be
> interpreted as an acknowledgement that the rest of the header files
> constitute a published "API".

	Except perhaps under the new DMCA, you can't make it necessary for a person
to violate your copyright in order to use something and then argue that
they've violated your copyright by using that something. This is precisely
equivalent to charging someone who purchased a book with making a copy
without authorization because they bounced a light off the book and produced
a copy on their retina.

	If you have unrestricted right to use a header file, you have unrestricted
right to create derived works consisting of C files that include that header
file and the resulting object code. The question of whether you can
distribute that derived work is a non-issue, there is no right recognized
under copyright (at least in the United States) to restrict the distribution
of derived works, only their creation.

	This will be my final post on this issue. I think I've made my position as
clear as I'm capable of making it. IANAL and have not discussed this with an
attorney. If I had to argue against the GPL in court, this is the line of
argumentation I'd take. Specifically, that you are not bound by the GPL
because everything you've done is use, fair use, and necessary steps for
use, so the GPL's distribution prohibitions don't apply.

	Linus wrote:

>Put another way: nVidia by _law_ has the right to do whatever essential
>step they need to be able to run Linux on their machines. That's what the
>exception to copyright law requires for any piece of software.

	So they need not agree to the GPL to *create* the derived work.

>But what they do NOT have the right to do is to create derivative works of
>the kernel, and distribute them to others.

	Yes, they do. Since they have the right to create the derived work and have
not agreed to the GPL, the only thing that could restrict their distribution
is the law, not the GPL. Please show me the law that permits a copyright
holder to restrict the distribution of derived works.

>That act of distribution is not
>essential _for_them_ to utilize the kernel program (while the act of
>_receiving_ the module and using it may be - so the recipient may well be
>in the clear).

	While he is correct that the distribution itself is not essential for use,
the creation of the derivative work is. However, once a derivative work is
created, no special rights to the *original* work are required to distribute
it to licensees of that original work.

	DS

RE: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Fri, 5 Dec 2003, David Schwartz wrote:
>
> >But what they do NOT have the right to do is to create derivative works of
> >the kernel, and distribute them to others.
>
> 	Yes, they do. Since they have the right to create the derived work and have
> not agreed to the GPL, the only thing that could restrict their distribution
> is the law, not the GPL. Please show me the law that permits a copyright
> holder to restrict the distribution of derived works.

I'm not going to argue with you any more. I am not a lawyer, and clearly
you aren't one either (or you're a really really bad one).

The "show me the law" is USC 17. It's called "US Copyright Law". As a
copyright holder in the Linux kernel, I _do_ have the right to restrict
the distribution of derived works. That's what copyright law is all about.

Your arguments are just vacuous and stupid.

I _very_ much have the right to restrict the distribution of derived
works, and that is what a license is all about. Without a license to
distribute, you have NO RIGHT AT ALL to distribute a derived work. What's
so hard to understand about that? And the only rights you have are rights
granted to you in some license.

And that license in this case is the GPL. Which does NOT grant you rights
to redistribute derived works without the source being available under the
same license.

End of discussion. You can whine all you like, but whining has never
changed reality.

		Linus

Re: Linux GPL and binary module exception clause?

[Shawn Willden]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 December 2003 01:14 pm, Linus Torvalds wrote:
> On Fri, 5 Dec 2003, David Schwartz wrote:
> > Please show me the law
> > that permits a copyright holder to restrict the distribution of
> > derived works.
> 
> The "show me the law" is USC 17. It's called "US Copyright Law". As a
> copyright holder in the Linux kernel, I _do_ have the right to restrict
> the distribution of derived works. That's what copyright law is all
> about.

Actually, based on my understanding of Title 17 and the GPL (both of which 
I just re-read), David *almost* has a point.

1.  As David implies, Title 17 does not grant the copyright holder the 
right to restrict distribution of derived works.  Section 106[1] describes 
the exclusive rights granted to copyright holders, and it only says that 
they have exclusive rights to *prepare* derived works.  So you cannot 
create a derived work without permission from the copyright holder, but 
once you have obtained permission to create it, you can distribute the 
result.  Maybe.

2.  The copyright holder can grant permission to create derived works to 
whomever (s)he likes, under whatever terms (s)he likes (modulo other 
laws).  So, the copyright holder can attach strings to the permission.  
For example, the copyright holder could specify that you are allowed to 
create a derived work, but only on the condition that you do not 
distribute it.

3.  The GPL understands points 1 and 2, which is why section 2 of the GPL 
states:

	You may modify your copy or copies of the Program or any
	portion of it, thus forming a work based on the Program,
	and copy and distribute such modifications or work under
	the terms of Section 1 above, provided that you also meet
	all of these conditions:

It then lists three conditions, the most important of which is the second, 
which states that if the derived work is distributed, it must be 
distributed under the terms of the GPL.

IANAL, but the language in Title 17 and the GPL seems pretty clear.  If 
someone creates a derived work and distributes it under any terms other 
than the GPL, they have violated the agreement which gave them permission 
to create the derived work, and thereby infringed on the copyright 
holder's exclusive rights.

So, yeah, you *do* have the right to restrict distribution of derived 
works, via a thunk in the GPL.

Oh, IANAL.

	Shawn.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0PWip1Ep1JptinARAjhXAJ9x66s2KNm8KK4+9bNDBKOQ6Hd6YQCghXFD
Ju6LimWjD6NJJqsG4u7Jr7g=
=vop3
-----END PGP SIGNATURE-----

Kernel 2.6-test10 on an Opteron

[Ananda Bhattacharya]

Hello!

	I was wondering if anyone has had any luck with 2.6 
on a Dual Opteron system. I have a Broadcom 5702 ethernet 
card, and the network starts up but it seems slugish. Lilke 
yobind and and nfs don't start up properly. They fail on 
startup and I have to run the init scripts by hand. I am 
also running a crazy Redhat Enterprise Server Beta release. Also 
I was wondering if anyone has an idea what a good distro 
for x86-64 bit architectures is?
	
thanks 
	-Anand


-- 
What is "walmart'?
Do they sell walls there or what?
-Paris Hilton

Re: Kernel 2.6-test10 on an Opteron

[Petr Sebor]

Ananda Bhattacharya wrote:
> Hello!
> 
> 	I was wondering if anyone has had any luck with 2.6 
> on a Dual Opteron system. I have a Broadcom 5702 ethernet 
> card, and the network starts up but it seems slugish. 

Hi,

I am playing with UP opteron system (2.6.0-t11) and have noticed the 
network slowness as well..

I am able to achieve max 8MBps on 100MBps network with the
Broadcom 5705...

00:0b.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705 
Gigabit Ethernet (rev 03)
         Subsystem: Micro-Star International Co., Ltd.: Unknown device 1300
         Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 16
         Memory at fa000000 (64-bit, non-prefetchable) [size=64K]

the board is MSI K8T - VIA KT800 chipset

with the 8MBps transferrate, the ftp daemon eats almost all of the
time and vmstat says that most of the time is spent inside of the 
kernel. (I am getting ~5MBps with rsync and SSH, so it is probably not
because of the proftpd)

on the sending side, the send-queue is 105168 (probably full) and on the 
receiving side the receive-queue (Recv-Q) has 65896 waiting packets.

dmesg reports:
tg3.c:v2.3 (November 5, 2003)
eth0: Tigon3 [partno(BCM95705A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 
10/100/1000BaseT Ethernet 00:0c:76:6a:b8:a7
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.

[vmstat report while proftpd running]
petr@opteron:~/music$ vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- --system-- 
----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us 
sy id wa
  1  0      0   4644  21988 802820    0    0     0  8192 2647    89  1 
99  0  0
  1  0      0   4132  22240 803060    0    0     0  8688 2674   122  0 
99  0  1
  1  0      0   4196  22244 803008    0    0     0  8192 2605   121  1 
95  4  0
  0  0      0   4760  22104 802588    0    0     0  8192 2727   388  1 
94  5  0
  1  0      0   4568  22112 802804    0    0     0     0 2808   651  1 
91  8  0
  1  0      0   5176  22096 802060    0    0     0 12288 2623    87  0 
100  0  0
  1  0      0   5048  22252 802040    0    0     0  8512 2663   119  1 
97  2  0
  1  0      0   4848  22264 802220    0    0     8  8192 2655   104  0 
99  1  0
  1  0      0   4848  22164 802484    0    0     0  8192 2628    77  1 
97  2  0
  1  0      0   4592  22108 802796    0    0     0  8192 2628    56  0 
98  2  0
  1  0      0   4368  22100 803012    0    0     0  8192 2648    81  1 
98  1  0

oops, sorry for the wrapped text ..

Regards,
Petr

Re: Kernel 2.6-test10 on an Opteron

[bill davidsen]

In article <Pine.LNX.4.44.0312081857200.537-100000@puma.cabm.rutgers.edu>,
Ananda Bhattacharya  <anandab@cabm.rutgers.edu> wrote:

| 	I was wondering if anyone has had any luck with 2.6 
| on a Dual Opteron system. I have a Broadcom 5702 ethernet 
| card, and the network starts up but it seems slugish. Lilke 
| yobind and and nfs don't start up properly. They fail on 
| startup and I have to run the init scripts by hand. I am 
| also running a crazy Redhat Enterprise Server Beta release. Also 
| I was wondering if anyone has an idea what a good distro 
| for x86-64 bit architectures is?

Is there a status page for that? I see that Tyan is going to (probably)
release a four-way board in the near future (post in comp.sys.intel
links to pictures, etc) and I deserve a new toy for my birthday in the
spring, so this is not idle curiousity. When I see the prices it may be,
but the SMP CPUs are affordable.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Linux GPL and binary module exception clause?

[Jesse Pollard]

On Friday 05 December 2003 13:55, David Schwartz wrote:
> 	Linus wrote:
> >Put another way: nVidia by _law_ has the right to do whatever essential
> >step they need to be able to run Linux on their machines. That's what the
> >exception to copyright law requires for any piece of software.
>
> 	So they need not agree to the GPL to *create* the derived work.
>
> >But what they do NOT have the right to do is to create derivative works of
> >the kernel, and distribute them to others.
>
> 	Yes, they do. Since they have the right to create the derived work and
> have not agreed to the GPL, the only thing that could restrict their
> distribution is the law, not the GPL. Please show me the law that permits a
> copyright holder to restrict the distribution of derived works.

Uhhh nope. You are forgetting the case of the estate of Jacquiline Susanne 
(SP?). There was a developer that created an expert system capable of 
generating stories/novels in the "style of".

The estate claimed copyright infringement, and won. The generated text was 
obviously "derived from", and the developer claimed that just because it
looked like and sounded like, that it was independant and could not infringe.
He lost.

There was no problem with him generating stories for himself, but as soon
as he started distributing what was generated... Deep do-do. If I remember
right, he couldn't even release the program.

Re: Linux GPL and binary module exception clause?

[Jesse Pollard]

On Friday 05 December 2003 05:16, David Schwartz wrote:
> > On Thu, 4 Dec 2003, David Schwartz wrote:
> > > The GPL gives you the unrestricted right to *use* the original work.
> > > This implicitly includes the right to peform any step necessary to use
> > > the work.
> >
> > No it doesn't.
> >
> > Your logic is fundamentally flawed, and/or your reading skills are
> > deficient.
>
> 	I stand by my conclusions.
>
> > The GPL expressly states that the license does not restrict the act of
> > "running the Program" in any way, and yes, in that sense you may "use"
> > the program in whatever way you want.
>
> 	Please tell me how you use the Linux kernel source code. Please tell me
> how you run the Linux kernel source code without creating a derived work.

You compile it without modifications.

> > But that "use" is clearly limited to running the resultant program. It
> > very much does NOT say that you can "use the header files in any way you
> > want, including building non-GPL'd programs with them".
>
> 	Huh? What "resultant program"? Are you talking about an executable that's
> a derived work of the Linux kernel source code?

You don't have "an executable" unless it includes the kernel as the 
executable.

It actually sounds like you are confusing Kernel mode with User mode.

> 	Modules are derived works of the Linux kernel source code, not the kernel
> executable. So the license that would be relevent would be a license that
> restricts how you can use the source code or derived works of the source
> code. License to run a program, when you have source code, is license to
> compile that source code.
>
> 	For example, 2b says:
>
>     b) You must cause any work that you distribute or publish, that in
>     whole or in part contains or is derived from the Program or any
>     part thereof, to be licensed as a whole at no charge to all third
>     parties under the terms of this License.
>
> 	You don't seriously think that's talking about derived works that are
> derived from *executables*, do you?

It is if you are referring to the Kernel. Look at the include files. They are
licened under GPL.

Look at the include files for applications. They are licenced under LGPL.

The kernel include files are NOT.

> > In fact, it very much says the reverse. If you use the source code to
> > build a new program, the GPL _explicitly_ says that that new program has
> > to be GPL'd too.
>
> 	I download the Linux kernel sources from kernel.org. Please tell me what I
> can do with them without agreeing to the GPL. Is it your position that I
> cannot compile them without agreeing to the GPL? If so, how can running the
> program be unrestricted? How can you run the linux kernel soruce code
> without compiling it?

compile them. Read them. run them.

You do not modify them. You do not combine them with propriatary executables 
and distribute them without that executable and it's source becoming GPL.

> > > Please tell me how you use a kernel header file, other than by
> > > including it in a code file, compiling that code file, and executing
> > > the result.
> >
> > You are a weasel, and you are trying to make the world look the way you
> > want it to, rather than the way it _is_.
>
> 	That is a serious example of projection.
>
> > You use the word "use" in a sense that is not compatible with the GPL.
> > You claim that the GPL says that you can "use the program any way you
> > want", but that is simply not accurate or even _close_ to accurate. Go
> > back and read the GPL again. It says:
> >
> > 	"The act of running the Program is not restricted"
> >
> > and it very much does NOT say
> >
> > 	"The act of using parts of the source code of the Program is not
> > 	 restricted"
>
> 	You run a piece of source code by compiling it. If a header file is
> protected by the GPL, permission to "run" it means permission to include it
> in files you compile.
>
> 	The GPL says:
>
>   0. This License applies to any program or other work which contains
> a notice placed by the copyright holder saying it may be distributed
> under the terms of this General Public License.  The "Program", below,
> refers to any such program or work, and a "work based on the Program"
> means either the Program or any derivative work under copyright law:
> that is to say, a work containing the Program or a portion of it,
>
> 	The work that was placed under the GPL is the Linux kernel source. The
> "program" is the source code. Please, tell me how you "run" the Linux
> kernel source code other than by compiling it to form a derived work.
>
> 	Perhaps you misunderstand the GPL to mean that a 'program' must be an
> executable? Not only does section zero clearly refute that, but if it were
> true, it would mean that a module is not a derived work from a GPL'd work!
> It is a program that's placed under the GPL, and a module is not a derived
> work from any other executable.
>
> > In short: you do _NOT_ have the right to use a kernel header file (or any
> > other part of the kernel sources), unless that use results in a GPL'd
> > program.
>
> 	The phrase "results in a GPL'd program" is one that I cannot understand. I
> have no idea what you mean by it. You have the right to "run" the header
> file, the GPL gives it to you. The way you "run" a header file is by first
> compiling a source code that includes it into an executable.

Quite simple. If you include the Linux kernel include files you get a derived
program that must be released under GPL if you distribute that program.

> > What you _do_ have the right is to _run_ the kernel any way you please
> > (this is the part you would like to redefine as "use the source code",
> > but that definition simply isn't allowed by the license, however much you
> > protest to the contrary).
>
> 	How can I run the kernel without compiling it? And how can I compile it
> without creating a derived work? The GPL says:
>
>   5. You are not required to accept this License, since you have not
> signed it.  However, nothing else grants you permission to modify or
> distribute the Program or its derivative works.  These actions are
> prohibited by law if you do not accept this License.  Therefore, by
> modifying or distributing the Program (or any work based on the
> Program), you indicate your acceptance of this License to do so, and
> all its terms and conditions for copying, distributing or modifying
> the Program or works based on it.
>
> 	Of course, the second sentence is utterly false. Fair use and necessary
> step provisions do just that.

It is not fair use to create and distribute derived works that use Kernel 
include files without agreeing to the GPL.

> > So you can run the kernel and create non-GPL'd programs while running it
> > to your hearts content. You can use it to control a nuclear submarine,
> > and that's totally outside the scope of the license (but if you do,
> > please note that the license does not imply any kind of warranty or
> > similar).
> >
> > BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.
> >
> > Comprende?
>
> 	I have no idea what you mean by a "NON-GPL'D BINARY". *Any* binary you
> create from a kernel header file is, at least to some extent, a derived
> work of that header file. However, the question for whether it would be
> covered by the GPL is whether you exercised a privilege in creating that
> work that you were only granted by the GPL.

Nope. You are confusing GPL with LGPL. Not the same thing.

> 	Again, what I'm trying to say is that the term "program" in the GPL means
> whatever it is that's placed under the GPL (which can be an executable
> and/or source code). Of course, placing an executable under the GPL
> effectively places its source code under the GPL (as soon as you distribute
> it to someone else, as you are required to do, who is limited only by the
> GPL).
>
> 	In the case of the Linux kernel, the source code was initially placed
> under the GPL. Once source code is placed under the GPL, your right to "run
> the program" means a right to compile the source code. In the case of
> header files, this means the right to include the header file in code files
> and thereby produce and use derived works. (Whether or not you can
> distribute those derived works is, of course, a whole different argument.)
>
> 	So my point is that the GPL isn't really even relevant here. You have all
> the rights you need without agreeing to it. "Activities other than copying,
> distribution and modification are not
> covered by this License; they are outside its scope." Including a header
> file in your own class file is not copying, distribution, or modification
> of that header file. It is use, mere use.

Depends on where that class file ends up. If it is in a binary, that you 
intend to distribute, then that binary, and its source is GPL.

Check the headers. If it says GPL, then anything compiled that uses that
header should be GPL when/if distributed.

Re: Linux GPL and binary module exception clause?

[Kendall Bennett]

Jesse Pollard <jesse@cats-chateau.net> wrote:

> It is if you are referring to the Kernel. Look at the include
> files. They are licened under GPL. 
> 
> Look at the include files for applications. They are licenced
> under LGPL. 

Really? Have you looked at the include files for Linux? The standard C 
include files that nearly every program uses will end up also *including* 
Linux kernel header files in order to build programs for Linux. Not all 
programs will end up including those files, but a very large portion 
will.

If you don't believe me, do a grep under /usr/include/sys on your machine 
for 'linux', and see how many of the header files include stuff from 
/usr/include/linux. All the files under /usr/include/linux are part of 
the kernel, so theoretically under the pure GPL, not LGPL.

Then again I say 'theoretically' because once again there is nary a 
kernel header file in sight that actually *has* a GPL license header 
attached! So who knows what license those files are *really* under.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

RE: Linux GPL and binary module exception clause?

[Kendall Bennett]

Linus Torvalds <torvalds@osdl.org> wrote:

> So you can run the kernel and create non-GPL'd programs while running it
> to your hearts content. You can use it to control a nuclear submarine, and
> that's totally outside the scope of the license (but if you do, please
> note that the license does not imply any kind of warranty or similar).
> 
> BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.
> 
> Comprende?

Right, and by extension of the same argument you cannot use kernel 
headers to create non-GPL'ed binaries that run IN USER SPACE! Just 
because a program runs in user space does not mean that it is not a 
dervived work. There is nothing special about a user mode program 
compared to a module just because it uses Linux system calls. The same 
principles you apply to determine whether a module is a derived work also 
apply to user space programs, *ESPECIALLY* if you consider that the GPL 
kernel header files contains code (inline C or assembler) that probably 
gets linked either directly or indirectly (through the C runtime library) 
into *EVERY* Linux user mode program. 

This exact reasoning is what RedHat (aka Cygnus) has been using for years 
with the Cygwin toolkit for Windows. Although 99% of the code built with 
the GNU compilers and Cygwin includes the glibc runtime library that is 
LGPL, every program *must* include the C runtime library startup code or 
it cannot function. *That* code is pure GPL, and by extension any program 
using the Cygwin libraries is a derived work and must be GPL. If you 
don't like that, by a commercially licensed version of Cygwin from 
RedHat/Cygnus instead.

This is also IMHO why so few people outside of Red Hat contribute to 
Cygwin, but that is a different issue ;-)

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: Linux GPL and binary module exception clause?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Fri, 05 Dec 2003 10:44:02 PST, Kendall Bennett said:

> Right, and by extension of the same argument you cannot use kernel 
> headers to create non-GPL'ed binaries that run IN USER SPACE! Just 
> because a program runs in user space does not mean that it is not a 
> dervived work. 

That's a bad idea for technical reasons too - how often do we have to tell
people not to use kernel headers from userspace?  glibc-kernheaders (and whatever
non-RedHat boxes call it) exists for a reason.

Interestingly enough, at least on my Fedora box, 'rpm -qi' reports glibc as LGPL,
but glibc-kernheaders as GPL, which seems right to me - linking against glibc gives
the LGPL semantics as we'd want, but forces userspace that's poking in the kernel
to be GPL as a derived work....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Linux GPL and binary module exception clause?

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Fri, 2003-12-05 at 20:09, Valdis.Kletnieks@vt.edu wrote:
\
> Interestingly enough, at least on my Fedora box, 'rpm -qi' reports glibc as LGPL,
> but glibc-kernheaders as GPL, which seems right to me - linking against glibc gives
> the LGPL semantics as we'd want, but forces userspace that's poking in the kernel
> to be GPL as a derived work....

but those headers do not have inlines etc etc 
just the bare minimum of structures and defines (neither of which result
in code in the binary )

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

So why not do the removal of the inlines to real .c files and quit playing
games with bogus attempts to bleed taint into the inprotectable api?

Clearly it is a game of bait and switch.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Fri, 5 Dec 2003, Arjan van de Ven wrote:

> On Fri, 2003-12-05 at 20:09, Valdis.Kletnieks@vt.edu wrote:
> \
> > Interestingly enough, at least on my Fedora box, 'rpm -qi' reports glibc as LGPL,
> > but glibc-kernheaders as GPL, which seems right to me - linking against glibc gives
> > the LGPL semantics as we'd want, but forces userspace that's poking in the kernel
> > to be GPL as a derived work....
> 
> but those headers do not have inlines etc etc 
> just the bare minimum of structures and defines (neither of which result
> in code in the binary )
> 

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Andre Hedrick wrote:
>
> So why not do the removal of the inlines to real .c files and quit playing
> games with bogus attempts to bleed taint into the inprotectable api?

The inlines have nothing to do with _anything_.

Trust me, a federal judge couldn't care less about some very esoteric
technical detail. I don't know who brought up inline functions, but they
aren't what would force the GPL.

What has meaning for "derived work" is whether it stands on its own or
not, and how tightly integrated it is. If something works with just one
particular version of the kernel - or depends on things like whether the
kernel was compiled with certain options etc - then it pretty clearly is
very tightly integrated.

Don't think that copyright would depend on any technicalities.

		Linus

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Wed, Dec 10, 2003 at 07:18:12AM -0800, Linus Torvalds wrote:
> Trust me, a federal judge couldn't care less about some very esoteric
> technical detail. I don't know who brought up inline functions, but they
> aren't what would force the GPL.

They've certainly been brought up here over and over as an example of
included work that forces the GPL.

> What has meaning for "derived work" is whether it stands on its own or
> not, and how tightly integrated it is. If something works with just one
> particular version of the kernel - or depends on things like whether the
> kernel was compiled with certain options etc - then it pretty clearly is
> very tightly integrated.

So what?  Plugins have a nasty tendency to have to be updated when the
main program is updated.  That doesn't mean that the Netscape license
is allowed to control the flash plugin license.  I think (and very
much hope) that your idea of a derived work is flawed.  Otherwise you
are helping make case law that is going to screw a lot people of over.
If you think Microsoft won't use your expanded definition of what is a
derived work, think again.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Larry McVoy wrote:
>
> > kernel was compiled with certain options etc - then it pretty clearly is
> > very tightly integrated.
>
> So what?  Plugins have a nasty tendency to have to be updated when the
> main program is updated.

Sorry, but again, I repeat: technicalities don't actually matter much to a
judge.

There's a fundamental difference between "plugins" and "kernel modules":
intent.

If you write a program that tries to have a stable API to outside modules,
and you make and document a plugin interface that is documented to accept
proprietary modules, then that is an ABI. And linking against such a thing
is fine.

But when you have the GPL, and you have documented for years and years
that it is NOT a stable API, and that it is NOT a boundary for the license
and that you do NOT get an automatic waiver when you compile against this
boundary, then things are different.

And they are different even if from a _technical_ standpoint you do
exactly the same: you dynamically link against a binary.

Ask a lawyer. Really.

I know people on this list are engineers and programmers, and you think
that technology is all that matters, and that if you link in one situation
and do exactly the same motions ("walk around the computer three times
widdershins, and give the -dynamic option to 'ld'") then you are doing the
same thing.

But that's not how "the real world" works. In the real world, intent and
permission matter a whole lot. When you make love to your wife in the
privacy of your own home, the "real world" is perfectly ok with that. When
you do the same thing to somebody you didn't get permission from, it's a
major crime and you can be put into prison for decades - even though
technically the movements are pretty much the same.

See? Intent matters. How you do something _technically_ does not.

In fact, I will bet you that if the judge thinks that you tried to use
technicalities ("your honour, I didn't actually run the 'ln' program,
instead of wrote a shell script for the _user_ to run the 'ln' program for
me"), that judge will just see that as admission of the fact that you
_knew_ you were doing something bad. Which means that now it wasn't just
unintentional copyright infringement, now it is clearly wilful.

So those technicalities you might use to try to make things better
actually can make them WORSE.

The best you can do is to just ask for permission. Maybe you'll get it.

			Linus

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Wed, Dec 10, 2003 at 08:21:52AM -0800, Linus Torvalds wrote:
> There's a fundamental difference between "plugins" and "kernel modules":
> intent.

Which is?  How is it that you can spend a page of text saying a judge doesn't
care about technicalities and then base the rest of your argument on the
distinction between a "plugin" and a "kernel module"?

    "Yes, your honor, I know you don't care about technicalities but let
    me explain how a kernel model, which is a wad of code that may be
    plugged into a program called the kernel and which provides some
    additional functionality or feature, is legally different than a
    plugin, which is a wad of code that may be plugged into some other
    program not called the kernel and which provides some additional
    functionality or feature.  These are not all the same things, your
    honor, you see that, right?"

Gimme a break, Linus.  You can't have it both ways.

> But when you have the GPL, and you have documented for years and years
> that it is NOT a stable API, and that it is NOT a boundary for the license
> and that you do NOT get an automatic waiver when you compile against this
> boundary, then things are different.

You need to reread your own postings on the topic over the years.  There are
documents all the web citing you as saying that binary drivers and modules 
are fine.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Larry McVoy wrote:
>
> Which is?  How is it that you can spend a page of text saying a judge doesn't
> care about technicalities and then base the rest of your argument on the
> distinction between a "plugin" and a "kernel module"?

I'll stop arguing, since you obviously do not get it.

I explained the technicalities to _you_, and you are a technical person.

But if you want to explain something to a judge, you get a real lawyer,
and you make sure that the lawyer tries to explain the issue in _non_
technical terms. Because, quite frankly, the judge is not going to buy a
technical discussion he or she doesn't understand.

Just as an example, how do you explain to a judge how much code the Linux
kernel contains? Do you say "it's 6 million lines of C code and header
files and documentation, for a total of about 175MB of data"?

Yeah, maybe you'd _mention_ that, but to actually _illustrate_ the point
you'd say that if you printed it out, it would be a solid stack of papers
100 feet high.  And you'd compare it to the height of the court building
you're in, or something. Maybe you'd print out _one_ file, bind it as a
book, and wave it around as one out of 15,000 files.

But when _you_ ask me about how big the kernel is, I'd say "5 million
lines". See the difference? It would be silly for me to tell you how many
feet of paper the kernel would print out to, because we don't have those
kinds of associations.

Similarly, if you want to explain the notion of a kernel module, you'd
compare it to maybe an extra chapter in a book. You'd make an analogy to
something that never _ever_ mentions "linking".

Just imagine: distributing a compiled binary-only kernel module that can
be loaded into the kernel is not like distributing a new book: it's more
like distributing a extra chapter to a book that somebody else wrote, that
uses all the same characters and the plot, but more importantly it
literally can only be read _together_ with the original work. It doesn't
stand alone.

In short, your honour, this extra chapter without any meaning on its own
is a derived work of the book.

In contrast, maybe you can re-write your code and distribute it as a
short-story, which can be run on its own, and maybe the author has been
influenced by another book, but the short-story could be bound AS IS, and
a recipient would find it useful even without that other book. In that
case, the short story is not a derived work - it's only inspired.

Notice? This is actually _exactly_ what I've been arguing all along,
except I've been arguing with a technical audience, so I've been using
technical examples and terminology. But my argument is that just the fact
that somebody compiled the code for Linux into a binary module that is
useless without a particular version of the kernel DOES MAKE IT A DERIVED
WORK.

But also note how it's only the BINARY MODULE that is a derived work. Your
source code is _not_ necessarily a derived work, and if you compile it for
another operating system, I'd clearly not complain.

This is the "stand-alone short story" vs "extra chapter without meaning
outside the book" argument. See? One is a work in its own right, the other
isn't.

			Linus

Re: Linux GPL and binary module exception clause?

[Chris Friesen]

Linus Torvalds wrote:

> But also note how it's only the BINARY MODULE that is a derived work. Your
> source code is _not_ necessarily a derived work, and if you compile it for
> another operating system, I'd clearly not complain.
> 
> This is the "stand-alone short story" vs "extra chapter without meaning
> outside the book" argument. See? One is a work in its own right, the other
> isn't.

We currently have a situation where an external company supplies us with 
a device driver containing a binary blob that was explicitly written as 
OS-agnostic, and a shim that is gpl'd (at least the linux shim is) to 
get the appropriate os-specific services.  I guess this would fall under 
the "not made just for linux" category in which you've placed the Nvidia 
driver?

Carrying on your analogy, this could be a generic love scene, with 
blanks in which to insert the character's names and location.

Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Chris Friesen wrote:
>
> Linus Torvalds wrote:
>
> > But also note how it's only the BINARY MODULE that is a derived work. Your
> > source code is _not_ necessarily a derived work, and if you compile it for
> > another operating system, I'd clearly not complain.
> >
> > This is the "stand-alone short story" vs "extra chapter without meaning
> > outside the book" argument. See? One is a work in its own right, the other
> > isn't.
>
> We currently have a situation where an external company supplies us with
> a device driver containing a binary blob that was explicitly written as
> OS-agnostic, and a shim that is gpl'd (at least the linux shim is) to
> get the appropriate os-specific services.  I guess this would fall under
> the "not made just for linux" category in which you've placed the Nvidia
> driver?
>
> Carrying on your analogy, this could be a generic love scene, with
> blanks in which to insert the character's names and location.

Yes. Depending on how it is done (ie is the support for other operating
systems really a major thing that you really care about, and not intended
just as a smoke-screen), I personally believe that this is likely a valid
way to show that some part of the code (the binary blob) is not a derived
work. Clearly it no longer depends on the kernel, and you can show that to
be true by the obvious argument.

And I think this argument is _especially_ strong for things like firmware
etc, and I've been on record as saying that I think it's ok to upload
standard firmware for a driver as long as you don't call it directly (ie
it really lives on the hardware itself).

(At this point I should probably point out that other people disagree, and
there are people who feel strongly that the kernel cannot contain binary
firmware. Whish is obviously part of the reason for having the firmware
loader interfaces for drivers - adding an extra layer of separation).

However, even that doesn't necessarily make the issue 100% clear. It
clarifies the status of the binary blob itself - but arguably the _other_
part of the story (eg the shim layer) is not a whole work, and it could be
argued that that part in itself violates the GPL.

At that point I just say "I'm personally a reasonable person, and quite
frankly, personally the _last_ thing I'd want to do is to complain in a
court of law".

Quite frankly, you'd have to really really try to actively irritate me
with some flagrant crap for me to decide that it's time to try to enforce
anything. But I'm only speaking for myself here, and there are other
copyright holders that might be more trigger-happy.

So while I may be arguing vehemently here against binary-only modules,
please realize that I haven't sued anybody over them, and in fact I'm a
big believer in trying to make sure everybody is pretty happy adn not make
a big deal out of things.

Sometimes that "everybody is happy" means that I literally tell people
that they might want to use a *BSD kernel instead of Linux, if I don't see
them being able to make themselves _and_ the GPL people happy otherwise.

		Linus

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Wed, Dec 10, 2003 at 09:10:18AM -0800, Linus Torvalds wrote:
> On Wed, 10 Dec 2003, Larry McVoy wrote:
> > Which is?  How is it that you can spend a page of text saying a judge doesn't
> > care about technicalities and then base the rest of your argument on the
> > distinction between a "plugin" and a "kernel module"?
> 
> I'll stop arguing, since you obviously do not get it.

Err, I think people might say you are punting.  You claim that there is a
difference between a plugin and a kernel module, I ask what, you say 
"I'll stop arguing because you don't get it".  Hmm.  

> But if you want to explain something to a judge, you get a real lawyer,
> and you make sure that the lawyer tries to explain the issue in _non_
> technical terms. Because, quite frankly, the judge is not going to buy a
> technical discussion he or she doesn't understand.

Exactly.  I agree.  And the lawyer is going to make mincemeat of your
argument that there is a difference between a flash plugin and a driver.

> In short, your honour, this extra chapter without any meaning on its own
> is a derived work of the book.

I see.  And your argument, had it prevailed 5 years ago, would have
invalidated the following, would it not?  The following from one of the
Microsoft lawsuits.

>From http://ecfp.cadc.uscourts.gov/MS-Docs/1636/0.pdf

    Substituting an alternative module for one supplied by Microsoft
    may not violate copyright law, and certainly not because of any
    "integrity of the work" argument. The United States recognizes "moral
    rights" of attribution and integrity only for works of visual art
    in limited editions of 200 or fewer copies. (See 17 U.S.C. 106A
    and the definition of "work of visual art" in 17 U.S.C. 101.) A
    bookstore can replace the last chapter of a mystery novel without
    infringing its copyright, as long as they are not reprinting the
    other chapters but are simply removing the last chapter and replacing
    it with an alternative one, but must not pass the book off as the
    original. Having a copyright in a work does not give that copyright
    owner unlimited freedom in the terms he can impose.

Start to see why I think what you are doing is dangerous and will backfire?

Note that the GPL does allow "reprinting" (that's section 1).  So any
"alternative" stuff can be added *and* distributed *together* with the
original stuff.  And, of course, the "alternative" added stuff doesn't
need to be under the GPL as long as the added stuff is NOT a derivative
work of the GPL'd thing (read: was prepared without copying any protected
elements from the GPL'd thing [clean room] or simply doesn't contain
them at all being a completely different [new] functional part of "a
whole" work).

>From http://www-106.ibm.com/developerworks/opensource/library/os-cplfaq.html

    Q: If I write a module to add to a Program licensed under the CPL
    and distribute the object code of the module along with the rest of
    the Program, must I make the source code to my module available in
    accordance with the terms of the CPL?

    A: No, as long as the module is not a derivative work of the Program.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Larry McVoy wrote:
>
> I see.  And your argument, had it prevailed 5 years ago, would have
> invalidated the following, would it not?  The following from one of the
> Microsoft lawsuits.

No it wouldn't.

Microsoft very much _has_ a binary API to their drivers, in a way that
Linux doesn't.

MS has to have that binary API exactly because they live in a binary-only
world. They've basically put that requirement on themselves by having
binary-only distributions.

So your argument doesn't fly. To Microsoft, a "driver" is just another
external entity, with documented API's, and they indeed ship their _own_
drivers that way too. And all third-party drivers do the same thing.

So there is no analogy to the Linux case. In Linux, no fixed binary API
exists, and the way normal drivers are distributed are as GPL'd source
code.

			Linus

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Wed, Dec 10, 2003 at 10:02:47AM -0800, Linus Torvalds wrote:
> 
> On Wed, 10 Dec 2003, Larry McVoy wrote:
> >
> > I see.  And your argument, had it prevailed 5 years ago, would have
> > invalidated the following, would it not?  The following from one of the
> > Microsoft lawsuits.
> 
> No it wouldn't.

And in the 4 minutes since I've posted that legal doc you have consulted
a lawyer and the lawyer told you this, right?

> Microsoft very much _has_ a binary API to their drivers, in a way that
> Linux doesn't.

Technicality.  Which, by your own reasoning, doesn't count.  Linux does
indeed have a binary interface, many people download drivers from some
website (I've done it a pile of times) and stuck them in and they worked.
I did that with the modem on my thinkpad across more than 10 kernel
versions in the 2.2 or 2.4 timeframe.

> So there is no analogy to the Linux case. In Linux, no fixed binary API
> exists, and the way normal drivers are distributed are as GPL'd source
> code.

Nonsense.  More distribution happens through ISO images than anything else
and the ISO images people download don't contain the source.  They *could*
download the source ones but they don't.  They download the binary image,
burn it, and install it.  And pass it around.  

If the *only* way you could get Linux was in source form and you had to 
build your own kernel, then you'd have an argument.  But that's not true
and there are plenty of examples of drivers being available for download
for Linux in binary form.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Larry McVoy wrote:
>
> And in the 4 minutes since I've posted that legal doc you have consulted
> a lawyer and the lawyer told you this, right?

Hey, you know I'm not a lawyer.

I told you my opinion. And I'm not considering even _trying_ to circumvent
somebody elses copyright.

You are the one who needs a lawyer, since _you_ are the one arguing for
potentially infringing on other peoples copyright.

			Linus

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Wed, Dec 10, 2003 at 10:17:34AM -0800, Linus Torvalds wrote:
> > And in the 4 minutes since I've posted that legal doc you have consulted
> > a lawyer and the lawyer told you this, right?
> 
> Hey, you know I'm not a lawyer.
> 
> I told you my opinion. And I'm not considering even _trying_ to circumvent
> somebody elses copyright.
> 
> You are the one who needs a lawyer, since _you_ are the one arguing for
> potentially infringing on other peoples copyright.

I can understand your touchiness, it's not much fun living through tons of
messages where people try and figure out how to circumvent your license.
You have my sympathy.

On the other hand, let's be perfectly clear: I'm not in the business of
making binary kernel extensions/modules/drivers/anything, I never have
been in that business, and neither I nor anyone at BitMover nor any of
our investors are contemplating that.  In other words, _I_ am not about
to violate anyone's copyright and I'll thank you not to accuse me of
that again without some data to back it up.

What I am doing is saying that you are way over the line in a way that
other people, who do not have your best interests at heart (nor the
kernel's, nor the FSF's, nor the GPL's), are going to jump all over what
you are saying and use it against you.  In multiple ways.  They will use
it to say that you are just as bad as they are, you are trying to twist
the system to your advantage to further your agenda.  Which is exactly,
I might add, what any corporation does.  You've become quite corporate
(aka one-sided) in your outlook recently.  If case law is established
that backs up your point of view, it is going to effect all of us in all
sorts of ways that are almost universally negative for everyone except
the corporation inflicting the pain.  You may not create case law which
helps your agenda and expect all the nasty folks to not grab at it and
use it to help their agenda.  The potential damage that this case law
would inflict dramatically outweighs the benefit of spanking some 
company that is shipping a binary driver.  Why can't you see it?
Reread Ted's message, he stated it nicely.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Larry McVoy wrote:
>
> I can understand your touchiness, it's not much fun living through tons of
> messages where people try and figure out how to circumvent your license.

That's not really the issue.

I'd like to make it clear that I'm actually much softer on this than many
other people - I've been making it clear that I think that binary-only
modules _are_ ok, but that the burden of proof of ok'ness is squarely on
the shoulders of the company that makes them.

So please do get that part clear: I'm pretty well-known for allowing
binary-only modules in things like AFS and nVidia, where some people think
they shouldn't be allowed.

But the real issue here (and in the subject line in this whole discussion)
is about an "exception clause".

There is none. And I'm just saying that there is NO WAY that a binary-only
module is "automatically in the clear". They _may_ be, but it's on the
basis of something totally different than just "it's a module".

This is why I want to make it so clear that "moduleness" (which is not a
word, but should be one) is not the thing that matters. There's still a
strong "linkage" to a particular kernel in a binary module, and the act of
running the linker is not what determines whether a work is a derived
work.

In short, you should not see my arguments as a way of saying "all modules
are derived works". I'm clearly not saying that, since I _do_ allow binary
only modules and I don't claim they infringe.

So I'm not arguing for a very wide notion of derived works: I'm arguing
AGAINST the narrow notion that a module would somehow automatically _not_
be derived.

This is why I've said at least fifty times that a kernel module is to be
considered "derived by default". The non-derivedness comes from things
that have nothing to do with whether it is a module.

		Linus

Driver API (was Re: Linux GPL and binary module exception clause?)

[Hannu Savolainen]

On Wed, 10 Dec 2003, Linus Torvalds wrote:

> I'd like to make it clear that I'm actually much softer on this than many
> other people - I've been making it clear that I think that binary-only
> modules _are_ ok, but that the burden of proof of ok'ness is squarely on
> the shoulders of the company that makes them.
Ok. That makes perfect sense.

It would be fair to have an official list of kernel services that are 100%
OK for use by binary-only device drivers (or kernel modules in general).
If anybody needs to use a service outside this list they know they may be
on thin ice. What I'm proposing into this kind of list are the basic
services needed to implement a character device driver (driver entry
points, kmalloc/vmalloc, mutex and sleep primitives, device I/O, userspace
access and few others). These all are primitives that can be found from
any "generic" kernel programming text book. Also they are available in
every operating system I have been worked with. So it would be very hard
to argue that using them could make aything "derived work".
I don't use anything but the charcater device interface so I can't say if
there is anything else that could/should be listed.

Even better would be a proper device driver ABI for "loosely integrated"
device drivers. It's possible to hide differences between kernel releases
so that the same driver can work with wide range of kernel versions).
There are some performance penalties but they are not significant. And the
drivers included in the kernel source tree don't need to use this
interface so I don't see there any _technical_ reasons against this idea.
I can volunteer to implement this interface if it's OK. Some motivation
for the ABI as well as some technical ideas will be at the end of this
message.

I don't make any statement about the correctness of the "derived work"
issue. However I think it's at least fair to avoid using kernel internals
in a way kernel developers don't like. It would be best for the future of
Linux that there is some agreement about this issue.

Developing software under GPL is everybody's right but not responsibility.
In distant future it may happen that all software gets distributed under
GPL or a similar license. However before that moment there will always be
some kind of gray zone between the open source and the closed source
worlds. And for various reasons somebody must live on the "right" side.
For example in my case we can't GPL our product for reasons that are beyond
our control (for example large parts of the source code are licensed from
hardware manufacturers and other companies under NDA). So I don't see it
fair that some developers think they have the right to enforce everybody
else to work under GPL.

-----
Why a driver ABI is required?

The reason wy I propose the driver ABI is that the current LKM mechanism
is quite unacceptable. It was fairly good sometimes around 1.2.x and
2.0.0 days but for some reason things have gotten worse and worse after
that. We  have learned to live with it. It just causes some waste of time
that could otherwise be spent on something productive. However for many
companies without prior LKM experience it's a big challenge.

Today there are 50-100 different kernel images released by numerous Linux
distribution vendors. In most Linux systems there are no development tools
installed so it's "impossible" to install any kernel modules from the
sources.  This is true also with "pure GPL" modules. To be able to compile
the module the user needs to install first the kernel sources, gcc,
binutils and make (if they have that much of free disk space left). After
figuring out what and how to install he also needs to figure out how to
configure the kernel (headers) in the right way. This is not something an
average Linux user can do. Many of them don't even know how to get to the
command line. For this reason companies making kernel modules must
distribute a precompiled module for each of the 50-100 different
distribution kernel images that are in active use (or a subset of them).
The number is very large because many distribution vendors release 2 to 8
different kernel images (SMP/UP, athlon/PIII/P4/etc) every time. And this
must be done also if the driver sources are under GPL.

There is not a problem if the module is compiled by the maintainer of
the distribution or if the user has compiled his kernel himself. However
it's impossible idea that drivers for every possible device could be
included in the kernel source tree or in some other way be compiled by the
distribution vendor. It can happen with devices that are in "mass"
production. However the world is full of other devices that are
interesting to about 0.0001% of all Linux users.

In the current way it's pretty impossible to produce Linux drivers (even
under GPL) because installing it would be too demanding. Things would be
much easier if the same driver image works with most (or every) kernels.
Another approach would be having the development tools and the properly
configured kernel sources included in the minimum configurations of each
Linux distribution but I would call this massive overkill.

Yet another problem is that there is no way to know which symbols are
only for kernel internal use and which ones can be safely used in some
drivers. Some routines change between kernel versions which often makes
drivers uncompilable. It's not difficult to find examples of this from
the net. Many companies have released Linux drivers for their hardware
but have then forgotten them. The result is that the driver sources are
available from the manufacturer but they don't compile any more. It's
usually difficult to fix them because they use unknown kernel routines
that have not been in the kernel since year 0. Having a stable driver
API or ABI very much eliminates this problem.

I understand that many of the kernel team members are against any kind of
non-GPL kernel space code. But I can't understand how making it difficult
to use it could make Linux better as an operating system. OTOH making it
easier to use binary only modules will also make it easier to use GPL
modules too.

Technical stuff
---------------

It's not true that kernel space code cannot be compiled without using the
kernel headers. OSS (Open Sound System) has for some time been compiled
against the standard (libc) headers. Just one of the source files contains
all the kernel dependent stuff and gets compiled against the kernel
headers. The reason is not trying to avoid any GPL issues. This is just
the only way to do that because otherwise the whole driver has to be
recompiled separately for each possible kernel (OK, it would have to be
shipped with sources too). We compile it against the libc headers to make
sure that no kernel inline code gets accidently called (which would cause
serious incompatibility problems). Also it's easier to set up the
compiling environment in this way (kernel headers often contain headers
that conflict with some other headers). The system headers are
required just because they contain values for some important constants.

The remaining "wrapper" module needs to be compiled against the right
kernel headers. It's kind of kernel ABI module. Instead of being a part
of the kernel it's part of our product (which is not the right place).

In it's current form the wrapper contains just wrappers around some
fundamental kernel routines and methods to access the required
fields of some kernel structures. The "client" driver sees the kernel
structures as some kind of cookies. It needs to call the right method to
read/write a field in this structure.

This kind of "1:1" wrapper is actually rather silly mechanism but it's
easy to implement. I'm currently re-designing the wrapper so that it
provides higher level of abstraction. In this way there is less overhead
because fewer calls need to be done between the wrapper and the client
driver. This wrapper will be released under LGPL (or GPL) so it will be
available for use by everybody who needs it. It can also be included in
the kernel sources.

Implementing drivers on top of this kind of wrapper causes some
performance impact. However it's not an issue. Many drivers actually
make other kernel calls rather infrequently so usually there is no inpact
at all. Most of time they spend by doing register I/O and things like
that. HW access can be done with the usual kernel inline routines without
any risk. Or the inline functions can be implemented inside the driver.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM

Re: Driver API (was Re: Linux GPL and binary module exception clause?)

[Peter Chubb]

>>>>> "Hannu" == Hannu Savolainen <hannu@opensound.com> writes:


Hannu> Even better would be a proper device driver ABI for "loosely
Hannu> integrated" device drivers. 

One of the things we're working on here is an ABI to allow device
drivers to live in user space, by enabling access to interrupts and PCI
DMA.  Now that NPTL and fast system calls are available, it's possible
to write, say, an IDE driver, that performs almost as well as (and in
some cases better than) the in-kernel driver.

Developing and tuning drivers out-of-kernel is *much* easier than
developing a module that lives in the kernel.  Also, bugs in an
out-of-kernel driver are much less likely to affect the rest of the
kernel (although screwing up the SG-list you pass to the device can
do it)

Sound drivers would be ideal to move out of the kernel entirely, and
there's a student here working on that.

I'll be talking about some of this work at LCA2004, and intend to
release the code then too.


--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: Driver API (was Re: Linux GPL and binary module exception clause?)

[Jason Kingsland]

Hannu Savolainen writes:
> Even better would be a proper device driver ABI for "loosely
> integrated" device drivers.

Peter Chubb writes:

> One of the things we're working on here is an ABI to allow device
> drivers to live in user space, by enabling access to interrupts and
> PCI DMA.

This is already available via a commercial product.

It's a proprietary licensed Linux binary loadable module (hmm...) that
exports the kernel services to user space in an abstract, OS and CPU
agnostic manner. The API is consistent for Win32, Linux, Solaris, VxWorks
and variants.

I've used it previously in a cross-platform commercial application which had
to run on Linux and Win32 and required hardware access, it works well. The
driver is provided as object code which you have to link against the kernel
headers to get access to the appropriate Linux ABI for the target release.

I believe the later versions include support for USB and HotSwap of PCI
busses (for things like CompactPCI) - look at the Kerneldriver and Windriver
products on the following page:

http://www.jungo.com/products.html#driver_tools

ps. Another dubious case of GPL boundaries perhaps - but I'm not going to
restart that thread !

Re: Driver API (was Re: Linux GPL and binary module exception clause?)

[Peter Chubb]

>>>>> "Jason" == Jason Kingsland <Jason_Kingsland@hotmail.com> writes:

Jason> Hannu Savolainen writes:
>> Even better would be a proper device driver ABI for "loosely
>> integrated" device drivers.

Jason> Peter Chubb writes:

>> One of the things we're working on here is an ABI to allow device
>> drivers to live in user space, by enabling access to interrupts and
>> PCI DMA.

Jason> This is already available via a commercial product.

 ...snip...
Jason> http://www.jungo.com/products.html#driver_tools

Yes I know, I read their web page, and if cross-platform compatibility
is what you want it looks a nice way to go.  They didn't publish any
performance figures (at least, not where I could find), and 
they're binary only, 

There's also the LinuxAnt stuff: http://www.linuxant.com that, for
Wireless cards at least, provides a Windows ABI for standard NDIS
drivers; and Hunt et al's work on Windows 
http://research.microsoft.com/~galenh/Publications/HuntUsenixNt97.pdf


--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: Driver API (was Re: Linux GPL and binary module exception clause?)

[viro]

On Thu, Dec 11, 2003 at 02:50:20AM +0200, Hannu Savolainen wrote:
 
> Even better would be a proper device driver ABI for "loosely integrated"
> device drivers. It's possible to hide differences between kernel releases
> so that the same driver can work with wide range of kernel versions).
> There are some performance penalties but they are not significant. And the
> drivers included in the kernel source tree don't need to use this
> interface so I don't see there any _technical_ reasons against this idea.
> I can volunteer to implement this interface if it's OK. Some motivation
> for the ABI as well as some technical ideas will be at the end of this
> message.

It doesn't work.  Let me give you an example: right now we have a way to get
from struct inode to struct block device - inode->i_bdev.  You can wrap it
into helper functions, whatever - it won't live to 2.8.

	Why?  Because if we want to handle device removal in a sane way, that
association will have to go.  We will still have a need (and a way) to get
from opened struct file of block device to its struct block_device.  And _that_
association will remain stable through the entire life of struct file.  Even
when the mapping from inode to block device gets changed.

	And it means that arguments of block device ->open(), ->release() and
->ioctl() will change - instead of struct inode we will pass the struct
block_device directly.  It's OK - callers have a way to get the thing and
methods themselves... right now the first thing they do is
	struct block_device *bdev = inode->i_bdev;
and either don't use inode afterwards at all or (very few) use it in a way
that can be replaced with use of bdev (e.g. inode->i_rdev -> bdev->bd_dev,
etc.).  The sole exception (floppy.c) still can get what it wants from the
second argument of ->open() (struct file *).

	The rest of the tree also can deal - I've done that and patches are
in -mm right now.  Most of them are easily mergable in 2.6, BTW.

	See what it means?  No fscking way to deal with that in wrappers.
Simply because the old assumption (inode->block_device remains stable)
is flat out wrong with new kernel.  Note that "just add a new API and leave
the old one for old drivers" would *NOT* work here.

	And yes, it's an interface change.  Caused by the fact that old
interface is Wrong(tm) (BTW, large part of that one is my fault - design
mistake in 2.3 that hadn't become obvious until 2.5.late).  Sure, we can
declare the new variant a part of ABI and have the glue for 2.4 and 2.6
wrap the new ->open()/->ioctl()/->release() with boilerplate that will
produce old-style ones.  _That_ direction is easy.  But that won't help
you with ABI - it allows to put new driver into old kernel, not the other
way round.  Which, come to think of it, is hardly a surprise - hindsight
is always 20/20 and all such.

	There is a good measure of interface quality - the less boilerplate
code you need to use it, the better.  It's not a trivial observation and
not just a matter of aesthetics.  It also means that there's less chance
of non-trivial breakage.  Note that you can wrap a good interface into bad
one - and that can usually be done in a uniform way (i.e. by _adding_ that
boilerplate code).  You can't go the other way round.  Case above is a good
example of that effect.

	See the problem now?  We can keep the same payload code if it uses
a good interface and we add wrappers to make it work with kernels that give
worse interfaces.  So if we design a really good one, we can say "that's our
ABI" and... what, exactly?  As long as new kernels have interfaces that are
not better than our, we are OK.  But it simply means that
	a) we should just use that good interface (and no glue) as kernel one.
	b) as soon as we have a need to improve the kernel interface, no amount
of glue is going to save that "ABI".
	c) in case if we decide to make kernel interface *WORSE*, our ABI will
really shine - then we will simply add glue to deal with degraded kernel.

	Which leaves only one question - why in damnation name would we ever
go for the case (c)?

	In other words, the nature of interface changes is such that usually
you can do glue between old interface and new driver and not the other way
round.  Which kills ABI idea - either you get a particular interface 100%
right and no glue is needed (then interface never changes simply because it's
Right(tm) and needs no changes) or you do not and no glue will save you as
soon as change becomes necessary.

	I'm a fairly arrogant bastard, but I do *not* claim that I can do
all interfaces right at once and avoid design mistakes.  Do you?  And if
yes, where can I get the drugs you are on?

Re: Driver API (was Re: Linux GPL and binary module exception clause?)

[Hannu Savolainen]

On Thu, 11 Dec 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:

> It doesn't work.  Let me give you an example: right now we have a way to get
> from struct inode to struct block device - inode->i_bdev.  You can wrap it
> into helper functions, whatever - it won't live to 2.8.
>
> 	Why?  Because if we want to handle device removal in a sane way, that
> association will have to go.  We will still have a need (and a way) to get
> from opened struct file of block device to its struct block_device.  And _that_
> association will remain stable through the entire life of struct file.  Even
> when the mapping from inode to block device gets changed.
I don't see this as a problem. I'm talking about an ABI for _character_
drivers only. Everybody who needs a "loosely coupled" device driver
will probably want to implement a character driver. If you look at any
operating systems there are very few differences between the character
driver interfaces of them. There have not been any dramatic changes in
this interface since Linux 0.99.x times. Some parameters have changed but
that's almost it.

Block devices, network devices and things like that are tighter coupled
by nature. I don't eventry to claim it's going to be possible to create
an ABI for them. At least I don't see it necessary.

In a charcter driver all you need to know from the inode structure is
basicly just the device (minor) number. It's not hard to implement the
ABI layer so that the minor number can be provided regardless of the
changes made to the kernel behind it.

To the client driver the ABI "wrapper" is a black box. It can't
see what is inside the box. In particular it can't see the kernel behind
it. If something changes in the kernel some changes are needed to the
internals of the box too.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM

Re: Driver API (was Re: Linux GPL and binary module exception clause?)

[viro]

On Thu, Dec 11, 2003 at 02:47:49PM +0200, Hannu Savolainen wrote:

> In a charcter driver all you need to know from the inode structure is
> basicly just the device (minor) number. It's not hard to implement the
> ABI layer so that the minor number can be provided regardless of the
> changes made to the kernel behind it.

Not good enough (if you want a demonstration, check USB character devices
and the nightmare stuff happening around handling of minor->object mapping
there).

Practically every place that uses minors instead of pointers to real objects
(whatever they are for that subsystem) is fscked as soon as you start dealing
with fun issues like hotplug, etc.

And then there is sysfs fun - my worst nightmare right now is that some
optimist will go ahead and put kobjects into sound/* objects.  Then we
are guaranteed several months of massaging the lifetime rules of the
damn things to pure refcounting and doing that in the maze of twisty little
wrappers, all pointless, will be *ugly*.  I'm getting more than enough of
that fun with netdev, thank you very much...

No, I don't know what changes will be needed in cdev interfaces; almost
certainly they will depend on subsystem and that's a work for 2.7.  But
we will need something and "just use minors" won't do it.

Re: Driver API (was Re: Linux GPL and binary module exception clause?)

[Hannu Savolainen]

On Thu, 11 Dec 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:

> On Thu, Dec 11, 2003 at 02:47:49PM +0200, Hannu Savolainen wrote:
>
> > In a charcter driver all you need to know from the inode structure is
> > basicly just the device (minor) number. It's not hard to implement the
> > ABI layer so that the minor number can be provided regardless of the
> > changes made to the kernel behind it.
>
> Not good enough (if you want a demonstration, check USB character devices
> and the nightmare stuff happening around handling of minor->object mapping
> there).
I'm not talking about USB character devices. I'm not talking about
hot-plugging. For sure it will be very difficult or even impossible to
handle this kind of issues. I'm only talking about simple character
device drivers. Ok, you can remove the major/minor mechanism entirely from
Linux. Then we have a problem but I'm sure there will be some easy
workaround even then.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM

Re: Linux GPL and binary module exception clause?

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

On Wed, 2003-12-10 10:08:22 -0800, Larry McVoy <lm@bitmover.com>
wrote in message <20031210180822.GI6896@work.bitmover.com>:
> On Wed, Dec 10, 2003 at 10:02:47AM -0800, Linus Torvalds wrote:
> > On Wed, 10 Dec 2003, Larry McVoy wrote:

> Technicality.  Which, by your own reasoning, doesn't count.  Linux does
> indeed have a binary interface, many people download drivers from some
> website (I've done it a pile of times) and stuck them in and they worked.
> I did that with the modem on my thinkpad across more than 10 kernel
> versions in the 2.2 or 2.4 timeframe.

But guess - that can fire back, too. Just had it these days: I've build
a Linux kernel with, erm, some strange GCC options (hey, I like playing)
and inserted AVM's binars ISDN driver. Guess what had happened then:)

That is, just let's stop to prattle about binary modules. We praddle
(all the time) that there's no thing called an "ABI" in Linux for
modules, but in The Real World, the ABIs of two kernel images are
quasi-identical (except in some instances which can easily be caught by
a wrapper module).

So it's all about *really* changing ABI things here and there. Yes, an
obnoxious pig I am:) I'd start thinking about who I could achieve that
in a working manner...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Linux GPL and binary module exception clause?

[Hua Zhong]

> No it wouldn't.
> 
> Microsoft very much _has_ a binary API to their drivers, in a way that
> Linux doesn't.
> 
> MS has to have that binary API exactly because they live in a 
> binary-only world. They've basically put that requirement on
themselves 
> by having binary-only distributions.
> 
> So your argument doesn't fly. To Microsoft, a "driver" is just another
> external entity, with documented API's, and they indeed ship 
> their _own_ drivers that way too. And all third-party drivers do the
same 
> thing.
> 
> So there is no analogy to the Linux case. In Linux, no fixed 
> binary API exists, and the way normal drivers are distributed are as 
> GPL'd source code.

With all due respect, I find the above hardly convincing.

With your own argument, how would you convince a judge to believe it
without understanding all the subtle technical differences? (and we're
just taking what you said about "one offers stable ABI the other not"
for granted for now)

Both Windows and Linux are operating systems, that's the first thing.
Whether they are open source or not is just a secondary difference. How
could this fundamentally change the question "if a driver is a derived
work of the OS or not"?

In either case the driver would not work "without the host OS". In
either case, the same driver binary would probably not work across
versions. Both are pretty strong points in your argument. Moreover, in
the Windows world, a non-trivial user space application very possibly
havs different binaries for different versions - hey, Windows may have a
less stable user space ABI than Linux, so they could very well claim
more rights over user space applications, can't they?

I'm not arguing because I am afraid of being sued, just to clarify. To
be frank the chance that I'm sued by kernel copyright holders for
writing a binary only module is slimer than being sued by SCO for using
Linux freely. The chance that I would lose is also slimer than IBM would
lose to SCO.

Hua

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Linus,

Didn't your earlier public comments state in clear terms, each kernel
release it self has a unique module interface.  This would be the
effective API for the snap shot in time.  Where as claims of it being a
moving target is between releases?  Thus binary module writers get what
they get?

This looks to be your position in the past.

With this in mind, it makes each "published" source the manual unique into
itself.

I am just a little confused and fuzzy around the edges.

Andre Hedrick
LAD Storage Consulting Group

PS: Nobody has yet to comment that I have remaind civil throught the
thread :-) whoops!

On Wed, 10 Dec 2003, Linus Torvalds wrote:

> 
> On Wed, 10 Dec 2003, Larry McVoy wrote:
> >
> > I see.  And your argument, had it prevailed 5 years ago, would have
> > invalidated the following, would it not?  The following from one of the
> > Microsoft lawsuits.
> 
> No it wouldn't.
> 
> Microsoft very much _has_ a binary API to their drivers, in a way that
> Linux doesn't.
> 
> MS has to have that binary API exactly because they live in a binary-only
> world. They've basically put that requirement on themselves by having
> binary-only distributions.
> 
> So your argument doesn't fly. To Microsoft, a "driver" is just another
> external entity, with documented API's, and they indeed ship their _own_
> drivers that way too. And all third-party drivers do the same thing.
> 
> So there is no analogy to the Linux case. In Linux, no fixed binary API
> exists, and the way normal drivers are distributed are as GPL'd source
> code.
> 
> 			Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Linux GPL and binary module exception clause?

[Andrew Pimlott]

On Wed, Dec 10, 2003 at 09:56:14AM -0800, Larry McVoy wrote:
> On Wed, Dec 10, 2003 at 09:10:18AM -0800, Linus Torvalds wrote:
> > In short, your honour, this extra chapter without any meaning on its own
> > is a derived work of the book.
> 
> I see.  And your argument, had it prevailed 5 years ago, would have
> invalidated the following, would it not?  The following from one of the
> Microsoft lawsuits.
> 
> >From http://ecfp.cadc.uscourts.gov/MS-Docs/1636/0.pdf
> 
>     Substituting an alternative module for one supplied by Microsoft
>     may not violate copyright law, and certainly not because of any
>     "integrity of the work" argument. The United States recognizes "moral
>     rights" of attribution and integrity only for works of visual art
>     in limited editions of 200 or fewer copies. (See 17 U.S.C. 106A
>     and the definition of "work of visual art" in 17 U.S.C. 101.) A
>     bookstore can replace the last chapter of a mystery novel without
>     infringing its copyright, as long as they are not reprinting the
>     other chapters but are simply removing the last chapter and replacing
>     it with an alternative one, but must not pass the book off as the
>     original. Having a copyright in a work does not give that copyright
>     owner unlimited freedom in the terms he can impose.

You probably should have mentioned that this statement was made not
by a judge or a lawyer, but by a CS professor in an amicus curiae
brief.  And the implication that this argument had much to do with
the outcome of the Microsoft case--which was about antitrust and
bundling, not copyrights--is disingenuous.

> Start to see why I think what you are doing is dangerous and will backfire?

You are extrapolating way too far.  There are so many differences
between the Linux-module issue and the vague doomsday scenario you
are trying to conjure.  Linus explained one (coherence and stability
of the API/ABI), and I think it could be easily be cast as a test
that a court could apply.

Maybe you can describe a specific case in which Linus's argument
backfires?  I'm not saying you have no point at all, just that I
don't think this one thing is holding back the flood-waters.

Andrew

Re: Linux GPL and binary module exception clause?

[Rob Landley]

On Wednesday 10 December 2003 11:56, Larry McVoy wrote:
> On Wed, Dec 10, 2003 at 09:10:18AM -0800, Linus Torvalds wrote:
> > On Wed, 10 Dec 2003, Larry McVoy wrote:
> > > Which is?  How is it that you can spend a page of text saying a judge
> > > doesn't care about technicalities and then base the rest of your
> > > argument on the distinction between a "plugin" and a "kernel module"?
> >
> > I'll stop arguing, since you obviously do not get it.
>
> Err, I think people might say you are punting.  You claim that there is a
> difference between a plugin and a kernel module, I ask what, you say
> "I'll stop arguing because you don't get it".  Hmm.

For one thing, the plugin was made by someone without access to Netscape or 
IE's source code, using a documented interface that contained sufficient 
information to do the job without access to that source code.

Yes, it matters.

Rob

RE: Linux GPL and binary module exception clause?

[Hua Zhong]

> For one thing, the plugin was made by someone without access 
> to Netscape or IE's source code, using a documented interface 
> that contained sufficient information to do the job without access 
> to that source code.
>
> Yes, it matters.

_What_ matters?

Open source? (if you write a plugin for an opensource
kernel/application, you are not plugin anymore and you are derived
work.) I am sure you don't mean it.

Documented interface? Hey, there are sources which are the best
documentation. :-)

Seriously, even if I accept that there is never an intent to support a
stable ABI for kernel modules, some vendor can easily claim that "we
support a stable ABI, so write kernel modules for the kernel we
distribute".

Anything can prevent that? I cannot see GPL disallow it.

So OK, Linus and other kernel developers never intended to provide a
stable ABI, but someone else could. The original author's intent is
never relevant anymore. This is the goodness of opensource, isn't it?

Re: Linux GPL and binary module exception clause?

[Rob Landley]

On Thursday 11 December 2003 02:11, Hua Zhong wrote:
> > For one thing, the plugin was made by someone without access
> > to Netscape or IE's source code, using a documented interface
> > that contained sufficient information to do the job without access
> > to that source code.
> >
> > Yes, it matters.
>
> _What_ matters?
>
> Open source? (if you write a plugin for an opensource
> kernel/application, you are not plugin anymore and you are derived
> work.) I am sure you don't mean it.
>
> Documented interface? Hey, there are sources which are the best
> documentation. :-)

If you write software by referring to documentation, the barrier for it being 
a derivative work is higher than if you write it by looking at another 
implementation.

> Seriously, even if I accept that there is never an intent to support a
> stable ABI for kernel modules, some vendor can easily claim that "we
> support a stable ABI, so write kernel modules for the kernel we
> distribute".
>
> Anything can prevent that? I cannot see GPL disallow it.
>
> So OK, Linus and other kernel developers never intended to provide a
> stable ABI, but someone else could. The original author's intent is
> never relevant anymore. This is the goodness of opensource, isn't it?

Once upon a time, Compaq did a clean-room clone of IBM's BIOS.  Group 1 
studied the original bios and wrote up a spec, and group 2 wrote a new bios 
from that spec, and group 1 never spoke to group 2, and all of this was 
extensively documented so that when IBM sued them they proved in court that 
their BIOS wasn't derived from IBM's.  (Of course compaq used vigin 
programmers fresh out of college who'd never seen a PC before, which was a 
lot easier to do in 1983...)

I didn't make this up.  This was a really big deal 20 years ago.  It happened, 
and it mattered, and people cared that they created a fresh implementation 
without seeing the original code, entirely from a written specification that 
was not a derivative work of the first implementation, so no matter how 
similar the second implementation was (hand-coded assembly performing the 
same functions on the same processor in the same amount of space), it could 
not be considered a derivative work.

This was a strong enough defense to beat IBM's lawyers, who were trying to 
claim that Compaq's new BIOS WAS a derivative work...

Rob

RE: Linux GPL and binary module exception clause?

[Hua Zhong]

> If you write software by referring to documentation, the 
> barrier for it being a derivative work is higher than if you 
> write it by looking at another implementation.
> 
> [and the IBM/Compaq lawsuit]

What you mentioned is not relevant to the discussion, I think.

People who write kernel modules might read kernel sources, yes. But they
read kernel source to understand how it works, not to clone it. Even
user space programmers do that. Even people not writing software for
Linux do that. Isn't the open source spirit to encourage people to read
it? Now what you said indicates "read me, but you are then tainted and
when I sue you you have to provide evidence you are not".

People also reverse-engineer how closed-source software works. That is
how we got FAT/NTFS support in Linux. People also write various
interesting software using undocumented APIs of DOS and Windows.
Remember TSR? Remember <<Undocumented DOS/Windows>>?

We want the same thing on Linux. Great Linux is open source so we don't
have to do the same reverse-engineering thing as we did to M$ operating
systems (IOW, reading source is the easiest way to "reverse-engineer" so
we could write software that interfaces with the system). Now after
reading your comment, I have to wonder "which one is nicer, Linux or
Windows"?

Hua

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Rob,

Help me out?  Who is cloning what ?

I am talking about original works, to talking about talking somebody's
stuff out of the kernel, hacking it up and distributing the work as an
original (that is clearly a derived work).

So your arguement is bogus, try again.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 11 Dec 2003, Rob Landley wrote:

> On Thursday 11 December 2003 02:11, Hua Zhong wrote:
> > > For one thing, the plugin was made by someone without access
> > > to Netscape or IE's source code, using a documented interface
> > > that contained sufficient information to do the job without access
> > > to that source code.
> > >
> > > Yes, it matters.
> >
> > _What_ matters?
> >
> > Open source? (if you write a plugin for an opensource
> > kernel/application, you are not plugin anymore and you are derived
> > work.) I am sure you don't mean it.
> >
> > Documented interface? Hey, there are sources which are the best
> > documentation. :-)
> 
> If you write software by referring to documentation, the barrier for it being 
> a derivative work is higher than if you write it by looking at another 
> implementation.
> 
> > Seriously, even if I accept that there is never an intent to support a
> > stable ABI for kernel modules, some vendor can easily claim that "we
> > support a stable ABI, so write kernel modules for the kernel we
> > distribute".
> >
> > Anything can prevent that? I cannot see GPL disallow it.
> >
> > So OK, Linus and other kernel developers never intended to provide a
> > stable ABI, but someone else could. The original author's intent is
> > never relevant anymore. This is the goodness of opensource, isn't it?
> 
> Once upon a time, Compaq did a clean-room clone of IBM's BIOS.  Group 1 
> studied the original bios and wrote up a spec, and group 2 wrote a new bios 
> from that spec, and group 1 never spoke to group 2, and all of this was 
> extensively documented so that when IBM sued them they proved in court that 
> their BIOS wasn't derived from IBM's.  (Of course compaq used vigin 
> programmers fresh out of college who'd never seen a PC before, which was a 
> lot easier to do in 1983...)
> 
> I didn't make this up.  This was a really big deal 20 years ago.  It happened, 
> and it mattered, and people cared that they created a fresh implementation 
> without seeing the original code, entirely from a written specification that 
> was not a derivative work of the first implementation, so no matter how 
> similar the second implementation was (hand-coded assembly performing the 
> same functions on the same processor in the same amount of space), it could 
> not be considered a derivative work.
> 
> This was a strong enough defense to beat IBM's lawyers, who were trying to 
> claim that Compaq's new BIOS WAS a derivative work...
> 
> Rob
> 

Re: Linux GPL and binary module exception clause?

[Rob Landley]

On Thursday 11 December 2003 15:20, Andre Hedrick wrote:
> Rob,
>
> Help me out?  Who is cloning what ?
>
> I am talking about original works, to talking about talking somebody's
> stuff out of the kernel, hacking it up and distributing the work as an
> original (that is clearly a derived work).
>
> So your arguement is bogus, try again.

If you'd read the message, you might have noticed that I was talking about why 
web browser plugins may be considered to be different from kernel modules.

The fact you personally were off in a corner talking about little green men 
from mars is remarkably irrelevant to what I wrote to Hua Zhong (who I'm 
fairly certain is not you.  His english is better.)

I have no intention of "trying again" because I wasn't talking to you in the 
first place.  (I don't find what you have to say on IP issues particularly 
interesting, and don't read the ones that aren't cc'd to me...)  Neither of 
us are lawyers.  The difference is that I know it.

Rob

> Cheers,
>
> Andre Hedrick
> LAD Storage Consulting Group
>
> On Thu, 11 Dec 2003, Rob Landley wrote:
> > On Thursday 11 December 2003 02:11, Hua Zhong wrote:
> > > > For one thing, the plugin was made by someone without access
> > > > to Netscape or IE's source code, using a documented interface
> > > > that contained sufficient information to do the job without access
> > > > to that source code.
> > > >
> > > > Yes, it matters.
> > >
> > > _What_ matters?
> > >
> > > Open source? (if you write a plugin for an opensource
> > > kernel/application, you are not plugin anymore and you are derived
> > > work.) I am sure you don't mean it.
> > >
> > > Documented interface? Hey, there are sources which are the best
> > > documentation. :-)
> >
> > If you write software by referring to documentation, the barrier for it
> > being a derivative work is higher than if you write it by looking at
> > another implementation.
> >
> > > Seriously, even if I accept that there is never an intent to support a
> > > stable ABI for kernel modules, some vendor can easily claim that "we
> > > support a stable ABI, so write kernel modules for the kernel we
> > > distribute".
> > >
> > > Anything can prevent that? I cannot see GPL disallow it.
> > >
> > > So OK, Linus and other kernel developers never intended to provide a
> > > stable ABI, but someone else could. The original author's intent is
> > > never relevant anymore. This is the goodness of opensource, isn't it?
> >
> > Once upon a time, Compaq did a clean-room clone of IBM's BIOS.  Group 1
> > studied the original bios and wrote up a spec, and group 2 wrote a new
> > bios from that spec, and group 1 never spoke to group 2, and all of this
> > was extensively documented so that when IBM sued them they proved in
> > court that their BIOS wasn't derived from IBM's.  (Of course compaq used
> > vigin programmers fresh out of college who'd never seen a PC before,
> > which was a lot easier to do in 1983...)
> >
> > I didn't make this up.  This was a really big deal 20 years ago.  It
> > happened, and it mattered, and people cared that they created a fresh
> > implementation without seeing the original code, entirely from a written
> > specification that was not a derivative work of the first implementation,
> > so no matter how similar the second implementation was (hand-coded
> > assembly performing the same functions on the same processor in the same
> > amount of space), it could not be considered a derivative work.
> >
> > This was a strong enough defense to beat IBM's lawyers, who were trying
> > to claim that Compaq's new BIOS WAS a derivative work...
> >
> > Rob

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Rob,

> The fact you personally were off in a corner talking about little green men
> from mars is remarkably irrelevant to what I wrote to Hua Zhong (who I'm
> fairly certain is not you.  His english is better.)

Gee, I love the insults.  I seriously doubt you have ever paid a lawyer
to even have the knowledge to allow you to pump out the bovine piles you
are spraying in the air.

Correct, I am not a lawyer, and you admit you are not one.

I have paid lawyers for advice and some damn good ones.

Can you say the same?

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 11 Dec 2003, Rob Landley wrote:

> On Thursday 11 December 2003 15:20, Andre Hedrick wrote:
> > Rob,
> >
> > Help me out?  Who is cloning what ?
> >
> > I am talking about original works, to talking about talking somebody's
> > stuff out of the kernel, hacking it up and distributing the work as an
> > original (that is clearly a derived work).
> >
> > So your arguement is bogus, try again.
> 
> If you'd read the message, you might have noticed that I was talking about why 
> web browser plugins may be considered to be different from kernel modules.
> 
> The fact you personally were off in a corner talking about little green men 
> from mars is remarkably irrelevant to what I wrote to Hua Zhong (who I'm 
> fairly certain is not you.  His english is better.)
> 
> I have no intention of "trying again" because I wasn't talking to you in the 
> first place.  (I don't find what you have to say on IP issues particularly 
> interesting, and don't read the ones that aren't cc'd to me...)  Neither of 
> us are lawyers.  The difference is that I know it.
> 
> Rob
> 
> > Cheers,
> >
> > Andre Hedrick
> > LAD Storage Consulting Group
> >
> > On Thu, 11 Dec 2003, Rob Landley wrote:
> > > On Thursday 11 December 2003 02:11, Hua Zhong wrote:
> > > > > For one thing, the plugin was made by someone without access
> > > > > to Netscape or IE's source code, using a documented interface
> > > > > that contained sufficient information to do the job without access
> > > > > to that source code.
> > > > >
> > > > > Yes, it matters.
> > > >
> > > > _What_ matters?
> > > >
> > > > Open source? (if you write a plugin for an opensource
> > > > kernel/application, you are not plugin anymore and you are derived
> > > > work.) I am sure you don't mean it.
> > > >
> > > > Documented interface? Hey, there are sources which are the best
> > > > documentation. :-)
> > >
> > > If you write software by referring to documentation, the barrier for it
> > > being a derivative work is higher than if you write it by looking at
> > > another implementation.
> > >
> > > > Seriously, even if I accept that there is never an intent to support a
> > > > stable ABI for kernel modules, some vendor can easily claim that "we
> > > > support a stable ABI, so write kernel modules for the kernel we
> > > > distribute".
> > > >
> > > > Anything can prevent that? I cannot see GPL disallow it.
> > > >
> > > > So OK, Linus and other kernel developers never intended to provide a
> > > > stable ABI, but someone else could. The original author's intent is
> > > > never relevant anymore. This is the goodness of opensource, isn't it?
> > >
> > > Once upon a time, Compaq did a clean-room clone of IBM's BIOS.  Group 1
> > > studied the original bios and wrote up a spec, and group 2 wrote a new
> > > bios from that spec, and group 1 never spoke to group 2, and all of this
> > > was extensively documented so that when IBM sued them they proved in
> > > court that their BIOS wasn't derived from IBM's.  (Of course compaq used
> > > vigin programmers fresh out of college who'd never seen a PC before,
> > > which was a lot easier to do in 1983...)
> > >
> > > I didn't make this up.  This was a really big deal 20 years ago.  It
> > > happened, and it mattered, and people cared that they created a fresh
> > > implementation without seeing the original code, entirely from a written
> > > specification that was not a derivative work of the first implementation,
> > > so no matter how similar the second implementation was (hand-coded
> > > assembly performing the same functions on the same processor in the same
> > > amount of space), it could not be considered a derivative work.
> > >
> > > This was a strong enough defense to beat IBM's lawyers, who were trying
> > > to claim that Compaq's new BIOS WAS a derivative work...
> > >
> > > Rob
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Linux GPL and binary module exception clause?

[Rob Landley]

On Thursday 11 December 2003 16:42, Andre Hedrick wrote:
> Rob,
>
> > The fact you personally were off in a corner talking about little green
> > men from mars is remarkably irrelevant to what I wrote to Hua Zhong (who
> > I'm fairly certain is not you.  His english is better.)
>
> Gee, I love the insults.  I seriously doubt you have ever paid a lawyer
> to even have the knowledge to allow you to pump out the bovine piles you
> are spraying in the air.

I've noticed that you love insults, yes.  I believe you've finally found a 
statement that we can both agree on.

> Correct, I am not a lawyer, and you admit you are not one.

Two.  Wow.  Progress.

> I have paid lawyers for advice and some damn good ones.
>
> Can you say the same?

I have paid lawyers for advice.  I have been paid BY lawyers.  I have hung out 
socially with lawyers.  I have studied law for years, although not with the 
aim of acquiring credentials.

Here's a week-long series on intellectual property I wrote for The Motley Fool 
a few years ago.  It was reviewed by TMF's legal department, and we went back 
and forth on a couple minor things before it got published.

http://www.fool.com/portfolios/rulemaker/2000/rulemaker000501.htm
http://www.fool.com/portfolios/rulemaker/2000/rulemaker000502.htm
http://www.fool.com/portfolios/rulemaker/2000/rulemaker000503.htm
http://www.fool.com/portfolios/rulemaker/2000/rulemaker000504.htm
http://www.fool.com/portfolios/rulemaker/2000/rulemaker000505.htm

I've since spotted a couple more minor points that crept past the lawyers who 
reviewed it.  I have learned since then.  I learned doing it: I still have 
some of the literature I picked up visiting the PTO in washington DC doing 
research for that series.  And I learned a lot years before doing it.  That's 
just one example that's still online.

I have been paid to explain the standard community interpretation of the GPL 
by at least three different companies' lawyers now.  (I started studying the 
GPL and LGPL specifically in 1996, which is really what got me into this 
whole hobby...)

A few years ago I had some fairly extensive email discussions with Richard 
Stallman about copyright and the GPL (even driving to boston to interview him 
in person once).  I've had considerably more extensive discussions with Eric 
Raymond (whose wife is a lawyer, and who as president of OSI has been asked 
to review licenses by companies like Apple and IBM...)

Heck, Eric and Cathy are _friends_ of mine.  Try "dig www.landley.net" and 
"dig www.thyrsus.com": I'm still borrowing space on the machine in Eric's 
basement because I've been too lazy to arrange a hosting box here in Texas.  
(It's on my to-do list...)  I'm mentioned in the introduction of Eric's new 
book because I went to Pennsylvania and crashed on his couch for a month to 
edit the thing.  (http://www.catb.org/~esr/writings/taoup/html/pr01s06.html 
paragraph 2. The "walkthrough" in 0.2 and 0.3 of the revision history was 
_ME_.)

I'm the one who arranged to have a panel at Penguicon on intellectual property 
issues with a real lawyer (Cathy) explaining what the various open source 
licenses mean to attendees (See 
http://penguicon.sourceforge.net/programming.shtml sunday, 10 am, north 
belle).  This year's Penguicon will probably have another one, although I'm 
much less involved...

And what I've learned from ALL of that (and far more that's not worth listing 
here) is that there's a reason it's called a legal OPINION, and what you 
generally say isn't "you're wrong" but "I disagree, and here's why".  Judges 
give rulings, not lawyers.  (And judges' rulings get overturned, don't apply 
to a given case, vary by jurisdiction, etc...)

Lawyers no more universally agree on interpretations of the law then techies 
agree on kernel optimizations.  And open source licensing (as a subset of 
intellectual property) is every bit as much a specialty area of the law as 
virtual memory page replacement strategies (a subset of kernel development) 
is a specialty area of programming.  (Most lawyers don't really know much 
about it at all, they just know where to look it up.  Hence a couple lawyers 
asking me what the community thinks the GPL means.  Obviously they don't take 
my opinion as gospel: they go and read the thing themselves, and the law, and 
as much relevant case law as they can find (which ain't much), and then we 
have a back and forth...)

I don't know much about estate planning, tax law, insurance law, or civil 
administrative procedure.  I keep forgetting what latin terms like "res 
judicata" mean (god bless Google), and I had to look up "barratry" at the 
start of the SCO thing.  But yes, I consider myself competently informed 
about my little niche.

These days, with resources like http://www4.law.cornell.edu/uscode/17/ out 
there, it's not nearly as hard to be up to speed on this as it used to be.  
(You used to have to go to the LIBRARY.  And get out BOOKS.  And send money 
to Nolo Press every time they got sued.  Uphill.  Both ways.)

> Can you say the same?

Why would I want to?

I've seen experts in this area.  Eben Moglen 
(http://emoglen.law.columbia.edu/) and Lawrence Lessig 
(http://www.lessig.org/blog/) come to mind.

I am not an expert here.  I am an educated layman.  I read things like "Legal 
battles that shaped the computer industry" (by Lawrence D. Graham, 
http://www.amazon.co.uk/exec/obidos/ASIN/1567201784/026-4037783-2541254 ) for 
fun.  Yes, I am weird.

You obviously aren't even an educated layman if you think that simply having 
spoken to a lawyer means that legalness somehow rubbed off on you and gave 
you an aura of absolute truth.  Every time I talk to a lawyer, the concept of 
absolute truth in law gets farther and farther away...

Feel free to take that as a suggestion.

Rob

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Rob,

You know, I would have to say you just waxed my arse all over the mailing
list and left it in the mop bucket for cooling off.  The beauty is I can
now laugh about it, and see you are so raw over the issue.  Have a case of
chapstick to help smooth over the burn.

It is kind of cool you had an atomic bomb to fry me, if I cared I would
respond in the old ugly manners, but hey I asked for it.  Feels like the
the dude in the Memorex commerial.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 11 Dec 2003, Rob Landley wrote:

> On Thursday 11 December 2003 16:42, Andre Hedrick wrote:
> > Rob,
> >
> > > The fact you personally were off in a corner talking about little green
> > > men from mars is remarkably irrelevant to what I wrote to Hua Zhong (who
> > > I'm fairly certain is not you.  His english is better.)
> >
> > Gee, I love the insults.  I seriously doubt you have ever paid a lawyer
> > to even have the knowledge to allow you to pump out the bovine piles you
> > are spraying in the air.
> 
> I've noticed that you love insults, yes.  I believe you've finally found a 
> statement that we can both agree on.
> 
> > Correct, I am not a lawyer, and you admit you are not one.
> 
> Two.  Wow.  Progress.
> 
> > I have paid lawyers for advice and some damn good ones.
> >
> > Can you say the same?
> 
> I have paid lawyers for advice.  I have been paid BY lawyers.  I have hung out 
> socially with lawyers.  I have studied law for years, although not with the 
> aim of acquiring credentials.
> 
> Here's a week-long series on intellectual property I wrote for The Motley Fool 
> a few years ago.  It was reviewed by TMF's legal department, and we went back 
> and forth on a couple minor things before it got published.
> 
> http://www.fool.com/portfolios/rulemaker/2000/rulemaker000501.htm
> http://www.fool.com/portfolios/rulemaker/2000/rulemaker000502.htm
> http://www.fool.com/portfolios/rulemaker/2000/rulemaker000503.htm
> http://www.fool.com/portfolios/rulemaker/2000/rulemaker000504.htm
> http://www.fool.com/portfolios/rulemaker/2000/rulemaker000505.htm
> 
> I've since spotted a couple more minor points that crept past the lawyers who 
> reviewed it.  I have learned since then.  I learned doing it: I still have 
> some of the literature I picked up visiting the PTO in washington DC doing 
> research for that series.  And I learned a lot years before doing it.  That's 
> just one example that's still online.
> 
> I have been paid to explain the standard community interpretation of the GPL 
> by at least three different companies' lawyers now.  (I started studying the 
> GPL and LGPL specifically in 1996, which is really what got me into this 
> whole hobby...)
> 
> A few years ago I had some fairly extensive email discussions with Richard 
> Stallman about copyright and the GPL (even driving to boston to interview him 
> in person once).  I've had considerably more extensive discussions with Eric 
> Raymond (whose wife is a lawyer, and who as president of OSI has been asked 
> to review licenses by companies like Apple and IBM...)
> 
> Heck, Eric and Cathy are _friends_ of mine.  Try "dig www.landley.net" and 
> "dig www.thyrsus.com": I'm still borrowing space on the machine in Eric's 
> basement because I've been too lazy to arrange a hosting box here in Texas.  
> (It's on my to-do list...)  I'm mentioned in the introduction of Eric's new 
> book because I went to Pennsylvania and crashed on his couch for a month to 
> edit the thing.  (http://www.catb.org/~esr/writings/taoup/html/pr01s06.html 
> paragraph 2. The "walkthrough" in 0.2 and 0.3 of the revision history was 
> _ME_.)
> 
> I'm the one who arranged to have a panel at Penguicon on intellectual property 
> issues with a real lawyer (Cathy) explaining what the various open source 
> licenses mean to attendees (See 
> http://penguicon.sourceforge.net/programming.shtml sunday, 10 am, north 
> belle).  This year's Penguicon will probably have another one, although I'm 
> much less involved...
> 
> And what I've learned from ALL of that (and far more that's not worth listing 
> here) is that there's a reason it's called a legal OPINION, and what you 
> generally say isn't "you're wrong" but "I disagree, and here's why".  Judges 
> give rulings, not lawyers.  (And judges' rulings get overturned, don't apply 
> to a given case, vary by jurisdiction, etc...)
> 
> Lawyers no more universally agree on interpretations of the law then techies 
> agree on kernel optimizations.  And open source licensing (as a subset of 
> intellectual property) is every bit as much a specialty area of the law as 
> virtual memory page replacement strategies (a subset of kernel development) 
> is a specialty area of programming.  (Most lawyers don't really know much 
> about it at all, they just know where to look it up.  Hence a couple lawyers 
> asking me what the community thinks the GPL means.  Obviously they don't take 
> my opinion as gospel: they go and read the thing themselves, and the law, and 
> as much relevant case law as they can find (which ain't much), and then we 
> have a back and forth...)
> 
> I don't know much about estate planning, tax law, insurance law, or civil 
> administrative procedure.  I keep forgetting what latin terms like "res 
> judicata" mean (god bless Google), and I had to look up "barratry" at the 
> start of the SCO thing.  But yes, I consider myself competently informed 
> about my little niche.
> 
> These days, with resources like http://www4.law.cornell.edu/uscode/17/ out 
> there, it's not nearly as hard to be up to speed on this as it used to be.  
> (You used to have to go to the LIBRARY.  And get out BOOKS.  And send money 
> to Nolo Press every time they got sued.  Uphill.  Both ways.)
> 
> > Can you say the same?
> 
> Why would I want to?
> 
> I've seen experts in this area.  Eben Moglen 
> (http://emoglen.law.columbia.edu/) and Lawrence Lessig 
> (http://www.lessig.org/blog/) come to mind.
> 
> I am not an expert here.  I am an educated layman.  I read things like "Legal 
> battles that shaped the computer industry" (by Lawrence D. Graham, 
> http://www.amazon.co.uk/exec/obidos/ASIN/1567201784/026-4037783-2541254 ) for 
> fun.  Yes, I am weird.
> 
> You obviously aren't even an educated layman if you think that simply having 
> spoken to a lawyer means that legalness somehow rubbed off on you and gave 
> you an aura of absolute truth.  Every time I talk to a lawyer, the concept of 
> absolute truth in law gets farther and farther away...
> 
> Feel free to take that as a suggestion.
> 
> Rob
> 

Re: Linux GPL and binary module exception clause?

[Rob Landley]

On Friday 12 December 2003 01:21, Andre Hedrick wrote:
> Rob,
>
> You know, I would have to say you just waxed my arse all over the mailing
> list and left it in the mop bucket for cooling off.  The beauty is I can
> now laugh about it, and see you are so raw over the issue.  Have a case of
> chapstick to help smooth over the burn.

Ah, it's finals week.  It's nice to vent a little steam and take a break from 
failing to get my Educational Psychology and Economics of Technology papers 
in on time. :)

Sorry if I came down a bit hard.  I type fast, and I've had a backlog of 
stress this week.  (I know I had a reason for going back to grad school.  I 
wonder what it was?)

Rob

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Rob,

I must admit when I jumped into this thread late, I said I was a little
chilly here in Northern California.  I am toasty warm now and look like
"Buckwheat" (just not on the top cause the hair is thin).

The up side of the roasting is you have exposed yourself as a serious pool
of knowledge.  The down side for you is class is in session, and if
nothing else I would like to here all the various positions and reviews
you have observer, contributed, and blah blah ...

TMF is not an easy place to express an opinion.

My butt is in the chair to listen if class is in session :-)

Cheers,

Andre Hedrick
LAD Storage Consulting Group

PS for all the flamage I have ever dumped on this list, it is good to take
some back in return.

On Fri, 12 Dec 2003, Rob Landley wrote:

> On Friday 12 December 2003 01:21, Andre Hedrick wrote:
> > Rob,
> >
> > You know, I would have to say you just waxed my arse all over the mailing
> > list and left it in the mop bucket for cooling off.  The beauty is I can
> > now laugh about it, and see you are so raw over the issue.  Have a case of
> > chapstick to help smooth over the burn.
> 
> Ah, it's finals week.  It's nice to vent a little steam and take a break from 
> failing to get my Educational Psychology and Economics of Technology papers 
> in on time. :)
> 
> Sorry if I came down a bit hard.  I type fast, and I've had a backlog of 
> stress this week.  (I know I had a reason for going back to grad school.  I 
> wonder what it was?)
> 
> Rob
> 

Re: Linux GPL and binary module exception clause?

[Rob Landley]

On Friday 12 December 2003 01:56, Andre Hedrick wrote:
> Rob,
>
> I must admit when I jumped into this thread late, I said I was a little
> chilly here in Northern California.  I am toasty warm now and look like
> "Buckwheat" (just not on the top cause the hair is thin).
>
> The up side of the roasting is you have exposed yourself as a serious pool
> of knowledge.  The down side for you is class is in session, and if
> nothing else I would like to here all the various positions and reviews
> you have observer, contributed, and blah blah ...
>
> TMF is not an easy place to express an opinion.
>
> My butt is in the chair to listen if class is in session :-)

Sheesh, I'm not an expert on this, but I'm happy to share my ignorance.  Just 
keep in mind, IANAL. :)

The place I started is http://www.faqs.org/faqs/law/copyright/faq/
which is pretty darn stale now (it's ten years old, it predates the sony bono 
copyright extension act, the DMCA, and a bunch of other stuff).  So don't 
take is as an authority on any specifics of the law, but I found it to be a 
great introduction to the basic concepts, and I'd guess it still is.

MIT has a similar FAQ here, but it's not nearly as thorough:

http://web.mit.edu/copyright/faq.html

And the next step (more authoritative/recent, but less detailed and newbie 
friendly) would be here:

http://www.copyright.gov/faq.html

What else...  Understanding that copyright law is NOT the same as contract 
law, trademark law, patent law, or the nebulous mess that is trade secrets.  
(This is why stallman objects to the term "intellectual property", since 
there are several distinct islands that do not quite form a whole.  I 
personally find his perfectionist attitude to be unhelpful dealing with the 
real world, but this is nothing new...)

If you just understand the difference between a copyright and a license, 
you're ahead of most people.  Dual licensing, who can issue a license, what 
happens when license terms are not compatable, etc...  It's also probably a 
good idea to try to understand the first sale doctrine and fair use.  These 
are good fundamental limits on copyright.  (Trying to figure out how they 
apply online gives professional lawyers headaches, but keep in mind that the 
law is all about analogies.  Half of what lawyers do is find good analogies 
to convince a judge "this situation is just like X" while the other lawyer 
tries to convince them it's just like Y...)

You know, you could probably grab a business law textbook from your local 
community college's bookstore.  It'll have chapters on this written by 
somebody who knows what they're talking about.

Beyond that... Understanding what the law currently _is_ takes a bit of work.  
It's almost like trying to follow new kernel versions.  Some of the lawyers I 
know occasionally send me articles from findlaw's news section 
(news.findlaw.com), which I don't have time to follow myself.  Typing "gpl" 
into its news search thingy would almost certainly be interesting. :)

Oh, and don't take anything you find as an absolute.  Precedent isn't a 
guarantee, and what the law actually says can be bent amazingly with enough 
money (OJ Simpson, Dmitry Skylarov...)  You may find some marvelous thing 
that's in the wrong jurisdiction, etc.

This is a hobby every bit as complicated as programming.  When it comes to the 
law I strive to be a "power user", and even that's work...

P.S.  I'd guess that the right place to ask questions on all this is 
www.groklaw.com.  It can best be described as the geek law equivalent of 
slashdot.  It focuses on the SCO mess, and lots of lawyers hang out there.  
(Their standard disclaimer is IAALBIANYL:  I Am A Lawyer, But I Am Not Your 
Lawyer.)

Rob

RE: Linux GPL and binary module exception clause?

[David Schwartz]

> Notice? This is actually _exactly_ what I've been arguing all along,
> except I've been arguing with a technical audience, so I've been using
> technical examples and terminology. But my argument is that just the fact
> that somebody compiled the code for Linux into a binary module that is
> useless without a particular version of the kernel DOES MAKE IT A DERIVED
> WORK.

	So I'd need a license from Ford to make an aftermarket bumper. Their design
is protected by copyright and my bumper is useless without a Ford car. You
keep arguing for the type of world I don't want to live in. I really hope
you're wrong.

	DS

RE: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, David Schwartz wrote:
>
> I really hope you're wrong.

My opinion literally shouldn't matter to you.

You can do anything you want. But if you start linking with the kernel,
you should talk to your lawyer, because it is going to be _your_ problem
(not mine) if you're found to be in violation of copyright.

I'm trying to explain what is _clearly_ ok.

It is _clearly_ ok to make a module that is 100% GPL'd.

And it is _clearly_ ok to do anything you want with user space programs.

Everything else, you need to convince _your_ lawyers that it is ok before
you do it. They may say "go ahead". But you're not getting a "get out of
jail" card from _me_.

			Linus

Re: Linux GPL and binary module exception clause?

[Kendall Bennett]

Linus Torvalds <torvalds@osdl.org> wrote:

> Just imagine: distributing a compiled binary-only kernel module
> that can be loaded into the kernel is not like distributing a new
> book: it's more like distributing a extra chapter to a book that
> somebody else wrote, that uses all the same characters and the
> plot, but more importantly it literally can only be read _together_
> with the original work. It doesn't stand alone. 

So what if the chapter you wrote was generic enough that it *could* be 
used for different books? Maybe it couldn't be read alone (at least not 
with a small book the link the chapters to make logical sense), but it 
could be read as a whole along with lots of book.

In that case you would believe such a book would not be a derivative 
work, correct?

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: Linux GPL and binary module exception clause?

[Rob Landley]

On Wednesday 10 December 2003 10:34, Larry McVoy wrote:
> On Wed, Dec 10, 2003 at 08:21:52AM -0800, Linus Torvalds wrote:
> > There's a fundamental difference between "plugins" and "kernel modules":
> > intent.
>
> Which is?  How is it that you can spend a page of text saying a judge
> doesn't care about technicalities and then base the rest of your argument
> on the distinction between a "plugin" and a "kernel module"?

Because there are distinctions that aren't technicalities?

Strange but true...

Rob

(I'm driving 55 MPH on the freeway.  I'm driving 55 MPH in a 35 MPH zone.  I'm 
driving 55 MPH through the middle of a crowded shopping mall...  Same action, 
same tools, three different contexts.  One is legal, one gets you a ticket, 
one gets you serious jail time.  The law's full of this sort of thing...)

Re: Linux GPL and binary module exception clause?

[Geert Uytterhoeven]

On Thu, 11 Dec 2003, Rob Landley wrote:
> On Wednesday 10 December 2003 10:34, Larry McVoy wrote:
> > On Wed, Dec 10, 2003 at 08:21:52AM -0800, Linus Torvalds wrote:
> > > There's a fundamental difference between "plugins" and "kernel modules":
> > > intent.
> >
> > Which is?  How is it that you can spend a page of text saying a judge
> > doesn't care about technicalities and then base the rest of your argument
> > on the distinction between a "plugin" and a "kernel module"?
> 
> Because there are distinctions that aren't technicalities?
> 
> Strange but true...

Let's take a fresh look, from a historical perspective...

We had a GPLed kernel with (lots of) GPLed drivers. Even too many drivers,
since a kernel with all drivers enabled is too large to fit in 640 KiB! (of
course we elitist m68k users didn't suffer from that limitation ;-)

So someone solved this problem and found a way to reduce the kernel image size
below the magical limit by moving driver code to `loadable kernel modules'. A
nice side-effect was that people (read: distributors) now no longer needed a
bloated kernel that took ages to start during device probe. They could provide
a small kernel instead, with separate driver modules for all possible hardware,
to be loaded at boot time or on demand.

Hence technically loadable kernel modules are just a work-around to allow
larger kernels, and all loadable kernel code should be treated the same as
in-kernel code. So they are clearly derived from the kernel.

Later people started to realize that:
  (a) They can build out-of-tree modules, i.e. drivers that can't even be built
      in,
  (b) They can build out-of-tree modules and make them non-GPL.

And (b) is where the problem started...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Linux GPL and binary module exception clause?

[Oliver Hunt]

Linus Torvalds wrote:
...
> There's a fundamental difference between "plugins" and "kernel modules":
> intent.
> 
...

The key difference between a plugin and a module(from my understanding 
of plugins in browser/application sense) is how information is passed.

Says we have the flash plugin for some random browser, say BrowserApp 
1.01, now the browser comes across a flash file, now it calls the flash 
plugin, passing both the file, and the graphics context the plugin can 
draw to.  Flash does it's rendering and then shoves it's output to the 
canvas: that's all it can do, it may make a request (say, 
browser::getURL) but that's about it, and the browser can always ignore it.

Now there is competitor to BrowserApp known as BrowserOS, instead of 
plugins it has modules.  Now, when BrowserOS comes across a flash file 
it loads it's flash module and passes the url, at which point the module 
takes over, and allocates a graphics context for it to draw to(see it 
controls what happens, rather than the otherway round).  Now say the 
module wants to load a webpage it now tells the address bar to change, 
then it makes internal changes (loads the new url, etc), that the 
browser _cannot_ stop, it is effectively part of the program...

--Oliver

RE: Linux GPL and binary module exception clause?

[Hua Zhong]

> The inlines have nothing to do with _anything_.
> 
> Trust me, a federal judge couldn't care less about some very esoteric
> technical detail. I don't know who brought up inline 
> functions, but they aren't what would force the GPL.

Great!

> What has meaning for "derived work" is whether it stands on its own or
> not, and how tightly integrated it is. If something works 
> with just one particular version of the kernel - or depends on things
like 
> whether the kernel was compiled with certain options etc - then it
pretty 
> clearly is very tightly integrated.

Many userspace programs fall into this category too. For example they
depend on /proc to be there. They probably only work with a certain
version of the kernel because the next version changed some format in
/proc.

Is /proc a stable API/ABI? Yes? No?

> Don't think that copyright would depend on any technicalities.
> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

RE: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Hua Zhong wrote:
>
> > What has meaning for "derived work" is whether it stands on its own or
> > not, and how tightly integrated it is. If something works
> > with just one particular version of the kernel - or depends on things like
> > whether the kernel was compiled with certain options etc - then it pretty
> > clearly is very tightly integrated.
>
> Many userspace programs fall into this category too.

Absolutely.

Trust me, REAL LAWYERS WERE WORRIED about this. It wasn't just random tech
people discussing issues on a technical (or, right now, not-so-technical)
mailing list.

There's a reason for those lines at the top of the COPYING file saying
that user space is not covered, and there are literally lawyers who say it
would hold up in a court of law.

Exactly because you _can_ argue that user-space might be covered. It's an
argument that almost certainly would fail very quickly due to "documented
interfaces" and ABI issues, but it is an argument that lawyers have made,
and it's that argument that makes the disclaimer in COPYING be worth it.

In other words: even without that disclaimer of derivation, user space
would almost certainly (with a very high probability indeed) be safe from
a copyright infringement suit. Such a suit would most likely be thrown out
very early, exactly because the UNIX system call interface is clearly
extensively documented, and the Linux implementation of it has strived to
be a stable ABI for a long time.

In fact, a user program written in 1991 is actually still likely to run,
if it doesn't do a lot of special things. So user programs really are a
hell of a lot more insulated than kernel modules, which have been known to
break weekly.

Similarly, things like /proc etc are clearly intended to be ways to
interface to the kernel in user space, so there's a clear intent there
that nobody can reasonably deny (again, that intent is made _clearer_ by
the COPYING disclaimer, but it would be hard to argue against even in the
absense of that).

But even DESPITE these strong arguments that user-space clearly isn't a
derived work, and real lawyers worried, and felt much happier with the
explicit disclaimer in the COPYING file.

That should tell you something. In particular, it should tell you to be
careful: some courts have made so broad "derivative work" judgements that
it's scary - think about the "Gone With the Wind" parody (I think the
ruling was eventually overturned on First Amendment grounds, but the
point is that you should be very careful, and while source code has
the potential for First Amendment protection, binary modules sure as hell
do not).

And please note that I am _not_ arguing for those overly broad judgements:
I'm just pointing out that you should not assume that "derivative" is
something simple. If an author claims your work is derivative, you should
step very very lightly.

And I claim that binary-only kernel modules ARE derivative "by default",
by virtue of having no meaning without the kernel.

		Linus

RE: Linux GPL and binary module exception clause?

[Andre Hedrick]

Linus,

How can the additional words alter the mean of GPL itself?
I am not baiting this time.  Does the simple addition of your meaning
imposed create an effective restriction?  Does that applied meaning make
the kernel license invalid for all?  I am sure there were no changes in
the text of the COPYING file, but the additions to the "coyrighted" file
appears to alter intent.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Wed, 10 Dec 2003, Linus Torvalds wrote:

> 
> 
> On Wed, 10 Dec 2003, Hua Zhong wrote:
> >
> > > What has meaning for "derived work" is whether it stands on its own or
> > > not, and how tightly integrated it is. If something works
> > > with just one particular version of the kernel - or depends on things like
> > > whether the kernel was compiled with certain options etc - then it pretty
> > > clearly is very tightly integrated.
> >
> > Many userspace programs fall into this category too.
> 
> Absolutely.
> 
> Trust me, REAL LAWYERS WERE WORRIED about this. It wasn't just random tech
> people discussing issues on a technical (or, right now, not-so-technical)
> mailing list.
> 
> There's a reason for those lines at the top of the COPYING file saying
> that user space is not covered, and there are literally lawyers who say it
> would hold up in a court of law.
> 
> Exactly because you _can_ argue that user-space might be covered. It's an
> argument that almost certainly would fail very quickly due to "documented
> interfaces" and ABI issues, but it is an argument that lawyers have made,
> and it's that argument that makes the disclaimer in COPYING be worth it.
> 
> In other words: even without that disclaimer of derivation, user space
> would almost certainly (with a very high probability indeed) be safe from
> a copyright infringement suit. Such a suit would most likely be thrown out
> very early, exactly because the UNIX system call interface is clearly
> extensively documented, and the Linux implementation of it has strived to
> be a stable ABI for a long time.
> 
> In fact, a user program written in 1991 is actually still likely to run,
> if it doesn't do a lot of special things. So user programs really are a
> hell of a lot more insulated than kernel modules, which have been known to
> break weekly.
> 
> Similarly, things like /proc etc are clearly intended to be ways to
> interface to the kernel in user space, so there's a clear intent there
> that nobody can reasonably deny (again, that intent is made _clearer_ by
> the COPYING disclaimer, but it would be hard to argue against even in the
> absense of that).
> 
> But even DESPITE these strong arguments that user-space clearly isn't a
> derived work, and real lawyers worried, and felt much happier with the
> explicit disclaimer in the COPYING file.
> 
> That should tell you something. In particular, it should tell you to be
> careful: some courts have made so broad "derivative work" judgements that
> it's scary - think about the "Gone With the Wind" parody (I think the
> ruling was eventually overturned on First Amendment grounds, but the
> point is that you should be very careful, and while source code has
> the potential for First Amendment protection, binary modules sure as hell
> do not).
> 
> And please note that I am _not_ arguing for those overly broad judgements:
> I'm just pointing out that you should not assume that "derivative" is
> something simple. If an author claims your work is derivative, you should
> step very very lightly.
> 
> And I claim that binary-only kernel modules ARE derivative "by default",
> by virtue of having no meaning without the kernel.
> 
> 		Linus
> 

Re: Linux GPL and binary module exception clause?

[Jason Kingsland]

"Andre Hedrick" wrote:

> How can the additional words alter the mean of GPL itself?

Because if the additional words in the license predate the publishing date
of the code, they form a valid part of the license for that code as
published.


So the answer to whether such a clause in valid and enforceable (rather than
just Linus' opinion) depends on when any particular piece of code was first
submitted publicly into the kernel tree, who the copyright holder is
(usually the author) and hence which license prevailed at the time the code
was first published.

Later changes to a license are not retroactive to earlier publications
unless the original copyright holder agrees - as only the copyright holder
can change the terms of any license after publication.

The readme for Linux version 0.1 had the copyright owned by Linus and was
not licensed under GPL at all:

"
This kernel is (C) 1991 Linus Torvalds, but all or part of it may be
redistributed provided you do the following:

	- Full source must be available (and free), if not with the
	  distribution then at least on asking for it.

	- Copyright notices must be intact. (In fact, if you distribute
	  only parts of it you may have to add copyrights, as there aren't
	  (C)'s in all files.) Small partial excerpts may be copied
	  without bothering with copyrights.

	- You may not distibute this for a fee, not even "handling" costs.
"

This changed in Version 0.12 with the following statement of intent:

"
The Linux copyright will change: I've had a couple of requests to make
it compatible with the GNU copyleft, removing the "you may not
distribute it for money" condition.  I agree.  I propose that the
copyright be changed so that it confirms to GNU - pending approval of
the persons who have helped write code.  I assume this is going to be no
problem for anybody: If you have grievances ("I wrote that code assuming
the copyright would stay the same") mail me.  Otherwise The GNU copyleft
takes effect as of the first of February.  If you do not know the gist
of the GNU copyright - read it.
"

The next major release was v0.95 in March 1992 which contained a reference
to GPL with this clarification:

"
NOTE! The linux unistd library-functions (the low-level interface to
linux: system calls etc) are excempt from the copyright - you may use
them as you wish, and using those in your binary files won't mean that
your files are automatically under the GNU copyleft.  This concerns
/only/ the unistd-library and those (few) other library functions I have
written: most of the rest of the library has it's own copyrights (or is
public domain).  See the library sources for details of those.
"

For release 0.99 the clarification was missing, with just a standard GPL V2
being used for releases up to 0.99.11 when the (in)famous disclaimer about
user programs was added:

"
 NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the linux
 kernel) is copyrighted by me and others who actually wrote it.

   Linus Torvalds
"

and then it stayed constant until 2.4 when the GPL V2-only clause was added:

"
 Also note that the only valid version of the GPL as far as the kernel
 is concerned is _this_ license (ie v2), unless explicitly otherwise
 stated.

"

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Jason,

Nice bit of research!  Hat tip to you, just close your eyes so the glare
off my balding head does not blind you :-)

This is so much fun!

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Wed, 10 Dec 2003, Jason Kingsland wrote:

> 
> "Andre Hedrick" wrote:
> 
> > How can the additional words alter the mean of GPL itself?
> 
> Because if the additional words in the license predate the publishing date
> of the code, they form a valid part of the license for that code as
> published.
> 
> 
> So the answer to whether such a clause in valid and enforceable (rather than
> just Linus' opinion) depends on when any particular piece of code was first
> submitted publicly into the kernel tree, who the copyright holder is
> (usually the author) and hence which license prevailed at the time the code
> was first published.
> 
> Later changes to a license are not retroactive to earlier publications
> unless the original copyright holder agrees - as only the copyright holder
> can change the terms of any license after publication.
> 
> The readme for Linux version 0.1 had the copyright owned by Linus and was
> not licensed under GPL at all:
> 
> "
> This kernel is (C) 1991 Linus Torvalds, but all or part of it may be
> redistributed provided you do the following:
> 
> 	- Full source must be available (and free), if not with the
> 	  distribution then at least on asking for it.
> 
> 	- Copyright notices must be intact. (In fact, if you distribute
> 	  only parts of it you may have to add copyrights, as there aren't
> 	  (C)'s in all files.) Small partial excerpts may be copied
> 	  without bothering with copyrights.
> 
> 	- You may not distibute this for a fee, not even "handling" costs.
> "
> 
> This changed in Version 0.12 with the following statement of intent:
> 
> "
> The Linux copyright will change: I've had a couple of requests to make
> it compatible with the GNU copyleft, removing the "you may not
> distribute it for money" condition.  I agree.  I propose that the
> copyright be changed so that it confirms to GNU - pending approval of
> the persons who have helped write code.  I assume this is going to be no
> problem for anybody: If you have grievances ("I wrote that code assuming
> the copyright would stay the same") mail me.  Otherwise The GNU copyleft
> takes effect as of the first of February.  If you do not know the gist
> of the GNU copyright - read it.
> "
> 
> The next major release was v0.95 in March 1992 which contained a reference
> to GPL with this clarification:
> 
> "
> NOTE! The linux unistd library-functions (the low-level interface to
> linux: system calls etc) are excempt from the copyright - you may use
> them as you wish, and using those in your binary files won't mean that
> your files are automatically under the GNU copyleft.  This concerns
> /only/ the unistd-library and those (few) other library functions I have
> written: most of the rest of the library has it's own copyrights (or is
> public domain).  See the library sources for details of those.
> "
> 
> For release 0.99 the clarification was missing, with just a standard GPL V2
> being used for releases up to 0.99.11 when the (in)famous disclaimer about
> user programs was added:
> 
> "
>  NOTE! This copyright does *not* cover user programs that use kernel
>  services by normal system calls - this is merely considered normal use
>  of the kernel, and does *not* fall under the heading of "derived work".
>  Also note that the GPL below is copyrighted by the Free Software
>  Foundation, but the instance of code that it refers to (the linux
>  kernel) is copyrighted by me and others who actually wrote it.
> 
>    Linus Torvalds
> "
> 
> and then it stayed constant until 2.4 when the GPL V2-only clause was added:
> 
> "
>  Also note that the only valid version of the GPL as far as the kernel
>  is concerned is _this_ license (ie v2), unless explicitly otherwise
>  stated.
> 
> "
> 
> 

RE: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Andre Hedrick wrote:
>
> How can the additional words alter the mean of GPL itself?

They can't.

But they _can_ alter your ability to sue. In particular, if you publicly
state that you will not sue anybody over something, they can now use that
statement to make future plans. If at a later date you decide to sue them
anyway, they can point the judge at your earlier statement, and claim
estoppel against you.

So note how the license itself didn't change - but your ability to
_enforce_ the license has changed by virtue of you stating that you won't.

So while I publicaly say that I'm a lazy bastard, and the less I have to
do with lawyers, the better - I won't actually say that I will never sue
anybody. I'll say that it is "unlikely", or that people would have to
irritate me mightily.

For most developers that literally doesn't much matter what they say. Even
when _I_ say something, that doesn't really matter to what other
developers do, and while it could potentially limit me from enforcing _my_
copyrights, it doesn't stop others from enforcing theirs. So my random
email ramblings should really be construed as my opinions rather than any
legally relevant stuff.

However, the few extra lines in the main COPYING file end up being
somewhat binding to others, simply because they are _so_ public (they are,
after all, in the _main_ COPYING file) and they have been there pretty
much since the beginning, that they would basically end up being a very
strong argument in any legal case where some random kernel developer would
try to argue that it doesn't cover "their" code.

You don't have to agree to them, btw - you can remove them from the copy
of Linux you distribute, since the GPL in no way requires you to keep
them. They're not part of the copyright license per se, they are expressly
marked as being my personal viewpoint.  I suspect that if you do, you'll
find companies that would be slightly more nervous to work with you,
though.

But nobody has really ever argued against the clause, even originally. And
in this particular discussion, I don't believe anybody is actually arguing
against it now either. The legal meaning of it may be under discussion,
but I don't think anybody is really even _trying_ to argue that it should
be removed and that we should suddenly try to claim that any future user
programs have to be GPL'd.

Quite the reverse - I think everybody involved would argue that that would
just be crazy talk.

			Linus

RE: Linux GPL and binary module exception clause?

[Andre Hedrick]

Linus:

Oh great!

> So while I publicaly say that I'm a lazy bastard, and the less I have to
> do with lawyers, the better - I won't actually say that I will never sue
> anybody. I'll say that it is "unlikely", or that people would have to
> irritate me mightily.

So what did you want for Christmas this year :-?

Maybe I should stop now because I have history of being able to "irritate
you mightily" !!!

You know me from our conversions offline and in person, and enough said
there.  There are times when I am a classic BOHA and other when I a
serious and cold.  You know my intent, and that is all that needs to be
said.

What I really want, is a better License for all.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Wed, 10 Dec 2003, Linus Torvalds wrote:

> 
> 
> On Wed, 10 Dec 2003, Andre Hedrick wrote:
> >
> > How can the additional words alter the mean of GPL itself?
> 
> They can't.
> 
> But they _can_ alter your ability to sue. In particular, if you publicly
> state that you will not sue anybody over something, they can now use that
> statement to make future plans. If at a later date you decide to sue them
> anyway, they can point the judge at your earlier statement, and claim
> estoppel against you.
> 
> So note how the license itself didn't change - but your ability to
> _enforce_ the license has changed by virtue of you stating that you won't.
> 
> So while I publicaly say that I'm a lazy bastard, and the less I have to
> do with lawyers, the better - I won't actually say that I will never sue
> anybody. I'll say that it is "unlikely", or that people would have to
> irritate me mightily.
> 
> For most developers that literally doesn't much matter what they say. Even
> when _I_ say something, that doesn't really matter to what other
> developers do, and while it could potentially limit me from enforcing _my_
> copyrights, it doesn't stop others from enforcing theirs. So my random
> email ramblings should really be construed as my opinions rather than any
> legally relevant stuff.
> 
> However, the few extra lines in the main COPYING file end up being
> somewhat binding to others, simply because they are _so_ public (they are,
> after all, in the _main_ COPYING file) and they have been there pretty
> much since the beginning, that they would basically end up being a very
> strong argument in any legal case where some random kernel developer would
> try to argue that it doesn't cover "their" code.
> 
> You don't have to agree to them, btw - you can remove them from the copy
> of Linux you distribute, since the GPL in no way requires you to keep
> them. They're not part of the copyright license per se, they are expressly
> marked as being my personal viewpoint.  I suspect that if you do, you'll
> find companies that would be slightly more nervous to work with you,
> though.
> 
> But nobody has really ever argued against the clause, even originally. And
> in this particular discussion, I don't believe anybody is actually arguing
> against it now either. The legal meaning of it may be under discussion,
> but I don't think anybody is really even _trying_ to argue that it should
> be removed and that we should suddenly try to claim that any future user
> programs have to be GPL'd.
> 
> Quite the reverse - I think everybody involved would argue that that would
> just be crazy talk.
> 
> 			Linus
> 

RE: Linux GPL and binary module exception clause?

[Kendall Bennett]

Linus Torvalds <torvalds@osdl.org> wrote:

> In fact, a user program written in 1991 is actually still likely
> to run, if it doesn't do a lot of special things. So user programs
> really are a hell of a lot more insulated than kernel modules,
> which have been known to break weekly. 

IMHO (and IANAL of course), it seems a bit tenuous to me the argument 
that just because you deliberating break compatibility at the module 
level on a regular basis, that they are automatically derived works. 
Clearly the module interfaces could be stabilised and published, and if 
you consider the instance of a single kernel version in time, that module 
ABI *is* published and *is* stable *for that version*. Just because you 
make an active effort to change things and actively *not* document the 
ABI other than in the source code across kernel versions, doesn't 
automatically make a module a derived work. 

IMHO anyway.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: Linux GPL and binary module exception clause?

[viro]

On Wed, Dec 10, 2003 at 11:48:45AM -0800, Kendall Bennett wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> 
> > In fact, a user program written in 1991 is actually still likely
> > to run, if it doesn't do a lot of special things. So user programs
> > really are a hell of a lot more insulated than kernel modules,
> > which have been known to break weekly. 
> 
> IMHO (and IANAL of course), it seems a bit tenuous to me the argument 
> that just because you deliberating break compatibility at the module 
> level on a regular basis, that they are automatically derived works. 
> Clearly the module interfaces could be stabilised and published, and if 
> you consider the instance of a single kernel version in time, that module 
> ABI *is* published and *is* stable *for that version*. Just because you 
> make an active effort to change things and actively *not* document the 
> ABI other than in the source code across kernel versions, doesn't 
> automatically make a module a derived work. 

Oh, for crying out loud!  Had you ever looked at that "API"?

At least 90% of it are random functions exposing random details of internals.
Most of them are there only because some in-tree piece of code had been
"modularized".  Badly.

Due to the dumb mechanism used to export symbols, each of those layering
violations automatically becomes available to all modules.  And they outnumber
the things that could be reasonably considered as something resembling an
API.  Outnumber by order of magnitude.

The problem had been festering for almost a decade now, and external modules
also didn't help things - a lot of them contained layering violations of their
own and asked to export this, this and that.  With no explanation offered and
too little resistance met.

In 2.7 we need to get the export list back to sanity.  Right now it's a such
a junkpile that speaking about even a relative stability for it...  Not funny.

Re: Linux GPL and binary module exception clause?

[Kendall Bennett]

viro@parcelfarce.linux.theplanet.co.uk wrote:

> On Wed, Dec 10, 2003 at 11:48:45AM -0800, Kendall Bennett wrote:
> > Linus Torvalds <torvalds@osdl.org> wrote:
> > 
> > > In fact, a user program written in 1991 is actually still likely
> > > to run, if it doesn't do a lot of special things. So user programs
> > > really are a hell of a lot more insulated than kernel modules, which
> > > have been known to break weekly. 
> > 
> > IMHO (and IANAL of course), it seems a bit tenuous to me the argument
> > that just because you deliberating break compatibility at the module
> > level on a regular basis, that they are automatically derived works.
> > Clearly the module interfaces could be stabilised and published, and if
> > you consider the instance of a single kernel version in time, that
> > module ABI *is* published and *is* stable *for that version*. Just
> > because you make an active effort to change things and actively *not*
> > document the ABI other than in the source code across kernel versions,
> > doesn't automatically make a module a derived work. 
> 
> Oh, for crying out loud!  Had you ever looked at that "API"?
> 
> At least 90% of it are random functions exposing random details of
> internals. Most of them are there only because some in-tree piece
> of code had been "modularized".  Badly. 

The fact that an API is 'badly' implemented does not detract from the 
fact that it is an API. It is still published as the mechanism that a 
module would use to load and interface to the kernel, via that API.

> In 2.7 we need to get the export list back to sanity.  Right now it's a
> such a junkpile that speaking about even a relative stability for it... 
> Not funny. 

You miss my point. I was talking about a single kernel version. For a 
single kernel version, the ABI is both *published* and *stable*. Sure it 
may not be what you consider a *clean* or *good* ABI, but it *IS* an ABI. 
Note that:

1. It is a published ABI because for that one kernel release, all the 
source code is available that documents the ABI (albiet badly IYO).

2. It is stable because that kernel version will never change on your 
machine.

Given that it is a stable and published ABI for a single kernel version, 
then what makes a kernel module different from a user program? The fact 
that binary only modules are *only* guaranteed to work with one single 
kernel version, the fact that the ABI changes from version to version is 
completely irrelevant to determing whether a binary module is derived 
from the kernel or not.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: Linux GPL and binary module exception clause?

[viro]

On Wed, Dec 10, 2003 at 02:36:46PM -0800, Kendall Bennett wrote:
 
> > In 2.7 we need to get the export list back to sanity.  Right now it's a
> > such a junkpile that speaking about even a relative stability for it... 
> > Not funny. 
> 
> You miss my point. I was talking about a single kernel version. For a 
> single kernel version, the ABI is both *published* and *stable*. Sure it 
> may not be what you consider a *clean* or *good* ABI, but it *IS* an ABI. 

The hell it is.  Change CONFIG_SMP or any number of other options and your
binary compatibility is toast.

> Given that it is a stable and published ABI for a single kernel version, 
> then what makes a kernel module different from a user program? The fact 

The utter lack of isolation in the former.  And that's a very practical
consideration - amount of efforts needed to tell whether any given bug is
in kernel or in an application is *way* less than for module vs. kernel.
Ditto for potential impact of changes on one side of "interface" upon the
other side.

Realistically there's no way to keep the module "API" fixed without a major
negative impact on kernel development, security and stability.  If somebody
has business model based on the expectation that this "API" will not be
changed whenever we find that useful - too bad, you can't possibly claim
that you had not been warned.

Again, lack of warranties regarding the module "API" is
	* deliberate
	* well-documented
	* older than binary-only modules
	* based on the very sound technical reasons

Live with it.  It's not going to change.

Of course some parts of the "API" are relatively stable; if nothing else,
we have in-tree drivers to consider whenever we make a change and well-behaving
3rd-party module won't take more efforts to update than a typical in-tree
driver.  But that's it - author of such module basically makes an educated
guess regarding the likeliness of change that would leave him in a bad
situation.  Generally, the deeper in kernel guts you play, the easier it
is to get burned.  And current set of exports goes very deep in said guts -
much deeper than it should have.

Anybody who does out-of-tree kernel work must understand the reality.
Modules are different from userland code in the ways that deeply affect
product cycle.  Pretending that there is no fundamental difference and
complaining about that difference signifies only one thing - lack of
basic research on part of complainers.  Don't pretend that you don't know
what you are getting into.

Re: Linux GPL and binary module exception clause?

[Jesse Pollard]

On Wednesday 10 December 2003 16:36, Kendall Bennett wrote:
> viro@parcelfarce.linux.theplanet.co.uk wrote:
> > On Wed, Dec 10, 2003 at 11:48:45AM -0800, Kendall Bennett wrote:
> > > Linus Torvalds <torvalds@osdl.org> wrote:
> > > > In fact, a user program written in 1991 is actually still likely
> > > > to run, if it doesn't do a lot of special things. So user programs
> > > > really are a hell of a lot more insulated than kernel modules, which
> > > > have been known to break weekly.
> > >
> > > IMHO (and IANAL of course), it seems a bit tenuous to me the argument
> > > that just because you deliberating break compatibility at the module
> > > level on a regular basis, that they are automatically derived works.
> > > Clearly the module interfaces could be stabilised and published, and if
> > > you consider the instance of a single kernel version in time, that
> > > module ABI *is* published and *is* stable *for that version*. Just
> > > because you make an active effort to change things and actively *not*
> > > document the ABI other than in the source code across kernel versions,
> > > doesn't automatically make a module a derived work.
> >
> > Oh, for crying out loud!  Had you ever looked at that "API"?
> >
> > At least 90% of it are random functions exposing random details of
> > internals. Most of them are there only because some in-tree piece
> > of code had been "modularized".  Badly.
>
> The fact that an API is 'badly' implemented does not detract from the
> fact that it is an API. It is still published as the mechanism that a
> module would use to load and interface to the kernel, via that API.
>
> > In 2.7 we need to get the export list back to sanity.  Right now it's a
> > such a junkpile that speaking about even a relative stability for it...
> > Not funny.
>
> You miss my point. I was talking about a single kernel version. For a
> single kernel version, the ABI is both *published* and *stable*. Sure it
> may not be what you consider a *clean* or *good* ABI, but it *IS* an ABI.
> Note that:
>
> 1. It is a published ABI because for that one kernel release, all the
> source code is available that documents the ABI (albiet badly IYO).
>
> 2. It is stable because that kernel version will never change on your
> machine.

Huh? I frequently update the kernel, and the kernel minor version... as
well as switch from uniprocessor to SMP. The major version may not change,
but that minor one certanly does. And adding SMP changes the ABI for
that version. And patches CAN and DO change the ABI, even within the
major version.

> Given that it is a stable and published ABI for a single kernel version,
> then what makes a kernel module different from a user program? The fact
> that binary only modules are *only* guaranteed to work with one single
> kernel version, the fact that the ABI changes from version to version is
> completely irrelevant to determing whether a binary module is derived
> from the kernel or not.

How do you handle the differences in a single version for something like
SMP? It is still the same version, but a binary driver for SMP will most
likely NOT work on uniprocessor, and even more likey not work if compiled
for a uniprocessor under SMP.

Re: Linux GPL and binary module exception clause?

[Kendall Bennett]

Jesse Pollard <jesse@cats-chateau.net> wrote:

> > You miss my point. I was talking about a single kernel version. For a
> > single kernel version, the ABI is both *published* and *stable*. Sure it
> > may not be what you consider a *clean* or *good* ABI, but it *IS* an
> > ABI. Note that:
> >
> > 1. It is a published ABI because for that one kernel release, all the
> > source code is available that documents the ABI (albiet badly IYO).
> >
> > 2. It is stable because that kernel version will never change on your
> > machine.
> 
> Huh? I frequently update the kernel, and the kernel minor version... as
> well as switch from uniprocessor to SMP. The major version may not change,
> but that minor one certanly does. And adding SMP changes the ABI for that
> version. And patches CAN and DO change the ABI, even within the major
> version.

So what? You don't change it on *MY* machine, now do you? *MY* version 
remains stable regardless of what *YOU* do unless I update my source 
code.

> How do you handle the differences in a single version for
> something like SMP? It is still the same version, but a binary
> driver for SMP will most likely NOT work on uniprocessor, and even
> more likey not work if compiled for a uniprocessor under SMP. 

No, it is not the same version. One is the UNI version and one is the SMP 
version. By version of kernel I mean the version of the binary that I am 
building the loadable module to work with. You can just consider the 
UNI/SMP support to be an extension of the version and treat them as 
different versions (after all, you will need two separate modules to 
handle this anyway).

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: Linux GPL and binary module exception clause?

[Nick Piggin]

Kendall Bennett wrote:

>Jesse Pollard <jesse@cats-chateau.net> wrote:
>
>
>>>You miss my point. I was talking about a single kernel version. For a
>>>single kernel version, the ABI is both *published* and *stable*. Sure it
>>>may not be what you consider a *clean* or *good* ABI, but it *IS* an
>>>ABI. Note that:
>>>
>>>1. It is a published ABI because for that one kernel release, all the
>>>source code is available that documents the ABI (albiet badly IYO).
>>>
>>>2. It is stable because that kernel version will never change on your
>>>machine.
>>>
>>Huh? I frequently update the kernel, and the kernel minor version... as
>>well as switch from uniprocessor to SMP. The major version may not change,
>>but that minor one certanly does. And adding SMP changes the ABI for that
>>version. And patches CAN and DO change the ABI, even within the major
>>version.
>>
>
>So what? You don't change it on *MY* machine, now do you? *MY* version 
>remains stable regardless of what *YOU* do unless I update my source 
>code.
>

Linus doesn't change it on *YOUR* machine either, when he releases a new
kernel. You do when you pull his changes. The point is the difficulty from
a module distributor's point of view.

Re: Linux GPL and binary module exception clause?

[Jesse Pollard]

On Thursday 11 December 2003 12:47, Kendall Bennett wrote:
> Jesse Pollard <jesse@cats-chateau.net> wrote:
> > > You miss my point. I was talking about a single kernel version. For a
> > > single kernel version, the ABI is both *published* and *stable*. Sure
> > > it may not be what you consider a *clean* or *good* ABI, but it *IS* an
> > > ABI. Note that:
> > >
> > > 1. It is a published ABI because for that one kernel release, all the
> > > source code is available that documents the ABI (albiet badly IYO).
> > >
> > > 2. It is stable because that kernel version will never change on your
> > > machine.
> >
> > Huh? I frequently update the kernel, and the kernel minor version... as
> > well as switch from uniprocessor to SMP. The major version may not
> > change, but that minor one certanly does. And adding SMP changes the ABI
> > for that version. And patches CAN and DO change the ABI, even within the
> > major version.
>
> So what? You don't change it on *MY* machine, now do you? *MY* version
> remains stable regardless of what *YOU* do unless I update my source
> code.

You won't be able to update it... Even in the face of real problems that
must be updated (as in a major security problem).

> > How do you handle the differences in a single version for
> > something like SMP? It is still the same version, but a binary
> > driver for SMP will most likely NOT work on uniprocessor, and even
> > more likey not work if compiled for a uniprocessor under SMP.
>
> No, it is not the same version. One is the UNI version and one is the SMP
> version. By version of kernel I mean the version of the binary that I am
> building the loadable module to work with. You can just consider the
> UNI/SMP support to be an extension of the version and treat them as
> different versions (after all, you will need two separate modules to
> handle this anyway).

According to the kernel it is the same version - the binary module loaded, it
just doesn't work. And no way to get it working either.

This also applies to other minor options - like AMD optimizations, PII/P3/P4
optimizations... They all run the same Kernel version... Even when they are
uniprocessor only...

So now you ALSO have to have that third party to distribute BINARY versions
of the kernel to make that binary driver work. And you can't make any
changes.. because that may/would break the system... You can no longer
upgrade your system. You might be able to go from P2 to p3, but if the
driver was built for p3, expect problems on a p2.

And blow it out your ear if you want an IA64, or even a 64 bit AMD.

And you don't even know what options that third party used in building their
kernel, and can't create an equivalent...

And forget trying to get any help for a problem. Especially if there are
two such modules you need... If you think the finger pointing is bad now,
think about what happens then.

Which is why I don't buy, nor even recommend, devices that reqire closed
source drivers.

There are just too many combinations of options that make a single (or even
limited number of) version(s) of a binary module either unusable or
unsupportable.

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Wed, Dec 10, 2003 at 11:48:45AM -0800, Kendall Bennett wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> 
> > In fact, a user program written in 1991 is actually still likely
> > to run, if it doesn't do a lot of special things. So user programs
> > really are a hell of a lot more insulated than kernel modules,
> > which have been known to break weekly. 
> 
> IMHO (and IANAL of course), it seems a bit tenuous to me the argument 
> that just because you deliberating break compatibility at the module 
> level on a regular basis, that they are automatically derived works. 

Not only that, I think the judge would have something to say about the 
fact that the modules interface is delibrately changed all the time 
with stated intent of breaking binary drivers.  In fact, Linus pointed
out his thoughts on what the judge would say:

    In fact, I will bet you that if the judge thinks that you tried to
    use technicalities ("your honour, I didn't actually run the 'ln'
    program, instead of wrote a shell script for the _user_ to run the
    'ln' program for me"), that judge will just see that as admission
    of the fact that you _knew_ you were doing something bad.

Why is it that the judge wouldn't see the delibrate changing of the
interfaces, the EXPORT_GPL stuff, all of that as a way to delibrately
force something that wouldn't otherwise be a derived work into a 
derived work category?
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Larry,

You have a strong grap of the obvious :-)
I wish more of the meatball could have such a strong grip.
2.6 is setting itself up to fall hard on the back edge of the sword.

"Made you Look" is not much use if it is published, because it is now a
public record.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Wed, 10 Dec 2003, Larry McVoy wrote:

> On Wed, Dec 10, 2003 at 11:48:45AM -0800, Kendall Bennett wrote:
> > Linus Torvalds <torvalds@osdl.org> wrote:
> > 
> > > In fact, a user program written in 1991 is actually still likely
> > > to run, if it doesn't do a lot of special things. So user programs
> > > really are a hell of a lot more insulated than kernel modules,
> > > which have been known to break weekly. 
> > 
> > IMHO (and IANAL of course), it seems a bit tenuous to me the argument 
> > that just because you deliberating break compatibility at the module 
> > level on a regular basis, that they are automatically derived works. 
> 
> Not only that, I think the judge would have something to say about the 
> fact that the modules interface is delibrately changed all the time 
> with stated intent of breaking binary drivers.  In fact, Linus pointed
> out his thoughts on what the judge would say:
> 
>     In fact, I will bet you that if the judge thinks that you tried to
>     use technicalities ("your honour, I didn't actually run the 'ln'
>     program, instead of wrote a shell script for the _user_ to run the
>     'ln' program for me"), that judge will just see that as admission
>     of the fact that you _knew_ you were doing something bad.
> 
> Why is it that the judge wouldn't see the delibrate changing of the
> interfaces, the EXPORT_GPL stuff, all of that as a way to delibrately
> force something that wouldn't otherwise be a derived work into a 
> derived work category?
> -- 
> ---
> Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm
> 

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Larry McVoy wrote:
>
> Not only that, I think the judge would have something to say about the
> fact that the modules interface is delibrately changed all the time
> with stated intent of breaking binary drivers.

Where do you people _find_ these ideas?

We don't "deliberately change the interfaces to make modules harder".

Rather, we deliberately don't _care_ about binary modules, exactly because
we have documented several times that it IS NOT AN API.

So what we do is to change the interfaces when it makes sense to change
them (ie we do have a real reason to do so), and we deliberately make
people AWARE of this fact.

See the difference?

The internal kernel module interface is clearly documented to be
_internal_ over several years of discussions (this particular discussion
seems to come up once every year or so). It's not an API, and never has
been.

But we don't change the interfaces just to be difficult.

			Linus

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Wed, Dec 10, 2003 at 03:38:02PM -0800, Linus Torvalds wrote:
> On Wed, 10 Dec 2003, Larry McVoy wrote:
> > Not only that, I think the judge would have something to say about the
> > fact that the modules interface is delibrately changed all the time
> > with stated intent of breaking binary drivers.
> 
> Where do you people _find_ these ideas?

Oh, I don't know, years of reading this list maybe?  Come on, Linus,
do you really need me to go surfing around to find all the postings to
the list where people were saying that's why change is good?  I *know*
you have said it.  Don't play dumb, you have and you know it.

Yeah, you have said that part of it is that you retain the right to
fix things that need to be fixed and that part I agree with 100%.
Broken interfaces suck and fixing them should be your right.  Agreed.
But is that all?  I don't think so and I've been here for 10 years.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Ingo Molnar]

On Wed, 10 Dec 2003, Larry McVoy wrote:

> > > Not only that, I think the judge would have something to say about the
> > > fact that the modules interface is delibrately changed all the time
> > > with stated intent of breaking binary drivers.
> > 
> > Where do you people _find_ these ideas?
> 
> Oh, I don't know, years of reading this list maybe?  Come on, Linus, do
> you really need me to go surfing around to find all the postings to the
> list where people were saying that's why change is good?  I *know* you
> have said it.  Don't play dumb, you have and you know it.

i challenge you to find such posts. What maybe might have happened is that
someone said "dont change this, it changes the module API" then someone
else said "that is not a good reason at all" - which is a perfectly
correct position. Maybe sometimes an interface was changed (or even
removed) because modules used it in a really unsafe way that lead to many
bogus bugreports and stability problems. I cant remember any instance of
pure "hey, lets change this function for fun and for breaking binary
modules".

i've been around here for a long time too and i find your accusation
insulting.

and even if someone did do something deliberately, it would be completely
legal, in fact, an action expressly protected by law. It is a
technological measure that effectively controls access to a work.
Deactivating an effective technological measure is against 17 USC 1201.
(the DMCA) Believe me, most kernel copyright holders are _a lot_ less anal
about their rights than they could be. Every time Congress makes copyright
laws stronger for Disney & co, the kernel copyright gets stronger too.

	Ingo

Re: Linux GPL and binary module exception clause?

[Andrea Arcangeli]

On Wed, Dec 10, 2003 at 02:18:00PM -0800, Larry McVoy wrote:
> interfaces, the EXPORT_GPL stuff, all of that as a way to delibrately

forget EXPORT_GPL, that's an hint, all _GPL can be removed, and any
EXPORT_SYMBOL can be added. what is a derived work or not, what is legal
or not, has nothing to do with whatever EXPORT_SYMBOL_GPL or even with
EXPORT_SYMBOL.

Clearly if we export everything with EXPORT_SYMBOL we make life easier
to illegal people, that's why using EXPORT_SYMBOL_GPL can make sense,
but any distributor is free to drop all _GPL tags everywhere, and export
every single kernel function with EXPORT_SYMBOL. If somebody than makes
a derived work through those exported symbols illegally, that's his own
problem. The distributor has no control on the export symbol users.

just look vmmon, that's a derived work with a non GPL compatible
licence, it does everything through exported symbols but it doesn't mean
it's not a derivative work.

Re: Linux GPL and binary module exception clause?

[Robin Rosenberg]

onsdagen den 10 december 2003 23.18 skrev Larry McVoy:
> On Wed, Dec 10, 2003 at 11:48:45AM -0800, Kendall Bennett wrote:
[...]
> Not only that, I think the judge would have something to say about the
> fact that the modules interface is delibrately changed all the time
> with stated intent of breaking binary drivers.  In fact, Linus pointed
> out his thoughts on what the judge would say:
>
>     In fact, I will bet you that if the judge thinks that you tried to
>     use technicalities ("your honour, I didn't actually run the 'ln'
>     program, instead of wrote a shell script for the _user_ to run the
>     'ln' program for me"), that judge will just see that as admission
>     of the fact that you _knew_ you were doing something bad.
>
> Why is it that the judge wouldn't see the delibrate changing of the
> interfaces, the EXPORT_GPL stuff, all of that as a way to delibrately
> force something that wouldn't otherwise be a derived work into a
> derived work category?

If EXPORT_GPL is changed as a means of protecting the copyright, i..e. provide
source code access. then doesn't this "mechanism" fall under the infamous DMCA, 
i.e. you're not allowed to even think about circumventing it...

-- robin

Re: Linux GPL and binary module exception clause?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

On Thu, 11 Dec 2003 18:44:03 +0100, Robin Rosenberg said:

> If EXPORT_GPL is changed as a means of protecting the copyright, i..e. provide
> source code access. then doesn't this "mechanism" fall under the infamous DMCA, 
> i.e. you're not allowed to even think about circumventing it...

17 USC 1201 (a)(1)(A) says:

"No person shall circumvent a technological measure that effectively controls
access to a work protected under this title. The prohibition contained in the
preceding sentence shall take effect at the end of the 2-year period beginning
on the date of the enactment of this chapter."

OK, so Adobe managed to make the case that rot-13 was an "effective control".
Given that the GPL specifically allows you to change the source and thus bypass
the EXPORT_GPL, I doubt you can make the case for "effective".

Of course, IANAL, just a sysadmin who can read.  If the definition of "effective"
is likely to matter to you, get legal advice from a qualified expert.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Linux GPL and binary module exception clause?

[Nick Piggin]

Valdis.Kletnieks@vt.edu wrote:

>On Thu, 11 Dec 2003 18:44:03 +0100, Robin Rosenberg said:
>
>
>>If EXPORT_GPL is changed as a means of protecting the copyright, i..e. provide
>>source code access. then doesn't this "mechanism" fall under the infamous DMCA, 
>>i.e. you're not allowed to even think about circumventing it...
>>
>
>17 USC 1201 (a)(1)(A) says:
>
>"No person shall circumvent a technological measure that effectively controls
>access to a work protected under this title. The prohibition contained in the
>preceding sentence shall take effect at the end of the 2-year period beginning
>on the date of the enactment of this chapter."
>
>OK, so Adobe managed to make the case that rot-13 was an "effective control".
>Given that the GPL specifically allows you to change the source and thus bypass
>the EXPORT_GPL, I doubt you can make the case for "effective".
>

You know, "effectively" has two (that I know of) meanings.

I would be surprised if a case for prosecution could be won based on
the argument that rot-13 "works properly". Not because I know anything
about law, maybe naive though.

Re: Linux GPL and binary module exception clause?

[Mihai RUSU]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 11 Dec 2003 Valdis.Kletnieks@vt.edu wrote:

> 17 USC 1201 (a)(1)(A) says:
> 
> "No person shall circumvent a technological measure that effectively controls
> access to a work protected under this title. The prohibition contained in the
> preceding sentence shall take effect at the end of the 2-year period beginning
> on the date of the enactment of this chapter."

What about section 1201(f)(2) :

    Notwithstanding the provisions of subsections (a)(2) and (b), a person 
may develop and employ technological means to circumvent a technological 
measure, or to circumvent protection afforded by a technological measure 
... for the purpose of enabling interoperability of an independently 
created computer program with other programs, if such means are necessary 
to achieve such interoperability, to the extent that doing so does not 
constitute infringement under this title.

Read more on this case analysis 
http://research.yale.edu/lawmeme/modules.php?name=News&file=article&sid=149

- -- 
Mihai RUSU                                    Email: dizzy@roedu.net
GPG : http://dizzy.roedu.net/dizzy-gpg.txt    WWW: http://dizzy.roedu.net
                       "Linux is obsolete" -- AST
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/2Lx2PZzOzrZY/1QRAiMVAKDRL1T2XM0dmIRWat3L9pFFw92JrQCgvyAw
Dop7R7K/waecGWn9PDhAJ1M=
=6zfE
-----END PGP SIGNATURE-----

RE: Linux GPL and binary module exception clause?

[David Schwartz]

> If EXPORT_GPL is changed as a means of protecting the copyright,
> i..e. provide
> source code access. then doesn't this "mechanism" fall under the
> infamous DMCA,
> i.e. you're not allowed to even think about circumventing it...
>
> -- robin

	This was already discussed to death.

	If EXPORT_GPL were a copyright enforcement mechanism, it could not add any
restrictions not already present in the GPL because the GPL prohibits
additional restrictions. So either EXPORT_GPL is not a copyright enforcement
mechanism (in which case the DMCA doesn't prohibit removing or circumventing
it), or it only enforces technically restrictions that are already in effect
legally. So this would only matter to someone who said, "I'm going to
violate the GPL, what might happen?"

	Interestingly, even if it is a copyright enforcement mechanism and even if
it only enforces the GPL's actual terms, anyone who wants to could still
remove it. The inability to remove a copyright enforcement mechanism would
be an "additional restriction" and so it couldn't be imposed on a GPL'd
work. (IANAL, and you never know how courts would rule of course.)

	DS

RE: Linux GPL and binary module exception clause?

[David Woodhouse]

On Wed, 2003-12-10 at 09:42 -0800, Linus Torvalds wrote:
> There's a reason for those lines at the top of the COPYING file saying
> that user space is not covered, and there are literally lawyers who say it
> would hold up in a court of law.

I'm glad that the lawyers have been specifically asked about that,
because the exception seems poorly worded to me. It does _not_ say that
user space 'is not covered'; in fact it says only that user space is not
considered a derived work.

But see §2 of the GPL:

	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.

Being pedantic about it, the precise wording of the exception does not
prevent a user space program from being affected by the above even
though it is explicitly _not_ considered to be 'derived work', and
though it 'can be reasonably considered [an] independent and separate
[work] in [itself]'.

If you distribute your user space programs not 'as separate works' but
rather 'as part of a whole which is a work based on the Program', then
they may be affected.

I don't _like_ the idea that user space could be affected, and I hope
that the _intent_ of the exception is clear enough to cover the
ambiguity. I'm not really sure that's the case though.

For example, imagine explaining to a judge the technicalities about user
space and kernel space, and the 'separation' between the kernel and the
cramfs in the downloadable binary blob which forms the firmware for the
Linksys/Cisco wireless routers -- and hence arguing that the user space
bits are being distributed 'as separate works', rather than 'as part of
a whole...'. What reaction do you think you'd get?

I don't think the GPL on the kernel _should_ extend its reach into user
space, and I'll allow people to invoke estoppel by publicly stating here
and now that I'd never sue for such 'violations' alone.

Note the word "alone" in the above sentence. I won't rule out the
possibility of including such violations in a case against a vendor
shipping binary-only modules, or committing other violations.

-- 
dwmw2

Re: Linux GPL and binary module exception clause?

[Jörn Engel]

On Wed, 10 December 2003 09:15:15 -0800, Hua Zhong wrote:
> 
> Many userspace programs fall into this category too. For example they
> depend on /proc to be there. They probably only work with a certain
> version of the kernel because the next version changed some format in
> /proc.
> 
> Is /proc a stable API/ABI? Yes? No?

Have you ever played roleplaying games?  Almost every rule system has
gray areas that could be exploited by the player.  But if you really
try to do it, the game master will simply notice that - as unlikely as
it sounds - a meteor just landed on your head and you are dead.

Try to use /proc/kcore to load kernel modules through a gray area and
the game master (aka judge) will notice.  Use it to check the kernel
version and noone cares.  So common sense applies again, no matter how
tricky your questions are.

Jörn

-- 
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Linus,

Thanks for the clarification !

So as I suspected and validated via other means, the content of the
headers are not an issue as it relates to GPL as many claim.

Well I have gotten side requests that I was late in joining the thread
party and I am distracting you from patch merging.  This is a fair point,
and we can restart after 2.6.0 is out.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Wed, 10 Dec 2003, Linus Torvalds wrote:

> 
> 
> On Wed, 10 Dec 2003, Andre Hedrick wrote:
> >
> > So why not do the removal of the inlines to real .c files and quit playing
> > games with bogus attempts to bleed taint into the inprotectable api?
> 
> The inlines have nothing to do with _anything_.
> 
> Trust me, a federal judge couldn't care less about some very esoteric
> technical detail. I don't know who brought up inline functions, but they
> aren't what would force the GPL.
> 
> What has meaning for "derived work" is whether it stands on its own or
> not, and how tightly integrated it is. If something works with just one
> particular version of the kernel - or depends on things like whether the
> kernel was compiled with certain options etc - then it pretty clearly is
> very tightly integrated.
> 
> Don't think that copyright would depend on any technicalities.
> 
> 		Linus
> 

Re: Linux GPL and binary module exception clause?

[Kendall Bennett]

Valdis.Kletnieks@vt.edu wrote:

> On Fri, 05 Dec 2003 10:44:02 PST, Kendall Bennett said:
> 
> > Right, and by extension of the same argument you cannot use kernel
> > headers to create non-GPL'ed binaries that run IN USER SPACE! Just
> > because a program runs in user space does not mean that it is not a
> > dervived work. 
> 
> That's a bad idea for technical reasons too - how often do we have
> to tell people not to use kernel headers from userspace? 
> glibc-kernheaders (and whatever non-RedHat boxes call it) exists
> for a reason. 
> 
> Interestingly enough, at least on my Fedora box, 'rpm -qi' reports
> glibc as LGPL, but glibc-kernheaders as GPL, which seems right to
> me - linking against glibc gives the LGPL semantics as we'd want,
> but forces userspace that's poking in the kernel to be GPL as a
> derived work.... 

If glibc-kernheaders (used only if you do not have real kernel source 
code installed) is GPL, and many of the standard Linux include files end 
up including either headers from glibc-kernheaders (or the real Linux 
kernel source if you have it installed and symlinked), then by extension 
the glibc library built for Linux must be GPL as would all programs 
linked against it.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

RE: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Fri, 5 Dec 2003, Kendall Bennett wrote:
>
> Right, and by extension of the same argument you cannot use kernel
> headers to create non-GPL'ed binaries that run IN USER SPACE!

This was indeed one of the worries that people had a long time ago, and is
one (but only one) of the reasons for the addition of the clarification to
the COPYING file for the kernel.

So I agree with you from a technical standpoint, and I claim that the
clarification in COPYING about user space usage through normal system
calls covers that special case.

But at the same time I do want to say that I discourage use of the kernel
header files for user programs for _other_ reasons (ie for the last 8
years or so, the suggestion has been to have a separate copy of the header
files for the user space library). But that's due to technical issues
(since I think the language of the COPYING file takes care of all
copyright issues): trying to avoid version dependencies.

> This exact reasoning is what RedHat (aka Cygnus) has been using for years
> with the Cygwin toolkit for Windows. Although 99% of the code built with
> the GNU compilers and Cygwin includes the glibc runtime library that is
> LGPL, every program *must* include the C runtime library startup code or
> it cannot function. *That* code is pure GPL, and by extension any program
> using the Cygwin libraries is a derived work and must be GPL. If you
> don't like that, by a commercially licensed version of Cygwin from
> RedHat/Cygnus instead.

And this is an area where I think the GPL just isn't the right license to
use - but on the other hand it obviously isn't my decision to make. I'm
not touching Cygwin with a ten-foot pole, and that has nothing to do with
licensing ;)

The GPL just doesn't make a lot of sense for library-like infrastructure.

		Linus

Re: Linux GPL and binary module exception clause?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On Thu, 04 Dec 2003 22:34:37 PST, David Schwartz said:

> 	So you're argument is that it's impossible to use the header file without
> creating a derived work, hence permission to use the header file is
> permission to create the derived work.

Right.  And getting the permission to create the derived work is contingent on your
agreeing that if it is distributed, the derived work is GPL.

> This supports my argument that you
> can create a derived work without agreeing to the GPL. Thanks.

It's quite possible and legal to *create* a derived work without agreeing to the
GPL.  However, the only things you can legally *do* with the work are use it
on your own system, and brag about how cool your code is.

You most certainly can't distribute it as non-GPL.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

RE: Linux GPL and binary module exception clause?

[Kendall Bennett]

"David Schwartz" <davids@webmaster.com> wrote:

> > That's 6,288 chances for you to #include GPL code and end up
> > with executable derived from it in *your* .o file, not the kernel's.
> 
>  I'm sorry, but that just doesn't matter. The GPL gives you the
> unrestricted right to *use* the original work. This implicitly
> includes the right to peform any step necessary to use the work.
> (This is why you can 'make a copy' of a book on your retina if you
> have the right to read it.) Please tell me how you use a kernel
> header file, other than by including it in a code file, compiling
> that code file, and executing the result. 

Another point worth mentioning is that if the Linux kernel headers are 
pure GPL, then user land programs that use the Linux kernel headers 
themselves would also be pure GPL by extension if the above argument 
holds water. Clearly the Linux developers would like to believe 
otherwise, but there are many Linux user mode programs that will make use 
of GPL kernel headers in their non-GPL programs. And some of that code 
will include inline assembler and inline functions to make calls into the 
kernel.

Likewise, by extension, any runtime library that uses GPL header files 
from the kernel directly would have to also be pure GPL. This means glibc 
folks. We all know glibc is LGPL, but if you link pure GPL code with LGPL 
code the entire work must be *GPL*, not LGPL if it is considered a 
derived work.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

RE: Linux GPL and binary module exception clause?

[Maciej Zenczykowski]

> Another point worth mentioning is that if the Linux kernel headers are 
> pure GPL, then user land programs that use the Linux kernel headers 
> themselves would also be pure GPL by extension if the above argument 
> holds water. Clearly the Linux developers would like to believe 

Problem being that user space programs are not supposed to use the kernel 
headers - they're supposed to use the glibc headers anyway.  In fact the 
latest kernel source headers don't work in userspace period.  And the user 
space glibc 'kernel' headers are released and distributed seperately and 
contain much less code than the actual kernel kernel headers.

Cheers,
MaZe.

Re: Linux GPL and binary module exception clause?

[Kendall Bennett]

Peter Chubb <peter@chubb.wattle.id.au> wrote:

> > As far as I know, interfacing to a published API doesn't infringe
> > copyright.
> 
> Well, if the only thing in the .h files was #defines and structure
> definitions, it would probably be a slam dunk to decide that, yes.
> 
> Here's the part where people's eyes glaze over:
> 
> % cd /usr/src/linux-2.6.0-test10-mm1
> % find include -name '*.h' | xargs egrep 'static.*inline' | wc -l
>    6288
> 
> That's 6,288 chances for you to #include GPL code and end up
> with executable derived from it in *your* .o file, not the kernel's.
> 
> More to the point, look at include/linux/rwsem.h, and ask yourself
> how to call down_read(), down_write(), up_read(), and up_write()
> without getting little snippets of GPL all over your .o.  

Clearly that is easy to work around, because all you need to do is have a 
small GPL wrapper module that includes the Linux kernel headers and would 
end up having GPL code linked into it, and build the wrapper such that it 
makes calls via an API *you* define into your code. Then your code is 
simply interfacing via your own API to the GPL wrapper module and none of 
your code would be tainted. 

At least via direct inclusion and use of Linux kernel API header files 
anyway. There is still the issue of whether the specific binary module 
code you are linking into the kernel is Linux specific or not and would 
be considered a dervived work. If it is only for Linux and is not very 
useful for other platforms, one could argue that it is a derived work and 
hence should be GPL regardless of what API or GPL wrapper it uses.

Then again, if a module is completely Linux specific and the source for 
it has no use outside of Linux, I doubt a vendor could care less about 
keeping it proprietary anyway ;-)

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Very simple.

Apply the basics of GPL and strip all the inlines to a file called
kernel_inlines.[ch] and export all the symbols to export_symbol.

Thus all the cute tricks people try to taint the unprotecable interface is
removed.  The basics of removing the code in question.

If you holler wait you are changing the core and you can't BUZZIT.
I can change what ever I want and distribute it where ever I care.

Thank you,

Andre Hedrick
LAD Storage Consulting Group

On Fri, 5 Dec 2003 Valdis.Kletnieks@vt.edu wrote:

> On Fri, 05 Dec 2003 15:23:10 +1100, Peter Chubb said:
> 
> > As far as I know, interfacing to a published API doesn't infringe
> > copyright.
> 
> Well, if the only thing in the .h files was #defines and structure definitions,
> it would probably be a slam dunk to decide that, yes.
> 
> Here's the part where people's eyes glaze over:
> 
> % cd /usr/src/linux-2.6.0-test10-mm1
> % find include -name '*.h' | xargs egrep 'static.*inline' | wc -l
>    6288
> 
> That's 6,288 chances for you to #include GPL code and end up
> with executable derived from it in *your* .o file, not the kernel's.
> 
> More to the point, look at include/linux/rwsem.h, and ask yourself
> how to call down_read(), down_write(), up_read(), and up_write()
> without getting little snippets of GPL all over your .o.  
> 
> And even if your module doesn't get screwed by that, there's a
> few other equally dangerous inlines waiting to bite you on the posterior.
> 
> I seem to recall one of the little buggers was particularly nasty, because it
> simply Would Not Work if not inlined, so compiling with -fno-inline wasn't an
> option.  Unfortunately, I can't remember which it was - it was mentioned on
> here a while ago when somebody's kernel failed to boot because a gcc 3.mumble
> had broken inlining.....
> 
> 

Re: Linux GPL and binary module exception clause?

[Jesse Pollard]

On Wednesday 10 December 2003 07:16, Andre Hedrick wrote:
> Very simple.
>
> Apply the basics of GPL and strip all the inlines to a file called
> kernel_inlines.[ch] and export all the symbols to export_symbol.

I belive that is what is done for the usermode includes (excluding the
inlines), and including some of the constants.

As a matter of fact, the user includes can't be used in the kernel anyway
since they ARE incomplete from the kernels point of view. They don't even
have to match the kernel at all.. They DO have to match the libc being
used, though.

> Thus all the cute tricks people try to taint the unprotecable interface is
> removed.  The basics of removing the code in question.
>
> If you holler wait you are changing the core and you can't BUZZIT.
> I can change what ever I want and distribute it where ever I care.

You are still deriving your binary from a GPL source when a module is loaded.
The kernel relocation symbols themselves are under GPL.

The advantage that the NVIDIA approach has is that all GPL symbols/relocation/
whatever is handled by the wrapper for the binary driver. And that wrapper is
distributed in an "acceptable" way.

The DISadvantage it has is that the "defined" module interface changes. And it
can even change during minor updates. The module interface is NOT a fixed 
target, like the usermode interface is. And then the NVIDIA driver(and/or
wrapper) will require changes to continue to work...

And bugs in a tainted kernel will continue to be unfixable.

Re: Linux GPL and binary module exception clause?

[Theodore Ts'o]

On Wed, Dec 10, 2003 at 09:02:21AM -0600, Jesse Pollard wrote:
> 
> You are still deriving your binary from a GPL source when a module is loaded.
> The kernel relocation symbols themselves are under GPL.
> 

Even if the relocation symbols are under GPL'ed (there is doubt
whether such symbols are copyrightable --- since things like telephone
numbers are not copyrightable, for example), there is still the issue
that the user is the one which is loading the module, not the person
writing and distributing the module.  And at this point, given that
the GPL itself says that it's all about distribution, not about the
use of the GPL'ed software, not to mention the fair use doctrine
(trust me, the open source community does **not** want to narrow what
is considered fair use), there isn't a problem.

						- Ted

Re: Linux GPL and binary module exception clause?

[Jesse Pollard]

On Wednesday 10 December 2003 14:37, Theodore Ts'o wrote:
> On Wed, Dec 10, 2003 at 09:02:21AM -0600, Jesse Pollard wrote:
> > You are still deriving your binary from a GPL source when a module is
> > loaded. The kernel relocation symbols themselves are under GPL.
>
> Even if the relocation symbols are under GPL'ed (there is doubt
> whether such symbols are copyrightable --- since things like telephone
> numbers are not copyrightable, for example), there is still the issue
> that the user is the one which is loading the module, not the person
> writing and distributing the module.

As a nit - It is the person writing and distributing the binary that
determines the symbols used.

In any case, my phrasing was definitely poor.

((Though individual telephone numbers are not copyrightable, arrangements
of telephone numbers are... Or the copyright notice in my phone book is
bogus :-))

> And at this point, given that
> the GPL itself says that it's all about distribution, not about the
> use of the GPL'ed software, not to mention the fair use doctrine
> (trust me, the open source community does **not** want to narrow what
> is considered fair use), there isn't a problem.

I had no real problem with the actual load... Just the distribution of
the binary. To create the binary required access to the kernel sources
just to identify the interfaces. But if the Kernel includes can provide
the required separation... (I don't think they do, because other things are
missing, such as the actual routines).

I don't even have a big problem (other than distaste) to GPL shim modules
for binary drivers. I don't see this as much different than loadable
firmware. At least the shim (if properly written, that is) should be
able to adjust to the various options in a specific kernel build. And I do
have SOME possibility (however remote) to fix a slightly broken shim.

Re: Linux GPL and binary module exception clause?

[Richard B. Johnson]

On Fri, 5 Dec 2003, Nick Piggin wrote:

>
>
> Paul Adams wrote:
>
> >--- In linux-kernel@yahoogroups.com, Linus Torvalds
> ><torvalds@o...> wrote:
> >
> >>- anything that was written with Linux in mind
> >>
> >(whether it then
> >
> >>_also_ works on other operating systems or not) is
> >>
> >clearly
> >
> >>partially a derived work.
> >>
> >
> >I am no more a lawyer than you are, but I have to
> >disagree.  You
> >are not free to define "derivative work" as you
> >please.  You
> >must use accepted legal definitions.  At least in the
> >U.S., you
> >must consider what Congress had to say on this.  They
> >said, "to
> >constitute a violation of section 106(2) [which gives
> >copyright
> >owners rights over derivative works], the infringing
> >work must
> >incorporate a portion of the copyrighted work in some
> >form; for
> >example, a detailed commentary on a work or a
> >programmatic musical
> >composition inspired by a novel would not normally
> >constitute
> >infringements under this clause."
> >http://www4.law.cornell.edu/uscode/17/106.notes.html
> >
> >A work that is inspired by Linux is no more a
> >derivative work than
> >a programmatic musical composition inspired by a
> >novel.  Having
> >Linux in mind cannot be enough to constitute
> >infringement.
> >
>
> Of course not, thought police aren't any good until a mind reader
> is invented ;)
>
> Seriously:
> What about specifically a module that includes the Linux Kernel's
> headers and uses its APIs? I don't think you could say that is
> definitely not a derivative work.
>

When copyright law was developed, nobody thought of
"#include <filename.h>".

Let's guess what that means. To me, that is like a reference
to a written work, when you attribute something to some document
that was previously written and, incidentally, give appropriate
credit to the writer(s). In this context, it is clearly not
a copyright infringement to include the works of others with
appropriate credit being given.

It is just like; "See John Smith's article on frogs", referenced
in an article about frogs.

However, there are some who would claim that they don't want
their previous work referenced by others at all, in particular
those who might dirty their hands by making money with it.

The only known way to prevent others from referencing a previous
work is to not publish it at all. "Publish means to make public".
If you don't want others referencing your precious work, then
you need to keep it secret. It's just that simple. You can't have
it both ways. You can't say, "I publish this only for the eyes of
my friends who will work for free."

Now, I have seen some who write their own header files because
they think that including somebody else's creation might violate
some copyright law. This, in fact, might be a violation in
itself, to incorporate "whole cloth" the works of others in
a separate document does appear to violate US law. However,
referencing the unmodified original document, clearly
(as clear are any law could be interpreted) does not.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Linux GPL and binary module exception clause?

[Oliver Hunt]

Paul Adams wrote:

> --- In linux-kernel@yahoogroups.com, Linus Torvalds
> <torvalds@o...> wrote:
> 
>>- anything that was written with Linux in mind
> 
> (whether it then
> 
>>_also_ works on other operating systems or not) is
> 
> clearly
> 
>>partially a derived work.
> 
> 
> I am no more a lawyer than you are, but I have to
> disagree.  You
> are not free to define "derivative work" as you
> please.  You
> must use accepted legal definitions.  At least in the
> U.S., you
> must consider what Congress had to say on this.  They
> said, "to
> constitute a violation of section 106(2) [which gives
> copyright
> owners rights over derivative works], the infringing
> work must
> incorporate a portion of the copyrighted work in some
> form; for
> example, a detailed commentary on a work or a
> programmatic musical
> composition inspired by a novel would not normally
> constitute
> infringements under this clause."
> http://www4.law.cornell.edu/uscode/17/106.notes.html
> 
> A work that is inspired by Linux is no more a
> derivative work than
> a programmatic musical composition inspired by a
> novel.  Having
> Linux in mind cannot be enough to constitute
> infringement.
> 
> Remember also that U.S. copyright law states:
> "In no case does copyright protection for an original
> work of
> authorship extend to any idea, procedure, process,
> system, method
> of operation, concept, principle, or discovery,
> regardless of
> the form in which it is described, explained,
> illustrated, or
> embodied in such work."
> http://www4.law.cornell.edu/uscode/17/102.html
> Thus you cannot claim infringement because a work
> merely shares
> ideas or methods of operation with Linux.
> 
> The standard used in U.S. courts for determining if
> software
> violates a copyright includes a filtering procedure to
> eliminate
> unprotected aspects as described above.  A standard
> filter is that
> you eliminate an element if "The element's expression
> was dictated
> by external factors, such as using an existing file
> format or
> interoperating with another program."  Computer
> Associates v.
> Altai specifically discusses the need to filter
> elements related
> to "compatibility requirements of other programs with
> which a
> program is designed to operate in conjunction."
> http://www.bitlaw.com/source/cases/copyright/altai.html
> Code needed to interoperate with the Linux kernel thus
> cannot be
> considered as a factor in determining if the Linux
> copyright is
> infringed.
> 
> Unless actual Linux code is incorporated in a binary
> distribution
> in some form, I don't see how you can claim
> infringement of the
> copyright on Linux code, at least in the U.S.
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Yes, but the if you want to write a kernel modules you need to #include
at least a few of the headers: you are including copyrighted work...

What (i think) linus is saying is that he, as the owner of the 
copyright, would accept a ported driver as not being derived(as most of 
the work would have been based on another system, not linux), but that 
is his choice, he is allowed to relax the terms of use because it is his 
copyright...

I'm not however ever a lawyer...

--Oliver
The Department Formerly Known as Cosc
University of Canterbury
New Zealand

Re: Linux GPL and binary module exception clause?

[Russell King]

On Fri, Dec 05, 2003 at 01:09:00PM +1300, Oliver Hunt wrote:
> What (i think) linus is saying is that he, as the owner of the 
> copyright,

Unfortunately, this statement isn't entirely correct.

Linus owns the copyright on parts of the kernel written by Linus, just
the same as I own copyright on the parts of the kernel written by me,
Red Hat own copyright on parts of the kernel written by their employees,
and IBM own copyright on parts of the kernel written by their employees.
etc.

No one person owns the overall copyright on the complete kernel.

This, in turn, means that no one person can change the terms and
conditions of the license under which the overall kernel is
distributed.

IANAL.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: Linux GPL and binary module exception clause?

[Erik Andersen]

On Thu Dec 04, 2003 at 03:50:55PM -0800, Paul Adams wrote:
> Unless actual Linux code is incorporated in a binary
> distribution
> in some form, I don't see how you can claim
> infringement of the
> copyright on Linux code, at least in the U.S.

A kernel module is useless without a Linux kernel in which it can
be loaded.  Once loaded, it becomes not merely an adjunct, but an
integrat part of the Linux kernel.  Further, it clearly
"incorporate[s] a portion of the copyrighted work" since it
can only operate within the context of the kernel by utilizing
Linux kernel function calls.

To abuse your earlier metaphor, a kernel module is not comparable
to a programmatic musical composition inspired by a novel.  It is
better comparared with another novel with substantial similarity
in the theme, plot, sequence, settings, mood, dialogue, and
characters, with the same story being told, with trademarked
phrases and taglines, and that makes no sense whatsoever unless
you insert it's entire content over the top of page 450,
paragraph 4 (of the Linux "novel"), and which thereby changes 
the ending of the original book...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux GPL and binary module exception clause?

[Zwane Mwaikambo]

On Thu, 4 Dec 2003, Erik Andersen wrote:

> On Thu Dec 04, 2003 at 03:50:55PM -0800, Paul Adams wrote:
> > Unless actual Linux code is incorporated in a binary
> > distribution
> > in some form, I don't see how you can claim
> > infringement of the
> > copyright on Linux code, at least in the U.S.
>
> A kernel module is useless without a Linux kernel in which it can
> be loaded.  Once loaded, it becomes not merely an adjunct, but an
> integrat part of the Linux kernel.  Further, it clearly
> "incorporate[s] a portion of the copyrighted work" since it
> can only operate within the context of the kernel by utilizing
> Linux kernel function calls.

What about software which utilises Linux specific kernel services, such as
say some cd writing software?

Re: Linux GPL and binary module exception clause?

[Erik Andersen]

On Thu Dec 04, 2003 at 07:58:18PM -0500, Zwane Mwaikambo wrote:
> What about software which utilises Linux specific kernel
> services, such as say some cd writing software?

An ordinary program that uses normal system calls?

linux/COPYING says: This copyright does *not* cover user programs
that use kernel services by normal system calls - this is merely
considered normal use of the kernel, and does *not* fall under
the heading of "derived work".

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Thu, Dec 04, 2003 at 06:03:49PM -0700, Erik Andersen wrote:
> On Thu Dec 04, 2003 at 07:58:18PM -0500, Zwane Mwaikambo wrote:
> > What about software which utilises Linux specific kernel
> > services, such as say some cd writing software?
> 
> An ordinary program that uses normal system calls?
> 
> linux/COPYING says: This copyright does *not* cover user programs
> that use kernel services by normal system calls - this is merely
> considered normal use of the kernel, and does *not* fall under
> the heading of "derived work".

Yeah, and the GPL specificly invalidates that statement.  We're on thin
ice here.  Linus is making up the rules, which is cool (since I tend to
like his rules) but the reality is that the GPL doesn't allow you to 
extend the GPL.  It's the GPL or nothing.

Given the GPL rules you have to disregard Linus' rules that are extensions
and work off of standard law.  When you get there it becomes an issue of
boundaries and the law seems to clearly support Linus' point of view, he
didn't need to make that clarification, whether he did or not, that's what
is true in the eyes of the law.

But given that, neither Linus (nor any of you) get to say "well, that's fine
for userland but drivers are derived works".  

I've said this over and over and I'll say it again.  If you want the
protection of the law you have to live with the law's rules.  You DO
NOT get to say "user programs are a boundary across which the GPL does
not apply but drivers are a boundary across which the GPL does apply".
It doesn't, and can't, work that way.  Either userland is GPL and drivers
are GPL or neither are GPLed.  Take your pick.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

RE: Linux GPL and binary module exception clause?

[Hua Zhong]

> But given that, neither Linus (nor any of you) get to say 
> "well, that's fine for userland but drivers are derived works".  

Indeed. Linus said nowadays kernel modules developed with Linux
specifically in mind are less likely to be considered "not a derived
work" as early days kernel modules.

However, how about user space programs designed specifically for Linux,
and even using Linux specific system calls?

It's definitely a grey area here, and it's not so clear that kernel-user
boundary is stronger than kernel-kernel boundary per se. :-)

Note kernel-user boundary is not just normal system calls. /proc, ioctl
(provided by kernel modules) are also part of it (which are system calls
too but they can be arbitrarily extended).

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Thu, 4 Dec 2003, Larry McVoy wrote:
> >
> > linux/COPYING says: This copyright does *not* cover user programs
> > that use kernel services by normal system calls - this is merely
> > considered normal use of the kernel, and does *not* fall under
> > the heading of "derived work".
>
> Yeah, and the GPL specificly invalidates that statement.  We're on thin
> ice here.  Linus is making up the rules, which is cool (since I tend to
> like his rules) but the reality is that the GPL doesn't allow you to
> extend the GPL.  It's the GPL or nothing.

Larry, you are wrong.

The license _IS_ the GPL. There's no issue about that. The GPL rules apply
100%.

But a license only covers what it _can_ cover - derived works. The fact
that Linux is under the GPL simply _cannot_matter_ to a user program, if
the author can show that the user program is not a derived work.

And the linux/COPYING addition is not an addition to the license itself
(indeed, it cannot be, since the GPL itself is a copyrighted work, and so
by copyright law you aren't allowed to just take it and change it).

No, the note at the top of the copying file is something totally
different: it's basically a statement to the effect that the copyright
holder recognizes that there are limits to a derived work, and spells out
one such limit that he would never contest in court.

See? It's neither a license nor a contract, but it actually does have
legal meaning: look up the legal meaning of "estoppel" (google "define:"
is qutie good). Trust me, it's got _tons_ of legal precedent.

		Linus

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Thu, Dec 04, 2003 at 05:58:18PM -0800, Linus Torvalds wrote:
> On Thu, 4 Dec 2003, Larry McVoy wrote:
> > > linux/COPYING says: This copyright does *not* cover user programs
> > > that use kernel services by normal system calls - this is merely
> > > considered normal use of the kernel, and does *not* fall under
> > > the heading of "derived work".
> >
> > Yeah, and the GPL specificly invalidates that statement.  We're on thin
> > ice here.  Linus is making up the rules, which is cool (since I tend to
> > like his rules) but the reality is that the GPL doesn't allow you to
> > extend the GPL.  It's the GPL or nothing.
> 
> Larry, you are wrong.

Linus, you are a purple 3 legged frog.  So there.  It is written and it
shall be so :)

> But a license only covers what it _can_ cover - derived works. The fact
> that Linux is under the GPL simply _cannot_matter_ to a user program, if
> the author can show that the user program is not a derived work.

I'll followup on this below.

> And the linux/COPYING addition is not an addition to the license itself
> (indeed, it cannot be, since the GPL itself is a copyrighted work, and so
> by copyright law you aren't allowed to just take it and change it).

Exactly my point.  The addition is not part of the license and given your 
other arguments, userland is 100% GPLed as a result.

> No, the note at the top of the copying file is something totally
> different: it's basically a statement to the effect that the copyright
> holder recognizes that there are limits to a derived work, and spells out
> one such limit that he would never contest in court.

It's one that _you_ apparently will never contest in court but the
amount of code in the kernel that you wrote is quite small.  You are the
leader but that doesn't mean you speak for everyone.  There seem to be
differing opinions.  In this case, that may be a good thing.

In my opinion, you are playing with fire and playing well into SCO's
hands.  I haven't read the original Unix license but I have heard that
it had a somewhat similar viral effect, like the GPL does.  I've heard
that it claims ownership of derived works, which I doubt is true.
But I've also heard that it claimed certain distribution rights for
derived works and that I do believe.  It's entirely plausible that a
commercial entity would have a license which says "you can't build on
my work and give to someone who hasn't also obtained a license from us".
Makes perfect sense and is quite likely.

However, if someone did take derived code (which is now covered by the
viral license) and add it illegally to Linux, it is entirely reasonable
for the license holder to say that all of Linux now has the virus.  Just
as reasonable as someone saying "hey, that's the Linux XYZ driver in 
Solaris, Solaris is now GPLed".

There seems to be this sentiment (a pleasant one) in this community that
if you do the wrong thing and then undo it, all is forgiven.  That's not
how the license reads.  The GPL doesn't say "if you uncombine the work you
are no longer obligated to obey the GPL".  Neither would any other license.

Roll forward a bit and see how this plays out in court.  Suppose there is
code in Linux that is derived from Unix.  Remember, if Unix licenses had
the same viral effect as the GPL, all it takes is a function or two and
the rest of the code is GPL-ed (or in this case, Unix-ed).  If you are
arguing that an API isn't a boundary for the GPL you are going to look
bloody two faced when you go and argue that an API is a boundary for Unix.

And all of this discussion is nicely indexed by Google for SCO's lawyers
to dig through and say "see, the leader of Linux doesn't think that
boundaries apply.  Linux is now covered *completely* by the SCO Unix
license.  Pay up".

I'm not a lawyer but I am someone who pays lawyers to figure this stuff
out and I've explored precisely this area.  I sure hope that what I've
learned is true because if what you are saying is true we are all likely
to be screwed.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

IANAL.

On Fri, 5 Dec 2003, Larry McVoy wrote:
>
> However, if someone did take derived code (which is now covered by the
> viral license) and add it illegally to Linux, it is entirely reasonable
> for the license holder to say that all of Linux now has the virus.

You are making a classic mistake, which is to confuse "license" and
"copyright", and mixing them together.

[ Caveat: I'm obviously not a lawyer, but I've talked to a number of them
  over the years, and this is my understanding. Make of it what you will. ]

Copyright (aka "ownership" of the code) and licenses are entirely
different animals, and they have very little to do with each other
legally. Except for the fact that the license can only be set by the
owner.  But even when you set the license, the license _remains_ a
separate issue from the ownership itself.

So a license is _independent_ of the copyright on a work. You can have
multiple licenses for a work that is copyrighted by one person, and you
can have a single license for a work that is copyrighted by multiple
people. Or you can have no license at all (or no copyright, but at that
point the license loses its meaning, for other reasons - if the code is in
the public domain, anybody can pick it up and claim ownership, and so
everybody can set their own licenses. "No ownership" is a special case
because of that).

So the only thing that ties the two together is that only the copyright
holder can set the license. Other than that they are totally separate
things.

For example, I set the license on the kernel because I weas originally the
only copyright holder, which meant that I could use any license I pleased.
That ends up constraining later people, since they now have to follow the
rules - unlike me, they can't just make up the license for the original
code.

But if somebody else writes a piece of code for Linux, we now have a
situation where Linux is comprised of two pieces (a) the original work
(for simplicity, let's say it's copyright by person A) and (b) the new
work (copyright person B).

Now, (a+b) is the new work (joint copyrighted by A+B), and if the original
code (a) required the GPL, then (a+b) requires the GPL too due to the
"viral" nature of the GPL. You are right so far.

BUT THAT DOES NOT MEAN THAT PERSON B LOST _ANY_ RIGTHS WRT WORK (b).

In particular, person B can still license work (b) under any other
license. He cannot license (a+b) under any other license, since that is
required by the GPL to continue to be GPL, but he _can_ license the code
he retains full copyright to.

In particular, he can take his contribution (b), and combine it with
somebody elses contribution (c), and HE IS NOT BOUND BY THE GPL!

See?

The "viral" nature of the GPL does not actually "infect" the code itself.
Because ownership always overrides _any_ license. The owner is not bound
by the license, and can license it anew. See how "ownership" and "license"
are totally different things? One is subject to the other.

The code remains copyright to person B, and as long as it so remains
(which it does forever, unless B actively gives it away or the US congress
finally stops playing its silly games and lets copyrights expire
eventually), person B can re-license his code any which way he pleases.

Ask a lawyer. Any good lawyer.

It is only "(a+b)" that is a derived work. The code (b) that B wrote is
(as long as he didn't incorporate anybody elses work) remains his, and is
_not_ derived on its own.

(See the definition of derived that I quoted earlier: "derivation" really
requires actual combination).

But my claim is that if (b) is compiled into a Linux kernel module, then
it _is_ part of (a+b) whether (a) is physically present or not. So if
company B compiles their code (owned 100% by them) into a binary linux
kernel module, that _does_ make it a part of (a+b). "Physical location"
has nothing to do with derived works - and the fact that compaby B
compiled code (b) for Linux and then only distributes the (broken up) part
of (a+b) doesn't mean that (a+b) didn't exist.

See what I'm aiming at? I'm saying that B still owns the code (b), but if
he uses it "as part of (a+b)", he has to license the result under the GPL.
And that "compiles into a kernel module" _is_ using (b) as part of (a+b).

But he could _also_ compile the module into some other project (c). And
when used _that_ way, he can license that derivation of (b) any way that
makes sense from a standpoint of a derived work (b+c).

And if he uses code (b) stand-alone (ie does not combine it with anything
at all that anybody else owned), he can use the result any way he wants
to.

I'll bet you a dollar that a copyright lawyer will tell you that my
argument is not incorrect. He probably won't agree with me (since no
lawyers ever agree on _anything_ as far as I can tell) but I really think
he'll say "yeah, seeing it that way is not incompatible with copyright
law".

>								  Just
> as reasonable as someone saying "hey, that's the Linux XYZ driver in
> Solaris, Solaris is now GPLed".

No. That's not what anybody sane is claiming. Let's have this following
schenario:

    (a) is the Linux kernel and is licensed entirely under the GPL
	(and can have hundreds of copyright owners)

    (b) is a driver written and thus owned by party B

    (c) is Solaris, copyright Sun and others.

And the rule is: only an OWNER can accept a license.

So (a+b) is possible only licensed under the GPL, and only if B accepts
the GPL.

And (b+c) is possible only if there is some license that B and Sun can
agree on. If the only license that B agrees to is the GPL, then the only
way (b+c) is possible is if Sun agrees to license (c) under a
GPL-compatible license.

In other words, if (b) is GPL-only, then you can't use (b) with (c), _or_
C has to accept the GPL. "Forcing" a (b+c) doesn't make (c) be under the
GPL. But forcing (b+c) is illegal, since you can't force a license without
the agreement of the owner.

IANAL.

			Linus

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Fri, Dec 05, 2003 at 08:39:03PM -0800, Linus Torvalds wrote:
> But if somebody else writes a piece of code for Linux, we now have a
> situation where Linux is comprised of two pieces (a) the original work
> (for simplicity, let's say it's copyright by person A) and (b) the new
> work (copyright person B).
> 
> Now, (a+b) is the new work (joint copyrighted by A+B), and if the original
> code (a) required the GPL, then (a+b) requires the GPL too due to the
> "viral" nature of the GPL. You are right so far.
> 
> BUT THAT DOES NOT MEAN THAT PERSON B LOST _ANY_ RIGTHS WRT WORK (b).

I never said that person B lost any rights at all.

> In particular, person B can still license work (b) under any other
> license. He cannot license (a+b) under any other license, since that is
> required by the GPL to continue to be GPL, but he _can_ license the code
> he retains full copyright to.

Yeah, I know this.  

> The code remains copyright to person B, and as long as it so remains
> (which it does forever, unless B actively gives it away or the US congress
> finally stops playing its silly games and lets copyrights expire
> eventually), person B can re-license his code any which way he pleases.
> 
> Ask a lawyer. Any good lawyer.

I have, I know all this.

> But my claim is that if (b) is compiled into a Linux kernel module, then
> it _is_ part of (a+b) whether (a) is physically present or not. So if
> company B compiles their code (owned 100% by them) into a binary linux
> kernel module, that _does_ make it a part of (a+b). "Physical location"
> has nothing to do with derived works - and the fact that compaby B
> compiled code (b) for Linux and then only distributes the (broken up) part
> of (a+b) doesn't mean that (a+b) didn't exist.

I know all this as well.

The issue is "what is a derived work", your claim is "pretty much anything
combined with the original work" and I don't agree and neither does the GPL.

    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.

A loadable driver doesn't modify the kernel.  I understand that the
license says "when you distribute them as separate works" and I think
that the courts will view providing a driver as just that.

Your view that "(b) is compiled into a Linux kernel module, then it
_is_ part of (a+b) whether (a) is physically present or not." is not
something that I have managed to seen in any caselaw.  On the other hand,
it is widely held that you can't force licenses across an API and it's
perfectly reasonable to see the loadable module interface as an API.

I think this is something that is going to get resolved by the courts,
not you or I.  And whether it get solved "correctly" is more a matter
of money than of correctness, unfortunately.  I stand behind my earlier
point that your thinking, Linus, could well bite you on this one.  I can
see how you are trying to work around the issues but I can also see,
clearly, how a lawyer would use your words against you and for SCO.

For example, you haven't puzzled out what happens if there are two
GPL-like licenses which cover work which is combined.  Which one wins?
What if they have conflicting terms?  The GPL *does not* automatically
win, any more than the other license automatically wins.  Either could
win.

I also don't buy your separation argument in the context of licensed
intellectual property.  Your whole argument seems to allow things to
cross over boundaries but then when something you don't want to cross
over does, you start talking about how the work was separated and the
license you don't like doesn't apply.  I may be missing something but it
sure sounds like you are trying to intepret the law one way when it meets
your goals and another way when it doesn't and that isn't real promising.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Fri, 5 Dec 2003, Larry McVoy wrote:
>
> For example, you haven't puzzled out what happens if there are two
> GPL-like licenses which cover work which is combined.  Which one wins?
> What if they have conflicting terms?  The GPL *does not* automatically
> win, any more than the other license automatically wins.  Either could
> win.

What?

Nobody can "win". If the owners of the code can't agree on a mutually
acceptable license, you simply cannot legally combine them. End of story.

Whoever tries to combine the works - if it is against the license of
_either_ of the individual works - is doing something he simply doesn't
have the right to do.

And even if he does it, that illegal act in no way affects the license of
_either_ piece, since only ownership gives the right to change a license.
Nobody else and nothing else _ever_ does.

This has nothing to do with software. Think of book editors: they can't
combine two short stories into an edition unless _both_ authors of the
stories agree to the combination.

And the GPL only agrees to combine with the GPL. It's that simple. There
are no other ways to combine it.

There just isn't anything unclear here. I don't see why you'd be confused.

> I also don't buy your separation argument in the context of licensed
> intellectual property.

What separation argument wrt licensed intellectual property? I never made
such an argument.

I made the argument that if A has ownership of the code (not "licensed
intellectual property" - OWNERSHIP - and I thought I made it very clear
that they are totally different things), then they can take that part of
the code that they own and license it any which way they want, and make
any derived works they want (obviously, as long the other party of such a
derivative work agrees to the aggregation. As mentioned, the GPL happily
agrees to that, but only if the license on the result is also the GPL).

But that requires outright OWNERSHIP. It really requires that you are the
copyrigth holder. If you are a mere licensee, you simply can't do it
(unless the license explicitly gives you the right to do it, of course, or
you enter into some other contractual agreement to do so as a
subcontractor for the real copyright holder or similar. Blah blah blah).

But I never introduced the notion of being a licensee. I have at all times
only talked about outright ownership. Sorry if I have been unclear (I
didn't think I had been, but hey, few people find _themselves_ unclear ;)

Maybe you were confused by the IBM thing, and thinking that when I
referred to IBM I referred to a licensee. But the fact is, IBM is _not_ a
licensor of the JFS code etc. They own it outright. Even SCO has
acknowledged that fact long ago.

So I want to clarify: I have at all times talked about outright copyright
ownership. No sublicensing involved anywhere.

 - deep breath -

Now, this is all only true as far as copyright law goes. There are other
sections of the law that can have _other_ limitations. Eg you can limit
yourself contractually or through other means, outside of what copyright
allows you to do.

So to clarify with an example: let's say my _contract_ with OSDL says that
anything I write as an OSDL employee has to be licensed under an
open-source license - but that I can retain copyright to it, ie OSDL
doesn't aquire copyright ownership rights unless I so choose.

What does this mean? _Copyright_ law allows me to take any piece of code I
wrote (say, I could take a few lines from the kernel that I can show that
I own personally), I can take that code and I can license it under any
other license - _despite_ the fact that it is also licensed under the GPL
when it is part of the kernel.

So according to copyright law I can sell that code under any license I
damn well please.

However, my _contract_ with OSDL says that the code I write as an employee
has to be open-sourced, so while I'm not limited by copyright law, I'm
obviously limited by _other_ laws. I can still re-license my code (I'm
still the owner), but now I can only re-license it in specific ways
(because I'm bound by a contract).

		Linus

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Fri, Dec 05, 2003 at 09:48:56PM -0800, Linus Torvalds wrote:
> But I never introduced the notion of being a licensee. I have at all times
> only talked about outright ownership. Sorry if I have been unclear (I
> didn't think I had been, but hey, few people find _themselves_ unclear ;)

Point taken.  You didn't, or at least I don't remember you doing it.
I was thinking about contract law being mixed with copyright law,
specifically the GPL (copyright) and the Unix license (which I believe
to be a contract and as such having nastier viral possibilities).

> Maybe you were confused by the IBM thing, and thinking that when I
> referred to IBM I referred to a licensee. But the fact is, IBM is _not_ a
> licensor of the JFS code etc. They own it outright. Even SCO has
> acknowledged that fact long ago.

Yes but that doesn't mean that SCO doesn't have a contract with IBM
(by way of ATT/Bell Labs) that gives SCO some rights over that code.

That said, I get your point about copyright and ownership.  It's a
good point and should probably be remade each time GPL fud comes up.
The prevailing view amongst manager types is not what you said, over and
over I have seen (as has everyone else) statements that if you combine
your code with GPLed code then your code becomes GPLed.  Period.  But
that's not true, as you pointed out.  If someone wants to keep combining
their code with the GPLed code then they have to offer their code under
the GPL (at the least).  The point that management types will like to hear
is that if someone screws up and puts something out there in binary form
that they shouldn't have, management has a choice.  They can cease and
desist or they have to offer up source under the GPL.

To management, that is a lot less scary than "combine this code and your
code is GPL".  Choice is good.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Theodore Ts'o]

On Fri, Dec 05, 2003 at 09:14:33PM -0800, Larry McVoy wrote:
> Your view that "(b) is compiled into a Linux kernel module, then it
> _is_ part of (a+b) whether (a) is physically present or not." is not
> something that I have managed to seen in any caselaw.  On the other hand,
> it is widely held that you can't force licenses across an API and it's
> perfectly reasonable to see the loadable module interface as an API.

Well, whether or not you can force licenses across an API is not well
settled, as far as I know (IANAL) Microsoft and Apple still have
licenses that try to claim ownership across API's.  And to the extent
that the FSF still tries to claim that programs written to use the GNU
readline library must fall under the GPL, when two other BSD-licensed
implementations of the readline interface exist, they are claiming
exactly the same thing (although the FSF has been known to call for
bycotts of companies that try to claim interfacde copyrights; heh).

Which brings up an interesting point.  The moment someone implements
BSD-licensed code which implements a particular interface, it very
strongly weakens the case that anyone implementing code to that
interface is a derived work of the GPL'ed interface.  This is one of
the reasons why claiming that the GPL can infect across an interface
(whether it is a module interface, a system call interface, or
dynamically linked shared library interface) is bizarre at best.

For example, let me give the following example.  Debugfs of the
e2fsprogs library uses libss, which I recently enhanced to attempt to
dynamically load one of the following libraries via dlopen: readline
(GPL'ed), editline (BSD licensed), or libedit (BSD licensed), which
all export the same interface.  Libss dates back to 1985 or so, and
has a BSD-style license.  It is also used in Kerberos V5 (which is
also BSD licensed), and so Solaris has a propietary derived version of
Krb5 whose administration client uses libss.  So if you compile the
latest version of e2fsprogs on Solaris, and Solaris' krb5 admin client
manages to use the new version of libss, then you could potentially
have in the single address space:

	* Solaris's propietary admin client
	* The libss shared library (BSD)
	* The GPL'ed readline library

OK, riddle me this: is there a GPL violation, and if so, who committed
it?  The user, for running the admin client in this configuration?
But the GPL explicitly says that it's only about distribution, and
doesn't restrict usage in any way, and the end-user is only using the
code.  

Solaris, the owner of the propietary admin client?  But they weren't
involved in my enhancing the libss shared library to dynamically load
either a GPL'ed or a BSD-licensed library, and they created the admin
client before I added the libss enhancement.  And heck, the original
admin client was created by me while I was working at MIT, and is part
of the original MIT Kerberos V5 disitribution (although Sun has
modified it extensively since then).

Me, for modifying a BSD-licensed library to try to dynamically load a
GPL'ed library?  But I was trying to make a perfectly legitimate stack
work:

	* Debugfs (which is GPL'ed)
	* The libss shared library (BSD)
	* The GPL'ed readline library

and the reason why I used dynamic linking was because I wanted debugfs
to only optionally depend on readline library, since the readline
library is a monster (over 600k) and so it wouldn't fit on a rescue
floppy.

So trust me, you really don't want to claim that just because a
program was written to use a particular interface, the license infects
across the API.  Apple and Microsoft are playing that game, and a very
unsavory game it is.  And it leads to all sorts of paradoxes, such as
the one I described above.

						- Ted

Re: Linux GPL and binary module exception clause?

[Jason Kingsland]

"Theodore Ts'o" wrote:
> you could potentially have in the single address space:
>
> * Solaris's propietary admin client
> * The libss shared library (BSD)
> * The GPL'ed readline library
>
> OK, riddle me this: is there a GPL violation, and if so, who committed it?

There is no violation so long as the GPL code isn't being distributed as
part of the Solaris proprietary work. It would be the responsibility of the
distributor (Sun?) to ensure the licenses on everything they distribute are
mutually compatible.

That is specifically the reason for the exception clause in GPL:

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

RE: Linux GPL and binary module exception clause?

[David Schwartz]

> So trust me, you really don't want to claim that just because a
> program was written to use a particular interface, the license infects
> across the API.  Apple and Microsoft are playing that game, and a very
> unsavory game it is.  And it leads to all sorts of paradoxes, such as
> the one I described above.
>
> 						- Ted

	What you want do is claim that taking from a copyrighted work merely what
you need to take from it in order to make your own code interoperate with it
is fair use. If people honestly believe in free software, they should be
making these types of claims.

	DS

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Sat, Dec 06, 2003 at 01:30:39PM -0800, David Schwartz wrote:
> 
> > So trust me, you really don't want to claim that just because a
> > program was written to use a particular interface, the license infects
> > across the API.  Apple and Microsoft are playing that game, and a very
> > unsavory game it is.  And it leads to all sorts of paradoxes, such as
> > the one I described above.
> >
> > 						- Ted
> 
> 	What you want do is claim that taking from a copyrighted work merely what
> you need to take from it in order to make your own code interoperate with it
> is fair use. If people honestly believe in free software, they should be
> making these types of claims.

I agree with David.  The GPL isn't free software it is "open" software,
it wants all the changes to be done out in the open.  Which is perfectly
fine, one can look at the BSD history and the Linux history and argue that
the GPL is what made Linux the "winner".  But GPLed software isn't free, it
is software with an agenda, a noble agenda in many opinions (including mine),
of allowing everyone to benefit from the work and enhancements of the work.

Not everyone likes this, however.  The BK license took a lot of heat for the
fact that we reserved the right to force your repositories out in the open
(because it became clear that some people were using the BK commercially and
not paying license fees).  Even though we were saying "it's free if you are
working out in the open" some free software developers felt that was too 
much (it occurs to me as I'm writing this that what the license should say
is that we can force you to open the repos if and only if the changes have
been pulled to another repo - that would finess security feature problem).
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Ingo Molnar]

On Fri, 5 Dec 2003, Linus Torvalds wrote:

> In other words, if (b) is GPL-only, then you can't use (b) with (c),
> _or_ C has to accept the GPL. "Forcing" a (b+c) doesn't make (c) be
> under the GPL. But forcing (b+c) is illegal, since you can't force a
> license without the agreement of the owner.

i'm wondering why it's layed out like this. Couldnt the FSF have extended
section 6 of the GPL the following way:

ORIGINAL:  6. Each time you redistribute the Program (or any work based on
the Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further restrictions on
the recipients' exercise of the rights granted herein.

[this section is a pure expression of a license from the original author,
covering the original Program only - not the derivative.]

ADDITION:  Each time you redistribute the Program (or any work based on
the Program), the recipient automatically receives a license from you to
copy, distribute or modify those portions ot the Program (or any work
based on the Program), where you are the copyright owner or sublicensor.  
Any existing or future contract or agreement restricting you from doing so
automatically terminates your rights under this License.

or something along these lines. Ie. cannot the act of distribution also
automatically trigger a license from the entity doing the redistribution,
for all portions which are owned by the redistributor? I suspect the FSF
would have done this if legally possible ... so there must be some major
roadblock in the way.

	Ingo

Re: Linux GPL and binary module exception clause?

[Rob Landley]

On Sunday 07 December 2003 07:01, Ingo Molnar wrote:
> On Fri, 5 Dec 2003, Linus Torvalds wrote:
> > In other words, if (b) is GPL-only, then you can't use (b) with (c),
> > _or_ C has to accept the GPL. "Forcing" a (b+c) doesn't make (c) be
> > under the GPL. But forcing (b+c) is illegal, since you can't force a
> > license without the agreement of the owner.
>
> i'm wondering why it's layed out like this. Couldnt the FSF have extended
> section 6 of the GPL the following way:
>
> ORIGINAL:  6. Each time you redistribute the Program (or any work based on
> the Program), the recipient automatically receives a license from the
> original licensor to copy, distribute or modify the Program subject to
> these terms and conditions. You may not impose any further restrictions on
> the recipients' exercise of the rights granted herein.
>
> [this section is a pure expression of a license from the original author,
> covering the original Program only - not the derivative.]
>
> ADDITION:  Each time you redistribute the Program (or any work based on
> the Program), the recipient automatically receives a license from you to
> copy, distribute or modify those portions ot the Program (or any work
> based on the Program), where you are the copyright owner or sublicensor.
> Any existing or future contract or agreement restricting you from doing so
> automatically terminates your rights under this License.

The GPL really needs an improved clause about patent licensing too.  (The GPL 
could easily be a patent pool.  Right now the language says that patents must 
be licensed for use by everybody, when all it really NEEDS to say is that the 
patent needs to be licensed for use in GPL programs.  in regards to patents, 
the GPL acts like the BSD license, rather than copyleft, and that would be 
really easy to fix.)

The GPL is sort of becoming a patent pool anyway, with Red Hat licensing its 
patents for use in GPL programs only, and IBM making noises about that, 
etc...  But it's not explicit, and it's not really one pool that you join 
automatically by participating, and that violation of the GPL could block you 
from access to all of...

Richard Stallman, unfortunately, is a zealot.  He wants to log roll a whole 
bunch of things like addressing the application service provider issue into a 
GPL 3.0, which means there probably never will be a GPL 3.0.  And he won't 
issue a GPL 2.1 with minor issues like these because that would erode the 
chocolate coating on the other unpopular issues he wants to lump together 
into a big "take it or leave it" upgrade at some nebulous point in the future 
that pushes unpopular elements of his agenda as part of the package...

Sad, really.  Oh well.  I suppose somebody could come out with a "GPL patent 
pool license", which might not violate the GPL.  The preamble says "we have 
made it clear that any patent must be licensed for everyone's free use or not 
licensed at all", but doesn't say who everyone is (since the license only 
applies to people who accept the license, then it could logically be 
"everyone who agrees to the GPL".)  Clauses 7 and 8 mention patents, but 
don't specify any license terms for them.  Therefore, you NEED a patent 
license, but the GPL doesn't give the text of it.

So if the GPL is just a copyright license, and it requires patents be licensed 
but doesn't specify the terms, therefore it's legal (and in fact expected) to 
combine the GPL with a (compatable) patent license.  But there IS no standard 
GPL patent license.  It would be nice if there was one, that could be 
regularly combined with the GPL in a standard way (GPL+), saying that the 
patents are licensed for use in GPL-licensed software only, as part of a GPL 
patent pool.

It's one way to bypass Stallman's log-rolling, anyway...

Rob

Re: Linux GPL and binary module exception clause?

[Andrew Pimlott]

On Fri, Dec 05, 2003 at 07:00:37PM -0800, Larry McVoy wrote:
> In my opinion, you are playing with fire and playing well into SCO's
> hands.  I haven't read the original Unix license but I have heard that
> it had a somewhat similar viral effect, like the GPL does.  I've heard
> that it claims ownership of derived works, which I doubt is true.
> But I've also heard that it claimed certain distribution rights for
> derived works and that I do believe.  It's entirely plausible that a
> commercial entity would have a license which says "you can't build on
> my work and give to someone who hasn't also obtained a license from us".
> Makes perfect sense and is quite likely.
> 
> However, if someone did take derived code (which is now covered by the
> viral license) and add it illegally to Linux, it is entirely reasonable
> for the license holder to say that all of Linux now has the virus.  Just
> as reasonable as someone saying "hey, that's the Linux XYZ driver in 
> Solaris, Solaris is now GPLed".

This last is unfounded.  It may be true to say that Sun could only
release Solaris+XYZ under the GPL, but it is fantasy to imagine that
this makes Solaris now GPLed.  That is simply not one of the
available legal remedies for breach of a copyright license.  Pamela
Jones of groklaw.net fame wrote a more authoritative article
covering this point at http://lwn.net/Articles/61292/ (unfortunately
subscriber-only for the next week, I think).  She cited (FSF's
lawyer) Eben Moglen:

    The claim that a GPL violation could lead to the forcing open of
    proprietary code that has wrongfully included GPL'd components
    is simply wrong. There is no provision in the Copyright Act to
    require distribution of infringing work on altered terms. What
    copyright plaintiffs are entitled to, under the Act, are
    damages, injunctions to prevent infringing distribution,
    and--where appropriate--attorneys' fees. A defendant found to
    have wrongfully included GPL'd code in its own proprietary work
    can be mulcted in damages for the distribution that has already
    occurred, and prevented from distributing its product further.
    That's a sufficient disincentive to make wrongful use of GPL'd
    program code. And it is all that the Copyright Act permits.

(At first, I had hoped that "mulcted" was a typo for "mulched", but
then I looked it up.)

It might be true that Sun's misdeed perpetually voids their license
to XYZ.  RMS argued similarly after QT was GPLed to accomodate KDE
(and explicitly "forgave" the breach wrt FSF-owned code).  But this
is entirely different from forcing anyone to put their own code
under some particular license.

> There seems to be this sentiment (a pleasant one) in this community that
> if you do the wrong thing and then undo it, all is forgiven.  That's not
> how the license reads.  The GPL doesn't say "if you uncombine the work you
> are no longer obligated to obey the GPL".  Neither would any other license.

Again, totally groundless AFAICT.  This is not within the scope of
what a copyright license can require, and runs directly counter to
my (meager) knowledge of case law.  Courts generally don't force
violators to license material under specific terms (except perhaps
in antitrust cases).

> Roll forward a bit and see how this plays out in court.  Suppose there is
> code in Linux that is derived from Unix.  Remember, if Unix licenses had
> the same viral effect as the GPL, all it takes is a function or two and
> the rest of the code is GPL-ed (or in this case, Unix-ed).  If you are
> arguing that an API isn't a boundary for the GPL you are going to look
> bloody two faced when you go and argue that an API is a boundary for Unix.

Your comparisons to the SCO case are far-fetched.  In part because
of what I said above (your idea of "viral" is divorced from
reality), and in part because there is a diverse range of
boundaries, and any judge can see that there is a wide gulf between
the kernel-module boundary and the unix-"anything that's ever
touched unix even through N indirections" boundary.  We are not on a
slippery slope.

> And all of this discussion is nicely indexed by Google for SCO's lawyers
> to dig through and say "see, the leader of Linux doesn't think that
> boundaries apply.  Linux is now covered *completely* by the SCO Unix
> license.  Pay up".

You seem to think that this boundary thing is black and white.  "If
the GPL crosses the kernel-module boundary, any license can cross
any boundary."  I think you have to do better than that.

Andrew

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Sat, Dec 06, 2003 at 09:13:00AM -0500, Andrew Pimlott wrote:
> On Fri, Dec 05, 2003 at 07:00:37PM -0800, Larry McVoy wrote:
> This last is unfounded.  It may be true to say that Sun could only
> release Solaris+XYZ under the GPL, but it is fantasy to imagine that
> this makes Solaris now GPLed.  

Right you are, my apologies.  My brain was in contract space, not
copyright space.  

>     and--where appropriate--attorneys' fees. A defendant found to
>     have wrongfully included GPL'd code in its own proprietary work
>     can be mulcted in damages for the distribution that has already
>     occurred, and prevented from distributing its product further.
>     That's a sufficient disincentive to make wrongful use of GPL'd
>     program code. And it is all that the Copyright Act permits.
> 
> (At first, I had hoped that "mulcted" was a typo for "mulched", but
> then I looked it up.)

I did too, for those who didn't, it's an old word with two meanings and 
the meaning here (I am pretty sure) is "punished with a fine".  Leave it
to a lawyer to know that one :)

> It might be true that Sun's misdeed perpetually voids their license
> to XYZ.  

That's a good question, it's not clear what the answer to that is.  I reread
the GPL and I don't see where it spells out what happens if you try and cheat.

> > Roll forward a bit and see how this plays out in court.  Suppose there is
> > code in Linux that is derived from Unix.  Remember, if Unix licenses had
> > the same viral effect as the GPL, all it takes is a function or two and
> > the rest of the code is GPL-ed (or in this case, Unix-ed).  If you are
> > arguing that an API isn't a boundary for the GPL you are going to look
> > bloody two faced when you go and argue that an API is a boundary for Unix.
> 
> Your comparisons to the SCO case are far-fetched.  In part because
> of what I said above (your idea of "viral" is divorced from
> reality)

In copyright law, yes.  Contract law is a bit different.  Linus and
you yanked me back into copyright law and you're right that SCO can't
claim rights to Linux, they don't own it.  But isn't it true that if
the Unix license they have with IBM (actually more likely Sequent) is a
contract then that contract could extend to anything that was originally
written in the context of Unix, even if 100% of was written by Sequent
and removed from Unix and ported to Linux?

If I wrote a contract that gave you rights to use and extend some program
I wrote and I put into that contract that you may not distribute any code
that was written as part of the program to a third party that did not have
a license, isn't that legal?

And if it is, which I believe to be true, and if you wrote a new widget
that was originally done in the context of that program but now wanted
to put that widget someplace else and the widget removed all references
to the original program, do I still have any contractially based rights
to that widget?  This is the crucial question for SCO.  I doubt that
the answer is really simple but I think that the answer has a lot to do 
with the concept of a boundary which is why I keep harping on that.

> You seem to think that this boundary thing is black and white.  "If
> the GPL crosses the kernel-module boundary, any license can cross
> any boundary."  I think you have to do better than that.

Nothing in law is black and white, it's all sorted out in caselaw
typically.  But as far as I can tell there has to be some way to limit
the influence of a contract or a license or otherwise everything that
ran on a GPLed kernel would be GPLed (the HURD is a GPLed kernel, right?
How much you want to bet that the FSF is not going to try and make the
claim that userland has to be GPLed?)

My guess is that at some point there will be a court case that clarifies
fair use for code and the clarification will be focussed on the concept
of a boundary with the definition of the boundary being the ability to
replace one section of the program with a different work, said work not
be derived from the program, and have the program continue to operate
as it did before.  I.e., a different userland implementation of "cat"
shows that the kernel can't infect userland, a different implementation
of libc.so shows that libc can't infect user programs.

The sticky one is the one where we started, kernel modules.  Linus is
saying that kernel modules are covered by the GPL because they are
combined with the kernel.  I think his reasoning is weak and unlikely
to be upheld by the courts.  If we remove the issue of inline functions
for a moment then we are talking about pure API's and there is no way
that the courts are going to uphold that a copyright license can cross a
pure API (famous last words).  Well, no way if both sides of the dispute
have equally good lawyers, without that who knows.  Let's just suppose
that things work out reasonably and the courts say that using an API
is "fair use".  That leaves the inline functions.  If they are small I
believe there is a lot of precedent for ignoring them.  Even the FSF says
that one liner patches don't need copyright assignment to the FSF.  And if
the module doesn't use those functions or provides their own version of
those functions then I doubt that the inline functions have any bearing.
Comments?
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Theodore Ts'o]

On Sat, Dec 06, 2003 at 09:50:41AM -0800, Larry McVoy wrote:
> The sticky one is the one where we started, kernel modules.  Linus is
> saying that kernel modules are covered by the GPL because they are
> combined with the kernel.  I think his reasoning is weak and unlikely
> to be upheld by the courts.  If we remove the issue of inline functions
> for a moment then we are talking about pure API's and there is no way
> that the courts are going to uphold that a copyright license can cross a
> pure API (famous last words).  Well, no way if both sides of the dispute
> have equally good lawyers, without that who knows.  

I had a law professor from the MIT Sloan School of Technology, who
when I posed the question informally, said that the FSF would be
laughed out of court if they tried to claim that the GPL infected
across API's.  But Larry's right, in the U.S. at least, you get the
best justice money can buy, and with enough high-paid lawyers and
lobbyist, you can probably pervert the system any way you like ---
witness the RIAA and DMCA.

But that aside, does the Open Source community really want to push for
the legal principal that just because you write an independent program
which uses a particular API, the license infects across the interface?
That's essentially interface copyrights, and if say the FSF were to
file an amicus curiae brief support that particular legal principle in
an kernel modules case, it's worthwhile to think about how Microsoft
and Apple could use that case law to f*ck us over very badly.  

It would mean that we would not be able to use Microsoft DLL's in
programs like xine.  It would mean that programs like Crossover office
wouldn't work.  It would mean that Apple could legally prohibit people
from writing enhancements to MacOS (for example, how do all of the
various extensions in Mac OS 9 work?  They link into the operating
system and modify its behaviour.  If they are therefore a derived work
of MacOS, then Apple could screw over all of the people who write
system extensions of MacOS.)  

Be careful of what you wish for, before you get it.  The ramifications
of the statement that just because a device driver is written for
Linux, that it is presumptively a derived work of Linux unless proven
otherwise, is amazingly scary.  Fortunately, we can hope that the law
professor I talked to was right, and that such a claim would be
laughed out of court.  But if it isn't, look to Microsoft and other
unsavory companies to use that kind of case law to completely screw us
to the wall.....

						- Ted

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Sat, Dec 06, 2003 at 04:19:00PM -0500, Theodore Ts'o wrote:
> But that aside, does the Open Source community really want to push for
> the legal principal that just because you write an independent program
> which uses a particular API, the license infects across the interface?
> That's essentially interface copyrights, and if say the FSF were to
> file an amicus curiae brief support that particular legal principle in
> an kernel modules case, it's worthwhile to think about how Microsoft
> and Apple could use that case law to f*ck us over very badly.  
> 
> It would mean that we would not be able to use Microsoft DLL's in
> programs like xine.  It would mean that programs like Crossover office
> wouldn't work.  It would mean that Apple could legally prohibit people
> from writing enhancements to MacOS (for example, how do all of the
> various extensions in Mac OS 9 work?  They link into the operating
> system and modify its behaviour.  If they are therefore a derived work
> of MacOS, then Apple could screw over all of the people who write
> system extensions of MacOS.)  
> 
> Be careful of what you wish for, before you get it.  The ramifications
> of the statement that just because a device driver is written for
> Linux, that it is presumptively a derived work of Linux unless proven
> otherwise, is amazingly scary.  Fortunately, we can hope that the law
> professor I talked to was right, and that such a claim would be
> laughed out of court.  But if it isn't, look to Microsoft and other
> unsavory companies to use that kind of case law to completely screw us
> to the wall.....

What Ted is saying is precisely what I have been trying to say for a long
time, he just said it better (thanks Ted).

If you want the rules to work a particular way when they benefit you you
have to be prepared to deal with it when someone else invokes the same 
rules against you.

I'm with Ted on this one, big time.  I agree that it is opening the door to
unbelievable amounts of bad juju from the corporate folks if licenses can
infect across APIs.  I'd personally like it if contracts couldn't do this
either.  The whole thing gives me more willies than the DMCA.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Andrew Pimlott]

On Sat, Dec 06, 2003 at 09:50:41AM -0800, Larry McVoy wrote:
> On Sat, Dec 06, 2003 at 09:13:00AM -0500, Andrew Pimlott wrote:
> > It might be true that Sun's misdeed perpetually voids their license
> > to XYZ.  
> 
> That's a good question, it's not clear what the answer to that is.  I reread
> the GPL and I don't see where it spells out what happens if you try and cheat.

FWIW, here's what RMS said:

    Misusing a GPL-covered program permanently forfeits the right to
    distribute the code at all. 

    http://linuxtoday.com/news_story.php3?ltsn=2000-09-05-001-21-OP-LF-KE

> > Your comparisons to the SCO case are far-fetched.  In part because
> > of what I said above (your idea of "viral" is divorced from
> > reality)
> 
> In copyright law, yes.  Contract law is a bit different.  Linus and
> you yanked me back into copyright law and you're right that SCO can't
> claim rights to Linux, they don't own it.  But isn't it true that if
> the Unix license they have with IBM (actually more likely Sequent) is a
> contract then that contract could extend to anything that was originally
> written in the context of Unix, even if 100% of was written by Sequent
> and removed from Unix and ported to Linux?

I guess I can't disagree in principle that a contract could cross
almost any boundary.  But it seems vanishingly unlikely that anyone
(not to speak of IBM) would agree to a contract with such
boundary-piercing powers as SCO claims.  For this reason, I don't
think that even the most bold claims for the GPL's virulence help
SCO one bit.  On the contrary, any intelligent discussion of
boundaries can only undermine SCO's nonsensical case.

I agree with you about the importance of figuring out where the
boundaries lie.  I also wish the FSF would get more involved in this
debate, but I have to say, they seem to be avoiding the hard
questions, perhaps because they're afraid to say anything that will
restrict them later.  The best statement I think I've read from them
is

    http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem

which introduces an "arms length" standard.

> And if it is, which I believe to be true, and if you wrote a new widget
> that was originally done in the context of that program but now wanted
> to put that widget someplace else and the widget removed all references
> to the original program, do I still have any contractially based rights
> to that widget?

For me, this doesn't pass the giggle test.

> Nothing in law is black and white, it's all sorted out in caselaw
> typically.  But as far as I can tell there has to be some way to limit
> the influence of a contract or a license or otherwise everything that
> ran on a GPLed kernel would be GPLed (the HURD is a GPLed kernel, right?
> How much you want to bet that the FSF is not going to try and make the
> claim that userland has to be GPLed?)

They seem to have waived that claim, at least, by deeming system
calls "arms length" communication.

Andrew

Re: Linux GPL and binary module exception clause?

[David Woodhouse]

On Thu, 2003-12-04 at 17:58 -0800, Linus Torvalds wrote:
> But a license only covers what it _can_ cover - derived works. The fact
> that Linux is under the GPL simply _cannot_matter_ to a user program, if
> the author can show that the user program is not a derived work.

Not so. You, as author of the GPL'd work, are granting permission for
someone else to make use of it (other than 'fair use' which they were
already permitted).

Your conditions for granting that permission do _not_ have to be
restricted to licensing of derived works. You can even ask for _money_
in return, if you like. Or you could require that the lucky recipient
bathe in creosote daily, in order to receive your licence.

I could write a piece of software and tell you that you're only allowed
to use it if you release _all_ future software you write under the GPL.
Even stuff which isn't at all related, let alone non-derived.

It wouldn't be illegal for you to create your own non-GPL software per
se; it would just mean you don't have permission to use what _I_ had
written and released under this hypothetical licence.

You'd probably have to be mad to accept this licence, and of course I
don't argue that the GPL actually goes _that_ far, but a copyright
licence certainly _can_ do so.

The GPL explicitly does make reference to required licensing terms for
non-derived works in certain circumstances, even those which can
reasonably be considered separate and independent works in themselves. 

There is no question that, as a copyright licence, the GPL _can_ extend
to a non-derived work; and in some circumstances it clearly _does_. 

-- 
dwmw2

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

> There is no question that, as a copyright licence, the GPL _can_ extend
> to a non-derived work; and in some circumstances it clearly _does_.

David,

Would you be kind enough to list "some circumstances" ?
Also the authoritative (sp) reference supporting the list.

Just spell it out for us who are a little slow in the wee hours of the
morning.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 11 Dec 2003, David Woodhouse wrote:

> On Thu, 2003-12-04 at 17:58 -0800, Linus Torvalds wrote:
> > But a license only covers what it _can_ cover - derived works. The fact
> > that Linux is under the GPL simply _cannot_matter_ to a user program, if
> > the author can show that the user program is not a derived work.
> 
> Not so. You, as author of the GPL'd work, are granting permission for
> someone else to make use of it (other than 'fair use' which they were
> already permitted).
> 
> Your conditions for granting that permission do _not_ have to be
> restricted to licensing of derived works. You can even ask for _money_
> in return, if you like. Or you could require that the lucky recipient
> bathe in creosote daily, in order to receive your licence.
> 
> I could write a piece of software and tell you that you're only allowed
> to use it if you release _all_ future software you write under the GPL.
> Even stuff which isn't at all related, let alone non-derived.
> 
> It wouldn't be illegal for you to create your own non-GPL software per
> se; it would just mean you don't have permission to use what _I_ had
> written and released under this hypothetical licence.
> 
> You'd probably have to be mad to accept this licence, and of course I
> don't argue that the GPL actually goes _that_ far, but a copyright
> licence certainly _can_ do so.
> 
> The GPL explicitly does make reference to required licensing terms for
> non-derived works in certain circumstances, even those which can
> reasonably be considered separate and independent works in themselves. 
> 
> There is no question that, as a copyright licence, the GPL _can_ extend
> to a non-derived work; and in some circumstances it clearly _does_. 
> 
> -- 
> dwmw2
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Linux GPL and binary module exception clause?

[David Woodhouse]

On Thu, 2003-12-11 at 04:42 -0800, Andre Hedrick wrote:
> Would you be kind enough to list "some circumstances" ?

You have a work which is not derived and can reasonably be considered an
independent and separate work in itself, but instead of distributing it
as a separate work you distribute it as part of a whole which is a work
based on a GPL'd Program.

The precise meaning of 'as separate works' and 'part of a whole which is
a work based on the Program' isn't entirely unambiguous. 

The GPL tries to clarify it by ruling out 'mere aggregation...on a
volume of a storage or distribution medium' but stating its intent to
control 'collective works'. There's still a little scope for
interpretation though.

My point, however, was that a copyright licence _can_ make such
requirements. It _can_ require you to bathe daily in creosote too, and
if you don't like that you have the option of not using the software
which is licensed that way.

> Also the authoritative (sp) reference supporting the list.

Section 2 of the GPL, which I quoted only moments ago.

-- 
dwmw2

Re: Linux GPL and binary module exception clause?

[Brian Beattie]

On Thu, 2003-12-11 at 07:58, David Woodhouse wrote:

> My point, however, was that a copyright licence _can_ make such
> requirements. It _can_ require you to bathe daily in creosote too, and
> if you don't like that you have the option of not using the software
> which is licensed that way.

I'd be willing to bet, that since bathing in creosote is extremely
unhealthy, the courts might well find that that restriction was
nonsense.  This being the case they might decide that taken as a whole
the license was a fraud and grant the public the right to unrestricted
use of the product in question.  Especially if the defendants lawyer was
particularly good.
-- 
Brian Beattie            | Experienced kernel hacker/embedded systems
beattie@beattie-home.net | programmer, direct or contract, short or
www.beattie-home.net     | long term, available immediately.

"Honor isn't about making the right choices.
It's about dealing with the consequences." -- Midori Koto

Re: Linux GPL and binary module exception clause?

[David Woodhouse]

On Fri, 2003-12-12 at 15:26 -0500, Brian Beattie wrote:
> I'd be willing to bet, that since bathing in creosote is extremely
> unhealthy, the courts might well find that that restriction was
> nonsense.  This being the case they might decide that taken as a whole
> the license was a fraud and grant the public the right to unrestricted
> use of the product in question.  Especially if the defendants lawyer was
> particularly good.

The misuse of copyright defence is _very_ limited, and it's not about
being reasonable or healthy.

If I charged money for my licence _and_ made the creosote requirement,
perhaps the court would be able to find a legal loophole which hasn't
yet been mentioned.

The court is much less likely to attempt this if the creosote is the
_only_ thing I'm asking for, and if that's the whole raison d'etre of my
licence, and the only reason I'm letting you use my work in the first
place.

Otherwise where does it end? I tell you that you can use my software
'when Hell freezes over' and since that's also unreasonable you get to
use it without restriction? :)

-- 
dwmw2

Re: Linux GPL and binary module exception clause?

[jeff millar]

Irony alert!

----- Original Message ----- 
From: "David Woodhouse" <dwmw2@infradead.org>

.................
> 
> Otherwise where does it end? I tell you that you can use my software
> 'when Hell freezes over' 

Isn't that about what Congress does with copyright extensions?

and since that's also unreasonable you get to
> use it without restriction? :)

And is that about what the population does with Kazaa?

Re: Linux GPL and binary module exception clause?

[Gene Heskett]

On Saturday 13 December 2003 07:03, David Woodhouse wrote:
>On Fri, 2003-12-12 at 15:26 -0500, Brian Beattie wrote:
>> I'd be willing to bet, that since bathing in creosote is extremely
>> unhealthy, the courts might well find that that restriction was
>> nonsense.  This being the case they might decide that taken as a
>> whole the license was a fraud and grant the public the right to
>> unrestricted use of the product in question.  Especially if the
>> defendants lawyer was particularly good.
>
>The misuse of copyright defence is _very_ limited, and it's not
> about being reasonable or healthy.
>
>If I charged money for my licence _and_ made the creosote
> requirement, perhaps the court would be able to find a legal
> loophole which hasn't yet been mentioned.
>
>The court is much less likely to attempt this if the creosote is the
>_only_ thing I'm asking for, and if that's the whole raison d'etre
> of my licence, and the only reason I'm letting you use my work in
> the first place.
>
>Otherwise where does it end? I tell you that you can use my software
>'when Hell freezes over' and since that's also unreasonable you get
> to use it without restriction? :)

Chuckle...  Hell quite often freezes over, or up as they say.

Hell, Michigan that is. :-)

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Linux, Inc. (Re: Linux GPL and binary module exception clause?)

[Andre Hedrick]

How about a charter orgainization called Linux, Inc. or The Linux
Foundation ?

CEO Linus Torvalds <aka ph> :-)
---
fill in the blanks.
---
CSA me <chief smart arse>

Now Linux, Inc is designed to regulate the commerial use of Linux and
defend the legal causes and actions of the kernel.  Everything has a cost.
Any company, organization, country, or what ever is required to pay 10% of
gross sales associated with products ship with Linux kernel inside,
period.

Distributions
Big Storage Companies
Big Box builders
Big Appliance Builders
blah blah ....
Set Top boxes
Firewall/VPN

Anybody who sells a product w/ the Linux Kernel as its base.

Now all the FSF/GPL supporting user space applications can go see FSF and
company because I do not give a damn about there issues.  They are l^Huser
land.

Now this allows for commerial adoption and commerial licnesing of Linux.
If this offer and idea is rejected then it proves the lack of seriousness
in the original goals of "world domination".

10% of Redhat,SuSE(Novell),Mandrake,Conectiva,UnitedLinux,...
10% of EMC,HP,IBM,Dell,Intel,...
10% of CGL people,...
10% of Rackable,Google,...
10% of the little guys ...

Now what to do with the money.

Hire really good SHARKS and ACCOUNTANTS ...
Fund and promote opensource development like a foundation ...
Yeah it starts to look like a business and that is what Linux needs.

Yeah, this is to simple and easy of an idea.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: Linux, Inc. (Re: Linux GPL and binary module exception clause?)

[Andre Hedrick]

Part II ...

Given the issue of binary module vendors not native to Linux rules and
standards, there becomes a need for a review body.  Given the problem of
most binary vendors are idiots and clueless, it provides a certification
for a given kernel.

It is short of racketeiring (sp) but it mean nobody gets to use all of
our hard work with out paying for it.  This is fair and equitable.

Oh yeah in order to be invited to the board or advisory board you have to
have some time in slavery to the kernel and continue to contribute.  Yeah
I am back off the nutter wagon and running around free again!

Dave Miller, can we have linux-wackos :-)

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Sat, 13 Dec 2003, Andre Hedrick wrote:

> 
> How about a charter orgainization called Linux, Inc. or The Linux
> Foundation ?
> 
> CEO Linus Torvalds <aka ph> :-)
> ---
> fill in the blanks.
> ---
> CSA me <chief smart arse>
> 
> Now Linux, Inc is designed to regulate the commerial use of Linux and
> defend the legal causes and actions of the kernel.  Everything has a cost.
> Any company, organization, country, or what ever is required to pay 10% of
> gross sales associated with products ship with Linux kernel inside,
> period.
> 
> Distributions
> Big Storage Companies
> Big Box builders
> Big Appliance Builders
> blah blah ....
> Set Top boxes
> Firewall/VPN
> 
> Anybody who sells a product w/ the Linux Kernel as its base.
> 
> Now all the FSF/GPL supporting user space applications can go see FSF and
> company because I do not give a damn about there issues.  They are l^Huser
> land.
> 
> Now this allows for commerial adoption and commerial licnesing of Linux.
> If this offer and idea is rejected then it proves the lack of seriousness
> in the original goals of "world domination".
> 
> 10% of Redhat,SuSE(Novell),Mandrake,Conectiva,UnitedLinux,...
> 10% of EMC,HP,IBM,Dell,Intel,...
> 10% of CGL people,...
> 10% of Rackable,Google,...
> 10% of the little guys ...
> 
> Now what to do with the money.
> 
> Hire really good SHARKS and ACCOUNTANTS ...
> Fund and promote opensource development like a foundation ...
> Yeah it starts to look like a business and that is what Linux needs.
> 
> Yeah, this is to simple and easy of an idea.
> 
> Cheers,
> 
> Andre Hedrick
> LAD Storage Consulting Group
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Linux, Inc. (Re: Linux GPL and binary module exception clause?)

[David S. Miller]

On Sat, 13 Dec 2003 17:06:50 -0800 (PST)
Andre Hedrick <andre@linux-ide.org> wrote:

> Dave Miller, can we have linux-wackos :-)

No, but I'll happily give you linux-fantasy or linux-utopia. :)

Re: Linux, Inc. (Re: Linux GPL and binary module exception clause?)

[Andre Hedrick]

Deal!

It also give a place to redirect all future threads and keep it of
linux-kernel, and you can apply something you really want ...

KILL THREAD !! :-)

linux-utopia-fantasy@vger.kernel.org

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Sat, 13 Dec 2003, David S. Miller wrote:

> On Sat, 13 Dec 2003 17:06:50 -0800 (PST)
> Andre Hedrick <andre@linux-ide.org> wrote:
> 
> > Dave Miller, can we have linux-wackos :-)
> 
> No, but I'll happily give you linux-fantasy or linux-utopia. :)
> 

Re: Linux, Inc. (Re: Linux GPL and binary module exception clause?)

[Rob Landley]

On Saturday 13 December 2003 19:06, Andre Hedrick wrote:
> Part II ...
>
> Given the issue of binary module vendors not native to Linux rules and
> standards, there becomes a need for a review body.

And thus a new layer of bureaucracy would be added to address a non-problem.
Study the history of usenix, will you?  Pay special attention to how it killed 
Atlanta Linux Showcase.  (Ask Peter Salus.)

>  Given the problem of
> most binary vendors are idiots and clueless, it provides a certification
> for a given kernel.

Sturgeon's law says that 90% of them are going to be clueless idiots, but 
that's nothing special.  The ones who make the binary modules that we 
actually care about are the 10% that _aren't_.

Nvidia, specifically, would love to release its code but it can't due to 
having licensed chunks of it from suppliers.  (Nvidia doesn't own all its own 
IP, it licenses huge chunks of it.)

> It is short of racketeiring (sp) but it mean nobody gets to use all of
> our hard work with out paying for it.  This is fair and equitable.

If you're mad that people use your hard work without paying for it, you have 
missed the entire POINT of open source.

I, personally, am fairly certain I have never paid you a dime.  My laptop has 
IDE in it, so I'd guess I'm using your work.  You have my thanks.  You do not 
have any of my money.  If this really bothers you, put a paypal link on your 
web page.

> Oh yeah in order to be invited to the board or advisory board you have to
> have some time in slavery to the kernel and continue to contribute.  Yeah
> I am back off the nutter wagon and running around free again!

I've run volunteer organizations.  I co-founded Penguicon, and I'm doing 
another one called Linucon here in Austin.  I put about $1000 of my own money 
into Penguicon, and I'm probably going to put more than that into Linucon, 
yet nobody involved with it actually got paid.  It was entirely volunteer 
run.  Even our guests of honor didn't get paid.  We flew Terry Pratchett in 
from England (a man who claims he had to switch banks having "filled the 
first one up" with book royalties), and although we bought his plane ticket, 
hotel room, and meals, we didn't actually give the man a dime.  (We did give 
him a badge ribbon that said "Geek", though, but that was more an award.)  
And he agreed to do it, and an important part was that nobody ELSE involved 
with it was paid a dime either, so it was hard to be jealous.

You've never run a volunteer effort.  It shows.  You clearly, profoundly, DO 
NOT UNDERSTAND how it works.  I admit it's a fairly tough thing to learn 
about from outside...

Here, this absolutely _sucks_, but it's the closest to a related write-up I've 
done:

http://www.fool.com/news/foth/2000/foth000731.htm
http://www.fool.com/news/foth/2000/foth000913.htm
http://www.fool.com/news/foth/2000/foth000905.htm
http://www.fool.com/news/foth/2000/foth000918.htm
http://www.fool.com/news/foth/2000/foth000925.htm
http://www.fool.com/portfolios/rulemaker/2000/rulemaker000928.htm
http://www.fool.com/news/foth/2000/foth001002.htm

And some australian woman's follow-up...

http://www.firstmonday.dk/issues/issue6_3/doheny/

I've needed to do a better write-up of this (that isn't stale, wrong in 
places, profoundly incomplete, and for a business audience) for years.  Bug 
me off-list if you're interested...

Rob

(Darn it, I ran a PANEL on this at Penguicon, with Jay Maynard of the Hercules 
project.  I just haven't got a convenient write-up I can point you to...)

Re: Linux, Inc. (Re: Linux GPL and binary module exception clause?)

[Rob Landley]

I suspect most people are going to ignore this message because it's so out 
there and loopy, but I thought I'd address it because I think Andre is 
serious.

On Saturday 13 December 2003 18:51, Andre Hedrick wrote:
> How about a charter orgainization called Linux, Inc. or The Linux
> Foundation ?

Why not an organization called OSDL?

> CEO Linus Torvalds <aka ph> :-)

Because he doesn't want to.

> Now Linux, Inc is designed to regulate the commerial use of Linux and

Regulating the commercial use of open source code.  Uh-huh.  And you honestly 
don't know why this won't work?

> defend the legal causes and actions of the kernel.  Everything has a cost.
> Any company, organization, country, or what ever is required to pay 10% of
> gross sales associated with products ship with Linux kernel inside,
> period.

Isn't this what SCO is trying to do?  Make everybody who ships Linux pay them 
money?  (And if them requiring money from people just to use Linux violates 
the GPL, why would _you_ be able to force people to?  We have a hard enough 
time getting source code out of people in basic compliance with the license 
terms, and you want money out of them, potentially in violation of the 
license?)

Alright, ignore that for a moment.  Think back: what if everybody who wanted 
to assemble a PC had to pay for a license to do so?  How far would PC 
hardware have gone?  On the left, you have the ISA bus, which is free to use.  
On the right, you have the micro-channel bus, which is patented and required 
a fee.

Which won in the open market?

> Now this allows for commerial adoption and commerial licnesing of Linux.

Excuse me, we HAVE commercial adoption and commercial licensing of Linux.  We 
have IBM putting a billion a year into it and HP putting $IBM*2 a year into 
their press releases.  Did you miss that memo?

> If this offer and idea is rejected then it proves the lack of seriousness
> in the original goals of "world domination".

PC hardware managed to avoid requiring anybody pay licensing fees for the 
basic design for 20 years now.  People have voluntarily joined consortia, but 
they haven't had to buy a license just to belong to the club of white box 
manufacturers or component vendors.

> 10% of the little guys ...

I've worked for little guys that this would have bankrupted.  And if such a 
requirement had been in place, I would have recommended that they use 
FreeBSD, technical merit notwithstanding.

> Now what to do with the money.

Belling the cat.

"Gee, if we only had a gazaillion dollars..."

> Hire really good SHARKS and ACCOUNTANTS ...
> Fund and promote opensource development like a foundation ...

There's about fifty.  Perl's got a foundation, Gnome has a foundation, KDE has 
a foundation...  Eric Raymond's most recent pet project was the Open Source 
Awards, which among other things involved giving cash to people who had done 
neat hacks.  (Sponsored by C/Net, if I remember...)

> Yeah it starts to look like a business and that is what Linux needs.

BeOS looked like a business.  OS/2 looked like a business.  Geos looked a lot 
like a business.  Desqview/X looked like a business.  AmigaOS looked like a 
business.

Ret Hat looks like a business.  Novell/SuSE looks like a business.  Lindows 
looks like a business.  (I'm not sure they ARE, but they LOOK like one...)

> Yeah, this is to simple and easy of an idea.

There's an old saying: "For every problem, there is a solution that's simple, 
easy, and wrong."  You're trying to address a problem that doesn't exist with 
a solution that nobody would support, and you're implying that the entire 
rest of the world is either stupid or not serious if they don't think you're 
idea is worth even the amount of attention it takes to respond negatively.

There are hundreds of thousands of people in the world who make their living 
from Linux right now.  Capitalism says that a couple percent of them are 
going to get royally screwed, no matter WHAT it is...

> Cheers,
>
> Andre Hedrick
> LAD Storage Consulting Group

Rob

Re: Linux GPL and binary module exception clause?

[Andrew Pimlott]

On Thu, Dec 11, 2003 at 12:37:58PM +0000, David Woodhouse wrote:
> Your conditions for granting that permission do _not_ have to be
> restricted to licensing of derived works. You can even ask for _money_
> in return, if you like. Or you could require that the lucky recipient
> bathe in creosote daily, in order to receive your licence.

NAL, but look up "misuse of copyright".  You can't just require
whatever pleases your fancy.

Eg,

    http://www.digital-law-online.com/lpdi1.0/cases/15PQ2D1846.htm

> I could write a piece of software and tell you that you're only allowed
> to use it if you release _all_ future software you write under the GPL.
> Even stuff which isn't at all related, let alone non-derived.

Highly doubtful.

Andrew

Re: Linux GPL and binary module exception clause?

[David Woodhouse]

On Thu, 2003-12-11 at 08:54 -0500, Andrew Pimlott wrote:
> NAL, but look up "misuse of copyright".  You can't just require
> whatever pleases your fancy.

>     http://www.digital-law-online.com/lpdi1.0/cases/15PQ2D1846.htm

The misuse of copyright defence: It is forbidden to use a patent or
copyright 'to secure an exclusive right or limited monopoly not granted
by the [Patent/Copyright] office and which it is contrary to public
policy to grant.'

It's _not_ just about conditions which are 'unreasonable' (cf. contract
law). In particular, the 'public policy' to which the court was
referring was the raison d'etre of copyright and patent law -- the
encouragement of creativity and development for the general benefit of
society.

So the hypothetical Creosote Public Licence should be fine.

In the case you cite, the licence was prohibiting the licensee (and even
others) from creativity which might benefit society:

	"Each time Lasercomb sells its Interact program to a company
	and obtains that company’s agreement to the noncompete
	language, the company is required to forego utilization of
	the creative abilities of all its officers, directors and
	employees in the area of CAD/CAM die-making software. Of yet
	greater concern, these creative abilities are withdrawn from
	the public. The period for which this anticompetitive
	restraint exists is ninety-nine years, which could be longer
	than the life of the copyright itself."

Even my other hypothetical licence, which requires you to release _all_
your future work under an open-source licence, does _not_ stop you from
benefiting society by being creative. It just makes requirements about
the _licensing_ of what you create.

Neither does the same licence create an exclusive right or limited
monopoly for the licensor -- quite the opposite, in fact, since it's
asking the licensee to do the _same_ as the licensor, not enforcing any
_difference_ in permitted behaviour.

I don't believe that a prosecution for violation of such a licence would
fall foul of the 'misuse of copyright' defence, either.

Furthermore, no other arrangement exists which allows you to make (other
than fair) use of the work in question. You didn't pay the licensor for
it and get lumbered with these extra clauses on the side -- the
hypothetical licence _only_ asks that you license your own creations in
a certain way, and asks nothing else.

This is not a 'normal' commercial software agreement with some
unreasonable clause tacked on the side; you get to use my software
_only_ because you agreed to these conditions and I didn't ask anything
else of you. A court _would_ take that into account. 

> > I could write a piece of software and tell you that you're only allowed
> > to use it if you release _all_ future software you write under the GPL.
> > Even stuff which isn't at all related, let alone non-derived.
> 
> Highly doubtful.

In the case where I accept financial reward from you and we enter into
any kind of agreement, I'm inclined to agree.

But in the case where no money (or other consideration) has been
exchanged, I very much doubt that a court would rule that my work
effectively becomes public domain -- the court might not award me
damages but you would not be permitted to use my work. 

-- 
dwmw2

Re: Linux GPL and binary module exception clause?

[Jason Kingsland]

On Thu, Dec 04, 2003 at 06:03:49PM -0700, Erik Andersen wrote:
> linux/COPYING says: This copyright does *not* cover user programs
> that use kernel services by normal system calls - this is merely
> considered normal use of the kernel, and does *not* fall under
> the heading of "derived work".

Larry McVoy adds:
> Given the GPL rules you have to disregard Linus' rules that are extensions
> and work off of standard law.  When you get there it becomes an issue of
> boundaries and the law seems to clearly support Linus' point of view, he
> didn't need to make that clarification, whether he did or not, that's what
> is true in the eyes of the law.


Actually, about two years ago a large company I previously worked at
performed a formal legal review of the GPL, as part of a due-dilligence
review whether to use Linux rather than a commercial OS in some of its
products.

One of the points raised was that the license clarification for user
programs was added by Linus to copying.txt well before most other authors
started working on the kernel - it can be traced back to a nascent version
of Linux to which most everyone else then submitted their code into later
on.

It was the opinion of the IPR lawyer reviewing the license that the "user
program" clarification is therefore a part of the core Linux license, is
legally binding and applies to all such subsequent code submitted by other
authors.

It's a subtle point, but I thought it would be worth a mention. Ultimately,
it would be for the courts to decide I guess, if any GPL copyright dispute
ever makes it that far.

Just goes to show that some companies are concerned about working
effectively with the GPL - it took several weeks of highly paid IPR lawyers
to formate a policy document which they considered acceptable use.

RE: Linux GPL and binary module exception clause?

[David Schwartz]

> On Thu Dec 04, 2003 at 03:50:55PM -0800, Paul Adams wrote:

> > Unless actual Linux code is incorporated in a binary
> > distribution
> > in some form, I don't see how you can claim
> > infringement of the
> > copyright on Linux code, at least in the U.S.

> A kernel module is useless without a Linux kernel in which it can
> be loaded.  Once loaded, it becomes not merely an adjunct, but an
> integrat part of the Linux kernel.

	There you go, *ONCE* *LOADED* it becomes an integral part. So it's the
*use* of it that makes it integral. Disitribution is prior to use.

> Further, it clearly
> "incorporate[s] a portion of the copyrighted work" since it
> can only operate within the context of the kernel by utilizing
> Linux kernel function calls.

	Except the kernel function calls are not copyrighted, only their
implementation is. If you really meant what you're saying, any program that
used 'malloc' would be a derived work of any implementation of 'malloc'.

> To abuse your earlier metaphor, a kernel module is not comparable
> to a programmatic musical composition inspired by a novel.  It is
> better comparared with another novel with substantial similarity
> in the theme, plot, sequence, settings, mood, dialogue, and
> characters, with the same story being told, with trademarked
> phrases and taglines, and that makes no sense whatsoever unless
> you insert it's entire content over the top of page 450,
> paragraph 4 (of the Linux "novel"), and which thereby changes
> the ending of the original book...

	So long as it must be mixed with the original work (and isn't already),
it's not clear that it's a derived work as it sits. Again, otherwise any
program that used 'malloc' would be a derived work of any implementation of
'malloc'.

	DS

Re: Linux GPL and binary module exception clause?

[Erik Andersen]

On Thu Dec 04, 2003 at 05:58:38PM -0800, David Schwartz wrote:
> There you go, *ONCE* *LOADED* it becomes an integral part. So
> it's the *use* of it that makes it integral.  Disitribution is
> prior to use.

Steven Spielberg doesn't care what you do to his movies in the
privacy of your own home.  You can use them as a room dividers
for your hamsters if you want for all he cares.  But if you try
modifying his movies, i.e. to remove the sex, nudity, and
violence and then distribute them, you will join Clean Flicks in
court [1].

Or maybe you feel like making a Harry Potter knockoff.  Go ahead
and write whatever you want in the privacy of your own home.  If
you dare to try distributing such a knock off novel, you will shortly
find Time-Warner sending a herd of lawyers your direction [2]. 

Similarly, nobody cares what kernel modules you feel like making
and loading in the privacy of your own home.

> So long as it must be mixed with the original work (and isn't
> already), it's not clear that it's a derived work as it sits.
> Again, otherwise any program that used 'malloc' would be a
> derived work of any implementation of 'malloc'.

The act of compiling a program and linking that program with a
library certainly does create a derivitive work of that library.
Try linking your program with the 30-day evaluation version of
Intel's Math Kernel Library and distributing the result without
paying them for a license.  Try using Qt in a non-GPL closed
source product without paying Trolltech.  Try using MS Visual
Studio to create and distribute your own competing compiler.
Guess how fast you would have herds of lawyers visiting to
discuss your opinions of what is and is not a derived work?

 -Erik

[1] http://writ.news.findlaw.com/hilden/20020903.html
[2] http://slate.msn.com/id/2084960/

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

RE: Linux GPL and binary module exception clause?

[David Schwartz]

> Or maybe you feel like making a Harry Potter knockoff.  Go ahead
> and write whatever you want in the privacy of your own home.  If
> you dare to try distributing such a knock off novel, you will shortly
> find Time-Warner sending a herd of lawyers your direction [2].

	Yes, but they will cite the prohibition against *creating* derived works.

> Similarly, nobody cares what kernel modules you feel like making
> and loading in the privacy of your own home.

	There's a difference between what you can and can't do and what you can and
can't get away with. You can get away with making a Harry Potter sequel in
the privacy of your own home because nobody would find about it, however
legally, you do not have the right to create the derived work. However, if
you did have the right to create the derived work, you'd automatically have
the right to distribute it to anyone who already owned the original work
from which it was derived.

> > So long as it must be mixed with the original work (and isn't
> > already), it's not clear that it's a derived work as it sits.
> > Again, otherwise any program that used 'malloc' would be a
> > derived work of any implementation of 'malloc'.

> The act of compiling a program and linking that program with a
> library certainly does create a derivitive work of that library.

	Right, however, you have the right to create that derivative work.

> Try linking your program with the 30-day evaluation version of
> Intel's Math Kernel Library and distributing the result without
> paying them for a license. Try using Qt in a non-GPL closed
> source product without paying Trolltech.  Try using MS Visual
> Studio to create and distribute your own competing compiler.
> Guess how fast you would have herds of lawyers visiting to
> discuss your opinions of what is and is not a derived work?

	These cases are much more interesting, except for the MS VC case. In the MS
VC case, there's a EULA that courts are likely to consider part of the sales
contract. As for the others, I think you'd have a very good chance of
winning them. See, for example, ProCD v. Zeidelberg (sp?). In the absence of
a shrink wrap or clickthrough at least, it would seem you only have those
specific rights copyright grants you, and the right to restrict the
distribution of derived works is not one of those rights.

	DS

RE: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Thu, 4 Dec 2003, David Schwartz wrote:
>
> Yes, but they will cite the prohibition against *creating* derived
> works.

So?

The same prohibition exists with the GPL. You are not allowed to create
and distribute a derived work unless it is GPL'd.

I don't see what you are arguing against. It is very clear: a kernel
module is a derived work of the kernel by default. End of story.

You can then try to prove (through development history etc) that there
would be major reasons why it's not really derived. But your argument
seems to be that _nothing_ is derived, which is clearly totally false, as
you yourself admit when you replace "kernel" with "Harry Potter".

		Linus

Re: Linux GPL and binary module exception clause?

[Kendall Bennett]

Erik Andersen <andersen@codepoet.org> wrote:

> On Thu Dec 04, 2003 at 03:50:55PM -0800, Paul Adams wrote:
> > Unless actual Linux code is incorporated in a binary
> > distribution
> > in some form, I don't see how you can claim
> > infringement of the
> > copyright on Linux code, at least in the U.S.
> 
> A kernel module is useless without a Linux kernel in which it can
> be loaded.  Once loaded, it becomes not merely an adjunct, but an
> integrat part of the Linux kernel.  Further, it clearly
> "incorporate[s] a portion of the copyrighted work" since it can
> only operate within the context of the kernel by utilizing Linux
> kernel function calls. 

But what about the case I stated earlier for a driver that is completely 
binary portable between different operating systems. Hence the low level 
portion of the driver is not Linux specific at all, and in fact not even 
designed specifically with Linux in mind. That muddies the waters even 
more, and even Linus has said he would believe such a driver to be OK.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: Linux GPL and binary module exception clause?

[Stefan Smietanowski]

Kendall Bennett wrote:

> Erik Andersen <andersen@codepoet.org> wrote:
> 
> 
>>On Thu Dec 04, 2003 at 03:50:55PM -0800, Paul Adams wrote:
>>
>>>Unless actual Linux code is incorporated in a binary
>>>distribution
>>>in some form, I don't see how you can claim
>>>infringement of the
>>>copyright on Linux code, at least in the U.S.
>>
>>A kernel module is useless without a Linux kernel in which it can
>>be loaded.  Once loaded, it becomes not merely an adjunct, but an
>>integrat part of the Linux kernel.  Further, it clearly
>>"incorporate[s] a portion of the copyrighted work" since it can
>>only operate within the context of the kernel by utilizing Linux
>>kernel function calls. 
> 
> 
> But what about the case I stated earlier for a driver that is completely 
> binary portable between different operating systems. Hence the low level 
> portion of the driver is not Linux specific at all, and in fact not even 
> designed specifically with Linux in mind. That muddies the waters even 
> more, and even Linus has said he would believe such a driver to be OK.

You mean kind of like a program being compiled by a compiler?

The program isn't designed for a specific platform/cpu/os/whatnot but
when compiled it's specific to a platform/cpu/os/whatnot. With the
"program" being the low level stuff and the extra cruft all compilers
include being the glue.

// Stefan

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Thu, 4 Dec 2003, Paul Adams wrote:
>
> A work that is inspired by Linux is no more a derivative work than
> a programmatic musical composition inspired by a novel.  Having
> Linux in mind cannot be enough to constitute infringement.

But it does - you have to include the Linux header files in order to be
able to make any nontrivial module.

I'm not claiming that "thinking about Linux makes you tainted". It's not
about inspiration. But it's a bit like getting somebody pregnant: you have
to do a lot more than just think about it to actually make it happen, or
every high school in the world would be crawling with babies.

In other words: feel free to be inspired by Linux all you want. But if you
release a binary module that loads and works, you've been doing more than
just feeling inspired. And then you need to be _careful_.

		Linus

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Linus,

So basically anyone in the past-present-future who worked on-with-about
the linux kernel is now tainted forever.  Get real Linus, that would mean
everyone would have to segment their brain and it will not happen.

The statement that something load means you have applied standard fair use
of the api's described in the manual.  Since you refuse to set a standard
document to become the manual, the source code itself is the manual.

Like it or not, your position to force people to read the source code or
read "Linux Kernel Internals", "Linux Device Drivers 1 & 2", and/or any
other web content from the internet make the kernel a periodical
reference.  Now that it is a reference, the ideas can be extracted and
used however and where ever.  The simple fact there are books with ISBN
which are verbatium printout of the kernel source for a given snap shot in
time, well the ideas are freed and the actual document is an empty shell!

Thus case law supports fair use and defines the unprotectable API.
Since the headers are the effective API, the are not copyright protected.
They can not, do not, and never will be a means test for "derivative
works".  Clear lines of derivatives if the headers are such, then
everything running in the in user space is a derivative.

Kernel headers provide the mappings to the compilers and libraries.
The libraries and headers in user space will dirty any applications.
Simple proof, rm -rf /usr/include/linux and /usr/include/asm.
Try to build any application and it will bomb in most cases.

So if modules are derived works then so is all of user space.
Then again, the linux kernel is an integration of ideas and no longer
could stand on its own with out all the contributions.

Linux == the sum of the drivers ?
The drivers are derivatives of Linux ?

Copyright License is such a JOKE, I really wish you would do a Michael
Jackson (the white glove grab) and find a way to switch by force to a
better license model.

OSL 1 and 2 are a preferred choice as they are slowly creaping into the
kernel.  The beauty and pain of OSL is that SCO would be a NOOP.  The
requirement imposed on the contributing author to indemnify (sp really
bad) the changes/patches to the codebase core, makes it a better world.
In short code sets of questionable origin are the liabities of the author
and not the community.

I know, everyone is going to flame me, Dave Miller is going to kick me off
lkml and whippity flip.  The majority of the meatballs here do not have
Lawyers nor could they afford them.  So it comes down to those who have
and those who do not.  The haves will anyway crush those who don't.

Well this should be enough bait to get it going.  It is chilly here in
California tonight and a little warmth from electrons heat would be good.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

PS sorry for the fragmented thoughts it is late.

On Thu, 4 Dec 2003, Linus Torvalds wrote:

> 
> 
> On Thu, 4 Dec 2003, Paul Adams wrote:
> >
> > A work that is inspired by Linux is no more a derivative work than
> > a programmatic musical composition inspired by a novel.  Having
> > Linux in mind cannot be enough to constitute infringement.
> 
> But it does - you have to include the Linux header files in order to be
> able to make any nontrivial module.
> 
> I'm not claiming that "thinking about Linux makes you tainted". It's not
> about inspiration. But it's a bit like getting somebody pregnant: you have
> to do a lot more than just think about it to actually make it happen, or
> every high school in the world would be crawling with babies.
> 
> In other words: feel free to be inspired by Linux all you want. But if you
> release a binary module that loads and works, you've been doing more than
> just feeling inspired. And then you need to be _careful_.
> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Linux GPL and binary module exception clause?

[Linus Torvalds]

On Wed, 10 Dec 2003, Andre Hedrick wrote:
>
> So basically anyone in the past-present-future who worked on-with-about
> the linux kernel is now tainted forever.

Andre - before you get involved in a flame war, take a deep breath. You
know you get too excited about things.

Go back and read what I said. I said _nothing_ like the above. Quite the
reverse.

Also, I don't see what the "API" discussion is. That's a _total_ red
herring. There is no "module API", and never has been. Modules have always
been about linking against internal kernel functions, and it's always been
very clear that there is no API, and that those internal kernel interfaces
change _all_ the time.

		Linus

Re: Linux GPL and binary module exception clause?

[Larry McVoy]

On Wed, Dec 10, 2003 at 07:14:31AM -0800, Linus Torvalds wrote:
> Go back and read what I said. I said _nothing_ like the above. Quite the
> reverse.

Err, you might reread some of what you have said and what people are saying
about it.  Here are a few references as well as some other interesting
links.

http://www.mail-archive.com/license-discuss@opensource.org/msg05842.html
http://www.mail-archive.com/license-discuss@opensource.org/msg05865.html
http://www.mail-archive.com/license-discuss@opensource.org/msg05867.html
http://www.mail-archive.com/license-discuss@opensource.org/msg05882.html
http://www.mail-archive.com/license-discuss@opensource.org/msg05888.html
http://www.rosenlaw.com/html/GL18.pdf
http://www.charvolant.org/~doug/gpl/gpl.pdf

That's a start, there are a pile more, I'll put them up on a web page when
I have some time.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Larry,

Erm,  You found where I went and started debating "real lawyers", and then
tossed cannon balls into pool of discussion to test reactions.  It was fun
and I learned alot.  I find it an interesting comparison of the BIG GUNS
with the degrees and the cork pop guns here on lkml.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Wed, 10 Dec 2003, Larry McVoy wrote:

> On Wed, Dec 10, 2003 at 07:14:31AM -0800, Linus Torvalds wrote:
> > Go back and read what I said. I said _nothing_ like the above. Quite the
> > reverse.
> 
> Err, you might reread some of what you have said and what people are saying
> about it.  Here are a few references as well as some other interesting
> links.
> 
> http://www.mail-archive.com/license-discuss@opensource.org/msg05842.html
> http://www.mail-archive.com/license-discuss@opensource.org/msg05865.html
> http://www.mail-archive.com/license-discuss@opensource.org/msg05867.html
> http://www.mail-archive.com/license-discuss@opensource.org/msg05882.html
> http://www.mail-archive.com/license-discuss@opensource.org/msg05888.html
> http://www.rosenlaw.com/html/GL18.pdf
> http://www.charvolant.org/~doug/gpl/gpl.pdf
> 
> That's a start, there are a pile more, I'll put them up on a web page when
> I have some time.
> -- 
> ---
> Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Linux GPL and binary module exception clause?

[Pavel Machek]

Hi!

> OSL 1 and 2 are a preferred choice as they are slowly creaping into the
> kernel.  The beauty and pain of OSL is that SCO would be a NOOP.  The
> requirement imposed on the contributing author to indemnify (sp really
> bad) the changes/patches to the codebase core, makes it a better world.
> In short code sets of questionable origin are the liabities of the author
> and not the community.

Hmm, remind me to never ever touch anything under OSL. Copyright is
different in different countries and having $1e9 lawsuit going after
_me_ just because U.S. laws are crazy does not seem funny to me.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

Pavel,

So basically you think it is okay to pollute the kernel tree and
opensource with information of questionable origin?  If this is your
position, remind me to remove all code that you have ever touched.

You do not get a lawsuit if you have ownership of the code you are
submitting.  Why should you worry if ethics of good code and content is
never in question.

I am do not mean to smudge you but you own word (if I understand them) do
it for you.  Plese correct if I misread.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Fri, 12 Dec 2003, Pavel Machek wrote:

> Hi!
> 
> > OSL 1 and 2 are a preferred choice as they are slowly creaping into the
> > kernel.  The beauty and pain of OSL is that SCO would be a NOOP.  The
> > requirement imposed on the contributing author to indemnify (sp really
> > bad) the changes/patches to the codebase core, makes it a better world.
> > In short code sets of questionable origin are the liabities of the author
> > and not the community.
> 
> Hmm, remind me to never ever touch anything under OSL. Copyright is
> different in different countries and having $1e9 lawsuit going after
> _me_ just because U.S. laws are crazy does not seem funny to me.
> 
> 								Pavel
> -- 
> When do you have a heart between your knees?
> [Johanka's followup: and *two* hearts?]
> 

Re: Linux GPL and binary module exception clause?

[Jamie Lokier]

Andre Hedrick wrote:
> You do not get a lawsuit if you have ownership of the code you are
> submitting.  Why should you worry if ethics of good code and content is
> never in question.

On the Bochs mailing list, someone just asked, paraphrased: "I read an
idea in the Bochs source code (which is GPL) and implemented the same
idea in another program.  The other code is not a copy, I wrote it
myself, but it does have some structural similarity.  Is the code I
wrote a derived work of Bochs which I read and got the idea, thus
requiring me to release my code under the GPL?".

My point is that sometimes you write something and you _just don't
know_ if you "own" the code that you wrote, because you don't know how
tainted you are by other things that you have read, seen, heard etc. -
in someone else's opinion.

When it comes to $1bn lawsuits, someone else's opinion counts more
than your own - and you don't know what it's going to be.

I do not want to be subject to a potential $1bn lawsuit for something
I didn't know I was doing.  I may be 99.999% confident I'm doing the
right thing even by other people's standards, but in an industry where
suing is the modern way to "innovate", I'd much rather work with
people whose license and social norms puts the risk where it's most
appropriate: with whoever is making money selling stuff and offering
to take on that risk as part of the fee.

This is one thing the GPL got right.  Restricting development _only_
to professional programmers with indemnity insurance is not the way to
build a vibrant free software community.

-- Jamie

Re: Linux GPL and binary module exception clause?

[Pavel Machek]

Hi!

> So basically you think it is okay to pollute the kernel tree and
> opensource with information of questionable origin?  If this is your
> position, remind me to remove all code that you have ever touched.

I think it should be okay to put code I wrote into kernel, and put
GPLed code into kernel when I keep original author's copyright (I
commonly integrate patches from the lists, etc). And I do not want to
deal with U.S. courts (or Afghanistan courts, for that matter).

> You do not get a lawsuit if you have ownership of the code you are
> submitting.  

As far as I can see, in U.S. you can get lawsuit independend of
whether you did anything wrong or not.

							Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Linux GPL and binary module exception clause?

[Adam Sampson]

Andre Hedrick <andre@linux-ide.org> writes:

> OSL 1 and 2 are a preferred choice as they are slowly creaping into
> the kernel.

The problem with the OSL is that it requires mirror sites to get
anybody downloading OSL-licensed software from them to explicitly
agree to the license; this is simply not practical, and the result is
that it is not feasible to freely mirror OSL-licensed software. This
hasn't been fixed with OSL 2, and as such it would be an exceptionally
poor choice for any piece of software that you want to be widely
distributed, which certainly includes Linux.

-- 
Adam Sampson <azz@us-lot.org>                        <http://offog.org/>

Re: Linux GPL and binary module exception clause?

[Andre Hedrick]

I quit ... all of you win.

Just remember, had OSL been in place IBM would not need to exercise
patents against SCO.  Caldera and Canopy Group would be liable for their
own pollution of the code stream.

Next OSl provides a means to recover legal fees for the author, and GPL
does not.  So unless you have a FAT WALLET, you can not defend you works.
Oh yeah, just give all your copyright works to FSF and they will defend it
and get any of the finacial rewards and you get ZERO!

Later ...

Andre Hedrick
LAD Storage Consulting Group

On Mon, 15 Dec 2003, Adam Sampson wrote:

> Andre Hedrick <andre@linux-ide.org> writes:
> 
> > OSL 1 and 2 are a preferred choice as they are slowly creaping into
> > the kernel.
> 
> The problem with the OSL is that it requires mirror sites to get
> anybody downloading OSL-licensed software from them to explicitly
> agree to the license; this is simply not practical, and the result is
> that it is not feasible to freely mirror OSL-licensed software. This
> hasn't been fixed with OSL 2, and as such it would be an exceptionally
> poor choice for any piece of software that you want to be widely
> distributed, which certainly includes Linux.
> 
> -- 
> Adam Sampson <azz@us-lot.org>                        <http://offog.org/>
>