2002-11-19 22:02:49

by Jeff Garzik

[permalink] [raw]
Subject: spinlocks, the GPL, and binary-only modules

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




2002-11-20 01:45:18

by Rik van Riel

[permalink] [raw]
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:"[email protected]">[email protected]</a>

2002-11-20 02:41:14

by Josh Myer

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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




2002-11-20 02:43:02

by David McIlwraith

[permalink] [raw]
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" <[email protected]>
To: "Jeff Garzik" <[email protected]>
Cc: "Linux Kernel Mailing List" <[email protected]>
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:"[email protected]">[email protected]</a>
>
> -
> 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/

2002-11-20 02:56:37

by David McIlwraith

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

Ugh. Seems I misunderstood; I didn't note the reference to binary modules.
----- Original Message -----
From: "David McIlwraith" <[email protected]>
To: <[email protected]>
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" <[email protected]>
> To: "Jeff Garzik" <[email protected]>
> Cc: "Linux Kernel Mailing List" <[email protected]>
> 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:"[email protected]">[email protected]</a>
> >
> > -
> > 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/
>

2002-11-20 02:52:41

by Rik van Riel

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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:"[email protected]">[email protected]</a>

2002-11-20 02:59:45

by Rik van Riel

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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:"[email protected]">[email protected]</a>

2002-11-20 04:06:12

by Andre Hedrick

[permalink] [raw]
Subject: Some like it HOT! (Re: spinlocks, the GPL, and binary-only modules)

On Tue, 19 Nov 2002, Rik van Riel wrote:

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

Lets see, who to sue first?

The embedded people? The video card people? The people who ship binary
drivers? All the people who sell appliances? Oh please sue me, because I
license binary only drivers for various appliances. This is a the
beginning of era of IP vultures and will quickly kill the use of Linux.

Free software does not make a dime with out value add.

So now that all the distros have their patch bomb hell that is not adopted
in the main stream, and some you can not download period. Sure they "open
source" the patches. Sure some have been caught putting in patches to
allow known binary extentions. Then there was MOSIX in the past.

What the hell happened to Linux being a flexable tool, it is just a
kernel!

Well I am the two face bard(1) running around with a band of people force
others to open spec for the creation of open source. Gee, some people
have contributed a lot and others less and remainder zero. I guess it is
time to start the corporate litigation party raiders and become no better
than whom we all look down upon. Oh HAIL Redmond we are soon to follow
your path to success and failure.

Somebody please tell me where I can invoice all the users of IDE/ATA/SATA
in the world of Linux. Since I have about $30K in bills I paid myself to
attend meeting, stop CPRM/DMCA from openly screwing the hardware, sign
licensing agreements currently with more $25K outstanding to be
potentially collected, single handedly bring most of the chipset hardware
vendors to the table of OPEN SOURCE yet I suffer the legal binds of the
NDA's to bring you free drivers.

So the minute somebody wants to make a little money for the return to keep
them in a position to continue to offer you open source, the IP VULTURES
are out in full force to steal and taint quality closed IP for using just
the stinking headers? Well I will be looking at using another OS which is
more business friendly now, because even though I would follow the rules
of forcable making my commerial product incapable of being compiled into
the kernel, there will be some "PISS ANT LOSER" ready to SUE me for just
using the headers. NICE !

Oh please bring it one, I have found my blow torch, flame thrower, and to
hell with the asbestos suit!! It is winter time and lets make it HOT!

Yippe KIA-AHHY Mother F***** !


Andre Hedrick
LAD Storage Consulting Group

(1) bard, a story teller

2002-11-20 04:19:25

by Ross Vandegrift

[permalink] [raw]
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
[email protected]

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.

2002-11-20 04:47:41

by David McIlwraith

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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 <[email protected]>
To: Rik van Riel <[email protected]>
Cc: <[email protected]>
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
[email protected]

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.

2002-11-20 04:55:06

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules


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 <[email protected]>
> To: Rik van Riel <[email protected]>
> Cc: <[email protected]>
> 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
> [email protected]
>
> 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 [email protected]
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2002-11-20 05:17:29

by Jon Portnoy

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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 <[email protected]>
> To: Rik van Riel <[email protected]>
> Cc: <[email protected]>
> 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]

2002-11-20 05:40:51

by Zac Hansen

[permalink] [raw]
Subject: GPL rant -- was: spinlocks, the GPL, and binary-only modules


I think he means when you contribute to a GNU piece of code? They ask you
to sign over your copyright so they can enforce it more easily in court.

Or so they say. They could also use this power for evil. Also, what's up
with that "GPL version 2 or later" stuff? I always take that out of my
licenses. While I understand that if I die, its then sort of trapped
under GPL2, I really don't want whoever decides to make the next GPL
changing the licensing on my program significantly...

--Zac

On Wed, 20 Nov 2002, Jon Portnoy wrote:

> 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 <[email protected]>
> > To: Rik van Riel <[email protected]>
> > Cc: <[email protected]>
> > 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]
>
> -
> 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/
>

2002-11-20 06:14:27

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules


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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>


2002-11-20 06:24:07

by Samium Gromoff

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

> 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
_____________________________________


2002-11-20 07:33:11

by Jeremy Fitzhardinge

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 07:57:54

by Mark Mielke

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/

2002-11-20 08:13:31

by Mark Mielke

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/

2002-11-20 10:10:55

by Xavier Bestel

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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.

2002-11-20 13:43:56

by Alan

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 13:45:43

by Alan

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 14:00:47

by Richard B. Johnson

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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


2002-11-20 18:19:42

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 18:50:42

by Thomas Langås

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 18:48:04

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 18:51:23

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 19:02:59

by Daniel Jacobowitz

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 18:58:13

by Alan

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 19:03:16

by Nicholas Berry

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules



>>> Andre Hedrick <[email protected]> 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


2002-11-20 19:05:24

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 19:13:34

by Nick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2002-11-20 19:09:03

by Dana Lacoste

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 19:25:27

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 19:30:08

by Cort Dougan

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 19:40:51

by Cort Dougan

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 19:34:24

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 19:43:46

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules


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


On Wed, 20 Nov 2002 [email protected] 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 [email protected]
> > 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 [email protected]
> 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

2002-11-20 19:48:45

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules


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

2002-11-20 19:54:51

by Andrew Morton

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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);
}
}

2002-11-20 19:58:22

by Larry McVoy

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 19:58:06

by Nick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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 [email protected] 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 [email protected]
> > > 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 [email protected]
> > 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
>
>

2002-11-20 20:14:24

by Alan

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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.

2002-11-20 20:34:49

by Jeff Garzik

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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



2002-11-20 20:40:42

by Alan

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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)

2002-11-20 22:04:38

by Rik van Riel

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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:"[email protected]">[email protected]</a>

2002-11-20 22:09:33

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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


2002-11-20 22:03:23

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules



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 [email protected]
> 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

2002-11-20 22:08:12

by Alan

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 22:11:51

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 22:29:21

by Larry McVoy

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-20 23:09:18

by Eli Carter

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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 `-------------------------------------------------

2002-11-20 23:56:38

by Russ Allbery

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

Mark Mielke <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/>

2002-11-21 02:18:02

by Rik van Riel

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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:"[email protected]">[email protected]</a>

2002-11-21 05:03:57

by Andre Hedrick

[permalink] [raw]
Subject: TAINTED (Re: spinlocks, the GPL, and binary-only modules)


Greetings LKML,

There is an interesting paradox to now consider.

Now the folks who invisioned the process to "taint" a kernel have by
default given the rule of exemption to the use of binary only. The very
process used to detect and determine "taint", has itself approved the use
of binary only! If this was not the case, then the detection process
would have rejected the loading. Since this in not the end result, the
claim is and will be made the headers and all api's are exempt, period.

The headers and api's are required to even obtain functionality.

The test for Tainted status below:

"Module Size Used by Tainted: P"

It allows/allowed a binary module to load.


If Linux is to truly only a GPL binary module friendly environment, then
it must enforce the rules. Therefore it must forcablely reject the
attempt to load any and all binaries which are not GPL. Regardless if the
license is commerial yet the source code is available.

Think long and hard before this step is taken, as it will crush the
viablity of Linux in many key places today and will delay future
deployment.

This shall force all distos to change policy and prevent the loading of
anything which is not GPL and they have the source code to ship.
Additionall

To this point, the issue is closed on the binary modules.

/*
* The following license idents are currently accepted as indicating free
* software modules
*
* "GPL" [GNU Public License v2 or later]
* "GPL and additional rights" [GNU Public License v2 rights and more]
* "Dual BSD/GPL" [GNU Public License v2 or BSD license choice]
* "Dual MPL/GPL" [GNU Public License v2 or Mozilla license choice]
*
* The following other idents are available
*
* "Proprietary" [Non free products]
*
* There are dual licensed components, but when running with Linux it is the
* GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
* is a GPL combined work.
*
*
* This exists for several reasons
* 1. So modinfo can show license info for users wanting to vet their setup
* is free
* 2. So the community can ignore bug reports including proprietary modules
* 3. So vendors can do likewise based on their own policies
*/

Again, this very file ./linux/include/linux/module.h grants permission for:
"Proprietary" [Non free products]

Now disbute the kernel!

Cheers,

Andre Hedrick
LAD Storage Consulting Group

PS The issue which is not closed is the legal status of what is a derived
work and what is an original work. This shall be settled in court when
it is challanged.


2002-11-21 08:58:27

by Giacomo A. Catenazzi

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules



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

2002-11-21 09:05:56

by Giacomo A. Catenazzi

[permalink] [raw]
Subject: Re: TAINTED (Re: spinlocks, the GPL, and binary-only modules)

> If Linux is to truly only a GPL binary module friendly environment, then
> it must enforce the rules. Therefore it must forcablely reject the
> attempt to load any and all binaries which are not GPL. Regardless if the
> license is commerial yet the source code is available.
>

Read GPL!
I can modify/create *private* and completly *non-free* code, and link to GPL,
legally. [I cannot distribute it, but kernel should not block me!]
nvidia unfortunatly use this, to not to disclose the complete sources]
And I can use an other OSI approved license, GPL compatible,
but if it is not yet recognized by kernel? Should kernel include all free
licences strings?

ciao
giacomo

2002-11-21 12:51:56

by Arjan van de Ven

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-21 13:02:13

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

2002-11-21 16:48:38

by Mark Mielke

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/

2002-11-21 17:14:33

by Jeff Garzik

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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




2002-11-21 17:40:59

by Herman Oosthuysen

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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: [email protected]
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
>


2002-11-21 23:55:55

by Andre Hedrick

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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


2002-11-22 06:06:18

by Mark Mielke

[permalink] [raw]
Subject: Re: spinlocks, the GPL, and binary-only modules

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

--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/