subject:"GPL vs non\-GPL device drivers"


On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote:

Actually, on re-reading the GPL, I see exactly why they made that pair of
exceptions. Where it's quite evident that a small to mid scale parsers that
could have been written *without* the use of Bison is clearly a
non-derivative work - Bison was not required, but was used as a mean of
expediency. When you reach a large scale parser, such as one that meets all
requirements to act as the parser for an ANSI C99 compiler, Bison stops being
expedient - it'd likely take just as much time to hand craft the parser as it
would to debug the Bison input. However, it makes maintaining the parser
easier.


I repeat, that is not what "derivative work" means.  Do not try to
reason about the phrase "derivative work" without reference to its
definition in statute and its legal history in appellate decisions.
You will get it wrong every time.  You have not "recast, transformed,
or adapted" the _creative_expression_ in Bison or Flex in the course
of using it; so whether or not you have infringed the FSF's copyright,
you have NOT created a "derivative work".

If Bison and Flex were offered under the "bare" GPL, and you used them
to build a parser, and the FSF sued you for offering that parser to
other people on terms other than the GPL's, you don't defend by
claiming license under the GPL with regard to your parser.  You attack
the claim of "copying" itself by saying that the _creative_expression_
copied from Bison/Flex into your parser is "de minimis" under the
Altai Abstraction-Filtration-Comparison test.  You also point out
that, even if it weren't "de minimis", it's "fair use"; that's a
complex four-factor test, but the main thing is that you're not
interfering with the FSF's ability to monetize its copyright in
Bison/Flex.

If you have any sense, you will strenuously argue that the various
"special exceptions" for things like Bison/Flex and GNU Classpath are
_not_ part of the offer of contract contained in the GPL, any more
than the Preamble is.  They're declarations of intent on the part of
the copyright holder, and can be used to _estop_ the FSF from making
the copyright infringement claim against you in court in the first
place.  They promised you they wouldn't, not as part of the contract
terms, but as part of the inducement to form a contract with them by
acceptance through conduct.


But the fact is that it's the small to medium scale parsers that have a lower
ratio of original to GPL'd code that are at risk of being declared derivative
works. All of this because the GPL contains the following text in section 0:
"The act of running the Program is not restricted, and the output from the
Program is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does."


I'm sorry, but that "ratio test" has nothing to do with whether
something is a derivative work or not.  It comes up mostly in
evaluating a "fair use" defense, and it's the ratio of the amount of
creative expression _copied_ to the amount of creative expression in
the _original_work_ that matters.  Just because you're writing a
49-volume encyclopedia does not give you the right to copy two thirds
of my one-page essay.  Those weasel-words about "depending on what the
Program does" are nonsense.  It depends on what _creative_expression_
from the Program winds up in the output.


That clause, to me, seems specifically tailored to cover programs such as
Bison and Flex. (and is the reason that I try to use Byacc and when I need
to, write tokenizers by hand) This frankly stinks of attempts to cover all
possible code. (I actually started studying Copyright law in my free time
because I was wondering how legal the GPL was and was also puzzled by some
major online entities actually complaining about it)


I've written tokenizers in at least six different languages to date,
including Fortran.  It's a pain in the butt.  The last thing I want to
be worrying about when I write a tokenizer is whether somebody else's
peanut butter is winding up in my chocolate.  So I will only use a
tool which, like bison and flex, is accompanied by a promise not to
claim that its output infringes the tool author's copyright or is
otherwise encumbered in any way.  M$ VC++ is actually more trustworthy
in that respect than G++.  If you don't believe (as I do) that it is
arrant nonsense to claim that the use of interface headers or linking
of any kind creates a derivative work, then you must believe that any
programs compiled with G++ can only be distributed under the terms of
the GPL.  libstdc++ is GPL, not LGPL.


Since I tailor the license I apply to code I produce to meet the needs of the
person or entity I am writing it for, I've never run into this.


That's kind of silly.  I use the GPL for my own from-scratch programs
all the time.  It's quite a sensible set of terms for source code
created as a side effect of a consu

Re: GPL vs non-GPL device drivers

2007-02-21 Thread Trent Waddington


On 2/22/07, D. Hazelton <[EMAIL PROTECTED]> wrote:

"  We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software."
--IE: Once you release the code under the GPL, it becomes the *copyrighted*
*property* of the FSF and you are just another person that the GPL is applied
to.


Put *down* the crack pipe.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-21 Thread D. Hazelton

On Wednesday 21 February 2007 21:05, Michael K. Edwards wrote:
> On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote:

> > Related to that... Though a parser generated by Bison and a tokenizer
> > generated by Flex both contain large chunks of GPL'd code, their
> > inclusion in the source file that is to be compiled is mechanical - the
> > true unique work is in writing the file that is processed by the tool to
> > produce the output. Since the aggregation of the GPL'd code into the
> > output source is done mechanically - via mechanical translation (which is
> > what compilation is as well) - the result is *not* and under US copyright
> > law *cannot* be a derivative work. What this means is that the GNU/FSF
> > "special" terms applied to parsers generated by Bison and tokenizers
> > generated by Flex is unnecessary - they are granting you a right you
> > already have.
>
> Half true.  It's not a derivative work exactly, but it could
> conceivably be held to infringe against the copyright in Flex/Bison,
> if you could prove that the amount of _creative_expression_ copied
> into the output exceeds a "de minimis" standard and doesn't constitute
> a "fair use".  Those nifty photomosaics would probably infringe
> against the photographers' copyright in the photos they're made up of,
> if they weren't licensed through the graphic industry's "stock photo
> archive" mechanism.  You could probably defend on "fair use" with
> respect to Flex/Bison and the vanilla GPL, since the fact that I can
> get some random program with a parser in it from you without needing
> my own copy of bison doesn't cost the FSF anything.  But it's a
> gamble, especially if that random program competes with something the
> FSF makes $$$ off of; and I'd want that extra bit of estoppel in my
> back pocket.

Actually, on re-reading the GPL, I see exactly why they made that pair of 
exceptions. Where it's quite evident that a small to mid scale parsers that 
could have been written *without* the use of Bison is clearly a 
non-derivative work - Bison was not required, but was used as a mean of 
expediency. When you reach a large scale parser, such as one that meets all 
requirements to act as the parser for an ANSI C99 compiler, Bison stops being 
expedient - it'd likely take just as much time to hand craft the parser as it 
would to debug the Bison input. However, it makes maintaining the parser 
easier.

But the fact is that it's the small to medium scale parsers that have a lower 
ratio of original to GPL'd code that are at risk of being declared derivative 
works. All of this because the GPL contains the following text in section 0:
"The act of running the Program is not restricted, and the output from the 
Program is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does."

That clause, to me, seems specifically tailored to cover programs such as 
Bison and Flex. (and is the reason that I try to use Byacc and when I need 
to, write tokenizers by hand) This frankly stinks of attempts to cover all 
possible code. (I actually started studying Copyright law in my free time 
because I was wondering how legal the GPL was and was also puzzled by some 
major online entities actually complaining about it)

> The LGPL is a very different story.  It's not just GPL with extra
> estoppel, it's a booby trap.  It goes a lot farther to put over its
> own perverse definition of "derivative work", and it tries to compel
> you to provide all the "data and utility programs needed for
> reproducing the executable from it".  I don't use the LGPL for my own
> work, I wouldn't touch it with a ten-foot pole if it didn't have the
> "GPL upgrade" clause in it, and I advise my employers and consulting
> clients to go through the "GPL (v2 only!) upgrade" rigmarole with
> respect to anything they so much as recompile.  They don't all take
> that advice, but that's not my problem.

Since I tailor the license I apply to code I produce to meet the needs of the 
person or entity I am writing it for, I've never run into this. In truth, the 
LGPL is, IMHO, a piece of garbage. (as is the GPL - if you release code under 
the GPL you no longer have a legal right to it. Note the following text that 
appears in the GPL:

"  We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software."
--IE: Once you release the code under the GPL, it becomes the *copyrighted* 
*property* of the FSF and you are just another person that the GPL is applied 
to. This means that if you later change your mind and decide to revoke the 
GPL on your code and replace it with say, the Larry Wall's "Artistic License" 
you are breaking the terms of the GPL and therefore lose all rights to modify 
and distribute your code.

A similar clause appears in the LGPL:
"We protec

Re: GPL vs non-GPL device drivers

On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote:

On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote:
> I think you just misread.  I said that the Evil Linker has cheerfully
> shipped the source code of the modified POP server.  He may not have
> given you the compiler he compiled it with, wihout which the source
> code is a nice piece of literature but of no engineering utility; but
> that's the situation the GPL is DESIGNED TO PRODUCE.

Actually, if memory serves, when you license a work under the GPL, part of the
terms is that you have to provide the source and any scripts needed to
produce a functioning executable.

Absolutely.  But not the toolchain, just the "scripts".  This is part
historical, since after all GNU got started when Sun started to
monetize its toolchain independently of its O/S, RMS got annoyed
enough to kick off another cloning project, and more competent
compiler people caught on to the economic opportunity.  Ever pay $5K
for a CD full of GNU binaries for a commercial UNIX?  I did, after
deciding that getting all their shit to compile was more Morlock-work
than I was up to.  So like I say, it's part historical -- RMS didn't
want to owe me a copy of Sun's toolchain along with that CD -- but
it's no accident that it's still in there, because THAT'S HOW CYGNUS
MADE MEGABUCKS.

As a side note: The distinct wording of the GPL actually *invalidates* the
GNU/FSF claim that dynamically linking a work with, say, the readline
library,  means the work is a derivative of said library. The GPL states (in
clause 0) that the license only covers copying, modification and
distribution. Unless they are confusing "Linking" with "copying" or "creating
a derivative work" the claim is invalid - because, as it has been shown, a
mechanical process such as compilation or linking *cannot* create a
derivative work.

Of course.  The FSF smokescreen around "derivative work" exists not
only to frighten potential commercial users of GPL libraries but to
squelch people like Eric A. Young (principal OpenSSL author) who have
the presumption to retain their own copyrights.  Eric has a quite
solid case (IMHO, IANAL) against the FSF and Eben Moglen personally
under at least three different U. S. antitrust and racketeering laws,
and it would be really entertaining to watch him take it up.

Related to that... Though a parser generated by Bison and a tokenizer
generated by Flex both contain large chunks of GPL'd code, their inclusion in
the source file that is to be compiled is mechanical - the true unique work
is in writing the file that is processed by the tool to produce the output.
Since the aggregation of the GPL'd code into the output source is done
mechanically - via mechanical translation (which is what compilation is as
well) - the result is *not* and under US copyright law *cannot* be a
derivative work. What this means is that the GNU/FSF "special" terms applied
to parsers generated by Bison and tokenizers generated by Flex is
unnecessary - they are granting you a right you already have.

Half true.  It's not a derivative work exactly, but it could
conceivably be held to infringe against the copyright in Flex/Bison,
if you could prove that the amount of _creative_expression_ copied
into the output exceeds a "de minimis" standard and doesn't constitute
a "fair use".  Those nifty photomosaics would probably infringe
against the photographers' copyright in the photos they're made up of,
if they weren't licensed through the graphic industry's "stock photo
archive" mechanism.  You could probably defend on "fair use" with
respect to Flex/Bison and the vanilla GPL, since the fact that I can
get some random program with a parser in it from you without needing
my own copy of bison doesn't cost the FSF anything.  But it's a
gamble, especially if that random program competes with something the
FSF makes $$$ off of; and I'd want that extra bit of estoppel in my
back pocket.

The LGPL is a very different story.  It's not just GPL with extra
estoppel, it's a booby trap.  It goes a lot farther to put over its
own perverse definition of "derivative work", and it tries to compel
you to provide all the "data and utility programs needed for
reproducing the executable from it".  I don't use the LGPL for my own
work, I wouldn't touch it with a ten-foot pole if it didn't have the
"GPL upgrade" clause in it, and I advise my employers and consulting
clients to go through the "GPL (v2 only!) upgrade" rigmarole with
respect to anything they so much as recompile.  They don't all take
that advice, but that's not my problem.

Anyway, it's been fun watching this thread. If I've made a mistake somewhere
in there, let me know - IANAL and I am just starting to really get into the
meat of Copyright and related laws in independant study.

Ditto.  If you see a mistake in something I write, please please
pretty please point it out, in public -- I am not a lawyer, absolutely
everything I say could be wrong, and I don't really wan

Re: GPL vs non-GPL device drivers

2007-02-21 Thread D. Hazelton

On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote:
> I think you just misread.  I said that the Evil Linker has cheerfully
> shipped the source code of the modified POP server.  He may not have
> given you the compiler he compiled it with, wihout which the source
> code is a nice piece of literature but of no engineering utility; but
> that's the situation the GPL is DESIGNED TO PRODUCE.

Actually, if memory serves, when you license a work under the GPL, part of the 
terms is that you have to provide the source and any scripts needed to 
produce a functioning executable.

*checks a local copy of GPLv2 for the exact wording*

Third clause of the license:
"For an executable work, complete source code means all the source code for 
all modules it contains, plus any associated interface definition files, plus 
the scripts used to control compilation and installation of the executable."

So yes, someone could produce a work that compiles on a specific compiler, but 
there is then nothing stopping someone from fixing the problems that cause it 
to not compile using another compiler and releasing that source code - 
distributing it as a patch, AFAICT, falls outside coverage by the GPLv2. The 
build tool-chain, libraries and other works that are not a direct part of the 
program produced by compilation of the source code. (the wording of the GPL 
is: "However, as a special exception, the source code distributed need not 
include anything that is normally distributed (in either source or binary 
form) with the major components (compiler, kernel, and so on) of the 
operating system on which the executable runs, unless that component itself 
accompanies the executable.")

As a side note: The distinct wording of the GPL actually *invalidates* the 
GNU/FSF claim that dynamically linking a work with, say, the readline 
library,  means the work is a derivative of said library. The GPL states (in 
clause 0) that the license only covers copying, modification and 
distribution. Unless they are confusing "Linking" with "copying" or "creating 
a derivative work" the claim is invalid - because, as it has been shown, a 
mechanical process such as compilation or linking *cannot* create a 
derivative work.

Related to that... Though a parser generated by Bison and a tokenizer 
generated by Flex both contain large chunks of GPL'd code, their inclusion in 
the source file that is to be compiled is mechanical - the true unique work 
is in writing the file that is processed by the tool to produce the output. 
Since the aggregation of the GPL'd code into the output source is done 
mechanically - via mechanical translation (which is what compilation is as 
well) - the result is *not* and under US copyright law *cannot* be a 
derivative work. What this means is that the GNU/FSF "special" terms applied 
to parsers generated by Bison and tokenizers generated by Flex is 
unnecessary - they are granting you a right you already have.

Anyway, it's been fun watching this thread. If I've made a mistake somewhere 
in there, let me know - IANAL and I am just starting to really get into the 
meat of Copyright and related laws in independant study.

DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


I think you just misread.  I said that the Evil Linker has cheerfully
shipped the source code of the modified POP server.  He may not have
given you the compiler he compiled it with, wihout which the source
code is a nice piece of literature but of no engineering utility; but
that's the situation the GPL is DESIGNED TO PRODUCE.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/21/07, Nuno Silva <[EMAIL PROTECTED]> wrote:

I can see that your argument is all about the defenition of a
"derivative work".


Far from it.  Try reading to the end.


We all know that #include  is mostly non copyrightable, so I
mostly agree that some - very very simple - modules may not need to
include the source when distributing the resulting module.ko. (need =
from a legal standpoint... The intended spirit of the GPL is another story)


The "intended spirit of the GPL" is very different from what you think
it is, as $674 million of Red Hat stock can testify.  It is also
utterly irrelevant except when the circumstances surrounding someone's
acceptance of the GPL indicate that the two parties negotiated more or
less directly before settling on its terms.


In this context what do you think about porting Linux to another arch?
Does the people porting the OS needs to distribute the source with the
[compiled] kernel?


Of course.  They're distributing a derivative work of the kernel, or
perhaps even (for legal purposes) distributing Linus's work of
authorship with trivial editorial changes that do not create a new
copyrightable work.  They need license to do so, and the only license
on offer is GPL v2, which conditions the license on distribution of
source code.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-21 Thread David Lang


On Wed, 21 Feb 2007, Michael K. Edwards wrote:


But wait, you say -- the Evil Linker modified, copied, and distributed
my POP server too!  That makes him subject to the terms of the GPL.
And you're right; but to understand what that means, you're going to
need to understand how a lawsuit for copyright infringement works.
The very, very, very concise version is:




I understand why you say that the Evil Linker's program isn't covered by the 
GPL, but your argument makes it sound like the modified POP server doesn't need 
to have it's source released. This I don't understand, it contains the origional 
source code, so what right does Evil Linker have to distribute it (or a modified 
version).


you are comeing dangerously close to saying that the GPL is meaningless and 
putting something under it is the same as putting it under public domain. There 
is case law now that says that this isn't the case (although I agree that it's 
not nearly as broad as it's proponents would like it to be)


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-21 Thread Nuno Silva

Michael K. Edwards wrote:
> Actually, it's quite clear under US law what a derivative work is and
> what rights you need to distribute it, and equally clear that
> compiling code does not make a "translation" in a copyright sense.
> Read Micro Star v. Formgen -- it's good law and it's funny and
> readable.

Hello.

[Sorry for deleting the rest of the email but it was quite large]

I can see that your argument is all about the defenition of a
"derivative work".

We all know that #include  is mostly non copyrightable, so I
mostly agree that some - very very simple - modules may not need to
include the source when distributing the resulting module.ko. (need =
from a legal standpoint... The intended spirit of the GPL is another story)

In this context what do you think about porting Linux to another arch?
Does the people porting the OS needs to distribute the source with the
[compiled] kernel?

(Yes, it's a trick question)

IANAL too.

Regards,
Nuno Silva

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


Actually, it's quite clear under US law what a derivative work is and
what rights you need to distribute it, and equally clear that
compiling code does not make a "translation" in a copyright sense.
Read Micro Star v. Formgen -- it's good law and it's funny and
readable.

I've drafted summaries from a couple of different angles since VJ
requested a "translation into English", and I think this is the most
coherent (and least foaming-at-the-mouth) I've crafted yet.  It was
written as an answer to a private query to this effect:  "I write a
POP server and release it under the GPL.  The Evil Linker adds some
hooks to my code, calls those hooks (along some of the existing ones)
from his newly developed program, and only provides recipients of the
binaries with source code for the modified POP server.  His code
depends on, and only works with, this modified version of my POP
server.  Doesn't he have to GPL his whole product, because he's
combined his work with mine?"

This is a fundamental misconception.  A <> is not a "work
of authorship".  Copyright is about "works of authorship" and cannot
be used to allow or disallow behavior based on whether you have
<> two things at an engineering level to make a product.  A
contract can be used to allow or disallow, and assign penalties to,
all sorts of things, and the GPL is an "offer of contract"; but its
plain text does _not_ disallow this <> -- largely because
the drafter was trying to put one over on you and me by pretending that
he could do that without recourse to contract law.

The fact that your Evil Linker's program will not do anything
interesting without your program is no more relevant than the fact
that Borland's spreadsheet program will not do anything interesting
without a spreadsheet document loaded.  Borland's interest lay in
making their macro language compatible with Lotus's so that users
didn't have to rewrite their documents from scratch.  The Evil
Linker's interest lies in making their program compatible with other
clients of your POP server so they don't have to rewrite your POP
server from scratch.  Borland won in court, and so will the Evil
Linker.  IANAL, TINLA.

Now, Borland _almost_ lost at the Supreme Court level.  Why?  Because
while they had a good case that it wasn't practical to copy the 1-2-3
macro language without copying its entire user interface, that gets
awfully close to the sort of expression that copyright is supposed to
protect.  You can take a picture of a skyscraper and sell copies of
that picture, not because it isn't in some sense an infringement on
the architect's copyright, but because it's "fair use" -- mostly
because it doesn't interfere with the architect's ability to make
money licensing _architectural_ replicas of her work.  When you take a
screenshot of a spreadsheet, you're on safe ground; but if you use
that screenshot to clone the spreadsheet, you're pushing your luck.

Borland won, sort of, when the Supremes split 4-4 (one was out sick or
recused or something).  If you want to know why, you can get hold of a
transcript of the oral argument before the Supreme Court, which is
mostly in plain English and about half debate between the Justices
about where they ought to draw the line.  For an example where
screenshots can be over the line, and where even unlicensed
distribution of data files can be held to infringe the copyright on
the program that reads them, read Micro Star v. Formgen (9th Circuit).
That involved a very different theory though, infringement on the
"characters and mise en scene" of a fictional work (Duke Nukem 3D),
and will not avail you against the Evil Linker.  All of this stuff is
covered in Lexmark v. Static Control (6th Circuit, cert. denied) --
the law of the land throughout the U. S. of A.

But wait, you say -- the Evil Linker modified, copied, and distributed
my POP server too!  That makes him subject to the terms of the GPL.
And you're right; but to understand what that means, you're going to
need to understand how a lawsuit for copyright infringement works.
The very, very, very concise version is:

You claim "copyright infringement".
He claims "copyright license" -- "acceptance through conduct" of a
"valid offer of contract".
You claim conduct outside the "scope of the license".
He claims the terms about distributing modified versions together with
source code are "covenants of return performance", which he duly
performed.
You claim the license covers the whole <>,
including his application.
He points out that <> is explicitly defined
in GPL Section 0 to be a "derivative work under copyright law", and
that while the paraphrase following this overstates the extent of the
"derivative works" category, a raft of case law says that his program
is not a "derivative work" of yours.  Furthermore, it would be
"contrary to the public interest" to allow a "contract of adhesion in
rem" to disallow the "universal industry practice" of <>,
for engineering purposes, many differently licensed works on comm

Re: GPL vs non-GPL device drivers

2007-02-21 Thread Helge Hafting


Jan-Benedict Glaw wrote:

On Tue, 2007-02-20 15:36:56 +0100, Helge Hafting <[EMAIL PROTECTED]> wrote:
  

If you have a need for "secret" source code, stuff most of it
in userspace.  Make the drivers truly minimal; perhaps their
open/closed status won't matter that much when the bulk
of the code and the cleverness is kept safe in userspace.

Note that keeping drivers small this way is the recommended
way of working anyway. It isn't merely a way to keep your
code away from the GPL - you always want a small kernel.



Keeping the legal stuff out of sight for a second, this'll solve the
"problem" for the embedded developer, but surely not for the Linux
community. Would you ever expect that eg. the thin GPL layer used by
ATI/NVidia would be merged iff the rest would run in userland?
  

A thin layer - no.  To get merged, a driver would have to
be of good quality.  I didn't think like that - I was thinking of
embedded developers that sometimes implement the
entire embedded application inside their device driver.

Which is crazy from a linux design standpoint, but sometimes
reasonable for an embedded developer when the sole purpose of
the embedded computer is to control the single "device" and
perhaps a little display with a couple of buttons.
The "app" part might not be that much
bigger than the device driver itself - it is then tempting to
cut some corners and put all in one place.

Of course this kind of "driver" ends up containing everything,
and nobody wants to GPL that.  Separating driver and app(s)
properly lets them keep a proprietary app, and a driver or two
that might be small and simple enough to be released.

It's just a workaround for the
linking-the-object-file-into-the-kernel-image problem, but after all,
it doesn't lead to a working driver being freely available.

MfG, JBG


Good point.  Fortunately, most devices are much simpler than
a card with accelerated 3D-graphichs.

Helge Hafting




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-20 Thread Jan-Benedict Glaw

On Tue, 2007-02-20 15:36:56 +0100, Helge Hafting <[EMAIL PROTECTED]> wrote:
> If you have a need for "secret" source code, stuff most of it
> in userspace.  Make the drivers truly minimal; perhaps their
> open/closed status won't matter that much when the bulk
> of the code and the cleverness is kept safe in userspace.
> 
> Note that keeping drivers small this way is the recommended
> way of working anyway. It isn't merely a way to keep your
> code away from the GPL - you always want a small kernel.

Keeping the legal stuff out of sight for a second, this'll solve the
"problem" for the embedded developer, but surely not for the Linux
community. Would you ever expect that eg. the thin GPL layer used by
ATI/NVidia would be merged iff the rest would run in userland?

It's just a workaround for the
linking-the-object-file-into-the-kernel-image problem, but after all,
it doesn't lead to a working driver being freely available.

MfG, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
 Signature of:If it doesn't work, force it.
 the second  :   If it breaks, it needed replacing anyway.

signature.asc
Description: Digital signature

Re: GPL vs non-GPL device drivers

2007-02-20 Thread Valdis . Kletnieks

On Tue, 20 Feb 2007 12:00:51 +0100, Bernd Petrovitsch said:
> Flame bait alert:
> I heard a talk from an Austrian lawyer an according to his believes (and
> I don't know if he is the only one or if there lots of) one must see
> from the "users" view if the GPL spreads over or not (and the usual
> technical terms like "linking" are basically irrelevant).
> E.g.:
> - You are distributing an application which links against a GPL-library.
> If you provide a link and the user/customer has to get and install that
> library, your application can have any license you wish.
> - If you distribute an application and it installs automatically a
> library (e.g. from the CD where your application is installed), your
> applications license must "fit" wit the library license.

So tell me - if RedHat distributes a non-GPL program that uses a GPL
library that is included as part of the distribution, but *not* one that's
usually installed, which rules apply?

Even better - does this mean that I can *intentionally* bypass the licensing by
including a installer script that removed a problematic library, and then
forces the user to re-install it?




pgpYyXP1m6V0a.pgp
Description: PGP signature

Re: GPL vs non-GPL device drivers

2007-02-20 Thread Bernd Petrovitsch

On Tue, 2007-02-20 at 10:14 -0500, [EMAIL PROTECTED] wrote:
> On Tue, 20 Feb 2007 12:00:51 +0100, Bernd Petrovitsch said:
> > Flame bait alert:
> > I heard a talk from an Austrian lawyer an according to his believes (and
> > I don't know if he is the only one or if there lots of) one must see
> > from the "users" view if the GPL spreads over or not (and the usual
> > technical terms like "linking" are basically irrelevant).
> > E.g.:
> > - You are distributing an application which links against a GPL-library.
> > If you provide a link and the user/customer has to get and install that
> > library, your application can have any license you wish.
> > - If you distribute an application and it installs automatically a
> > library (e.g. from the CD where your application is installed), your
> > applications license must "fit" wit the library license.
> 
> So tell me - if RedHat distributes a non-GPL program that uses a GPL
> library that is included as part of the distribution, but *not* one that's
> usually installed, which rules apply?

I'm well aware that there are (probably lots of) contradictions with
this "idea".
IANAL and we must ask that lawyer actually for this. And he will
probasbly do not understand the question since he very probably doesn't
know all the usual software distribution methods.

> Even better - does this mean that I can *intentionally* bypass the licensing 
> by
> including a installer script that removed a problematic library, and then
> forces the user to re-install it?

A good question which belongs in the same category as above.

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-20 Thread Helge Hafting


v j wrote:


Assuming these need not be GPL, I have a problem with
EXPORT_SYMBOL_GPL and the general trend in the direction of making
proprietary drivers harder on companies. Our drivers use basic
interfaces in the kernel like open, read, write, ioctl, semaphores,
interrupts, timers etc. This is functionality we would expect from any
operating system. We used devfs before and had no problems there. Greg
KH has gone and made the basic sysfs interface, which any generic
driver could use as EXPORT_SYMBOL_GPL. I don't really care, I just
don't use sysfs. The point is that old functionality is being ripped
off and new ones introduced, and their interfaces are not open
anymore. Hence there will be a point where non-GPLed drivers simply
cannot be loaded.

So why beat about the bush? Just make it illegal to load proprietary
drivers, or remove EXPORT_SYMBOL_GPL.

Those wo introduce EXPORT_SYMBOL_GPL are not in a position where
they can make it illegal to load proprietary modules. They may want to,
but they can't.  The kernel has very many copyright holders, each
decides for his own part only.

Someone who didn't write the module interface or posix interface can't
stop you there.  Anti-proprietary folks then go and make new
useful subsystems, and make sure those are accessed with
EXPORT_SYMBOL_GPL only.  Then they phase out the old
interfaces as the new ones are clearly better, and the vast majority
with GPL drivers have no problem with this.
As long as there are developers with this attitude, expect
EXPORT_SYMBOL_GPL to crop up in new places over time.

Yes - this makes it harder (although not impossible) to distribute
closed-source drivers.  Which is exactly what these people want.
When they are powerless to forbid such drivers, they settle for making
them harder and harder to use instead.  They want this trend
to continue.

There is an obvious way around it - you (and other people
with an interest in closed-source drivers) can write & contribute your
own "sysfs" and whatever else you might need.  Make it better
than the existing sysfs so it actually gets into the kernel,
replacing the existing stuff. And of
course there will be no EXPORT_SYMBOL_GPL in it - since
that is what you want to avoid. 


The price for this then, is to outcompete the proponents of
GPL-only symbols.  If you offer more and better source (under the GPL)
then you can turn the trend and keep linux the way you want it.
If you don't - those that do contribute will get to shape linux
the way they like. Whoever makes linux gets to decide.

Another way is to stay with linux 2.4.  You won't get any
new stuff that way, but no new GPL surprises either.

Helge Hafting

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-20 Thread Helge Hafting


v j wrote:
You are trying to cram this in a simple yes or no box, and it just 
doesn't
fit. There are questions nobody knows the answers to (such as what 
rights
you need to distribute a derivative work or whether compiling code 
makes a

translation).


Thanks, all for the discussion. I certainly learnt a lot. I definitely
expected to be flamed and roasted for posting my original message, and
was not disappointed :)

I do not possess all the knowledge ("legal" and technical) that people
who have contributed to this discussion possess. However I will still
comment from a user's perspective, which was my original point.

Many companies in the embedded field still mistakenly feel (or felt
until a while ago) that Linux was not right for them. That they would
have to open source their code, that they would not get adequate
support, and that Linux was too big and heavy to perform well in an
embedded platform. People like me who were Linux Desktop junkies were
actually trying to convince companies of the opposite.

Now the popularity of Linux is exploding in the embedded space. Nobody
talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be
a worthwhile experiment to study this surge in popularity. I am not an
expert, but perhaps the reason is "it works so goddamn well and has a
wealth of third party FREE software". Sure its a bit of work to make
it work on our platform and we don't have to Enea or Windriver to
write our gripes to. But it definitely is worth it.

Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
does to this popularity. I don't know. I am just giving you my
opinion. The moment companies learn of something like this, alarm
bells start to go off. This is not rational. I personally have nothing
against open-sourcing all software. *But*, this is not how companies
think.

Let's think about why Linux became so popular and strive towards
keeping it that way instead of resorting to innovative ways of just
confusing a lot of people.

Having said this, I am committed to contribute back to the Linux
community in any way I can, not withstanding my present employer. Keep
up the good work guys!


As linux becomes popular, there will always be some people looking
at it that find that it don't fit them perfectly.  That don't mean
we have to make sure linux fits them too - they may be better off
with something else, or we may be better off without them.
Linux has a price - you can use it compeltely free but we want
any useful changes you might make. If everybody sat on their stuff,
linux wouldn't be useful to you today.

There are embedded developers who don't have a problem with
writing GPL drivers.  And there are embedded developers who
don't need any special hardware driver.  No _kernel_ change,
no open-sourcing of company code.  It was never a problem, and
will never be a problem, to run proprietary user processes "apps"
on a linux kernel.

If you have a need for "secret" source code, stuff most of it
in userspace.  Make the drivers truly minimal; perhaps their
open/closed status won't matter that much when the bulk
of the code and the cleverness is kept safe in userspace.

Note that keeping drivers small this way is the recommended
way of working anyway. It isn't merely a way to keep your
code away from the GPL - you always want a small kernel.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-20 Thread Bernd Petrovitsch

On Mon, 2007-02-19 at 21:19 -0800, v j wrote:
[...]
> Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
> does to this popularity. I don't know. I am just giving you my

The big problem with such discussions (as this) are: It is a law
decision which license applies in which situation. And preprocessor can
solve this (so EXPORT_SYMBOL_GPL may mean that or may only express the
wish of one/several/many/a lot of people).

Flame bait alert:
I heard a talk from an Austrian lawyer an according to his believes (and
I don't know if he is the only one or if there lots of) one must see
from the "users" view if the GPL spreads over or not (and the usual
technical terms like "linking" are basically irrelevant).
E.g.:
- You are distributing an application which links against a GPL-library.
If you provide a link and the user/customer has to get and install that
library, your application can have any license you wish.
- If you distribute an application and it installs automatically a
library (e.g. from the CD where your application is installed), your
applications license must "fit" wit the library license.

Guess now what this implies for (typical) embedded systems with one
piece of GPL code in it where you download complete firmware images -
and he explicitly confirmed that.

So this whole thing is not really defined yet and one (read: we) must
also educate such free-software-illiterate people on how it is intended
to work.

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-20 Thread Nick Piggin


v j wrote:


Now the popularity of Linux is exploding in the embedded space. Nobody
talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be
a worthwhile experiment to study this surge in popularity. I am not an
expert, but perhaps the reason is "it works so goddamn well and has a
wealth of third party FREE software". Sure its a bit of work to make
it work on our platform and we don't have to Enea or Windriver to
write our gripes to. But it definitely is worth it.


And do you think it works well because of all those companies that
don't contribute anything back? For that matter, do they do a single
thing to help anyone or anything to do with Linux except themselves?



Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
does to this popularity. I don't know. I am just giving you my
opinion. The moment companies learn of something like this, alarm
bells start to go off. This is not rational. I personally have nothing
against open-sourcing all software. *But*, this is not how companies
think.


Opinions or motivations, or the people working for companies don't really
have any relevance at all. What matters is their actions.

You would think that those people who think their IP is so priceless that
it can't be opened would respect the rights of others. Sadly that doesn't
appear to be the case.



Let's think about why Linux became so popular and strive towards
keeping it that way instead of resorting to innovative ways of just
confusing a lot of people.


Linux has become popular _in spite_ of parasites, rather than because of
them. The main reason for its popularity is its quality. And a big reason
for its quality is the GPL.

--
Send instant messages to your online friends http://au.messenger.yahoo.com 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-20 Thread Trent Waddington


On 2/20/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

I don't think anyone wants to read that.


I guess that was a stupid thing to say.  Ok, fine people, Michael is
ok with me posting this, so enjoy:

http://rtfm.insomnia.org/~qg/chat-with-michael-k-edwards.html

There ya go.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-20 Thread v j


On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

Just in case anyone cares, after speaking with Michael for a few hours
I've found he's not nearly as abrasive as this mailing list banter
might suggest.  He makes some good arguments once you stop him from
spouting conspiracy stuff and, although I don't agree with all of
them, I think he has some good points.  He suggested posting a
transcript of our chat but, frankly, I don't think anyone wants to
read that.


If you can translate what he had to say in English, I certainly would
be willing to hear about it.

vj.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


Just in case anyone cares, after speaking with Michael for a few hours
I've found he's not nearly as abrasive as this mailing list banter
might suggest.  He makes some good arguments once you stop him from
spouting conspiracy stuff and, although I don't agree with all of
them, I think he has some good points.  He suggested posting a
transcript of our chat but, frankly, I don't think anyone wants to
read that.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-19 Thread v j


You are trying to cram this in a simple yes or no box, and it just doesn't
fit. There are questions nobody knows the answers to (such as what rights
you need to distribute a derivative work or whether compiling code makes a
translation).


Thanks, all for the discussion. I certainly learnt a lot. I definitely
expected to be flamed and roasted for posting my original message, and
was not disappointed :)

I do not possess all the knowledge ("legal" and technical) that people
who have contributed to this discussion possess. However I will still
comment from a user's perspective, which was my original point.

Many companies in the embedded field still mistakenly feel (or felt
until a while ago) that Linux was not right for them. That they would
have to open source their code, that they would not get adequate
support, and that Linux was too big and heavy to perform well in an
embedded platform. People like me who were Linux Desktop junkies were
actually trying to convince companies of the opposite.

Now the popularity of Linux is exploding in the embedded space. Nobody
talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be
a worthwhile experiment to study this surge in popularity. I am not an
expert, but perhaps the reason is "it works so goddamn well and has a
wealth of third party FREE software". Sure its a bit of work to make
it work on our platform and we don't have to Enea or Windriver to
write our gripes to. But it definitely is worth it.

Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
does to this popularity. I don't know. I am just giving you my
opinion. The moment companies learn of something like this, alarm
bells start to go off. This is not rational. I personally have nothing
against open-sourcing all software. *But*, this is not how companies
think.

Let's think about why Linux became so popular and strive towards
keeping it that way instead of resorting to innovative ways of just
confusing a lot of people.

Having said this, I am committed to contribute back to the Linux
community in any way I can, not withstanding my present employer. Keep
up the good work guys!


DS


vj.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers

Combined responses

> On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> > There is no legal meaning to "combining" two works of authorship under
> > the Berne Convention or any national implementation thereof.  If you
> > "compile" or "collect" them, you're in one area of law, and if you
> > create a work that "adapts" or "recasts" (or more generally "derives
> > from") them, you're in another area of law.

> As I said, you're having a purely semantic argument.

When someone uses a term that can mean more than one possible thing and then
uses the fact that it's true for one meaning to argue that it must be true
for the other, what else can you do other than point out that the term they
are using has multiple meanings?

> Regardless of what you *call* it, shoving two works together does not
> excuse you from the conditions of the license on one of those works,
> *when you make a copy*.

Nobody is arguing otherwise. Nobody is saying "you don't have to comply with
the GPL". We're saying that the GPL doesn't mean what people think it means.
In some cases it's because of the GPL's wording, but in other cases it's
because the GPL cannot set its own scope.

> And that's the GPL in a nutshell, if you want
> to copy the work, you need a license, if you want a license, you must
> abide the conditions, and one of the conditions is that you may not
> combine it with a work that is under an incompatible license unless it
> is mere aggregation.

Right. And all the cases we are talking about are mere aggregation (that is,
they do not create derivative works).

> Of course, now you're going to argue that there's no such thing as an
> "incompatible license" or "mere aggregation" and that these are just
> words that were made up for the GPL, so they can be ignored.. another
> pointless semantic argument because it doesn't change the very simple
> fact that you don't have any rights to copy the work unless you have a
> license and you don't have a license if you fail to abide the
> conditions of the license.

The issue is about what the license *means* and what its scope is. For
example, if the license said "if you ever use a work that is subject to this
license, you must place every work you create after that under the license",
that would obviously not be enforceable. The question of the *scope* of the
license is critical, and you can't read the license to understand its scope.

> Hang on, you're actually debating that you have to abide by conditions
> of a license before you can copy a copyright work?

Well, there are certainly cases where you can. Necessary step, first sale,
and fair use all provide possible situations where you can copy a
copyrighted work without complying with the license. But more generally, the
argument is over the scope of the license.

The GPL doesn't restrict the distribution of mere aggregations not because
the authors felt this was a wise decision, but because it *can't*. That is
outside the GPL's power. So the question of what's a "mere aggregation" is a
legal question about the scope of the GPL, and you have to look at law and
case law to understand it, not the text of the GPL.

The GPL grants you the permission to modify and distribute the original work
if you distribute the source of the original work. The GPL also puts certain
requirements on the distribution of derivative works. This is, as far as I
can tell, the maximum of the scope it can have.

You are trying to cram this in a simple yes or no box, and it just doesn't
fit. There are questions nobody knows the answers to (such as what rights
you need to distribute a derivative work or whether compiling code makes a
translation).

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

And for those reading along at home, _surely_ you understand the
meanings of "ambiguities in an offer of contract must be construed
against the offeror", "'derivative work' and 'license' are terms of
art in copyright law", and "not a valid limitation of scope".  If not,
I highly recommend to you that master of exposition who goes by "Op.
Cit.".


You're really not helping yourself in making a convincing argument here.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


And for those reading along at home, _surely_ you understand the
meanings of "ambiguities in an offer of contract must be construed
against the offeror", "'derivative work' and 'license' are terms of
art in copyright law", and "not a valid limitation of scope".  If not,
I highly recommend to you that master of exposition who goes by "Op.
Cit.".

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

No, dear, I'm just not interested in convincing you if you can't be
bothered to look back in the thread and Google a bit.  Think of it as
a penny ante, which is pretty cheap in a card game with billion-dollar
table stakes.


Well, with that attitude I can't imagine why people would think you're
a crackpot.. Maybe if you cut back on what you believe the motive is
for Eben Moglen wanting to misconstrue the law and focus on what you
actually claim the law is then people wouldn't mind trawling through
your insane ramblings to find the references that you claim back up
your extraordinary claims.

Now if you care to repeat your references here, without rambling on,
I'm happy to go read them and temporarily suspend my belief that
you're a crackpot.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

that's what I figured yes, as you're obviously not interested in
convincing anyone of your opinions, otherwise you wouldn't mind
repeating yourself when someone asks you a simple question.


No, dear, I'm just not interested in convincing you if you can't be
bothered to look back in the thread and Google a bit.  Think of it as
a penny ante, which is pretty cheap in a card game with billion-dollar
table stakes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

Can we put the gamesmanship on "low" here for a moment?  Ask yourself
which is more likely: am I a crank who spends years researching the
legal background of the GPL solely for the purpose of ranting
incoherently on debian-legal and LKML,


that's what I figured yes, as you're obviously not interested in
convincing anyone of your opinions, otherwise you wouldn't mind
repeating yourself when someone asks you a simple question.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

Hang on, you're actually debating that you have to abide by conditions
of a license before you can copy a copyright work?

Please, tell us the names of these appellate court decisions so that
we can read them and weep.


Can we put the gamesmanship on "low" here for a moment?  Ask yourself
which is more likely: am I a crank who spends years researching the
legal background of the GPL solely for the purpose of ranting
incoherently on debian-legal and LKML, or am I a mid-career embedded
software developer with an obsessive streak who has come to a
realization how dangerous this whole EXPORT_SYMBOL_GPL business is to
his niche in the industry?  Do I have an irrational hatred for people
named Eben, or am I sick to the heart of seeing decent young kids'
beliefs about the law perverted by a racketeer in attorney's clothing
with (at an informed guess) somewhere between $300K and $2M a year in
easy money from his web of "non-profit" shell companies?  I may be
_wrong_ -- but I'm not _witless_.

Now, if you want to play games, get yourself a copy of this
new-fangled invention called a "web browser", and Google for each set
of capitalized words with a "v." in between that has appeared in my
posts to LKML in the last few days.  For extra credit, follow links to
older posts, cleverly signposted with "http://";.  Repeat ad nauseam.
When you have an argument to offer that isn't already a blenderized
equine, preferably associated with a citation to one of those shiny
URL thingies with an "edu" or a "findlaw" in it, or even one of those
phrases with the magic "v.", I'm all ears.  Good morning -- and if I
don't see ya, good afternoon, good evening, and good night.

- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

I don't have to argue these points, because they're obvious to anyone
who cares to do their own homework.  Appellate court decisions _are_
the law, my friend; read 'em and weep.


Hang on, you're actually debating that you have to abide by conditions
of a license before you can copy a copyright work?

Please, tell us the names of these appellate court decisions so that
we can read them and weep.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

Of course, now you're going to argue that there's no such thing as an
"incompatible license" or "mere aggregation" and that these are just
words that were made up for the GPL, so they can be ignored.. another
pointless semantic argument because it doesn't change the very simple
fact that you don't have any rights to copy the work unless you have a
license and you don't have a license if you fail to abide the
conditions of the license.


I don't have to argue these points, because they're obvious to anyone
who cares to do their own homework.  Appellate court decisions _are_
the law, my friend; read 'em and weep.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

There is no legal meaning to "combining" two works of authorship under
the Berne Convention or any national implementation thereof.  If you
"compile" or "collect" them, you're in one area of law, and if you
create a work that "adapts" or "recasts" (or more generally "derives
from") them, you're in another area of law.


As I said, you're having a purely semantic argument.

Regardless of what you *call* it, shoving two works together does not
excuse you from the conditions of the license on one of those works,
*when you make a copy*.  And that's the GPL in a nutshell, if you want
to copy the work, you need a license, if you want a license, you must
abide the conditions, and one of the conditions is that you may not
combine it with a work that is under an incompatible license unless it
is mere aggregation.

Of course, now you're going to argue that there's no such thing as an
"incompatible license" or "mere aggregation" and that these are just
words that were made up for the GPL, so they can be ignored.. another
pointless semantic argument because it doesn't change the very simple
fact that you don't have any rights to copy the work unless you have a
license and you don't have a license if you fail to abide the
conditions of the license.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers

> On 2/20/07, David Schwartz <[EMAIL PROTECTED]> wrote:
> > There is no such thing as the "combined work". If I put a DVD
> > of The Phantom
> > Menace in the same box as a DVD of The Big Lebowski, the box is not a
> > "combined work".

> If you can't even agree on that the legal concept of a combined work
> exists then you're obviously too far from reality for anyone to reason
> with.

The term "combined work" is sometimes used to mean a combination of two or
more works whether or not the result is a work. It is also sometimes used to
refer to a work that contains literal elements from one or more other works.
There is a very important distinction between these two uses. (And it's
sometimes used to mean something that contains literal elements from one or
more works, whether or not that thing is a work and whether or not the
elements taken are protectable.)

In your example, there is no "the combined work" because the combination
does not produce a work. Look at my example, if you put a DVD of The Phantom
Menace in the same box as a DVD of The Big Lebowski, is the box a "combined
work"? Obviously not, it simply contains two works.

In any event, I've been unable to find anything remotely resembling a clear
definition of "combined work". It's not clear whether a "combined work" is
supposed to be a type of work or can be a combination of works that is not
itself a work.

I have seen many people say that something is "legally considered a combined
work", but as far as I can tell, there is no such legal term. If you have a
citation to the contrary, I'd very much like to see it.

> It's a given.. are you seriously contending that if you combine two
> copyright works you are not obliged to conform with the conditions of
> the license on one of them when making a copy of the combined work?

The problem with statements like the above is that it's imposisble to tell
what you're talking about. You use terms like "combined work", which as far
as I can tell, could mean almost anything. You talk about when you "combine
two works", but there are many different types of combination that have very
many different meanings. (For example, mere aggregation versus creative
selective combination.)

The short answer to your question is yes. Owners of intellectual property
have some rights but not all rights, and in many cases, the right you are
talking about is not one of the rights they have. This is not arbitrary or
some kind of loophole, this is for very fundamental and important reasons.

Copyright is not supposed to make any ideas any more difficult to express.
You are only supposed to be able to protect the one way you chose to express
an idea. It is a serious abuse of copyright to claim that your copyright
protects certain functional ideas such that all those who try to express
them must follow your rules.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> Bah.  Show us a citation to treaty, statute, or case law, anywhere in
> the world, Mr. Consensus-Reality.

It's a given.. are you seriously contending that if you combine two
copyright works you are not obliged to conform with the conditions of
the license on one of them when making a copy of the combined work?

There is no legal meaning to "combining" two works of authorship under
the Berne Convention or any national implementation thereof.  If you
"compile" or "collect" them, you're in one area of law, and if you
create a work that "adapts" or "recasts" (or more generally "derives
from") them, you're in another area of law.  A non-exclusive license
can authorize one of these categories of conduct and not the other, or
can slice and dice the scope of the license along almost any axis of
law or fact.  But what it can't do is use the phrase "derivative work"
passim -- a legal term of art invented by US judges and legislators to
corral a class of infringing works and treat them differently from
compilations -- and pretend that it also encompasses compilations
(copyrightable and otherwise; there is an originality threshold here
too) and use by reference.

If you are just arguing about the term, what term do you find more
appropriate?  Compilation?

If the amount of "adapting, translating, and recasting" done to the
pre-existing works crosses a minimum threshold of creative expression
(not "sweat of the brow", at least not under Feist), then you've
created a derivative work.  If the amount of "selecting and arranging"
done to create a compilation crosses a similar threshold of creative
expression, you've created a copyrightable compilation or collective
work.  If neither, then all you've done is copy and distribute.
That's how the law works.  IANAL, TINLA.

You guys seem to love pointless semantic arguments.  Are you always in
violent agreement?

Perhaps pointless if you were the sole audience, since you seem
disinclined to evaluate the accuracy of your beliefs given novel
information backed by extensive citations to the primary literature.
Not pointless if it disabuses other people, with less deeply ingrained
errors of understanding, of the notion that they can trust certain
very heavily financially interested parties to tell them the truth
about what the law says.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-19 Thread Michael Dreher

Am Montag, 19. Februar 2007 22:50 schrieb Michael K. Edwards:
> On 2/19/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
> > FWIW. A license is NOT a contract in the United States, according to
> > contract law. A primary requirement of a contract is an agreement. A
> > contract cannot, therefore, be forced. Licenses, on the other hand,
> > can be forced upon the user of the licensed material.
>
> Wrong.  Acceptance through conduct has been integral to contract law
> in common-law countries since the days of writs in Chancery, and is
> part of the codification of the difference between contracts "in
> personam" and "in rem".  Allow me to recommend Kevin Teeven's "A
> History of the Anglo-American Common Law of Contract".  It is settled
> law throughout the Western world that non-exclusive licenses of
> copyright need not be formalized, or even put in writing.  

Well, what you write is certainly not correct in Germany.
At least here in Germany, a licence is NOT a contract.
If you go into a shop and buy a cardboard box with a software CD in it, 
the only contract you have made is that contract with the shop
owner about purchasing this very box. The german law is very
explicit in stating that there is absolute NO contract with the producer
i.e., the software company which has the rights on the software.
And as a consequence, that funny microsoft eula is totally void,
even if you have clicked at "I agree". Never ever (at least in Germany)
constitutes the act of clicking this button a contract with the software
company. Because the law says that a contract is not valid without an 
agreement, and the law gives some requirements on the form of an agreement in
order to be valid, and "clicking somewhere" is not enough.

Of course, the user has to honor the general law which forbids copying and
distributing the software (except with permission from the creator).

Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

Bah.  Show us a citation to treaty, statute, or case law, anywhere in
the world, Mr. Consensus-Reality.


It's a given.. are you seriously contending that if you combine two
copyright works you are not obliged to conform with the conditions of
the license on one of them when making a copy of the combined work?

If you are just arguing about the term, what term do you find more
appropriate?  Compilation?

You guys seem to love pointless semantic arguments.  Are you always in
violent agreement?

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

If you can't even agree on that the legal concept of a combined work
exists then you're obviously too far from reality for anyone to reason
with.


Bah.  Show us a citation to treaty, statute, or case law, anywhere in
the world, Mr. Consensus-Reality.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/19/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:

FWIW. A license is NOT a contract in the United States, according to
contract law. A primary requirement of a contract is an agreement. A
contract cannot, therefore, be forced. Licenses, on the other hand,
can be forced upon the user of the licensed material.


Wrong.  Acceptance through conduct has been integral to contract law
in common-law countries since the days of writs in Chancery, and is
part of the codification of the difference between contracts "in
personam" and "in rem".  Allow me to recommend Kevin Teeven's "A
History of the Anglo-American Common Law of Contract".  It is settled
law throughout the Western world that non-exclusive licenses of
copyright need not be formalized, or even put in writing.  Licenses
cannot in any sense be forced on anyone; they are simply a defense
against an action for tort, a conditional waiver of the right to sue,
and cannot even be introduced as evidence by a plaintiff.


A license is a document that states the conditions under which an
item may be used. A prerequisite of the licensor is that he/she/they
have a legal right to control the thing being licensed. When a licensed
item has its license modified by a party, not the original licensor,
it is quite possible that such attempts to control the item are
invalid (moot). Lawyers like this because it gives them work since
the final resolution of such a action can old be determined by a
court!


Wrong again.  A copyright license is a term in an otherwise valid
written, oral, or implied offer of contract, with certain limitations
of scope and certain conditions and covenants of return performance,
waiving the right to sue for the statutory tort of copyright
infringement.  Read Nimmer on Copyright, or follow the links in this
paragraph (another self-quotation from two years ago,
http://lists.debian.org/debian-legal/2005/01/msg00621.html):


Same difference, legally.  Non-exclusive license has a longer history
in patent cases than in copyright, and copyright cases frequently
point to patent cases as precedent.  The commonly cited Supreme Court
precedent that a non-exclusive patent license is "a mere waiver of the
right to sue" is a 1927 case (De Forest Radio Telephone v. United
States, http://laws.findlaw.com/us/273/236.html ), which in turn cites
Robinson on Patents -- so it was evidently already well established by
then, at least with respect to patents.  Everex Systems v Cadtrak (aka
in re CFLC) 1996, for instance, cites De Forest in concluding that
such a license constitutes significant continuing performance
(settling, as far as I am concerned, the question about whether GPL
release is a "one-shot" act with no continuing performance -- it's
not).  For an example that all this applies to copyright, see Jacob
Maxwell v. Veeck 1997 ( http://laws.findlaw.com/11th/962636opa.html ),
which brings in re CFLC over to the copyright arena.


Please do not bother to trot out Webster's definition or medieval uses
of the word "license", or the theory of unilateral license with regard
to trespass and third-party beneficiaries.  These are concepts
different from "license" as used in the phrase "non-exclusive
copyright license", and just happen to be spelled the same.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/20/07, David Schwartz <[EMAIL PROTECTED]> wrote:

There is no such thing as the "combined work". If I put a DVD of The Phantom
Menace in the same box as a DVD of The Big Lebowski, the box is not a
"combined work".


If you can't even agree on that the legal concept of a combined work
exists then you're obviously too far from reality for anyone to reason
with.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-19 Thread linux-os \(Dick Johnson\)

On Mon, 19 Feb 2007, Michael K. Edwards wrote:

> On 2/19/07, Alan <[EMAIL PROTECTED]> wrote:
>>> jurisdiction.  Copyright infringement is a statutory tort, and the
>>> only limits to contracting away the right to sue for this tort are
>>> those provided in the copyright statute itself.  A contract not to sue
>>> for tort is called a "license".)
>>
>> I'd insert large quantities of "In the USA" in the above and probably
>> some "not what I've heard from a lawyer" cases.
>
> Name ANY counterexample in the entire history of copyright, anywhere
> in the world.  I've sifted through the past couple of decades of US
> appellate history until I'm blue in the face, and reviewed Canadian
> and British and German and French and EU statutes and decisions, and
> read Nimmer on Copyright and Corbin on Contracts and historical
> analyses of copyright law going back to the Statute of Anne.  And yes,
> I too have conversed with attorneys and other individuals with legal
> educations, in the US and Belgium and Brazil.
>
> You have been lied to.  You have been hoodwinked.  You have neglected
> to inform yourself about the simplest truths.  The GPL is not a
> "copyright-based license", anywhere in the developed world.  There.
> Is.  No.  Such.  Thing.

FWIW. A license is NOT a contract in the United States, according to
contract law. A primary requirement of a contract is an agreement. A
contract cannot, therefore, be forced. Licenses, on the other hand,
can be forced upon the user of the licensed material.

A license is a document that states the conditions under which an
item may be used. A prerequisite of the licensor is that he/she/they
have a legal right to control the thing being licensed. When a licensed
item has its license modified by a party, not the original licensor,
it is quite possible that such attempts to control the item are
invalid (moot). Lawyers like this because it gives them work since
the final resolution of such a action can old be determined by a
court!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5594.84 BogoMips).
New book: http://www.AbominableFirebug.com/
_

The information transmitted in this message is confidential and may be 
privileged.  Any review, retransmission, dissemination, or other use of this 
information by persons or entities other than the intended recipient is 
prohibited.  If you are not the intended recipient, please notify Analogic 
Corporation immediately - by replying to this message or by sending an email to 
[EMAIL PROTECTED] - and destroy all copies of this information, including any 
attachments, without reading or disclosing them.

Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

On 2/19/07, Alan <[EMAIL PROTECTED]> wrote:

> jurisdiction.  Copyright infringement is a statutory tort, and the
> only limits to contracting away the right to sue for this tort are
> those provided in the copyright statute itself.  A contract not to sue
> for tort is called a "license".)

I'd insert large quantities of "In the USA" in the above and probably
some "not what I've heard from a lawyer" cases.

Name ANY counterexample in the entire history of copyright, anywhere
in the world.  I've sifted through the past couple of decades of US
appellate history until I'm blue in the face, and reviewed Canadian
and British and German and French and EU statutes and decisions, and
read Nimmer on Copyright and Corbin on Contracts and historical
analyses of copyright law going back to the Statute of Anne.  And yes,
I too have conversed with attorneys and other individuals with legal
educations, in the US and Belgium and Brazil.

You have been lied to.  You have been hoodwinked.  You have neglected
to inform yourself about the simplest truths.  The GPL is not a
"copyright-based license", anywhere in the developed world.  There.
Is.  No.  Such.  Thing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-19 Thread Alan

> jurisdiction.  Copyright infringement is a statutory tort, and the
> only limits to contracting away the right to sue for this tort are
> those provided in the copyright statute itself.  A contract not to sue
> for tort is called a "license".)

I'd insert large quantities of "In the USA" in the above and probably
some "not what I've heard from a lawyer" cases.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers

> On Saturday 17 February 2007 15:19, David Schwartz wrote:

> > Static Controls argued that taking the TLP was the only practical way to
> > make a cartridge that would work with that printer.

> Which shows how that case is different from writing Linux drivers. For
> example, looking at the example the OP was himself proposing a few
> alternative approaches to work around the limitation they were hitting:
> could just switch to static major/minors instead of dynamics ones, they
> could skip sysfs, or they could even reimplement something like sysfs
> themselves, or whatever other interface they deem useful for the
> purpose of
> plopping in their own binary blob on top of it, sort of like what nVidia
> and ATi do for their stuff.

These are all different functional ideas.

It is no response to an argument like this to say, "you could always express
a different idea". Copyright only protects the one way the author chose to
express an idea. You should not ever need to change an idea to get around
copyright.

I hate to sound like a broken record, but have you read Lexmark v. Static
Controls? There was a section where they talked about how perhaps you could
have used a different algorithm to measure the toner level.

You may have to change your idea to get around a patent, but you should
never, ever have to change a functional idea to get around a copyright.

Do you realize that you are arguing for software patents? And worse, for
patents that are easy to get (and last as long) as copyrights.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers


> Sigh.  VJ is distributing the linux kernel with proprietary
> extensions.  If you want to argue that the proprietary extensions in
> isolation are not derivative works of the kernel, fine, you might have
> a case, but the combined work, which VJ is distributing is *clearly* a
> derivative work and must be distributed under the terms of the GPL.

There is no such thing as the "combined work". If I put a DVD of The Phantom
Menace in the same box as a DVD of The Big Lebowski, the box is not a
"combined work".

VJ is, presumably, distributing the Linux kernel and some additional works
that he has written. There is no "combined work" just because the two works
are distributed on the same media. There isn't even a "combined work" just
because the two works were designed to work together. (The DVD of the
Phantom Menace was designed to work with the firmware in my DVD player, but
it's absurd to argue that there is a "combined work" or that one is
derivative of the other.)

> Despite which, legal bullshit is best left for lawyers.. the *intent*
> of the GPL is that if you distribute *any* changes, extensions or
> plugins for a GPL work, you do so under the GPL.

Suppose the intent of the Microsoft EULA was that if you ever used Windows,
Microsoft owned every work of software you ever wrote. Should this "intent"
be honored? This kind of intent -- the intent of a license author to try to
leverage the license to own someone else's work, should be ridiculed and
dishonored.

> The law may not
> allow for this to be enforced, but it shouldn't need to.. one should
> read the GPL as 100% enforceable and follow it without looking for
> "loop holes" as it is the stated desire of how the author of the code
> wants you to use his work.  Looking for loop holes, and worse yet,
> discussing those loop holes in a public place, is just insulting.

I think this is a completely irrational view. The GPL *is* the rule we've
all been playing by. Not something in RMS' head. People who have chosen to
apply the GPL know what the GPL says, and only to some extent know what
other people meant or intended by it. The GPL *is* the rule.

As for law and loop holes, that's the supreme irony. The same people who
argue that people have too little freedom and intellectual property rights
are too great (and who oppose software patents) still seem to argue that
when *their* intellectual property is at stake, not even the law and the
text of their license limits their powers and control.

Let's not be a bunch of hypocrites.

> Yes, it does matter.. the author of the work has defined the terms
> under which you may use it.. if you don't like it, don't use the work.

Right, don't believe all that crap about "freedom". That's just PR speak.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-18 Thread Michael K. Edwards


Eensy weensy follow-up.  No screed.  Well, maybe just a _little_ screed.

On 2/18/07, Oleg Verych <[EMAIL PROTECTED]> wrote:

Ulrich Drepper is known to be against current FSF's position on glibc
licence changing.


Will that stop the FSF?  Will it stop Red Hat, MontaVista, or
CodeSourcery?  Even if Ulrich tells the FSF to stuff it where the sun
don't shine, and hosts his new fork on Google Code along with the rest
of the GNU corpus, the moment he or you or any of us wants to run any
binary that was compiled against a newer FSF glibc, we're screwed.
All it takes is for that binary to have a post-v3-switch symbol in its
link table (which can easily happen _without_ any change in the
application source code).

It's all very well to say we can live without anything that ships as a
binary, but commercial applications atop glibc are a big part of how
Linux left the hobbyist ghetto, and I don't want to go back there.  Do
you?  Or do you really want to spend the rest of your precious time on
Earth shimming clean-room reverse-engineered crap into
glibc-GPLv2-fork to keep Oracle running on a distro that Moglen
doesn't have by the 'nads?  Not that it really matters whether you're
using Oracle or MySQL -- an RDBMS, like any racing thoroughbred, goes
lame if you look at it funny, and once you've gotten burned once in
production by the unreproducibility of the golden bits, you won't try
it again.

The existence of GNU-free userlands is nice for us embedded folk but
ultimately useless for desktops and servers.  Talk to the people who
have spent untold person-years scrubbing bashisms out of Debian's
/etc/init.d.  Talk to the people who have ported their
industrial-scale multithreaded apps from linuxthreads (with its
annoying non-POSIX behaviors) to NPTL (with its equally annoying POSIX
behaviors).  Talk to the people struggling to package Gnome and KDE
for anything other than glibc, libstdc++, and (worst of all) ld.so.2.
Portability ain't all it's cracked up to be.

If you think "embrace, extend, destroy" is tattooed on Ballmer's
forehead, you should take a good look at an RMS word-portrait
sometime.  And imagine a nice private chat with the
if-you-can't-beat-'em-join-'em club -- from IBM and HP to Apple, Wind
River, and Sun.  Say what you will about Steve Jobs, he's a survivor
-- but the ex-CEOs of all the rest will give you an earful about being
shot out of the saddle by the "free software" mafia and replaced with
people who know how to do a deal with the devil and call it a
come-to-Jesus moment in the press release.

Intel is keeping mum -- they've made an industry out of playing both
ends against the middle, and they've got a compiler that can more or
less do Linux anyway, so they don't really care.  Google doesn't care
either -- they've got more cash than they can spend and can afford to
fork internally and go their merry way.  The only heavyweight that had
refused to get on board until very recently was Oracle.  Not just
because Larry Ellison likes to fly solo, either -- read
http://www.internetnews.com/dev-news/article.php/3614721.  Then read
http://www.internetnews.com/dev-news/article.php/3655261.  Larry, too,
is a survivor.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-18 Thread Trent Waddington


On 2/18/07, Theodore Tso <[EMAIL PROTECTED]> wrote:

Actually, the FSF and many of its representatives, has claimed, on
many occassions, that the GPL infects across dynamic linking.  That
is, if you write your own code that calls readline which links via a
dynamically linked shared library, and perhaps even across dlopen(),
they claim that the GPL applies to the code which you write.  Given
that the only way this could happen is via copyright law, they are
basically saying that if you use the readline interface, you have
created a derived work and they therefore 0wn your source code.


Is that so?


Whether or not this would be laughed out of court or not will very
much depend on the local legal precedents (and Trent Waddington has
quoted some very interesting legal cases based on US court decisions,


Wow?  I did?  Really?  I must have been sleep typing.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-18 Thread Pavel Machek

Hi!

> >Contrawise, if Embedded developers do contribute their 
> >device driver
> >changes back to the kernel, they will be fine.  ...
> ---
> 
> In fairness, though, some of the developers WILL bitch 
> about your not
> using a recent kernel and not providing patches until 
> products ship,
> despite that meeting the letter of the license. Some of 
> the notes in

Well, of course developers will complain, they _always_ complain. But
it is very different kind of complain... first is

'I think you are violating the law, you are evil'

and second is

'Thank you for playing by the rules, but you know, your code is not
mergeable right now'.

> this thread do exactly that. And I HAVE seen real 
> developers say
> something very close to "Your code is based on a kernel 
> too old to
> have any value to us" even though they would also claim 
> abuse if the
> code hadn't been made available at all. And I've seen 

Yep, and guess what, thats okay. Someone with more time than they do
may decide to forward port the code and/or rewrite it for new kernel.

I was doing exactly that with 2.4 sharp sl-5500 code.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-18 Thread Pavel Machek

Hi!

> >> (See, among other cases, Lexmark. v. Static
> >> Controls.) A copyright is not a patent, you can only 
> >own something if there
> >> are multiple equally good ways to do it and you claim 
> >*one* of them.
> >
> >Only in a world where "write a Linux module" is a 
> >"functional idea." I
> >don't think that the legal world in the US is an 
> >example of such a
> >world, though you clearly do.
> ---
> 
> "Interface the xyz device to the Linux kernel" is a 
> functional idea in
> pretty much the same sense that the Lexmark case 
> involved. You
> generally can't copyright functional interfaces; there 
> is a strong
> prejudice towards allowing interoperability.

You are welcome to write kernel modules without including *any* header
files. That may be ok in parts of US based on precedent you cite.

Somehow I do not think v j is doing, so he is violating our copyright.
Seems simple to me...

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-18 Thread Theodore Tso

On Sun, Feb 18, 2007 at 01:26:47PM +1000, Trent Waddington wrote:
> Such a strange attitude.. to go to all this effort to quote carefully
> and correctly one set of people and to then total misconstrue the
> words of another.
> 
> The FSF's argument in regards to readline is that you may not
> distribute readline with proprietary software linked to it.  They
> don't claim they "0wn" your source code.

Actually, the FSF and many of its representatives, has claimed, on
many occassions, that the GPL infects across dynamic linking.  That
is, if you write your own code that calls readline which links via a
dynamically linked shared library, and perhaps even across dlopen(),
they claim that the GPL applies to the code which you write.  Given
that the only way this could happen is via copyright law, they are
basically saying that if you use the readline interface, you have
created a derived work and they therefore 0wn your source code.

Whether or not this would be laughed out of court or not will very
much depend on the local legal precedents (and Trent Waddington has
quoted some very interesting legal cases based on US court decisions,
including an entertaining brief written by Eben Moglen decrying
interface copyrights which on the surface seems to go against
everything else the FSF has said since the Lotus case), but the
kernel-mailing list isn't the place to debate how law can be applied
to facts, or whether or not Eben Moglen is a hypocrite or not.

So can we please stop now?  I doubt anyone is going to be able to
convince anyone else on this matter; people's opinions are pretty well
formed by now, and until someone chooses to litigate on this specific
point about whether or not the GPL (v2 or v3) can infect across a
dynamic link in various jurisdictions, we're not going to settle it here.

Regards,

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-18 Thread Giuseppe Bilotta

On Sunday 18 February 2007 00:55, Michael K. Edwards wrote:

> Or they could run:
>     find . -type f -exec
perl -i.bak -pe 's/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g'
> and be done with it.  Or even just MODULE_LICENSE("GPL") in their
> module -- that's not "lying about the module license", it's "doing the
> minimum necessary in order to interoperate efficiently with the
> kernel".  Atari v. Nintendo is still good law, but only to the
> extent that it does not conflict with Lexmark, which now has the seal
> of Supreme Court approval.  And (IMHO, IANAL) if writing
> MODULE_LICENSE("GPL") is obviously the only remotely efficient way to
> achieve the goal of interoperation with the kernels that people
> already have on their systems

Except that this is not about a driver that is supposed to interoperated
with the kernels people already have on their systems. This is about
shipping new (embedded) systems with a modified (if you go the s/_GPL//g
route, even more so) Linux kernel, and distribution a modified kernel *has*
to comply with the GPL, since this is *exactly* what the GPL is about:
redistribution of modified copies of the work.

-- 
Giuseppe "Oblomov" Bilotta

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-18 Thread Oleg Verych

> From: "Michael K. Edwards"
> Newsgroups: gmane.linux.kernel
> Subject: Re: GPL vs non-GPL device drivers
> Date: Sat, 17 Feb 2007 22:56:00 -0800
[]
> How are you going to like being forced to fork the entire GNU corpus in
> whatever state it's in the day before the v3 conversion hits SVN?  Xorg
> is going to look like a cakewalk by comparison.

Don't worry, just help ;)

Ulrich Drepper is known to be against current FSF's position on glibc
licence changing.

Linus Torvalds has wrote sparse, which got it's maintainer. Maybe Google,
if it will, will do some job(backend) to get GCS (Google Compiling
Serivice ;), no need in compiler here (tm;).

Jeff Garzik doing his POSIX utilites.

There are many other alternatives to GNU software, and they are working
and being maintained, being "nongnu.org" or in their open source zoos,
rather than in savannah(.gnu.org (:

- dash / busybox (rip GNU bash)
- builders (many, rip GNU make)
- s-lang lib (rip GNU ncurses)
- jed, Xemacs (rip GNU Emacs)


After making live alternative to GNU software, you may *say* and *do*
everything you like against it. Indeed, i think Linux Kernel club is one
of such creatures (not with bull's head ;)

So, as you can see it's OK. Just grab your "non-GNU-Emacs" and join
the club!

Cheers.

p.s. i can be very naive, of course.
--
-o--=O`C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found  o (yes --- R.I.P. FSF+RMS)
<___=E M  man gcc: not found`-- ( viva Debian Operating System )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On second thought, let's not deconstruct this.  It's too much work,
and it's a waste of time.  Because if you can't read "anything other
people wrote is fair game, but what we write is sacred; our strategy
is to cajole when we can and strong-arm when we can't, and the law be
damned" into that, no amount of verbiage from me is going to change
your mind.


Er, that would be, "cajole when we must and strong-arm whenever we
can".  That didn't stay on the floor long enough to pick up any germs;
doesn't count.  :-)

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

This screed is the last that I am going to pollute LKML with, at least
for a while.  I'll write again if and when I have source code to
contribute, and if my off-topic vitriol renders my technical
contributions (if and when) unwelcome, I'll understand.  FSF
skulduggery is not very relevant to the _engineering_ of the kernel,
but it is (or ought to be) relevant to people's beliefs about whether
EXPORT_SYMBOL_GPL is the right thing to do.

On 2/17/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

On 2/18/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> If you can
> read that and still tolerate the stench of the FSF's argument that
> linking against readline means they 0wn your source code, you have a
> stronger stomach than I.

Such a strange attitude.. to go to all this effort to quote carefully
and correctly one set of people and to then total misconstrue the
words of another.

Dammit, the world at large has been far too nice to these people for
far too long.  There's no sin in people getting rich and/or famous,
but how they did it deserves some scrutiny.  The FSF is leading
thousands of idealistic young people all over the world up the garden
path by bullshitting about the nature of US law, and if Moglen at
least isn't making bank doing it, it isn't for lack of trying.  For
starters, read http://lists.debian.org/debian-legal/2005/07/msg00531.html
(another self-reference that doesn't need flowing in).  Google around
for his letters of opinion (not pro bono, I assure you) to Fluendo and
Vidomi.  How do they smell to you?

The GPL is big money, folks; the FSF General Counsel's designing "GPL
circumvention" schemes for other people's software -- and estopping
away his ability to contest them in court, one letter of opinion (and
one hefty lump-sum fee) at a time -- isn't a tenth of it.  Ask the
OSDL, who (I am very sorry to report) funneled $4M of certain hardware
makers' money to the SFLC to bankroll the expansion of Moglen's
protection racket.  Yes, protection racket.  What other phrase could
possibly describe the Software Freedom Conservancy?

Speaking of protection rackets, how about Moglen's plaintive comments,
back in the day, to the effect of (not a direct quote):  "The
conditions of the GPL can't touch Red Hat's new trademark policy,
subscription agreement, and ISV support lock-ins because they aren't
about copyright.  The GPL, as we all know, is a creature of copyright
law.  Even though the GPL says plainly, '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', that can't possibly be taken as an 'entire agreement'
clause, because the GPL isn't an offer of contract.  Don't like having
to pay per seat for RHEL?  Sorry, we can't help you."

This would be the same Red Hat that bought Cygnus Solutions in 1999 at
an estimated price of 674 MILLION dollars (in stock, of course).  That
made some individual Cygnus stockholders rich; see
http://www.salon.com/tech/feature/1999/11/18/red_hat/print.html.  Want
to bet Moglen held a Cygnus share or two, along with (via the FSF)
control over all the source code Cygnus had ever produced?  How does
it smell now?

There's yet more money in the toolchain oligopoly that Moglen and
Redmond tacitly share, and in embedded targets generally.  (Have you
ever asked yourself how the XCode and Tornado IDEs happened?  Have you
ever tried to obtain their source code?  Now do you understand why the
FSF fetishizes the fork/exec boundary?)  Redmond is not the FSF's
enemy; the phantom menace called "software patents" is, because they
protect other software makers from the FSF's volunteer army of reverse
engineers.  All those crocodile tears over TiVo, just because they
forked GCC, put the lower layers of MPEG into silicon, and wrote their
own damn DRM in RTL, instead of toeing Moglen's line on "give me naked
ripped media or give me death".  (No, I don't have first-hand
knowledge of any of these dealings; do your own research if you want
the sordid details.)

The FSF doesn't bother with kernels.  The HURD (nee Alix) is RMS's pet
project, and there are some charming young fellows who truly believe
it's going to win time trials and cure cancer someday, but I doubt
anyone in the know ever put cash money into it.  Some kernels are
better than others but once they work they're pretty interchangeable
for desktop and low-grade network server workloads.  They do, however,
take more engineering skill than the world's most prolific cloner of
other people's interfaces (RMS, in case that isn't blindingly obvious)
has ever been able to muster.  (RMS's skill exceeds mine, or used to;
but not by the light-years that Linus's, or even Theo's, does.)

However, the FSF is very careful not to let kernel authors' peanut
butter into _their_ chocolate, because the money is in supporting
toolchains for _proprietary_ kernels (Vx

Re: GPL vs non-GPL device drivers

2007-02-17 Thread Alexandre Oliva

On Feb 17, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

>> On Saturday 17 February 2007 03:42, David Schwartz wrote:
>> 
>> > Again, see Lexmark v. Static Controls. If "make a toner cartridge
>> > that works with a particular Lexmark printer" is a functional
>> > idea, why is "make a graphics driver that works with a particular
>> > Linux kernel" not? What is the difference you think matters?

>> That you cannot build such modules without integrating parts of
>> actual Linux kernel code (via #includes etc), whereas you can build
>> compatible toner cartridges without using any original component.

> Static Controls actually put a copy of Lexmark's 'Toner Loading Program' on
> each compatible cartridge they made. The printer actually copies the TLP off
> the cartridge. In other words, to make a compatible catridge, you do have to
> use an original component. (Or at least, it's much more difficult not to.)

Besides, you *can* build a module for Linux without using any kernel
code.  It just takes a lot of work to implement all you'd otherwise
need from the kernel in a clean-room fashion.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-17 Thread Alexandre Oliva

On Feb 17, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> Interestingly, if you are right, then what online translation services like
> babelfish [...]
> but much harder to argue that it gives them the right to create a derivative
> work. (Of course, you could argue fair use.)

One could try to argue it's an accessibility issue, if local fair use
has provisions for it.  Even for manual translations.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-17 Thread Trent Waddington


On 2/18/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

If you can
read that and still tolerate the stench of the FSF's argument that
linking against readline means they 0wn your source code, you have a
stronger stomach than I.


Such a strange attitude.. to go to all this effort to quote carefully
and correctly one set of people and to then total misconstrue the
words of another.

The FSF's argument in regards to readline is that you may not
distribute readline with proprietary software linked to it.  They
don't claim they "0wn" your source code.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/17/07, Neil Brown <[EMAIL PROTECTED]> wrote:

Suppose someone created a work of fiction titled - for example -
"Picnic at Hanging Rock".  And suppose further that this someone left
some issues unresolved at the end of the story, leaving many readers
feeling that they wanted one more chapter to complete the story and
give them a sense of closure.

Suppose that a number of independent individuals wrote such a chapter
that in very different ways completed the story.

[snip]

They are derived works because they borrow the characters, the setting,
the theme, etc of the original work, and build on it.


Very well put.  That doctrine is sometimes known as "mise en scene",
and is every bit as applicable to software as to any other sort of
creative work.  When, that is, the software has characters, setting,
theme, etc.  See Micro Star v. Formgen (available anywhere Google hits
are sold).


In a similar way, people claim that any driver written for Linux will
inevitably borrow some creative content that is in Linux, via the
various interfaces that are used (and it is the nature of kernel
modules that the interface between the module and the kernel is quite
intimate).  And so, they claim that any driver written for Linux will
ipso-facto be a derived work.  The interface that ties the kernel and
the module together is certainly more intimate than the interface
between the Printer and the Toner in the Lexmark case.


Yes, people claim these things.  It's just that they're wrong.  Read
Lexmark.  Read the First Circuit opinion in Lotus v. Borland.  For
some really eye-opening dialogue, read the transcript of oral argument
before the Supreme Court in the Lotus v. Borland certioriari
proceeding.  For some long-winded but cogent discourse, read the
amicus curiae brief of the League for Programming Freedom in Lotus v.
Borland, submitted to the Supremes by one Eben Moglen.  If you can
read that and still tolerate the stench of the FSF's argument that
linking against readline means they 0wn your source code, you have a
stronger stomach than I.


Also, the "every practical way" point doesn't entirely apply.  In a
growing number of cases, it is possible to write a driver in
user-space.  This is apparently true for USB and is becoming true for
PCI.  And writing drivers as user-space programs is explicitly not a
derived work for the purposes of the Linux kernel license.


"Possible" doesn't mean "practical".  Compare Galoob and Micro Star,
Atari v. Nintendo and Sega v. Accolade.  There's a fine line, and
Judge Sutton walked up one side of it and down the other, and his
fellow panelists ably advocated drawing it either to the left or to
the right of where he had.  When the Supremes denied cert. -- in a
case where the appellate court had vacated and remanded to the
district court, meaning that they had to demonstrate that the lower
court had erred _as_a_matter_of_law_ -- they endorsed Judge Sutton's
reading of the record.  Lexmark is now settled law.
MODULE_LICENSE("GPL") on a binary-only turd is -- insofar as you can
demonstrate to the court of fact that it resembles the Lexmark fact
pattern, anywhere in the US -- as legal as an 8.5" x 14" pad of yellow
paper.  IANAL, TINLA.


So while that case sets an interesting precedent, I don't think it can
apply to the general issue of Linux kernel modules.


I mean this in the nicest possible way:  Think again.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-17 Thread Trent Waddington


On 2/18/07, David Lang <[EMAIL PROTECTED]> wrote:

by this same logic the EULA's that various commercial vendors use are
completely valid,

it doesn't matter what the intent is if it's not a legal thing to require.


Yes, it does matter.. the author of the work has defined the terms
under which you may use it.. if you don't like it, don't use the work.

There's a name for people who look at everything in terms of "you
can't make me".

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-17 Thread David Lang

On Sun, 18 Feb 2007, Trent Waddington wrote:

Despite which, legal bullshit is best left for lawyers.. the *intent*
of the GPL is that if you distribute *any* changes, extensions or
plugins for a GPL work, you do so under the GPL. The law may not
allow for this to be enforced, but it shouldn't need to.. one should
read the GPL as 100% enforceable and follow it without looking for
"loop holes" as it is the stated desire of how the author of the code
wants you to use his work. Looking for loop holes, and worse yet,
discussing those loop holes in a public place, is just insulting.

by this same logic the EULA's that various commercial vendors use are completely
valid, and the e-mail sigs that make you liable for reading e-mail are also
valid.

it doesn't matter what the intent is if it's not a legal thing to require.

in the case of the GPL the key is the border of being a drivitive work or not.

some people would like to interpret this so broadly as to make it impossible to
run userspace code on a GPL OS, however everyone who is sane recognises that
this is beyond the boundry.

in the case of kernel modules, this is very murky territory, and it's one that
nobody has felt compelled (and confident enough in the outcome) to litigate.

I've heard many people express their opinion on what it takes to be a derivitive
work, but very few lawyers

one of the few that I have seen is from IBM's lawyers in the SCO case

quote:
Second, SCO's claim that Dynix/ptx is a "derivative work" within the meaning of SCO's definition is likewise unhelpful
to its motion. As an initial matter, the assertion is untenable because it is based on a definition of "derivative works
based on such SOFTWARE PRODUCT" that is unsupported and in dispute (as stated above). Moreover, SCO fails even to identify
the versions and components of the SOFTWARE PRODUCT and Dynix/ptx to which SCO refers. It is impossible to determine whether one
product is a derivative work of another product without specific reference to what is at issue. See Gates Rubber Co. v. Bando
Chem. Indus., 9 F.3d 823, 834 (10th Cir. 1993) (indicating that, in determining whether one work is a derivative of another, a
court should "dissect", "examine", and "compare" the two specific works in question).

To support the proposition that Dynix/ptx is a derivative work of UNIX System V, SCO relies entirely on the testimony of its
experts, Mr. Marc Rochkind and Dr. Thomas Cargill. However, as SCO admits, Mr. Rochkind's testimony is based solely on a
"computer-science perspective". (SCO Br. at 14.) There is no basis for importing into the Agreement the perspective of
a single computer scientist offered two decades after the Agreement was signed and providing no objective standard for his
testimony. 4 See Fed. R. Evid. 702 (requiring that expert testimony be "the product of reliable principles and
methods"). The term "derivative work" is a term of art under copyright law and is explicitly defined in the
Copyright Act as "a work that is based on (or derived from) one or more already existing works. . . in which the editorial
revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship". 17
U.S.C.A. ? 101 (West 2006). In the absence of a provision in the Agreement to the contrary, the term "derivative work"
should be understood to have the meaning that it has under federal law. One of IBM's experts, Professor Randall Davis, has
provided unrebutted testimony that the portions of Dynix specifically challenged by SCO are not derivative works of UNIX System
V. (Ex. 181 ?50.)

this seems to be saying that the boundries of derivitive work as far as
copyright goes are much more limited then just about anyone in computer science
would define the term

David Lang

Re: GPL vs non-GPL device drivers

2007-02-17 Thread Trent Waddington


On 2/17/07, David Schwartz <[EMAIL PROTECTED]> wrote:

I don't think that's grey at all. I think it's perfectly clear that linking
cannot create a derivative work. No automated process can -- it takes
creativity to create a derivative work. (That doesn't mean that just because
you can link A to B, a cannot be a derivative work of B or vice verse, of
course. It just means that if A is not a derivative work of B, linking A to
B cannot make it so, nor can the result be a derivative work.)


Sigh.  VJ is distributing the linux kernel with proprietary
extensions.  If you want to argue that the proprietary extensions in
isolation are not derivative works of the kernel, fine, you might have
a case, but the combined work, which VJ is distributing is *clearly* a
derivative work and must be distributed under the terms of the GPL.

Despite which, legal bullshit is best left for lawyers.. the *intent*
of the GPL is that if you distribute *any* changes, extensions or
plugins for a GPL work, you do so under the GPL.  The law may not
allow for this to be enforced, but it shouldn't need to.. one should
read the GPL as 100% enforceable and follow it without looking for
"loop holes" as it is the stated desire of how the author of the code
wants you to use his work.  Looking for loop holes, and worse yet,
discussing those loop holes in a public place, is just insulting.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/17/07, Giuseppe Bilotta <[EMAIL PROTECTED]> wrote:

Which shows how that case is different from writing Linux drivers. For
example, looking at the example the OP was himself proposing a few
alternative approaches to work around the limitation they were hitting:
could just switch to static major/minors instead of dynamics ones, they
could skip sysfs, or they could even reimplement something like sysfs
themselves, or whatever other interface they deem useful for the purpose of
plopping in their own binary blob on top of it, sort of like what nVidia
and ATi do for their stuff.


Or they could run:
   find . -type f -exec perl -i.bak -pe 's/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g'
and be done with it.  Or even just MODULE_LICENSE("GPL") in their
module -- that's not "lying about the module license", it's "doing the
minimum necessary in order to interoperate efficiently with the
kernel".  Atari v. Nintendo is still good law, but _only_ to the
extent that it does not conflict with Lexmark, which now has the seal
of Supreme Court approval.  And (IMHO, IANAL) if writing
MODULE_LICENSE("GPL") is obviously the only remotely efficient way to
achieve the goal of interoperation with the kernels that people
already have on their systems, through the documented, tested,
currently recommended APIs (like sysfs), then you have a Sega / Altai
/ Lexmark fact pattern, not an Atari v. Nintendo fact pattern.

So what's the penalty for MODULE_LICENSE("GPL") on code that is not
actually offered under the GPL?  Being shunned by the kernel
community.  Maintaining a fork.  Getting to keep both halves when it
breaks.  Friends don't let friends write non-GPL drivers.  But friends
also don't let friends go off into delusional spasms of denial.
nVidia and ATI do what they do so that their code has more than a
snowball's chance in hell of running on people's desktops, not out of
fear that the Big Bad LKML Wolf will come blow down their houses.
Their hardware is doubtless so fiddly and buggy and crash-prone that
four out of five attempts to compile a driver for it reorder the
instructions enough to slag the GPU, under Windows or Linux.  _That's_
why they ship binary drivers.  Capisce?

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers

2007-02-17 Thread Giuseppe Bilotta

On Saturday 17 February 2007 15:19, David Schwartz wrote:

> Static Controls argued that taking the TLP was the only practical way to
> make a cartridge that would work with that printer.

Which shows how that case is different from writing Linux drivers. For
example, looking at the example the OP was himself proposing a few
alternative approaches to work around the limitation they were hitting:
could just switch to static major/minors instead of dynamics ones, they
could skip sysfs, or they could even reimplement something like sysfs
themselves, or whatever other interface they deem useful for the purpose of
plopping in their own binary blob on top of it, sort of like what nVidia
and ATi do for their stuff.

-- 
Giuseppe "Oblomov" Bilotta

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/17/07, Dave Neuer <[EMAIL PROTECTED]> wrote:

I think you are reading Lexmark wrong. First off, Lexmark ruled that
scenes a faire applied to the toner-level calculation, not "make a
toner cartridge that works with a particular Lexmark printer." It was
the toner-calculation algorithm that could't be done any other sane
way, which made the TLP unprotectable via copyright. The opinion says,
"Both prongs of the infringement test, in other words, consider
'copyrightability,' which at its heart turns on the principle that
copyright protection extends to expression, not to ideas."


David S. is reading Lexmark right (IMHO, IANAL).  The byte-for-byte
content of the TLP had to be copied in order to interoperate with the
printer, because the printer checksummed it (apparently using SHA-1,
but possibly truncating the result to 8 bits, which is rather comical;
it is not 100% clear to me based on the appellate decision, which also
seems to say that the printer cartridge contains the SHA-1 algorithm,
which is probably just an error).  That rendered it a "lock-out code"
within the sense of Sega v. Accolade, and ultimately that's why the
circuit court vacated the district court's decision in Lexmark's
favor.

In order to vacate and remand, the appellate court had to demonstrate
that the district court's grant of preliminary injunction to Lexmark
was wrong _as_a_matter_of_law_.  So they had to construe the facts of
the case in a light as favorable to Lexmark as humanly possible.  They
concluded that, _even_ if the TLP contained copyrightable expression,
and _even_ if all of the district court's reasoning about the other
prongs of a preliminary injunction test (potential for irreparable
harm, balance of harms, the public interest) were correct, neither the
Copyright Act nor the DMCA could be used to establish the fourth
prong: likelihood of success on the merits.

Cloners rejoice:  the US Supreme Court has, by denying certioriari on
Judge Sutton's opinion, given you carte blanche to copy and distribute
freely any software or firmware whose author has been so stupid as to
cryptographically checksum it as an anti-interoperability measure.
Using copyrighted software as a "lock-out code" to create a cause of
action against reverse engineers has the paradoxical effect of
rendering it uncopyrightable _as_a_matter_of_law_ in the US, unless
and until Congress or a later Supreme Court creates new law to the
contrary.  I am not a lawyer, this is not legal advice, on your own
head be it.


You're saying that there's no other way to interface device drivers to
an operating system than the current Linux driver model? That's
strange, since it's a different driver model than Linux had
previously, and it's also different from the BeOS driver interface,
etc. If the Linux driver interface is protectable, it doesn't seem
like scenes a faire applies.


The Linux driver interface is, as a matter of law, not copyrightable
in the U. S. of A., no matter how many EXPORT_SYMBOL_GPLs and dactylic
hexameters you adorn it with.  That was already true under Baker v.
Selden, and didn't get any less so as a result of Lotus v. Borland,
and is now inescapable (IMHO) under Lexmark, and it's not likely to
get any less true unless RMS is elected president and appoints Eben
Moglen to the Supreme Court.  Sorry, folks; I'm just the messenger.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers


> You're saying that there's no other way to interface device drivers to
> an operating system than the current Linux driver model?

Interfacing an X1900 graphics card to FreeBSD and interfacing an X1900
graphics card to Linux are two different ideas. They are *not* two
expressions of the same idea.

> That's
> strange, since it's a different driver model than Linux had
> previously, and it's also different from the BeOS driver interface,
> etc. If the Linux driver interface is protectable, it doesn't seem
> like scenes a faire applies.

These are all diferent ideas. Scenes a faire applies to how you express a
given idea, not other ideas you could possibly express. (This is explicitly
addressed in the decision.)

Otherwise, there would be no scenes a faire. Perhaps you cannot make a
western without a shootout at high noon, but you can make a romance.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-17 Thread Dave Neuer

On 2/16/07, David Schwartz <[EMAIL PROTECTED]> wrote:

> On 2/16/07, David Schwartz <[EMAIL PROTECTED]> wrote:

> > (See, among other cases, Lexmark. v. Static
> > Controls.) A copyright is not a patent, you can only own
> > something if there
> > are multiple equally good ways to do it and you claim *one* of them.

> Only in a world where "write a Linux module" is a "functional idea." I
> don't think that the legal world in the US is an example of such a
> world, though you clearly do.

I'm not arguing "write a Linux module" is a functional idea. But "write code
so that a graphics card with a X1950 chipset works with a Linux kernel"
certainly is.

Again, see Lexmark v. Static Controls. If "make a toner cartridge that works
with a particular Lexmark printer" is a functional idea, why is "make a
graphics driver that works with a particular Linux kernel" not? What is the
difference you think matters?

I think you are reading Lexmark wrong. First off, Lexmark ruled that
scenes a faire applied to the toner-level calculation, not "make a
toner cartridge that works with a particular Lexmark printer." It was
the toner-calculation algorithm that could't be done any other sane
way, which made the TLP unprotectable via copyright. The opinion says,
"Both prongs of the infringement test, in other words, consider
'copyrightability,' which at its heart turns on the principle that
copyright protection extends to expression, not to ideas."

You're saying that there's no other way to interface device drivers to
an operating system than the current Linux driver model? That's
strange, since it's a different driver model than Linux had
previously, and it's also different from the BeOS driver interface,
etc. If the Linux driver interface is protectable, it doesn't seem
like scenes a faire applies.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers

> On 2/17/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> > Per this principle, it would seem that only source code and
> > hand-crafted object code would be governed by copyright, since
> > compilation is also an automated process.

> Well, compilation is probably equivalent to "translation", which is
> specifically included in the Act as forming a derivative work.

I would hope that courts will hold that "translation" still means what it
originally meant -- the creative process of converting a work from one
language to another where one has to choose how to map the concepts behind a
work to the most appropriate concept in a different language. Clearly
translating Jabberwocky into German is creative in a way that compiling the
Linux kernel from C to x86 binary is not.

Interestingly, if you are right, then what online translation services like
babelfish (that allow you to see a web site in another language) do is
probably illegal as they create derivative works without permission of the
copyright holder. It's easy to argue that putting up a web site grants
people implicit permission to copy and render it so that they can see it,
but much harder to argue that it gives them the right to create a derivative
work. (Of course, you could argue fair use.)

As far as I know, no court has addressed this issue. But I think the
sensible thing is to hold that "translation", in copyright law, is meant as
an example of one type of creative process that could create a derivative
work, not that any process that can be argued to be translation (whether
creative or not) automatically makes the result a work for copyright
purposes.

But you never know.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers


On 2/17/07, Scott Preece <[EMAIL PROTECTED]> wrote:

Well, compilation is probably equivalent to "translation", which is
specifically included in the Act as forming a derivative work.


Nix.  "Translation" is something that humans do.  What's governed by
copyright is the creative expression contained in a work, and it makes
no difference whether it's source code or object code, RTL or silicon,
PDF or parchment.  There's a requirement of tangible fixation for
registration purposes, so you can't claim copyright on a story that's
in your head which you haven't written down.  But what's copyrightable
about a computer program is neither the "ideas and methods of
operation" nor the blob of bits (compiled or not); it's the
idiosyncrasies, the human touches, the things that would differ
between two equally skilled coders' ways of putting those ideas into
language.

A judge doesn't care whether a C compiler will spin silk purses or
spit chunks when fed this language, except insofar as duplicating
another coder's language (by trial and error or by blatant, arrant,
heartless enslavement of poor little bytes in ROM) is obligatory in
order to build a silk-purse-spinner.  You can't claim copyright on the
only way to accomplish some engineering purpose.  Even if that purpose
is to interoperate with, or even substitute for, someone else's
software or hardware in a way that destroys its marketability or turns
its author's moral imperatives into subjunctives.  Them's the breaks,
folks; if you don't like it, write poetry instead.  (And don't use it
as a passphrase for a printer cartridge.)

(You also can't claim copyright on something that isn't your work of
authorship, so you can't just write down someone else's sermon and go
obtain copyright registration on it.  Or rather, you can, but you will
lose when you try to sue someone else for infringing it, because
you've falsified the registration.  Under the Berne Convention, you
have also not spoiled the actual author's opportunity to write it
down, register her copyright, and sue you and anyone else for
infringing it.  People who thought they licensed it legitimately from
the ostensible copyright holder may have a defense of innocent
infringement, depending on whether the author can demonstrate
negligence according to the usual tort standards in the relevant
jurisdiction.  Copyright infringement is a statutory tort, and the
only limits to contracting away the right to sue for this tort are
those provided in the copyright statute itself.  A contract not to sue
for tort is called a "license".)

Again, I recommend the Lexmark v. Static Control decision to you.  It
references the major appellate decisions in this space from the late
70's forward, mostly from the 9th and 2nd Circuits.  The full text is
available from FindLaw; the few older decisions not available from
FindLaw are easily Googled.  Or you could just mine the debian-legal
archives for the links; sadly, 80% or more of the actual citations to
case law or statute in the debian-legal archives are in my
handwriting, so you can't take that as an independent source of
information.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

2007-02-17 Thread Scott Preece


On 2/17/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:


Per this principle, it would seem that only source code and
hand-crafted object code would be governed by copyright, since
compilation is also an automated process.

---

Well, compilation is probably equivalent to "translation", which is
specifically included in the Act as forming a derivative work.

scott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers

> On Saturday 17 February 2007 03:42, David Schwartz wrote:
>
> > Again, see Lexmark v. Static Controls. If "make a toner cartridge that
> > works
> > with a particular Lexmark printer" is a functional idea, why is "make a
> > graphics driver that works with a particular Linux kernel" not? What is
> > the
> > difference you think matters?

> That you cannot build such modules without integrating parts of
> actual Linux
> kernel code (via #includes etc), whereas you can build compatible toner
> cartridges without using any original component.

Static Controls actually put a copy of Lexmark's 'Toner Loading Program' on
each compatible cartridge they made. The printer actually copies the TLP off
the cartridge. In other words, to make a compatible catridge, you do have to
use an original component. (Or at least, it's much more difficult not to.)

Static Controls argued that taking the TLP was the only practical way to
make a cartridge that would work with that printer. The court held that you
cannot use copyright to own every practical way to perform some function, so
as used in the compatible cartridge, the TLP was not protectable by
copyright. (The same work and the same elements can be protectable in one
context and not another.)

But in any event, your entire argument makes no sense. I was citing Lexmark
v. Static Controls here for the point that making an object to make X work
with Y is a function. I was responding to the argument that "Linux driver
for a particular piece of hardware" is more like a specific expression of an
idea than an idea. The court in this case held that a "toner cartridge that
works with a particular Lexmark printer" was an idea, not an expression.
It's hard to see how a "X1950 driver that works with a particular Linux
kernel" is similarly not an idea.

The implicit argument is that while you could not own every driver, you
might be able to own every Linux driver. That is, that while a "driver" is
an idea, a "Linux driver" might be a particular expression of an idea. But
if that were true, why couldn't Lexmark own every cartridge that worked with
this particular printer? (With a "toner cartridge" being an idea but a
"toner cartridge that works with this particular printer" being an
expression.)

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers