Re: spinlocks, the GPL, and binary-only modules

Re: spinlocks, the GPL, and binary-only modules

[Giacomo Catenazzi]

Andre Hedrick wrote:

> On 20 Nov 2002, Alan Cox wrote:
>
>
> >On Wed, 2002-11-20 at 18:57, Andre Hedrick wrote:
> >
> >>The double negative unwrapped:
> >>
> >>"Being a module doesnt make it not a derivative work."
> >>
> >>'Being a module does (not) make it not a derivative work.'
> >>'Being a module does (not) make it (not) a derivative work.'
> >>
> >>'Being a module does make it a derivative work.'
> >>
> >>Is this the intent of the statement?
> >
> >No
>
>
> Excellent!
>
> Now if Linus would just make to position clear.

Check this Linus' post: recent and with clear statment:
http://lwn.net/Articles/13066/
[Full discussion in http://lwn.net/Articles/13398/, support LWN!]

ciao
	giacomo

Re: spinlocks, the GPL, and binary-only modules

[Herman Oosthuysen]

The way I read it, the GPL is not the monster that most people think it 
is.  In order to understand the GPL, you have to read all the acts that 
apply and that should start with the constitution of your country and 
state.  You cannot read the GPL in isolation and think that you 
understand it.  "Beware of a man of only one book", applies in this case.

Using a header file in proprietary code, could be argued as reverse 
engineering to ensure interoperability with another program.  This type 
of thing is described in the DMCA in the USA and in the copyright acts 
of other countries, which are all pretty much the same.  Since the GPL 
depends on the various Copyright acts, I think that using a GPL header 
in proprietary code to ensure compatibility, is allowed.

Another thing to bear in mind, is that 'fair use' is also allowed under 
the various copyright acts.  Consequently it can be argued that you may 
use *some* GPL code in proprietary code and the larger the base of GPL 
code becomes, the larger the amount of fair use that will be allowed. 
Since the total GPL code base of the kernel is now many megabytes in 
size, fair use of some kilobytes of GPL code may very well be reasonable.

Check this out with your own lawyers...

Cheers,
-- 

------------------------------------------------------------------------
Herman Oosthuysen
B.Eng.(E), Member of IEEE
Wireless Networks Inc.
http://www.WirelessNetworksInc.com
E-mail: Herman@WirelessNetworksInc.com
Phone: 1.403.569-5687, Fax: 1.403.235-3965
------------------------------------------------------------------------

Mark Mielke wrote:

 > On Wed, Nov 20, 2002 at 01:06:39AM -0200, Rik van Riel wrote:
 >
 >> On Wed, 20 Nov 2002, David McIlwraith wrote:
 >>
 >>> How should it? The compiler (specifically, the C preprocessor) includes
 >>> the code, thus it is not the AUTHOR violating the GPL.
 >>
 >>
 >> If the compiler includes a .h file, it happens because
 >> the programmer told it to do so, using a #include.
 >
 >
 >
 > I was recently re-reading the GPL and I came to the following conclusion:
 >
 > The GPL is only an issue if the software is *distributed* with GPL
 > software. Meaning -- it is not legal to distribute a linux kernel that
 > contains non-GPL code, however, it *is* legal for an administrator to
 > install linux, and then download a copy of the dynamically linked
 > module from a separate web site, under a different (incompatible)
 > license, and load it into the kernel. This new kernel image is a
 > 'derived work', however, as long as the new kernel image is not
 > distributed to 'the public', the GPL terms do *not* come into play.
 >
 > While I believe my understanding on this issue to be correct, I still
 > haven't answered the original question... is it legal to distribute a
 > non-GPL binary that used a GPL header file to be compiled? Is the
 > answer to this different depending on the amount of code that is
 > generated using the GPL header file as source (i.e. inlined
 > functions)?
 >
 > mark
 >

Re: spinlocks, the GPL, and binary-only modules

[Russ Allbery]

Mark Mielke <mark@mark.mielke.cc> writes:

> I think this restriction (the need for copyright assignment) only
> applies to code 'incorporated in FSF projects', whatever that means. See
> the GPL FAQ for a rather vague explanation.

> Are 'FSF projects' the packages that can be downloaded from ftp.gnu.org?

Copyright assignments are only needed for projects for which the FSF holds
the copyright and requires copyright assignments, and then only if one
wants one's code to make it into the GNU-distributed version.

I don't believe it is possible to answer that question with more
granularity without going down to a project-by-project check.  There
certainly have been packages available from ftp.gnu.org that do not
require copyright assignments to contribute to.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: spinlocks, the GPL, and binary-only modules

[Nicholas Berry]

>>> Andre Hedrick <andre@linux-ide.org> 11/20/02 01:57PM >>>
<snip>

> The double negative unwrapped:

> "Being a module doesnt make it not a derivative work."

> 'Being a module does (not) make it not a derivative work.'
> 'Being a module does (not) make it (not) a derivative work.'

> 'Being a module does make it a derivative work.'

> Is this the intent of the statement?

> Andre Hedrick
> LAD Storage Consulting Group

Logical fallacy. You're converting a universal proposition.

Not being on lkml does not make me a fool !=
Being on lkml  makes me a fool.

Nik

Re: spinlocks, the GPL, and binary-only modules

[Samium Gromoff]

> When you GPL a piece of software, you sign over your rights to the FSF.
> Therefore, there is very little that can be done about this;
> from a legal perspective, the FSF _itself
> determines what is and what isn't construed as a derived work.
    Microsoft would _love_ the world to think that GPL is like that.
  I`m sorry this is a plain FUD.

---
cheers,
   Samium Gromoff
_____________________________________

Re: spinlocks, the GPL, and binary-only modules

[Mark Mielke]

On Wed, Nov 20, 2002 at 09:31:08AM +0300, Samium Gromoff wrote:
> > When you GPL a piece of software, you sign over your rights to the FSF.
> > Therefore, there is very little that can be done about this;
> > from a legal perspective, the FSF _itself
> > determines what is and what isn't construed as a derived work.
> Microsoft would _love_ the world to think that GPL is like that.
> I`m sorry this is a plain FUD.

I think this restriction (the need for copyright assignment) only
applies to code 'incorporated in FSF projects', whatever that
means. See the GPL FAQ for a rather vague explanation.

Are 'FSF projects' the packages that can be downloaded from ftp.gnu.org?

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: spinlocks, the GPL, and binary-only modules

[David McIlwraith]

Ugh. Seems I misunderstood; I didn't note the reference to binary modules.
----- Original Message -----
From: "David McIlwraith" <quack@bigpond.net.au>
To: <linux-kernel@vger.kernel.org>
Sent: Wednesday, November 20, 2002 1:49 PM
Subject: Re: spinlocks, the GPL, and binary-only modules


> How should it? The compiler (specifically, the C preprocessor) includes
the
> code, thus it is not the AUTHOR violating the GPL.
>
> ----- Original Message -----
> From: "Rik van Riel" <riel@conectiva.com.br>
> To: "Jeff Garzik" <jgarzik@pobox.com>
> Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
> Sent: Wednesday, November 20, 2002 12:52 PM
> Subject: Re: spinlocks, the GPL, and binary-only modules
>
>
> > On Tue, 19 Nov 2002, Jeff Garzik wrote:
> >
> > > So, since spinlocks and semaphores are (a) inline and #included into
> > > your code, and (b) required for just about sane interoperation with
> Linux...
> > >
> > > does this mean that all binary-only modules that #include kernel code
> > > such as spinlocks are violating the GPL?
> >
> > > But who knows if #include'd code constitutes a derived work :(
> >
> > Only if the #included snippets of code are large enough to be
> > protected by copyright, which might be true of the stuff in
> > mm_inline.h and of some of the semaphore code, but probably
> > isn't true of the spinlock code.
> >
> > Even if the code #included is large enough to be protected by
> > copyright I don't know if the code including it would be considered
> > a derived work. Many questions remaining...
> >
> > regards,
> >
> > Rik
> > --
> > Bravely reimplemented by the knights who say "NIH".
> > http://www.surriel.com/ http://guru.conectiva.com/
> > Current spamtrap:  <a
> href=mailto:"october@surriel.com">october@surriel.com</a>
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
>

spinlocks, the GPL, and binary-only modules

[Jeff Garzik]

blah.

So, since spinlocks and semaphores are (a) inline and #included into 
your code, and (b) required for just about sane interoperation with Linux...

does this mean that all binary-only modules that #include kernel code 
such as spinlocks are violating the GPL?  IOW just about every binary 
module out there, I would think...

I'm sure this would make extremeists happy, but I personally don't mind 
binary-only modules as long as the binary-only code [ignoring the 
#included kernel code] cannot be considered a derived work.

But who knows if #include'd code constitutes a derived work :(

	Jeff

Re: spinlocks, the GPL, and binary-only modules

[Rik van Riel]

On Tue, 19 Nov 2002, Jeff Garzik wrote:

> So, since spinlocks and semaphores are (a) inline and #included into
> your code, and (b) required for just about sane interoperation with Linux...
>
> does this mean that all binary-only modules that #include kernel code
> such as spinlocks are violating the GPL?

> But who knows if #include'd code constitutes a derived work :(

Only if the #included snippets of code are large enough to be
protected by copyright, which might be true of the stuff in
mm_inline.h and of some of the semaphore code, but probably
isn't true of the spinlock code.

Even if the code #included is large enough to be protected by
copyright I don't know if the code including it would be considered
a derived work. Many questions remaining...

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: spinlocks, the GPL, and binary-only modules

[Josh Myer]

On Tue, 19 Nov 2002, Rik van Riel wrote:
> On Tue, 19 Nov 2002, Jeff Garzik wrote:
> > But who knows if #include'd code constitutes a derived work :(
>
> Only if the #included snippets of code are large enough to be
> protected by copyright, which might be true of the stuff in
> mm_inline.h and of some of the semaphore code, but probably
> isn't true of the spinlock code.
>

(US-Centric, since that's where I'm from, live, and code)

Since you're functionally using it, and it's not a protected use (Satire,
etc, though some would argue that the nvidia drivers are a mockery...), I
would tend to think Fair Use wouldn't apply in this case. Are there any IP
Lawyers in the house?

The only analogy i can think of is a remix of songs, and several people
have gotten into wonderfully large lawsuits over that.

> Even if the code #included is large enough to be protected by
> copyright I don't know if the code including it would be considered
> a derived work. Many questions remaining...
>

This basically all falls upon the shoulders of whoever wrote the spinlock
code on whatever platform you're compiling for...

At this point, I think it's safe to say that the days of the legally
unencumbered binary-only module (read: binary-only modules you aren't
liable to get sued for) are numbered. Personally, I'm a little
saddened at the loss of openness, but won't miss weird binary-only
problems.
--
/jbm, but you can call me Josh. Really, you can!
 "What's a metaphor?" "For sheep to graze in"
7958 1C1C 306A CDF8 4468  3EDE 1F93 F49D 5FA1 49C4

Re: spinlocks, the GPL, and binary-only modules

[Rik van Riel]

On Tue, 19 Nov 2002, Josh Myer wrote:
> On Tue, 19 Nov 2002, Rik van Riel wrote:
> > On Tue, 19 Nov 2002, Jeff Garzik wrote:
> > > But who knows if #include'd code constitutes a derived work :(
> >
> > Only if the #included snippets of code are large enough to be
> > protected by copyright, which might be true of the stuff in
> > mm_inline.h and of some of the semaphore code, but probably
> > isn't true of the spinlock code.

> Since you're functionally using it, and it's not a protected use
> (Satire, etc, though some would argue that the nvidia drivers are a
> mockery...), I would tend to think Fair Use wouldn't apply in this case.
> Are there any IP Lawyers in the house?
>
> The only analogy i can think of is a remix of songs, and several people
> have gotten into wonderfully large lawsuits over that.

You can copyright songs, but not individual musical notes.

Likewise, snippets of code aren't copyrightable if they're below
a certain "triviality size".

> > Even if the code #included is large enough to be protected by
> > copyright I don't know if the code including it would be considered
> > a derived work. Many questions remaining...
>
> This basically all falls upon the shoulders of whoever wrote the spinlock
> code on whatever platform you're compiling for...

No, this is an issue of legislation and case law. Some copyright
holders (*eyes hollywood*) would like to be able to decide such
things for themselves, but this isn't something copyright holders
can decide...

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: spinlocks, the GPL, and binary-only modules

[Ross Vandegrift]

On Wed, Nov 20, 2002 at 12:59:26AM -0200, Rik van Riel wrote:
> You can copyright songs, but not individual musical notes.
> 
> Likewise, snippets of code aren't copyrightable if they're below
> a certain "triviality size".

I don't pretend to be current on all the issues involved, but I've
always been under the impression that Linus has insisted that
binary-only drivers aren't derived works, with respect to the GPL.

If someone is worried they are, make all future headers state it
explicitly:

"Including this header in a Linux kernel module shall not be construed
to constitute a derived work."

-- 
Ross Vandegrift
ross@willow.seitz.com

A Pope has a Water Cannon.                               It is a Water Cannon.
He fires Holy-Water from it.                        It is a Holy-Water Cannon.
He Blesses it.                                 It is a Holy Holy-Water Cannon.
He Blesses the Hell out of it.          It is a Wholly Holy Holy-Water Cannon.
He has it pierced.                It is a Holey Wholly Holy Holy-Water Cannon.
He makes it official.      It is a Cannon Holey Wholly Holy Holy-Water Cannon.
Batman and Robin arrive.                                       He shoots them.

Re: spinlocks, the GPL, and binary-only modules

[archaios]

When you GPL a piece of software, you sign over your rights to the FSF. Therefore, there is very little that can be done about this;
from a legal perspective, the FSF _itself_ determines what is and what isn't construed as a derived work.

- David McIlwraith
----- Original Message -----
From: Ross Vandegrift <ross@willow.seitz.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: <linux-kernel@vger.kernel.org>
Sent: Wednesday, November 20, 2002 3:26 PM
Subject: Re: spinlocks, the GPL, and binary-only modules


On Wed, Nov 20, 2002 at 12:59:26AM -0200, Rik van Riel wrote:
> You can copyright songs, but not individual musical notes.
>
> Likewise, snippets of code aren't copyrightable if they're below
> a certain "triviality size".

I don't pretend to be current on all the issues involved, but I've
always been under the impression that Linus has insisted that
binary-only drivers aren't derived works, with respect to the GPL.

If someone is worried they are, make all future headers state it
explicitly:

"Including this header in a Linux kernel module shall not be construed
to constitute a derived work."

--
Ross Vandegrift
ross@willow.seitz.com

A Pope has a Water Cannon.                               It is a Water Cannon.
He fires Holy-Water from it.                        It is a Holy-Water Cannon.
He Blesses it.                                 It is a Holy Holy-Water Cannon.
He Blesses the Hell out of it.          It is a Wholly Holy Holy-Water Cannon.
He has it pierced.                It is a Holey Wholly Holy Holy-Water Cannon.
He makes it official.      It is a Cannon Holey Wholly Holy Holy-Water Cannon.
Batman and Robin arrive.                                       He shoots them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

What pile if CRACK are you smoking?

Just because I assign parts of my IP portfolio to GPL does not give
anything to FSF and they have no rights or assignment.  When did the
kernel become assigned to FSF?

Getting warmer,

Andre Hedrick
LAD Storage Consulting Group

On Wed, 20 Nov 2002, archaios wrote:

> When you GPL a piece of software, you sign over your rights to the FSF. Therefore, there is very little that can be done about this;
> from a legal perspective, the FSF _itself_ determines what is and what isn't construed as a derived work.
> 
> - David McIlwraith
> ----- Original Message -----
> From: Ross Vandegrift <ross@willow.seitz.com>
> To: Rik van Riel <riel@conectiva.com.br>
> Cc: <linux-kernel@vger.kernel.org>
> Sent: Wednesday, November 20, 2002 3:26 PM
> Subject: Re: spinlocks, the GPL, and binary-only modules
> 
> 
> On Wed, Nov 20, 2002 at 12:59:26AM -0200, Rik van Riel wrote:
> > You can copyright songs, but not individual musical notes.
> >
> > Likewise, snippets of code aren't copyrightable if they're below
> > a certain "triviality size".
> 
> I don't pretend to be current on all the issues involved, but I've
> always been under the impression that Linus has insisted that
> binary-only drivers aren't derived works, with respect to the GPL.
> 
> If someone is worried they are, make all future headers state it
> explicitly:
> 
> "Including this header in a Linux kernel module shall not be construed
> to constitute a derived work."
> 
> --
> Ross Vandegrift
> ross@willow.seitz.com
> 
> A Pope has a Water Cannon.                               It is a Water Cannon.
> He fires Holy-Water from it.                        It is a Holy-Water Cannon.
> He Blesses it.                                 It is a Holy Holy-Water Cannon.
> He Blesses the Hell out of it.          It is a Wholly Holy Holy-Water Cannon.
> He has it pierced.                It is a Holey Wholly Holy Holy-Water Cannon.
> He makes it official.      It is a Cannon Holey Wholly Holy Holy-Water Cannon.
> Batman and Robin arrive.                                       He shoots them.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: spinlocks, the GPL, and binary-only modules

[Jon Portnoy]

Blatantly false. Have you even _read_ the GPL? It doesn't seem that way - 
in which case why are you discussing it?

Please get your facts straight. While you're at it, please avoid making 
yourself look like an idiot in the future.

On Wed, 20 Nov 2002, archaios wrote:

> When you GPL a piece of software, you sign over your rights to the FSF. Therefore, there is very little that can be done about this;
> from a legal perspective, the FSF _itself_ determines what is and what isn't construed as a derived work.
> 
> - David McIlwraith
> ----- Original Message -----
> From: Ross Vandegrift <ross@willow.seitz.com>
> To: Rik van Riel <riel@conectiva.com.br>
> Cc: <linux-kernel@vger.kernel.org>
> Sent: Wednesday, November 20, 2002 3:26 PM
> Subject: Re: spinlocks, the GPL, and binary-only modules
> 
> 
> On Wed, Nov 20, 2002 at 12:59:26AM -0200, Rik van Riel wrote:
[snip]

Re: spinlocks, the GPL, and binary-only modules

[Alan Cox]

On Wed, 2002-11-20 at 04:26, Ross Vandegrift wrote:
> On Wed, Nov 20, 2002 at 12:59:26AM -0200, Rik van Riel wrote:
> > You can copyright songs, but not individual musical notes.
> > 
> > Likewise, snippets of code aren't copyrightable if they're below
> > a certain "triviality size".
> 
> I don't pretend to be current on all the issues involved, but I've
> always been under the impression that Linus has insisted that
> binary-only drivers aren't derived works, with respect to the GPL.

Linus has said much the reverse if you look back. Being a module doesnt
make it not a derivative work. In some ways thats not even directly
relevant

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

On 20 Nov 2002, Alan Cox wrote:

> On Wed, 2002-11-20 at 04:26, Ross Vandegrift wrote:
> > On Wed, Nov 20, 2002 at 12:59:26AM -0200, Rik van Riel wrote:
> > > You can copyright songs, but not individual musical notes.
> > > 
> > > Likewise, snippets of code aren't copyrightable if they're below
> > > a certain "triviality size".
> > 
> > I don't pretend to be current on all the issues involved, but I've
> > always been under the impression that Linus has insisted that
> > binary-only drivers aren't derived works, with respect to the GPL.
> 
> Linus has said much the reverse if you look back. Being a module doesnt
> make it not a derivative work. In some ways thats not even directly
> relevant

The double negative unwrapped:

"Being a module doesnt make it not a derivative work."

'Being a module does (not) make it not a derivative work.'
'Being a module does (not) make it (not) a derivative work.'

'Being a module does make it a derivative work.'

Is this the intent of the statement?

Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Daniel Jacobowitz]

On Wed, Nov 20, 2002 at 10:57:58AM -0800, Andre Hedrick wrote:
> On 20 Nov 2002, Alan Cox wrote:
> 
> > On Wed, 2002-11-20 at 04:26, Ross Vandegrift wrote:
> > > On Wed, Nov 20, 2002 at 12:59:26AM -0200, Rik van Riel wrote:
> > > > You can copyright songs, but not individual musical notes.
> > > > 
> > > > Likewise, snippets of code aren't copyrightable if they're below
> > > > a certain "triviality size".
> > > 
> > > I don't pretend to be current on all the issues involved, but I've
> > > always been under the impression that Linus has insisted that
> > > binary-only drivers aren't derived works, with respect to the GPL.
> > 
> > Linus has said much the reverse if you look back. Being a module doesnt
> > make it not a derivative work. In some ways thats not even directly
> > relevant
> 
> The double negative unwrapped:
> 
> "Being a module doesnt make it not a derivative work."
> 
> 'Being a module does (not) make it not a derivative work.'
> 'Being a module does (not) make it (not) a derivative work.'
> 
> 'Being a module does make it a derivative work.'
> 
> Is this the intent of the statement?

That's faulty grammar and faulty logic.  "A" does not require "not B".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

On Wed, 20 Nov 2002, Daniel Jacobowitz wrote:

> On Wed, Nov 20, 2002 at 10:57:58AM -0800, Andre Hedrick wrote:
> > On 20 Nov 2002, Alan Cox wrote:
> > 
> > > On Wed, 2002-11-20 at 04:26, Ross Vandegrift wrote:
> > > > On Wed, Nov 20, 2002 at 12:59:26AM -0200, Rik van Riel wrote:
> > > > > You can copyright songs, but not individual musical notes.
> > > > > 
> > > > > Likewise, snippets of code aren't copyrightable if they're below
> > > > > a certain "triviality size".
> > > > 
> > > > I don't pretend to be current on all the issues involved, but I've
> > > > always been under the impression that Linus has insisted that
> > > > binary-only drivers aren't derived works, with respect to the GPL.
> > > 
> > > Linus has said much the reverse if you look back. Being a module doesnt
> > > make it not a derivative work. In some ways thats not even directly
> > > relevant
> > 
> > The double negative unwrapped:
> > 
> > "Being a module doesnt make it not a derivative work."
> > 
> > 'Being a module does (not) make it not a derivative work.'
> > 'Being a module does (not) make it (not) a derivative work.'
> > 
> > 'Being a module does make it a derivative work.'
> > 
> > Is this the intent of the statement?
> 
> That's faulty grammar and faulty logic.  "A" does not require "not B".
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

So fix the intent and make it clear.
I am not an english major.
I generally try to keep you disk storage alive.


Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Alan Cox]

On Wed, 2002-11-20 at 18:57, Andre Hedrick wrote:
> The double negative unwrapped:
> 
> "Being a module doesnt make it not a derivative work."
> 
> 'Being a module does (not) make it not a derivative work.'
> 'Being a module does (not) make it (not) a derivative work.'
> 
> 'Being a module does make it a derivative work.'
> 
> Is this the intent of the statement?

No

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

On 20 Nov 2002, Alan Cox wrote:

> On Wed, 2002-11-20 at 18:57, Andre Hedrick wrote:
> > The double negative unwrapped:
> > 
> > "Being a module doesnt make it not a derivative work."
> > 
> > 'Being a module does (not) make it not a derivative work.'
> > 'Being a module does (not) make it (not) a derivative work.'
> > 
> > 'Being a module does make it a derivative work.'
> > 
> > Is this the intent of the statement?
> 
> No

Excellent!

Now if Linus would just make to position clear.

Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Thomas Langås]

Rik van Riel:
> > The only analogy i can think of is a remix of songs, and several people
> > have gotten into wonderfully large lawsuits over that.
> You can copyright songs, but not individual musical notes.

Right, you need atleast a X number of notes to make it a copyrighted piece,
doesn't have to be a whole song, tho. If someone snags 10-20 secs of a song,
and puts it into his/her song that's violation of the copyrights (given
that the person didn't ask for permission). But, then there's "what's the
minimum"-question, and with code that's hard, and you would probably need
a lawyer and a few settlements in the court-systems, if not even more,
to get an agreement on this.

-- 
Thomas

Re: spinlocks, the GPL, and binary-only modules

[Dana Lacoste]

On Wed, 2002-11-20 at 13:57, Thomas Langås wrote:
> If someone snags 10-20 secs of a song,
> and puts it into his/her song that's violation of the copyrights (given
> that the person didn't ask for permission). But, then there's "what's the
> minimum"-question

7 seconds for music.

What's 7 seconds worth of code? :)

--
Dana Lacoste
Ottawa, Canada

Re: spinlocks, the GPL, and binary-only modules

[nick]

Ahh, but that's 7 seconds of *PREFORMED* music.  This implies that no
matter how much past work has gone into it, if it can be run in under 7
seconds it can't be copyrighted.  I rather like this interpretation.
	Nick

On 20 Nov 2002, Dana Lacoste wrote:

> On Wed, 2002-11-20 at 13:57, Thomas Langås wrote:
> > If someone snags 10-20 secs of a song,
> > and puts it into his/her song that's violation of the copyrights (given
> > that the person didn't ask for permission). But, then there's "what's the
> > minimum"-question
> 
> 7 seconds for music.
> 
> What's 7 seconds worth of code? :)
> 
> -- 
> Dana Lacoste
> Ottawa, Canada
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

How about 7% of code max that can pollute the headers and not taint the
closed source.


On Wed, 20 Nov 2002 nick@snowman.net wrote:

> Ahh, but that's 7 seconds of *PREFORMED* music.  This implies that no
> matter how much past work has gone into it, if it can be run in under 7
> seconds it can't be copyrighted.  I rather like this interpretation.
> 	Nick
> 
> On 20 Nov 2002, Dana Lacoste wrote:
> 
> > On Wed, 2002-11-20 at 13:57, Thomas Langås wrote:
> > > If someone snags 10-20 secs of a song,
> > > and puts it into his/her song that's violation of the copyrights (given
> > > that the person didn't ask for permission). But, then there's "what's the
> > > minimum"-question
> > 
> > 7 seconds for music.
> > 
> > What's 7 seconds worth of code? :)
> > 
> > -- 
> > Dana Lacoste
> > Ottawa, Canada
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[nick]

7% of the code you're takeing from, or 7% of the code you're adding
to?  Either of these can be abused badly.  What do you
count?  Words?  Lines?  Uncommented lines?  Non-blank uncommented
lines?  I think it should and can be argued that the 7 second rule is
sound for code as well as music.
	Nick

On Wed, 20 Nov 2002, Andre Hedrick wrote:

> 
> How about 7% of code max that can pollute the headers and not taint the
> closed source.
> 
> 
> On Wed, 20 Nov 2002 nick@snowman.net wrote:
> 
> > Ahh, but that's 7 seconds of *PREFORMED* music.  This implies that no
> > matter how much past work has gone into it, if it can be run in under 7
> > seconds it can't be copyrighted.  I rather like this interpretation.
> > 	Nick
> > 
> > On 20 Nov 2002, Dana Lacoste wrote:
> > 
> > > On Wed, 2002-11-20 at 13:57, Thomas Langås wrote:
> > > > If someone snags 10-20 secs of a song,
> > > > and puts it into his/her song that's violation of the copyrights (given
> > > > that the person didn't ask for permission). But, then there's "what's the
> > > > minimum"-question
> > > 
> > > 7 seconds for music.
> > > 
> > > What's 7 seconds worth of code? :)
> > > 
> > > -- 
> > > Dana Lacoste
> > > Ottawa, Canada
> > > 
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > > 
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> 
> Andre Hedrick
> LAD Storage Consulting Group
> 
> 

Re: spinlocks, the GPL, and binary-only modules

[Rik van Riel]

On 20 Nov 2002, Dana Lacoste wrote:
> On Wed, 2002-11-20 at 13:57, Thomas Langås wrote:
> > If someone snags 10-20 secs of a song,
> > and puts it into his/her song that's violation of the copyrights (given
> > that the person didn't ask for permission). But, then there's "what's the
> > minimum"-question
>
> 7 seconds for music.

Even more fun is that this limit probably varies per country
and governments are tending towards applying their own law
against every work which is made available to their country,
regardless of where it is being published from...

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: spinlocks, the GPL, and binary-only modules

[David McIlwraith]

How should it? The compiler (specifically, the C preprocessor) includes the
code, thus it is not the AUTHOR violating the GPL.

----- Original Message -----
From: "Rik van Riel" <riel@conectiva.com.br>
To: "Jeff Garzik" <jgarzik@pobox.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Sent: Wednesday, November 20, 2002 12:52 PM
Subject: Re: spinlocks, the GPL, and binary-only modules


> On Tue, 19 Nov 2002, Jeff Garzik wrote:
>
> > So, since spinlocks and semaphores are (a) inline and #included into
> > your code, and (b) required for just about sane interoperation with
Linux...
> >
> > does this mean that all binary-only modules that #include kernel code
> > such as spinlocks are violating the GPL?
>
> > But who knows if #include'd code constitutes a derived work :(
>
> Only if the #included snippets of code are large enough to be
> protected by copyright, which might be true of the stuff in
> mm_inline.h and of some of the semaphore code, but probably
> isn't true of the spinlock code.
>
> Even if the code #included is large enough to be protected by
> copyright I don't know if the code including it would be considered
> a derived work. Many questions remaining...
>
> regards,
>
> Rik
> --
> Bravely reimplemented by the knights who say "NIH".
> http://www.surriel.com/ http://guru.conectiva.com/
> Current spamtrap:  <a
href=mailto:"october@surriel.com">october@surriel.com</a>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: spinlocks, the GPL, and binary-only modules

[Rik van Riel]

On Wed, 20 Nov 2002, David McIlwraith wrote:

> How should it? The compiler (specifically, the C preprocessor) includes
> the code, thus it is not the AUTHOR violating the GPL.

"Your honour, he didn't die because I shot him; he died
because he tried to catch the bullet, with his chest..."

If the compiler includes a .h file, it happens because
the programmer told it to do so, using a #include.

The programmer (or the copyright holder of the code) is
responsible.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: spinlocks, the GPL, and binary-only modules

[Mark Mielke]

On Wed, Nov 20, 2002 at 01:06:39AM -0200, Rik van Riel wrote:
> On Wed, 20 Nov 2002, David McIlwraith wrote:
> > How should it? The compiler (specifically, the C preprocessor) includes
> > the code, thus it is not the AUTHOR violating the GPL.
> If the compiler includes a .h file, it happens because
> the programmer told it to do so, using a #include.

I was recently re-reading the GPL and I came to the following conclusion:

The GPL is only an issue if the software is *distributed* with GPL
software. Meaning -- it is not legal to distribute a linux kernel that
contains non-GPL code, however, it *is* legal for an administrator to
install linux, and then download a copy of the dynamically linked
module from a separate web site, under a different (incompatible)
license, and load it into the kernel. This new kernel image is a
'derived work', however, as long as the new kernel image is not
distributed to 'the public', the GPL terms do *not* come into play.

While I believe my understanding on this issue to be correct, I still
haven't answered the original question... is it legal to distribute a
non-GPL binary that used a GPL header file to be compiled? Is the
answer to this different depending on the amount of code that is
generated using the GPL header file as source (i.e. inlined
functions)?

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: spinlocks, the GPL, and binary-only modules

[Xavier Bestel]

Le mer 20/11/2002 à 09:12, Mark Mielke a écrit :
> On Wed, Nov 20, 2002 at 01:06:39AM -0200, Rik van Riel wrote:
> > On Wed, 20 Nov 2002, David McIlwraith wrote:
> > > How should it? The compiler (specifically, the C preprocessor) includes
> > > the code, thus it is not the AUTHOR violating the GPL.
> > If the compiler includes a .h file, it happens because
> > the programmer told it to do so, using a #include.
> 
> I was recently re-reading the GPL and I came to the following conclusion:
> 
> The GPL is only an issue if the software is *distributed* with GPL
> software. Meaning -- it is not legal to distribute a linux kernel that

Yeah, that's precisely the problem here: the binary-only module is
distributed with included spinlock code, which *is* GPL.

Re: spinlocks, the GPL, and binary-only modules

[Alan Cox]

On Wed, 2002-11-20 at 10:17, Xavier Bestel wrote:
> Yeah, that's precisely the problem here: the binary-only module is
> distributed with included spinlock code, which *is* GPL.

That doesnt neccessarily make it a derived work. Suppose I publish a
book including a lawyer who says "Your honour I ...". That doesn't make
it a derivative of some previous work I read that used the same phrase.

Equally if I paraphase the entire court scene but use no identical words
it may be a derived work. 

Stop thinking about this as a mathematical question. It isnt about the
union of sets of instructions.

Alan

Re: spinlocks, the GPL, and binary-only modules

[Richard B. Johnson]

On 20 Nov 2002, Alan Cox wrote:

> On Wed, 2002-11-20 at 10:17, Xavier Bestel wrote:
> > Yeah, that's precisely the problem here: the binary-only module is
> > distributed with included spinlock code, which *is* GPL.
> 
> That doesnt neccessarily make it a derived work. Suppose I publish a
> book including a lawyer who says "Your honour I ...". That doesn't make
> it a derivative of some previous work I read that used the same phrase.
> 
> Equally if I paraphase the entire court scene but use no identical words
> it may be a derived work. 
> 
> Stop thinking about this as a mathematical question. It isnt about the
> union of sets of instructions.
> 
> Alan
> 

Well stated. Further "spin-locks" are generic things that have nothing
to do with Linux, much less GPL. It has been pretty much established
that there are some kernel internals that writers have insisted cannot
be accessed except by GPL code. These are typically complex things
that can be easily broken by incorrect access. Therefore, the writer
insists that if you access that procedure, or tamper with the elements
of some structure, then your code must be GPL so that it may be
publicly scrutinized. There is other kernel code that is so obvious
that, even though an incorrect access can break things, the writer
figured that if you break it, you just keep the pieces. So, it
boils down to what lawyers call "intent". And as Alan stated, it
isn't mathematics.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
   Bush : The Fourth Reich of America

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

On 20 Nov 2002, Alan Cox wrote:

> On Wed, 2002-11-20 at 10:17, Xavier Bestel wrote:
> > Yeah, that's precisely the problem here: the binary-only module is
> > distributed with included spinlock code, which *is* GPL.
> 
> That doesnt neccessarily make it a derived work. Suppose I publish a
> book including a lawyer who says "Your honour I ...". That doesn't make
> it a derivative of some previous work I read that used the same phrase.
> 
> Equally if I paraphase the entire court scene but use no identical words
> it may be a derived work. 
> 
> Stop thinking about this as a mathematical question. It isnt about the
> union of sets of instructions.
> 
> Alan

This can be made clean if all the inlined C in the headers are pushed
back to an actual .c file and the make it function to call as an extern.
So the solution is to make a patch and publish that patch which cleans the
out the C code in question and move the associacted GPL license to the new
.c files.  This is proper and legal as structs are just the glue or api.

So if I publish this patch where it can be freely available for usage by
all, I comply with GPL.  This also removes any of the "extremists" points
of the smallest amount of GPL code invoked by the compiler can not touch
pure code.

Any arguments why this will not work?



Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Cort Dougan]

} This can be made clean if all the inlined C in the headers are pushed
} back to an actual .c file and the make it function to call as an extern.
} So the solution is to make a patch and publish that patch which cleans the
} out the C code in question and move the associacted GPL license to the new
} .c files.  This is proper and legal as structs are just the glue or api.
} 
} So if I publish this patch where it can be freely available for usage by
} all, I comply with GPL.  This also removes any of the "extremists" points
} of the smallest amount of GPL code invoked by the compiler can not touch
} pure code.
} 
} Any arguments why this will not work?

Maybe something else would be better.  Adding -fno-inline to the build
might be more useful.  It makes things a bit cleaner.

It's a nasty mess to have to do this for every subsystem when someone gets
a wild-hair and starts inline-ing things without thinking.

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

On Wed, 20 Nov 2002, Cort Dougan wrote:

> } This can be made clean if all the inlined C in the headers are pushed
> } back to an actual .c file and the make it function to call as an extern.
> } So the solution is to make a patch and publish that patch which cleans the
> } out the C code in question and move the associacted GPL license to the new
> } .c files.  This is proper and legal as structs are just the glue or api.
> } 
> } So if I publish this patch where it can be freely available for usage by
> } all, I comply with GPL.  This also removes any of the "extremists" points
> } of the smallest amount of GPL code invoked by the compiler can not touch
> } pure code.
> } 
> } Any arguments why this will not work?
> 
> Maybe something else would be better.  Adding -fno-inline to the build
> might be more useful.  It makes things a bit cleaner.
> 
> It's a nasty mess to have to do this for every subsystem when someone gets
> a wild-hair and starts inline-ing things without thinking.

Well since there is a fork for everything else,  how about a
business-linux-2.{4,5} fork?

As a place to make it even harder for the extremist to whine and cry over
the usages of binary only modules.

Comments?

Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Cort Dougan]

} Well since there is a fork for everything else,  how about a
} business-linux-2.{4,5} fork?
} 
} As a place to make it even harder for the extremist to whine and cry over
} the usages of binary only modules.
} 
} Comments?

Maybe it's best to not add yet another fork.  I just managed to
dis-entangle myself from maintaining some trees and wouldn't wish that on
anyone else.  A single config option that adds -fno-inline wouldn't be
fork-worthy.

As for extremists complaining... I think you'd just give them a target and
a forum rather than quiet them.

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

So " -fno-inline " should be enough to squelch the extremists?

So lets hear from the extremists who do not have the money to litigate yet
can scare people away with noise and their angery rants.  Sort of what LA
has with the gang turf wars.  The ones who are to afraid to show thier
face but will stab in the back in the right moment.


On Wed, 20 Nov 2002, Cort Dougan wrote:

> } Well since there is a fork for everything else,  how about a
> } business-linux-2.{4,5} fork?
> } 
> } As a place to make it even harder for the extremist to whine and cry over
> } the usages of binary only modules.
> } 
> } Comments?
> 
> Maybe it's best to not add yet another fork.  I just managed to
> dis-entangle myself from maintaining some trees and wouldn't wish that on
> anyone else.  A single config option that adds -fno-inline wouldn't be
> fork-worthy.
> 
> As for extremists complaining... I think you'd just give them a target and
> a forum rather than quiet them.
> 

Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Jeff Garzik]

Alan Cox wrote:

> On Wed, 2002-11-20 at 19:55, Andre Hedrick wrote:
>
> >So " -fno-inline " should be enough to squelch the extremists?
>
>
> Its not relevant to the discussion even.


That's $topic AFAICS.  Some armchair lawyers are alleging that 
#include'ing GPL'd kernel code into non-GPL'd binary kernel module makes 
that module a derivative work and thus must be GPL'd itself.

Have we decided that #include'ing GPL'd code does, or does not, taint 
otherwise "license-clean" code that includes the GPL'd code?

The only thing I've seen from Linus is him mentioning that this is a 
"grey area".  Given this message:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103487469728730&w=2

we fall to copyright law, and wonder aloud if an obviously-non-derived 
work #includes GPL'd code, does it become derived?

	Jeff

Re: spinlocks, the GPL, and binary-only modules

[Alan Cox]

On Wed, 2002-11-20 at 20:41, Jeff Garzik wrote:
> Have we decided that #include'ing GPL'd code does, or does not, taint 
> otherwise "license-clean" code that includes the GPL'd code?

Ask a lawyer - and the answer mostly is "it depends"

> we fall to copyright law, and wonder aloud if an obviously-non-derived 
> work #includes GPL'd code, does it become derived?

Example 1

	I paste your name and address into my document does it become
	a derived work

Example 2

	I paste your poem into my document does it become a derived work


So #include isnt terribly relevant 8)

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

So it is business as usual, all sabre noise but none drawn.
Everyone is scared of the lawyers and all it would do is feed the sharks
and nobody makes any money but them.

So it is a draw ?


On 20 Nov 2002, Alan Cox wrote:

> On Wed, 2002-11-20 at 20:41, Jeff Garzik wrote:
> > Have we decided that #include'ing GPL'd code does, or does not, taint 
> > otherwise "license-clean" code that includes the GPL'd code?
> 
> Ask a lawyer - and the answer mostly is "it depends"
> 
> > we fall to copyright law, and wonder aloud if an obviously-non-derived 
> > work #includes GPL'd code, does it become derived?
> 
> Example 1
> 
> 	I paste your name and address into my document does it become
> 	a derived work
> 
> Example 2
> 
> 	I paste your poem into my document does it become a derived work
> 
> 
> So #include isnt terribly relevant 8)
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Rik van Riel]

On Wed, 20 Nov 2002, Andre Hedrick wrote:

> So it is business as usual, all sabre noise but none drawn.
> So it is a draw ?

Basically.

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

On Wed, 20 Nov 2002, Rik van Riel wrote:

> On Wed, 20 Nov 2002, Andre Hedrick wrote:
> 
> > So it is business as usual, all sabre noise but none drawn.
> > So it is a draw ?
> 
> Basically.

Well, I hope not to see in litigation and will try to do the correct
thing.  Who knows I may even decide to empower Linux with some new
technology to level the playing field of storage.  You heard it, I still
am willing to opensource a version to help set the standard for it to be
done the correct and proper way.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Alan Cox]

On Wed, 2002-11-20 at 22:03, Andre Hedrick wrote:
> 
> 
> So it is business as usual, all sabre noise but none drawn.
> Everyone is scared of the lawyers and all it would do is feed the sharks
> and nobody makes any money but them.
> 
> So it is a draw ?

A pointless war has two losers.

Alan

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

On 20 Nov 2002, Alan Cox wrote:

> On Wed, 2002-11-20 at 22:03, Andre Hedrick wrote:
> > 
> > 
> > So it is business as usual, all sabre noise but none drawn.
> > Everyone is scared of the lawyers and all it would do is feed the sharks
> > and nobody makes any money but them.
> > 
> > So it is a draw ?
> 
> A pointless war has two losers.

Well I like it!

Now I can make a little money and get back to finishing out the 2.5/2.4
ATA/SATA stuff which is the good free stuff people depend on now!

Cheers,


Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Larry McVoy]

On Wed, Nov 20, 2002 at 10:43:00PM +0000, Alan Cox wrote:
> A pointless war has two losers.
> 
> Alan

I like:

"When you're arguing with an idiot, two idiots are arguing"

Told to me by Victor Yodaiken (who suggested I tattoo it on the tops
of my hands and look down a lot while I'm flaming. Good idea, that.)
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: spinlocks, the GPL, and binary-only modules

[Eli Carter]

Larry McVoy wrote:
[snip]
> I like:
> 
> "When you're arguing with an idiot, two idiots are arguing"
> 
> Told to me by Victor Yodaiken (who suggested I tattoo it on the tops
> of my hands and look down a lot while I'm flaming. Good idea, that.)

If that isn't in 'fortune', it should be. :)  (Hmm... even better, it 
should be in /.'s fortune file... as its _only_ entry. ;) )

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------

Re: spinlocks, the GPL, and binary-only modules

[Alan Cox]

On Wed, 2002-11-20 at 19:55, Andre Hedrick wrote:
> 
> So " -fno-inline " should be enough to squelch the extremists?

Its not relevant to the discussion even. 

Re: spinlocks, the GPL, and binary-only modules

[Andrew Morton]

Cort Dougan wrote:
> 
>  A single config option that adds -fno-inline wouldn't be
> fork-worthy.

It takes a 400k patch to make the kernel build with -fno-inline.

The patch is generated by a script which weeds out all the
`extern inline's.  And then you need another little patch which
provides stub implementations of __this_fixmap_does_not_exist() and
__br_lock_usage_bug().

The extern-inline-weeder script is from Jim Houston.


#!/usr/bin/perl
#
# This script changes "extern inline" to "static inline" in header
# files.  I did this so that I could use -finstrument-functions to
# trace Linux kernel code.  The script is pretty stupid if it finds
# extern and inline togther its likely to make a change.  It removes
# the inline from forward references and changes extern to static
# for definitions.

open(FIND, "find . -name \*.[ch] |") || die "couldn't run find on *.[ch]\n";
while ($f = <FIND>) {
	chop $f;
	if (!open(FILE, $f)) {
		print STDERR "Can't open $f\n";
		next;
	}
#	print STDERR "scanning $f\n";
	undef $file_content;
	$file_content = "";
	$modified = 0;
OUT:
	while ($line = <FILE>) {
		# check for comment, ignore lines that start with 
		# a comment.  Ignore block comments
		if ($line =~ /^\s*\/\*.*\*\//) {
			$file_content .= $line;
			next;
		}
		if ($line =~ /^\s*\/\*/) {
			$file_content .= $line;
			while ($line = <FILE>) {
				$file_content .= $line;
				if ($line =~ /\*\//) { 
					next OUT;
				}
			}
			print STDERR "??? $f: end of file in comment?";
			
		}
		if ($line  =~ /extern\s+(.*)(inline|__inline|__inline__)\s/) {
			$extra = 0;
			if ($line =~ /^#define/) {
				# Alpha & ARM have defines
				# for extern inline which I'm
				#ignoring for now.
				$file_content .= $line;
				next;
			}
			while (!($line =~ /;|{/)) {
				if (!($nl = <FILE>)) {
					die "hit EOF... file=$f\n";
				}
				if (++$extra > 8) {
					print STDERR "??? $f: $line";
					last;
				}
				$line .= $nl;
			}
			if ($line =~ /{/) {
				$line =~ s/extern/static/;
				$modified = 1;
			} elsif ($line =~ /;/) {
				$line =~ s/[ 	]*__inline__[ 	]*/ /;
				$line =~ s/[ 	]*__inline[ 	]*/ /;
				$line =~ s/[ 	]*inline[ 	]*/ /;
				$modified = 1;
			}
		}
		$file_content .= $line;
	}
	close(FILE);
	$name = $f . ".orig";
	if ($modified && -e $name) {
		print STDERR "$name already exists - no changes made\n";
		next;
	}
	if ($modified) {
#		if (link($f, $name)) {
#			unlink($f);
#		} else {
#			print STDERR "Can't move $f to $name\n";
#			next;
#		}
		if (!open(FILE, ">$f")) {
			prinf STDERR "Can't open $f for output\n";
			next;
		}
		print FILE $file_content;
		close(FILE);
	}
}

Re: spinlocks, the GPL, and binary-only modules

[Larry McVoy]

make it ignore BK and/or SCCS files.

> open(FIND, "find . -name \*.[ch] |") || die "couldn't run find on *.[ch]\n";
> while ($f = <FIND>) {
> 	chop $f;
	next if m|SCCS/s\.|;
	next if m|BitKeeper/|;


-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

On 20 Nov 2002, Xavier Bestel wrote:

> Le mer 20/11/2002 à 09:12, Mark Mielke a écrit :
> > On Wed, Nov 20, 2002 at 01:06:39AM -0200, Rik van Riel wrote:
> > > On Wed, 20 Nov 2002, David McIlwraith wrote:
> > > > How should it? The compiler (specifically, the C preprocessor) includes
> > > > the code, thus it is not the AUTHOR violating the GPL.
> > > If the compiler includes a .h file, it happens because
> > > the programmer told it to do so, using a #include.
> > 
> > I was recently re-reading the GPL and I came to the following conclusion:
> > 
> > The GPL is only an issue if the software is *distributed* with GPL
> > software. Meaning -- it is not legal to distribute a linux kernel that
> 
> Yeah, that's precisely the problem here: the binary-only module is
> distributed with included spinlock code, which *is* GPL.

So if it bugs you so much, why doing you start the process to sue all the
places everyone know the violation exist?  First go for the major ones lin
the embedded space.  So where is you lawyer and you fat pile of cash to
run you war against the use of Linux in Business?

Now lets wreck the one decent video driver that happens to be closed
source.

Can we as REDMOND ?

Later!

Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Arjan van de Ven]

On Wed, 2002-11-20 at 03:49, David McIlwraith wrote:
> How should it? The compiler (specifically, the C preprocessor) includes the
> code, thus it is not the AUTHOR violating the GPL.

It is if the AUTHOR then decides to distribute the resulting binary
which would contain a mix of GPL and non GPL work..

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

On 21 Nov 2002, Arjan van de Ven wrote:

> On Wed, 2002-11-20 at 03:49, David McIlwraith wrote:
> > How should it? The compiler (specifically, the C preprocessor) includes the
> > code, thus it is not the AUTHOR violating the GPL.
> 
> It is if the AUTHOR then decides to distribute the resulting binary
> which would contain a mix of GPL and non GPL work..

The mix is a direct result of developers knowingly inlining critical C
code into the headers.  If this code was placed in proper .c files and not
set in a .h then the potential for accidental mixing is removed.

This would limit and restrict the headers to being structs and extern
functions to call.

This would be the first step to narrow the grey and broaden the black and
white.

I expect to be showered with boos and go away stupid, followed by "We are
not here to make it easy for binary modules!  Go use BSD you moron!!!".

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Mark Mielke]

On Thu, Nov 21, 2002 at 05:08:45AM -0800, Andre Hedrick wrote:
> On 21 Nov 2002, Arjan van de Ven wrote:
> > It is if the AUTHOR then decides to distribute the resulting binary
> > which would contain a mix of GPL and non GPL work..
> The mix is a direct result of developers knowingly inlining critical C
> code into the headers.  If this code was placed in proper .c files and not
> set in a .h then the potential for accidental mixing is removed.
> This would limit and restrict the headers to being structs and extern
> functions to call.

Some (not all) of the inlined functions are 'inline' to accelerate the
kernel.

Perhaps, though, the inlined functions should be declared:

   #ifdef __GNUC__
   #  define INLINE extern inline
   #else
   #  define INLINE inline
   #endif

   #ifdef GPL
   INLINE type function (arguments)
   {
      ...
   }
   #else
   INLINE type function (arguments);
   #endif

This would be neat in that no real additional code would be brought into
the module, however, there is a possibility that the module would run a little
bit slower - a small incentive to GPL the module...

Of course, this would mean that any #define's still sitting around that
contributed code of significance should be replaced with possibly inlined
functions...

Would this make everybody happy?

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

On Thu, 21 Nov 2002, Mark Mielke wrote:

> Some (not all) of the inlined functions are 'inline' to accelerate the
> kernel.

Point is noted and the performance issue stands on its own as a strike
against removing the inline, this is a given.  Now what is the performance
difference if the inline is moved to a .c and makd and extern inline in
the .h ?

The object of the question is determine if there is a peformance break
point to consider the moving of a inlined C code to a proper .c file.

Obviously adding a new kernel fork to move around the inline game will be
painful but if it narrows the gap between black and white to remove
the chance of accidentail GPL code inclusion.  It may be worth it to
consider.

Comments and Flames welcome.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: spinlocks, the GPL, and binary-only modules

[Jeff Garzik]

Mark Mielke wrote:

> On Thu, Nov 21, 2002 at 05:08:45AM -0800, Andre Hedrick wrote:
>
> >On 21 Nov 2002, Arjan van de Ven wrote:
> >
> >>It is if the AUTHOR then decides to distribute the resulting binary
> >>which would contain a mix of GPL and non GPL work..
> >
> >The mix is a direct result of developers knowingly inlining critical C
> >code into the headers.  If this code was placed in proper .c files 
> and not
> >set in a .h then the potential for accidental mixing is removed.
> >This would limit and restrict the headers to being structs and extern
> >functions to call.
>
>
> Some (not all) of the inlined functions are 'inline' to accelerate the
> kernel.
>
> Perhaps, though, the inlined functions should be declared:
>
>    #ifdef __GNUC__
>    #  define INLINE extern inline
>    #else
>    #  define INLINE inline
>    #endif


[...]

Please review prior posts in this thread, notably from Andrew Morton and 
Cort Dougan.  They describe a much better method of doing this.

It still doesn't handle macros, though they are much less of a worry 
since Linux kernel emphasizes inlines over macros.

	Jeff

Re: spinlocks, the GPL, and binary-only modules

[Mark Mielke]

On Thu, Nov 21, 2002 at 12:21:21PM -0500, Jeff Garzik wrote:
> Mark Mielke wrote:
> >   #ifdef __GNUC__
> >   #  define INLINE extern inline
> >   #else
> >   #  define INLINE inline
> >   #endif
> [...]
> Please review prior posts in this thread, notably from Andrew Morton and 
> Cort Dougan.  They describe a much better method of doing this.
> It still doesn't handle macros, though they are much less of a worry 
> since Linux kernel emphasizes inlines over macros.

I just scanned it over and it isn't exactly the same as what I suggested.

Re-stating for clarity: Header files should use 'extern inline'
('inline' for C99) to declare inline functions in "GPL-mode" and
'extern' (or no qualifer) should be used to declare only the prototype
in "non-GPL-mode". The benefit of this is that GPL code continues to
work as is with no speed degradation, but non-GPL source code will not
require GPL code in the object code.

Converting 'extern inline' to 'static inline' doesn't accomplish very much,
except to force referenced code to be inlined into each object code. This
is the opposite effect of 'ensure that no GPL code is compiled into a
non-GPL object file'.

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: spinlocks, the GPL, and binary-only modules

[Andre Hedrick]

Greeting Jeff and Eben,

Eben, if I understand you are presently or in the past the general council
for FSF arguments and legal briefs, would you be kind enough to set a
legal position of the nature of headers in any environment.  I would have
#include RMS but his position is known, and may have violated a license.

Now the joke is over, but it has significant implications now.

Soon the question will be raised and either you or somebody else will be
called to answer and justify the point.  So please send me a quote for the
estimated cost of a legal brief on the specifics related to the content
below.  If I can afford it, I will pay for it to begin the process of
setting the legal guides of usage of binary only drivers which only use
the headers of a given kernel.

Given the context of embedded software based on GPL, VAR appliance
builders, large|mid|small cap companies, individuals, etc... who are using
and improving the quality of entire package because it benefits them to do
so and it is the right thing to do.

So the issue come down to the following:

Will the few idealist in the world who dream the impossible, make it
impossible to for the realist whom are trying to follow but have to make
money to justify the goal.  There appears to be a push to kill the dream
by forcing the folks who believe in the goals but now will have to justify
their position and risk.  If the risk of litigation becomes to high, even
for those who follow the rules and promote compliance to rules set forth
in the past, people will adopt another environment.

Now we are in quite a dangerous position presently, as the strength and
maturity of the Linux Community of Contributors rises to the what everyone
knew it could be, to have find out it is a house of cards build on sand 
and not pilars of stone set on bedrock.

I have already carpet bombed the mailing list in sheer anger.

Now it is time to put the rubber on the road, and it costs money.
So again I do not have an endless pile of money to do it alone, but I have
to risk it all now including a potential for personal bankruptecy, if I
stand a chance to help keep the dream alive.  Please provide me a quote
for the brief and the estimated time to complete.


Sincerely,

Andre Hedrick
LAD Storage Consulting Group

I apologize if it is not clear, as I am trying to not mix words.

On Tue, 19 Nov 2002, Jeff Garzik wrote:

> blah.
> 
> So, since spinlocks and semaphores are (a) inline and #included into 
> your code, and (b) required for just about sane interoperation with Linux...
> 
> does this mean that all binary-only modules that #include kernel code 
> such as spinlocks are violating the GPL?  IOW just about every binary 
> module out there, I would think...
> 
> I'm sure this would make extremeists happy, but I personally don't mind 
> binary-only modules as long as the binary-only code [ignoring the 
> #included kernel code] cannot be considered a derived work.
> 
> But who knows if #include'd code constitutes a derived work :(
> 
> 	Jeff
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: spinlocks, the GPL, and binary-only modules

[Jeremy Fitzhardinge]

On Tue, 2002-11-19 at 14:09, Jeff Garzik wrote:
> blah.
> 
> So, since spinlocks and semaphores are (a) inline and #included into 
> your code, and (b) required for just about sane interoperation with Linux...
> 
> does this mean that all binary-only modules that #include kernel code 
> such as spinlocks are violating the GPL?  IOW just about every binary 
> module out there, I would think...

There are a whole pile of rules and precedents over this.  For one, a
certain code size limit applies, as does the notion of whether there's
any creative input (for example, constants and structure definitions are
not considered creative, because they are simply required for an
interface to work).

One argument is that since the interfaces require you to manipulate the
locks in a particular way, and only a given set of instructions will do
those manipulations correctly, then any correct implementation will
contain those instructions.  Whether they get them from including a
particular header, or by having their own versions of those
instructions, it all looks the same in the binary.  It would be hard
work to claim the presence of those instructions constitutes a derived
work, any more than you could claim the instructions which set the stack
or registers up for a function call constitute a derived work.

	J