Controversy over dynamic linking -- how to end the panic

Controversy over dynamic linking -- how to end the panic

[Eric S. Raymond]

As you know, there's been another flap recently about the GPL status
of loadable kernel modules.  You have a note that touches on this in
the kernel COPYING file, but it is not sufficient to resolve the
questions that keep coming up.

Earlier today I was contacted by a principal at a well-known Linux
company who was in a mild panic over recent arguments by Alan Cox and
David Miller.  This company (not VA or Red Hat, BTW) fears that their
customers will run from Linux if they get the idea that linking
drivers to the kernel might force them open.

I wrote back as follows:

>Alan's posting beginning "Linus opinion on this is irrelevant" is not a
>`perspective' that he can be argued out of.  He is not arguing about whether
>allowing proprietary binary modules is good, bad, or indifferent.
>
>Alan is merely stating legal facts as he understands them -- and, in
>fact, I agree with his assessment.  The key question is whether the
>particular kind of linking involved with loading binary modules
>propagates derivative-work status under copyright law.  This is a legal
>question a court may rule on someday.  Until one does, anyone who
>relies on such linking is taking a legal risk.
>
>Alan is not quite right that Linus's opinion is irrelevant.  It is irrelevant
>to the underlying legal question, but not to the associated business risk.
>
>As copyright holder of the Linux kernel, Linus is the only person with
>standing to sue for license violation.  Therefore, when he says
>"binary modules are OK", he is stating a policy intention which your
>customers may include in their evaluation of legal risk.  This means
>that in order for them to lose, a court must rule that module linking
>propagates derivative-work status *and* Linus must reverse himself and
>sue.

So I'm proposing a solution.  We can't resolve the underlying legal
question yet, but you can make your policy clearer.

In the existing kernel COPYING file:

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

I suggest replacing this with something resembling the following:

------------------------------------------------------------------------
The GPL license reproduced below is copyrighted by the Free Software 
Foundation, but the Linux kernel is copyrighted by me and others who 
actually wrote it.

The GPL license requires that derivative works of the Linux kernel
also fall under GPL terms, including the requirement to disclose
source.  The meaning of "derivative work" has been well established
for traditional media, and those precedents can be applied to
inclusion of source code in a straightforward way.  But as of
mid-2001, neither case nor statute law has yet settled under what
circumstances *binary* linkage of code to a kernel makes that code a
derivative work of the kernel.

To calm down the lawyers, I as the principal kernel maintainer and
anthology copyright holder on the code am therefore adding the
following interpretations to the kernel license:

1. Userland programs which request kernel services via normal system
   calls *are not* to be considered derivative works of the kernel.

2. A driver or other kernel component which is statically linked to
   the kernel *is* to be considered a derivative work.

3. A kernel module loaded at runtime, after kernel build, *is not*
   to be considered a derivative work.

These terms are to be considered part of the kernel license, applying
to all code included in the kernel distribution.  They define your
rights to use the code in *this* distribution, however any future court
may rule on the underlying legal question and regardless of how the
license or interpretations attached to future distributions may change.
------------------------------------------------------------------------

I believe this would express the present policy clearly enough to soothe
jittery nerves at a lot of companies that are worried about this issue.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Government: If you refuse to pay unjust taxes, your property will be
confiscated. If you attempt to defend your property, you will be arrested.  If
you resist arrest, you will be clubbed. If you defend yourself against
clubbing, you will be shot dead. These procedures are known as the Rule of
Law.

	-- Edward Abbey

Re: Controversy over dynamic linking -- how to end the panic

[Alan Cox]

> >As copyright holder of the Linux kernel, Linus is the only person with
> >standing to sue for license violation.  Therefore, when he says

He's copyright holder of parts of it. The FSF is also a copyright holder of
oddments, as are many people.

> >"binary modules are OK", he is stating a policy intention which your
> >customers may include in their evaluation of legal risk.  This means
> >that in order for them to lose, a court must rule that module linking
> >propagates derivative-work status *and* Linus must reverse himself and
> >sue.

Right. I'm not planning to go and harass people (well not unless they start
it) but it is important that people are aware of the potential issue and they
make sure they understand it. Its no different to being sure you understand
exactly which grandparents and/or limbs you signed away when you joined MSDN 8)

Alan

Re: Controversy over dynamic linking -- how to end the panic

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > >As copyright holder of the Linux kernel, Linus is the only person with
> > >standing to sue for license violation.  Therefore, when he says
> 
> He's copyright holder of parts of it. The FSF is also a copyright holder of
> oddments, as are many people.

IANAL, but I believe that Linus's position as anthology copyright holder
makes him privileged in this respect.

My wife, who *is* an attorney, will be researching this.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

If gun laws in fact worked, the sponsors of this type of legislation
should have no difficulty drawing upon long lists of examples of
criminal acts reduced by such legislation. That they cannot do so
after a century and a half of trying -- that they must sweep under the
rug the southern attempts at gun control in the 1870-1910 period, the
northeastern attempts in the 1920-1939 period, the attempts at both
Federal and State levels in 1965-1976 -- establishes the repeated,
complete and inevitable failure of gun laws to control serious crime.
        -- Senator Orrin Hatch, in a 1982 Senate Report

Re: Controversy over dynamic linking -- how to end the panic

[Andrew Pimlott]

On Thu, Jun 21, 2001 at 03:17:16PM -0400, Eric S. Raymond wrote:
> IANAL, but I believe that Linus's position as anthology copyright holder
> makes him privileged in this respect.

Regardless of what you find in the books, recall that Linus has
stated that decentralizing the copyright of Linux was a goal, so you
may not find him willing to claim an "anthology copyright" (if such
a thing even applies to the kernel, which in my NAL opinion, it does
not).

>From http://www.softpanorama.org/People/Torvalds/linus1998.shtml:

     Torvalds:  And when somebody sends me big patches, I don't ask
     them to assign the copyright over to me. So right now for
     example, the kernel itself has probably on the order of 50 or
     100 copyright holders and the actual copyright license has
     always been the same. It's the GPL that requires that sources
     always be available. So in order to make a version of Linux
     that is not under that license, you have to get all those
     copyright holders to agree to the new license. The parts of the
     kernel that I own completely are significant, but they aren't
     enough to really make a good system. I did that consciously. I
     wanted to bind my own hands so that even if people don't trust
     me personally, they trust the fact that even if I wanted to
     turn commercial, I couldn't.

Andrew
(Feeling stupid for quoting Linus and Cc:ing Linus.)

Re: Controversy over dynamic linking -- how to end the panic

[Eric S. Raymond]

Andrew Pimlott <andrew@pimlott.ne.mediaone.net>:
> On Thu, Jun 21, 2001 at 03:17:16PM -0400, Eric S. Raymond wrote:
> > IANAL, but I believe that Linus's position as anthology copyright holder
> > makes him privileged in this respect.
> 
> Regardless of what you find in the books, recall that Linus has
> stated that decentralizing the copyright of Linux was a goal, so you
> may not find him willing to claim an "anthology copyright" (if such
> a thing even applies to the kernel, which in my NAL opinion, it does
> not).

Linus *is*, however, implicitly claiming the authority to make license
policy on behalf of the other copyright holders in cases where the GPL
is unclear.

In COPYING, Linus says that that the version of GPL applying to the
kernel is v2 unless explicitly otherwise stated.  He has also already
issued the interpretation that normal system calls from userland do
not create a derivation relationship.

I consider Linus to have the moral right to make these decisions, whether
or not the law gives him a formal legal right to do so.  All I have done
is propose that he be more explicit about his policy in order to prevent
needless confusion and nervousness.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The possession of arms by the people is the ultimate warrant
that government governs only with the consent of the governed.
        -- Jeff Snyder

Re: Controversy over dynamic linking -- how to end the panic

[Andrew Pimlott]

On Thu, Jun 21, 2001 at 04:13:22PM -0400, Eric S. Raymond wrote:
> Andrew Pimlott <andrew@pimlott.ne.mediaone.net>:
> > On Thu, Jun 21, 2001 at 03:17:16PM -0400, Eric S. Raymond wrote:
> > > IANAL, but I believe that Linus's position as anthology copyright holder
> > > makes him privileged in this respect.
> > 
> > Regardless of what you find in the books, recall that Linus has
> > stated that decentralizing the copyright of Linux was a goal, so you
> > may not find him willing to claim an "anthology copyright" (if such
> > a thing even applies to the kernel, which in my NAL opinion, it does
> > not).
> 
> Linus *is*, however, implicitly claiming the authority to make license
> policy on behalf of the other copyright holders in cases where the GPL
> is unclear.
> 
> In COPYING, Linus says that that the version of GPL applying to the
> kernel is v2 unless explicitly otherwise stated.  He has also already
> issued the interpretation that normal system calls from userland do
> not create a derivation relationship.
> 
> I consider Linus to have the moral right to make these decisions, whether
> or not the law gives him a formal legal right to do so.  All I have done
> is propose that he be more explicit about his policy in order to prevent
> needless confusion and nervousness.

I agree entirely that Linus, as creator of the license, is
privileged with respect to interpretation of the license.  I
disagree however with your suggestion that he is privileged with
respect to the copyright (eg the ability to sue or relicense),
especially since his own words (cited earlier) read like a
disclaimer of such privilege.

I basically support your position.

Andrew

Re: Controversy over dynamic linking -- how to end the panic

[Timur Tabi]

** Reply to message from Andrew Pimlott <andrew@pimlott.ne.mediaone.net> on
Thu, 21 Jun 2001 16:46:25 -0400


> I agree entirely that Linus, as creator of the license, is
> privileged with respect to interpretation of the license.

Ah, but Linus didn't create the license, he's using someone else's.  The GPL is
a creation of the FSF, not Linus.  The actual meanings of a license can only be
determined by the judicial system of whatever country you live in.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: Controversy over dynamic linking -- how to end the panic

[Andrew Pimlott]

On Thu, Jun 21, 2001 at 04:02:49PM -0500, Timur Tabi wrote:
> ** Reply to message from Andrew Pimlott <andrew@pimlott.ne.mediaone.net> on
> Thu, 21 Jun 2001 16:46:25 -0400
> 
> > I agree entirely that Linus, as creator of the license, is
> > privileged with respect to interpretation of the license.
> 
> Ah, but Linus didn't create the license, he's using someone
> else's.  The GPL is a creation of the FSF, not Linus.  The actual
> meanings of a license can only be determined by the judicial
> system of whatever country you live in.

Sorry, I meant to say "chooser of the license".  Given that Linux
was never an FSF project, and that Linus editorializes at the top of
COPYING, I think it is reasonable to infer that we are talking about
his interpretation of the GPL.

Andrew

Re: Controversy over dynamic linking -- how to end the panic

[Timur Tabi]

** Reply to message from Andrew Pimlott <andrew@pimlott.ne.mediaone.net> on
Thu, 21 Jun 2001 17:05:34 -0400


> Sorry, I meant to say "chooser of the license".  Given that Linux
> was never an FSF project, and that Linus editorializes at the top of
> COPYING, I think it is reasonable to infer that we are talking about
> his interpretation of the GPL.

And my point is that by making such a public, far-reaching interpretation of
the GPL, a lawyer in court could argue that his interpretation should be THE
interpretation.  I believe that judges have made interpretations of a law based
solely on how the law is practiced, to avoid situations where everyone affected
by that law has to change what he's doing.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: Controversy over dynamic linking -- how to end the panic

[David S. Miller]

Eric S. Raymond writes:
 > All I have done is propose that he be more explicit about his
 > policy in order to prevent needless confusion and nervousness.

Amen.

Later,
David S. Miller
davem@redhat.com

Re: Controversy over dynamic linking -- how to end the panic

[Timur Tabi]

** Reply to message from "Eric S. Raymond" <esr@thyrsus.com> on Thu, 21 Jun
2001 16:13:22 -0400


> Linus *is*, however, implicitly claiming the authority to make license
> policy on behalf of the other copyright holders in cases where the GPL
> is unclear.

And that could be dangerous to "GPL purists", because in a legal situation,
someone could point at Linus and say, "See, I don't have to GPL my code."

> In COPYING, Linus says that that the version of GPL applying to the
> kernel is v2 unless explicitly otherwise stated.  He has also already
> issued the interpretation that normal system calls from userland do
> not create a derivation relationship.

I just hope that's enough.

> I consider Linus to have the moral right to make these decisions, whether
> or not the law gives him a formal legal right to do so.  All I have done
> is propose that he be more explicit about his policy in order to prevent
> needless confusion and nervousness.

I agree completely.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: Controversy over dynamic linking -- how to end the panic

[Jeff Golds]

"Eric S. Raymond" wrote:
> ------------------------------------------------------------------------
> The GPL license reproduced below is copyrighted by the Free Software
> Foundation, but the Linux kernel is copyrighted by me and others who
> actually wrote it.
> 
> The GPL license requires that derivative works of the Linux kernel
> also fall under GPL terms, including the requirement to disclose
> source.  The meaning of "derivative work" has been well established
> for traditional media, and those precedents can be applied to
> inclusion of source code in a straightforward way.  But as of
> mid-2001, neither case nor statute law has yet settled under what
> circumstances *binary* linkage of code to a kernel makes that code a
> derivative work of the kernel.
> 
> To calm down the lawyers, I as the principal kernel maintainer and
> anthology copyright holder on the code am therefore adding the
> following interpretations to the kernel license:
> 
> 1. Userland programs which request kernel services via normal system
>    calls *are not* to be considered derivative works of the kernel.
> 
> 2. A driver or other kernel component which is statically linked to
>    the kernel *is* to be considered a derivative work.
> 
> 3. A kernel module loaded at runtime, after kernel build, *is not*
>    to be considered a derivative work.
> 
> These terms are to be considered part of the kernel license, applying
> to all code included in the kernel distribution.  They define your
> rights to use the code in *this* distribution, however any future court
> may rule on the underlying legal question and regardless of how the
> license or interpretations attached to future distributions may change.

I disagree with 2.  Consider the following:

- GPL library foo is used by application bar.  bar must be GPL because
foo is.  I agree with this.
- Non-GPL library foo is used by GPL application bar.  foo does NOT
become GPL just because bar is, even if bar statically linked foo in.

The kernel is the equivalent of an application.  If someone needs to
statically link in a driver, which is the equivalent of a library, I
don't see how that should make the driver GPL.


-Jeff

P.S.  I don't claim to be a lawyer, this is just my opinion.

-- 
Jeff Golds
Sr. Software Engineer
jgolds@resilience.com

Re: Controversy over dynamic linking -- how to end the panic

[Jeff Mahoney]

On Thu, Jun 21, 2001 at 11:39:13AM -0700, Jeff Golds wrote:
> "Eric S. Raymond" wrote:
> > ------------------------------------------------------------------------
> > The GPL license reproduced below is copyrighted by the Free Software
> > Foundation, but the Linux kernel is copyrighted by me and others who
> > actually wrote it.
> > 
> > The GPL license requires that derivative works of the Linux kernel
> > also fall under GPL terms, including the requirement to disclose
> > source.  The meaning of "derivative work" has been well established
> > for traditional media, and those precedents can be applied to
> > inclusion of source code in a straightforward way.  But as of
> > mid-2001, neither case nor statute law has yet settled under what
> > circumstances *binary* linkage of code to a kernel makes that code a
> > derivative work of the kernel.
> > 
> > To calm down the lawyers, I as the principal kernel maintainer and
> > anthology copyright holder on the code am therefore adding the
> > following interpretations to the kernel license:
> > 
> > 1. Userland programs which request kernel services via normal system
> >    calls *are not* to be considered derivative works of the kernel.
> > 
> > 2. A driver or other kernel component which is statically linked to
> >    the kernel *is* to be considered a derivative work.
> > 
> > 3. A kernel module loaded at runtime, after kernel build, *is not*
> >    to be considered a derivative work.
> > 
> > These terms are to be considered part of the kernel license, applying
> > to all code included in the kernel distribution.  They define your
> > rights to use the code in *this* distribution, however any future court
> > may rule on the underlying legal question and regardless of how the
> > license or interpretations attached to future distributions may change.
> 
> I disagree with 2.  Consider the following:
> 
> - GPL library foo is used by application bar.  bar must be GPL because
> foo is.  I agree with this.
> - Non-GPL library foo is used by GPL application bar.  foo does NOT
> become GPL just because bar is, even if bar statically linked foo in.
> 
> The kernel is the equivalent of an application.  If someone needs to
> statically link in a driver, which is the equivalent of a library, I
> don't see how that should make the driver GPL.
> 
> 
> -Jeff
> 
> P.S.  I don't claim to be a lawyer, this is just my opinion.

    http://www.gnu.org/copyleft/gpl-faq.html#WritingFSWithNFLibs offers some
    insight on linking free software with non-free libraries.

    However, I'm not sure I agree with your interpretation of the relationship
    between kernel and driver.

    The kernel is fully functional (excluding use of the hardware for which
    the driver provides an interface) without the driver code - however, the
    driver requires the kernel to be usable. Still using your analogy, it would
    seem the driver is the application, and the kernel is the library.
    The facilities that the driver provides to the kernel don't seem to be
    much more than callbacks used in traditional library schemes to implement
    application specific behavior as part of a larger library framework.

    My 2c.

    -Jeff

-- 
Jeff Mahoney
jeffm@suse.com
jeffm@csh.rit.edu

Re: Controversy over dynamic linking -- how to end the panic

[Steve Brueggeman]

Your analogy is flawed.
You state that "the kernel is the equivalent of an application", when
compared to user-space application/library relationships.

The flaw in this analogy is, a library does 'require! and use'
routines provided by the application.  The library provides methods
and services TO the application through a well defined API.  This is
exactly what the kernel also provides.

So, IMHO, the kernel is also acting more like a library, and drivers
are wrappers around that library, much the same as libc gets wrapped
by many other libraries to provide higher-level services.

If your analogy were accurate, there would be no issue here.  The
driver (library in your analogy) would become simply a provider, to be
used by others, and as such, the driver's license would be effecting
the users of the API (kernel/application in your analogy).

I believe the licensing issue here is more related to the fact that,
for a driver to be useful, it must use the services of the kernel.
The problem is complicated by the fact, that unlike sys_call()'s, the
API that drivers use, cannot by nature, be very well defined.  

If you are to allow proprietary, binary only drivers, you must then
come up with some generalized definition.

Personally, I'd rather like to see some standardized, well defined,
stable  kernel provider API,to which  binary-only drivers could design
to, and know they're legally safe.  This has been discussed before,
and, NO, I am definitely not trying to rekindle that flame-war.  I
just think that it would both make a legal stand on this issue
stronger, and it would also give those who want to provide binary-only
code the ability to do so with some confidence.

Just my $0.02 worth.
(me thinks that by the time this thread ends, he who collects all of
the 2-cents dropped here, will be rich)

(If I had 2-cents for every time......)



On Thu, 21 Jun 2001 11:39:13 -0700, you wrote:

>"Eric S. Raymond" wrote:
>> ------------------------------------------------------------------------
[snip]
>> 
>> 2. A driver or other kernel component which is statically linked to
>>    the kernel *is* to be considered a derivative work.
[snip[
>
>I disagree with 2.  Consider the following:
>
>- GPL library foo is used by application bar.  bar must be GPL because
>foo is.  I agree with this.
>- Non-GPL library foo is used by GPL application bar.  foo does NOT
>become GPL just because bar is, even if bar statically linked foo in.
>
>The kernel is the equivalent of an application.  If someone needs to
>statically link in a driver, which is the equivalent of a library, I
>don't see how that should make the driver GPL.
>
>
>-Jeff
>
>P.S.  I don't claim to be a lawyer, this is just my opinion.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: Controversy over dynamic linking -- how to end the panic

[Timur Tabi]

** Reply to message from "Eric S. Raymond" <esr@snark.thyrsus.com> on Thu, 21
Jun 2001 14:14:42 -0400


> To calm down the lawyers, I as the principal kernel maintainer and
> anthology copyright holder on the code am therefore adding the
> following interpretations to the kernel license:
> 
> 1. Userland programs which request kernel services via normal system
>    calls *are not* to be considered derivative works of the kernel.
> 
> 2. A driver or other kernel component which is statically linked to
>    the kernel *is* to be considered a derivative work.
> 
> 3. A kernel module loaded at runtime, after kernel build, *is not*
>    to be considered a derivative work.

Although these are good things to add, I don't think they're compatible with
the GPL.  That is, Linus can't just state these "interpretations" and add them
to the GPL, because it will weaken the GPL as a whole.  I say that because you
do not include any language that clarifies that from a legal sense.

I heard recently that kernel modules are technically, from the GPL
point-of-view, a derivative work, because they include kernel header files.
However, since Linus understands that this precludes binary-only modules, he has
"made an exception" to the Linux kernel license.

The problem with that is that I have never seen any written evidence of this.

IANAL, but IMO, there are only two solutions:

1. License the Linux kernel under a different license that is effectively the
GPL but with additional text that clarifies the binary module issue.
Unfortunately, this license cannot be called the GPL.  Politically, this would
probably be a bad idea.

2. License the Linux kernel under TWO licenses, one the GPL, and another which
talks about the binary module issue.  Unfortunately, this would probably not
work either, as technically these two licenses are incompatible.

I guess what I'm trying to say is that this issue won't be resolve simply by
some "interpretations" by Linus as to what is and is not a derived work.  I
think the FSF needs to be involved in this.

To be honest, I disagree that #include'ing a GPL header file should force your
app to be GPL as well.  That may be how the license reads, but I think it's a
very bad idea.  I could write 1 million lines of original code, but if someone
told me that but simply adding #include <stdio.h> my code is now a derivative of
the stdio.h, I'd tell him to go screw himself.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: Controversy over dynamic linking -- how to end the panic

[Timur Tabi]

** Reply to message from Wei Weng <wweng@kencast.com> on 21 Jun 2001 16:01:58
-0400


> Hell, why does the linux community need to care about other *greedy*
> people who don't want to GPL their work anyway? If you want to protect
> GPL as the principle in Linux, well, screw the device driver makers!

Unfortunately, your position will result in reduce hardware support.  There are
companies out there that will not release the source code to their drivers.  By
preventing binary-only drivers, you're basically telling those companies, "I
don't care who needs your hardware to work under Linux, I won't let you ship
your drivers." 

Besides, your opinion on this matter is irrelevant.  Linus has already decided
to allow binary-only drivers.  The question is not WHETHER it is allowed, but
HOW it will be allowed.  Please stay on topic.

> What is the difference between including kernel header file and
> including GPLed header file?

None, as far as I know, and that's the problem.  By Linus saying, "including
kernel header files doesn't make your driver a derivative work", he is
effectively _weakening_ a provision in the GPL _as a whole_ (assuming that you
believe including header files makes your work a derivative, which I don't).


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: Controversy over dynamic linking -- how to end the panic

[Erik Mouw]

On Thu, Jun 21, 2001 at 02:03:32PM -0500, Timur Tabi wrote:
> Besides, your opinion on this matter is irrelevant.  Linus has already decided
> to allow binary-only drivers.  The question is not WHETHER it is allowed, but
> HOW it will be allowed.  Please stay on topic.

In my opinion Linus was already too late when he decided to allow
binary-only drivers. At that time there were already way too many
principal authors that contributed to the kernel, and not all authors
of all files might have agreed with his decision.

But then again: IANAL and this is a legal issue, so Alan is right:
consult a lawyer.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: Controversy over dynamic linking -- how to end the panic

[Mike Harrold]

> To be honest, I disagree that #include'ing a GPL header file should force your
> app to be GPL as well.  That may be how the license reads, but I think it's a
> very bad idea.  I could write 1 million lines of original code, but if someone
> told me that but simply adding #include <stdio.h> my code is now a derivative of
> the stdio.h, I'd tell him to go screw himself.

Not to mention utterly unenforceable. Consider:

1) Oracle Corp. builds their database for Linux on a Linux system.
2) Said system comes with standard header files, which happen in this case to
   be GPL'd header files.
3) Oracle Corp.'s database becomes GPL.

There's not a court in the civilised world that would uphold the GPL in that
scenario.

Regards,

/Mike

Re: Controversy over dynamic linking -- how to end the panic

[Alan Cox]

> 1) Oracle Corp. builds their database for Linux on a Linux system.
> 2) Said system comes with standard header files, which happen in this case to
>    be GPL'd header files.
> 3) Oracle Corp.'s database becomes GPL.
> 
> There's not a court in the civilised world that would uphold the GPL in that
> scenario.

Yes but the concern is the USA 8)

An application is clearly not a derivative work in the general case, and they
are linked with glibc which is LGPL and gives the users the choice and right
to run non-free apps. 

In fact the people in the application space trying to take away the users
rights are Microsoft with its new 'no free software allowed' licenses on 
Windows libraries.

Drivers are a more complex issue. I'm not opposed to binary only drivers, 
providing its easy to tell they are there and dump all bug reports about them.
Freedom generally includes the right to give up freedom. I'll tell people its
a bad idea but once they get caught, well it was their right to do so...

Alan

Re: Controversy over dynamic linking -- how to end the panic

[Marco Colombo]

On Thu, 21 Jun 2001, Alan Cox wrote:

> > 1) Oracle Corp. builds their database for Linux on a Linux system.
> > 2) Said system comes with standard header files, which happen in this case to
> >    be GPL'd header files.
> > 3) Oracle Corp.'s database becomes GPL.
> >
> > There's not a court in the civilised world that would uphold the GPL in that
> > scenario.
>
> Yes but the concern is the USA 8)

Pardon me, but what does "Oracle Corp.'s database becomes GPL" mean in the
above 3)? (I'm asking to you since you seem to agree).  Even if the
database is found to be linked with a GPLed piece of SW, this doesn't make
it (the database) GPLed, it just breaks Oracle's licence on the GPL SW.
They only have to recompile their program against non-GPLed code (e.g.
rewrite that part from scratch) and redistribute it.  That's not like
everyone going to Oracle and say "Your SW is now GPLed, hand me the Source.
Resistance is Futile." ... GPL has a viral behaviour iff you want to
keep using the GPLed part that you included, or am I missing something?

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: Controversy over dynamic linking -- how to end the panic

[Alan Cox]

> Pardon me, but what does "Oracle Corp.'s database becomes GPL" mean in the
> above 3)? (I'm asking to you since you seem to agree).  Even if the
> database is found to be linked with a GPLed piece of SW, this doesn't make
> it (the database) GPLed, it just breaks Oracle's licence on the GPL SW.

Right. And anyone who claims that Oracle is a derivative work of the Linux
Kernel has a few screws loose.

It no more belongs to Linus because it runs on Linux than to Bill Gates because
it runs on NT

Re: Controversy over dynamic linking -- how to end the panic

[Timur Tabi]

** Reply to message from Marco Colombo <marco@esi.it> on Thu, 21 Jun 2001
22:12:35 +0200 (CEST)


> They only have to recompile their program against non-GPLed code (e.g.
> rewrite that part from scratch) and redistribute it.

That assumes that a non-GPL equivalent even exists, or can be written without
completely plagiarizing (sp?) the GPL original.  How do you make a non-GPL
version of vmlinux or stdio.h?  Ok, that's not the best example, but I think you
get my point.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: Controversy over dynamic linking -- how to end the panic

[Timur Tabi]

** Reply to message from Mike Harrold <mharrold@cas.org> on Thu, 21 Jun 2001
15:04:21 -0400 (EDT)


> Not to mention utterly unenforceable. Consider:
> 
> 1) Oracle Corp. builds their database for Linux on a Linux system.
> 2) Said system comes with standard header files, which happen in this case to
>    be GPL'd header files.
> 3) Oracle Corp.'s database becomes GPL.
> 
> There's not a court in the civilised world that would uphold the GPL in that
> scenario.

I do believe, however, that in these cases the header files in question are
under the LGPL, which does specifically allow linking and #including in non-GPL
and non-LGPL code.

In my opinion, this whole thing would just go away (including some of
Microsoft's anti-GPL rants), if the FSF officially declared that under the GPL,
#including a GPL header file does NOT force your code to be also GPL.


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: Controversy over dynamic linking -- how to end the panic

[Alexander Viro]

On Thu, 21 Jun 2001, Timur Tabi wrote:

> In my opinion, this whole thing would just go away (including some of
> Microsoft's anti-GPL rants), if the FSF officially declared that under the GPL,
> #including a GPL header file does NOT force your code to be also GPL.

The problem being, there is no such thing as header file from C point of view.
I can do

cat >my_file.c <<EOF
#include "/home/you/your_file.c"
EOF

and be done with that. And yes, it's abusing cpp.

Re: Controversy over dynamic linking -- how to end the panic

[Wei Weng]

On 21 Jun 2001 13:46:48 -0500, Timur Tabi wrote:
> ** Reply to message from "Eric S. Raymond" <esr@snark.thyrsus.com> on Thu, 21
> Jun 2001 14:14:42 -0400
> 
> 
> > To calm down the lawyers, I as the principal kernel maintainer and
> > anthology copyright holder on the code am therefore adding the
> > following interpretations to the kernel license:
> > 
> > 1. Userland programs which request kernel services via normal system
> >    calls *are not* to be considered derivative works of the kernel.
> > 
> > 2. A driver or other kernel component which is statically linked to
> >    the kernel *is* to be considered a derivative work.
> > 
> > 3. A kernel module loaded at runtime, after kernel build, *is not*
> >    to be considered a derivative work.
> 
> Although these are good things to add, I don't think they're compatible with
> the GPL.  That is, Linus can't just state these "interpretations" and add them
> to the GPL, because it will weaken the GPL as a whole.  I say that because you
> do not include any language that clarifies that from a legal sense.
Hell, why does the linux community need to care about other *greedy*
people who don't want to GPL their work anyway? If you want to protect
GPL as the principle in Linux, well, screw the device driver makers!

> I heard recently that kernel modules are technically, from the GPL
> point-of-view, a derivative work, because they include kernel header files.
> However, since Linus understands that this precludes binary-only modules, he has
> "made an exception" to the Linux kernel license.
> 
> The problem with that is that I have never seen any written evidence of this.
> 
> IANAL, but IMO, there are only two solutions:
> 
> 1. License the Linux kernel under a different license that is effectively the
> GPL but with additional text that clarifies the binary module issue.
> Unfortunately, this license cannot be called the GPL.  Politically, this would
> probably be a bad idea.
> 
> 2. License the Linux kernel under TWO licenses, one the GPL, and another which
> talks about the binary module issue.  Unfortunately, this would probably not
> work either, as technically these two licenses are incompatible.
> 
> I guess what I'm trying to say is that this issue won't be resolve simply by
> some "interpretations" by Linus as to what is and is not a derived work.  I
> think the FSF needs to be involved in this.
> 
> To be honest, I disagree that #include'ing a GPL header file should force your
> app to be GPL as well.  That may be how the license reads, but I think it's a
> very bad idea.  I could write 1 million lines of original code, but if someone
> told me that but simply adding #include <stdio.h> my code is now a derivative of
> the stdio.h, I'd tell him to go screw himself.
What is the difference between including kernel header file and
including GPLed header file? 


Best Regards,


Wei

Re: Controversy over dynamic linking -- how to end the panic

[Alan Cox]

> > the stdio.h, I'd tell him to go screw himself.
> What is the difference between including kernel header file and
> including GPLed header file? 

There are real differences between programs and interface definitions. At this
point you get into law and the like and its probably best you read up on it
from a reputable source not l/k

Re: Controversy over dynamic linking -- how to end the panic

[Jonathan Lundell]

At 8:06 PM +0100 2001-06-21, Alan Cox wrote:
>  > > the stdio.h, I'd tell him to go screw himself.
>>  What is the difference between including kernel header file and
>>  including GPLed header file?
>
>There are real differences between programs and interface definitions. At this
>point you get into law and the like and its probably best you read up on it
>from a reputable source not l/k

Though header files don't fall clearly on the interface-definition 
side of the line. ctype.h, for example, in userland, or any other 
header with #defined or inline code.
-- 
/Jonathan Lundell.

Re: Controversy over dynamic linking -- how to end the panic

[D. Stimits]

Jonathan Lundell wrote:
> 
> At 8:06 PM +0100 2001-06-21, Alan Cox wrote:
> >  > > the stdio.h, I'd tell him to go screw himself.
> >>  What is the difference between including kernel header file and
> >>  including GPLed header file?
> >
> >There are real differences between programs and interface definitions. At this
> >point you get into law and the like and its probably best you read up on it
> >from a reputable source not l/k
> 
> Though header files don't fall clearly on the interface-definition
> side of the line. ctype.h, for example, in userland, or any other
> header with #defined or inline code.
> --
> /Jonathan Lundell.

Add to that the complications of C++ templates (not used in kernel, but
it could certainly test the law).

Re: Controversy over dynamic linking -- how to end the panic

[Rob Landley]

On Thursday 21 June 2001 14:46, Timur Tabi wrote:

> 1. License the Linux kernel under a different license that is effectively
> the GPL but with additional text that clarifies the binary module issue.
> Unfortunately, this license cannot be called the GPL.  Politically, this
> would probably be a bad idea.

I thought this was what the LGPL was for?

Unfortunately, it wouldn't be easy to switch from GPL to LGPL for the LInux 
kernel precisely BECAUSE Linus is not the sole copyright holder.

(Note: Richard Stallman insisted anyone who contributed a patch of any size 
to GNU sign a piece of paper handing their copyright over to the FSF.  
Unfortunately, this created so much friction around getting patches in that 
it was a significant factor to GNU stalling and forking to produce Linux.)

Rob

Re: Controversy over dynamic linking -- how to end the panic

[Craig Milo Rogers]

	IANAL.  I also dislike fencepost errors.  Hence, these
comments.

	The GNU GPL Version 2, June 1991, (hereafter the GPL), applies
"to the modified work as a whole".  Consequently:

>2. A driver or other kernel component which is statically linked to
>   the kernel *is* to be considered a derivative work.

	The kernel image, including the statically-linked device
driver, is the primary derived work licensed by the GPL.  That portion
of the kernel image that represents some actual device driver binary
code (continuing the example above, and assuming that the device
driver's unlinked object code isn't already subject to the provisions
of the GPL), may or may not be a derived work under copyright law,
depending upon what modifications the linker made to the binary code
during linking. If the device driver didn't become a derived work
during compilation, and it didn't (for example) resolve any kernel
symbols during linking, it would not be a derived work under copyright
law, right?  Of course, right.

>3. A kernel module loaded at runtime, after kernel build, *is not*
>   to be considered a derivative work.

	The in-core kernel image, including a dynamically-loaded
driver, is clearly a derived work per copyright law.  As above, the
portion consisting only of the dynamically-loaded driver's binary code
may or may not be a derived work per the GPL.  It doesn't much matter
under the GPL, anyway, so long as the in-code kernel image isn't
"copied or distributed".

	Looking to the future, what if Linux is enhanced with the
ability to take a snapshot of a running system (including any
dynamically-loaded driver modules), and the snapshots are copied and
distributed by, say, a PDA vendor to make an instant-on Linux system?
I think it's reasonable to argue that the GPL requirements must apply
to all parts of the distributed kernel image, even the parts that were
derived from pre-snapshot dynamically-loaded modules.


	The act of "copying and distributing" a linked kernel image
containing GPL'ed code and, say, a non-GPL'ed device driver, requires
that the distributor follow the requirements of the GPL as applied to
the work as a whole, which means that source code must be available
for *all* portions of the linked kernel, which means that source code
for the driver must be made available... under the terms of sections 1
and 2 of the GPL.  The GPL's source code availability requirement
applies even to those identifiable sections of the linked kernel image
which themselves are not derived (per copyright law) from GPL'ed
sources.

	Remember, however, that the GPL, as written, imposes
requirements upon the the *distributor* of a combined work, not upon
the owner of the non-GPL'ed portions that were included in the
combined work.  It is the distributor's responsibility to make source
code available as require by the GPL.  This is *not* the same as
saying that any non-GPL'ed source code in question has, automatically,
itself become licensed under the GPL (sections 1 and 2).

					Craig Milo Rogers

Re: Controversy over dynamic linking -- how to end the panic (long)

[Alex Bligh - linux-kernel]

>> 3. A kernel module loaded at runtime, after kernel build, *is not*
>>   to be considered a derivative work.
>
> It doesn't much matter
> under the GPL, anyway, so long as the in-code kernel image isn't
> "copied or distributed".

Broadly agree - thanks for someone pointing out the obvious
here. Perhaps an analysis from a clause by clause reading
would be useful.

This seems to me to be the nub of the argument. There are three
questions to be considered:

1. Is development of a kernel module distributed under terms
   other than under the GPL (for instance, binary only) a
   breach of the license?

2. If not, is distributing such a kernel module (under its
   own license) along with the kernel (otherwise correctly,
   under its license) a breach of the GPL?

3. Is running the kernel, and loading such a kernel module,
   a breach of the kernel's license?

In order:

1. This hinges on whether the driver is covered by the GPL
   (definition of "Program" in 0). As the driver is clearly
   not the kernel, the test is whether it is a derived work,
   under copyright law. If we have already excluded (somehow,
   and I can't find it explicitly) inclusion of kernel headers
   from making a 'derived work', or if copyright law would
   not dictate that such inclusions made a 'derived work'
   (and I think that would be reasonably safe in a project
   of non-trivial size), then one could safely say that
   (1) would not be a breach of the license. Putting kernel
   headers under LGPL or other ammended GPL would clarify the
   matter beyond dispute.

2. To answer (2), we assume that (1) does not apply, and that
   a kernel module is (thus) not a derived work, and that the
   GPL does not apply to it. Reading license section (2):
   "If identifiable sections of that work are not derived
   from the Program, and can be reasonably considered independent
   and separate works in themselves, then this License, and its
   terms, do not apply to those sections when you distribute
   them as separate works." and further "In addition, mere
   aggregation of another work not based on the Program
   with the Program (or with a work based on the Program) on a
   volume of a storage or distribution medium does not bring the
   other work under the scope of this License." clearly shows
   that if the distribution of the driver alone is not in
   breach of the GPL (as it is not a derived work), then,
   as a work that is not a derived work, it can be distributed
   with the kernel.

3. The license states "Activities other than copying, distribution
   and modification are not covered by this License; they are
   outside its scope.  The act of running the Program is not
   restricted, and the output from the Program is covered only
   if its contents constitute a work based on the
   Program (independent of having been made by running the Program).
   Whether that is true depends on what the Program does."
   Now it is reasonably easy to argue that loading linux kernel, and
   linking with arbitrary kernel modules after running the kernel
   is not distribution. It could easilly be argued that it is
   not copying, any more than playing a CD whose contents
   are (temporarilly) copied into buffers on the CD player is
   copying. There is a possibility that the 'work' is being
   modified. However, the work modifies itself in several ways
   (it unzips the image) as part of its normal running. Further,
   the header from Linus says "NOTE! This copyright does *not*
   cover user programs that use kernel services by normal system
   calls - this is merely considered normal use of the kernel, and
   does *not* fall under the heading of "derived work". Note the
   use of the words 'user programs' not 'user mode programs'. But
   in anycase, insmod is a user program and a user mode program,
   which uses normal system calls (documented in libraries),
   albeit to change the behaviour of the kernel. But crucially,
   let us assume this argument fails, and 'insmod' actually
   performs modification of the work. The only obligations
   on modifiers seem to be under section (2), which obligies
   modifiers to do things with modified files (none), and
   on distribution (none, of the modified work). An implication
   of this reading is that you are free to modify the linux
   kernel (or any other GPL program) in any way you want,
   and retain whatever copyright you want on such modifications,
   so long as you neither copy nor distribute the result (though
   arguably you could distribute the modifications if you did not
   distribute any part of the original). I believe that (at least
   without the parenthesised element) is entirely within both the
   letter and the spirit of the GPL - it is /not/ designed to
   keep you from developing (under copyright or otherwise)
   your own modifications, it's designed to keep you from denying
   or restricting rights of distribution of the GPL'd code if
   you distribute stuff yourself. This is set out clearly
   in the preamble.

Areas of doubt:

A. Are all contributed patches / files /always/ under a license
   no more restrictive than 'COPYING' - including Linus'
   preamble.

B. Is it clear that inclusion of kernel headers when compiling
   a progam does not make that program a derived work of the
   kernel.

Implications:

A. It would be worth Linus publicising the fact (or some URL
   be added to Linux kernel postings) that patches by default
   will be assumed to be under the 'COPYING' license.

B. It would be worth someone clearing up the status of the
   license on header files.

C. It would be preferable if people read the COPYING file
   before commenting on license issues.

--
Alex Bligh

Fair Use (Was Re: Controversy over dynamic linking -- how to end the panic)

[Rob Landley]

On Thursday 21 June 2001 16:34, Craig Milo Rogers wrote:

> 	The in-core kernel image, including a dynamically-loaded
> driver, is clearly a derived work per copyright law.  As above, the
> portion consisting only of the dynamically-loaded driver's binary code
> may or may not be a derived work per the GPL.  It doesn't much matter
> under the GPL, anyway, so long as the in-code kernel image isn't
> "copied or distributed".

It would  be entirely legal to generate a patch against the copyrighted work 
which contains no code from the copyrighted work, and which is seperately 
distributed.

This falls under fair use.  The "fortify" folks did it for netscape 
navigator.  Your instructions for a set of changes to someone else's work are 
a unique creation as long as they don't actually include any portion of the 
other person's work.  (And things like book reviews or parody may contains 
small sections of the work being referred to, exactly how much is nebulous 
and generally decided on a case by case basis if it ever gets to court.)

A tarball containing a set of source code for a new, independent module, 
which does not include any GPLed code, is obviously not a "derivative work" 
in legal terms.  (It may be inspired by, but ideas aren't copyrighted, only 
the specific expression/implementation.  You can paraphrase an encyclopedia 
article for a school report, etc.  Just don't quote verbatim.)

Now the COMPILED version is where the fun begins.  Distributing a precompiled 
binary of this module means that GPL code was used during the compilation (at 
the very least header files), and that an argument could be made that 
technically this binary is a derivative work, and distribution of it might 
trigger licensing terms of the GPL.

Considering that the implied use of headers (I.E. .h files) is to allow their 
inclusion in other programs and therefore the creation of other programs, 
it's possible that an argument could be made that header files (originally 
distributed with a .h extension by the person who issued the license in the 
first place) are intended to be used to create other programs, and therefore 
this is fair use and not the creation of a derived work.  After all, the 
copyright holder of the code made a distinction between .c and .h files, when 
the functional aspects of the language dont' demand it.  And normally, .h 
files do not directly result in code in the output (inline macros being an 
exception that doesn't change the overall nature and intent of the file).  
But it'd be a coin flip whether the judge would buy that argument.

Now what LINUS seems to have done is offer an nebulous and imprecisely worded 
second license on at least the header files of Linux, which allows the 
creation of precompiled binaries as seperate items, as long as none of the 
existing Linux code has to be modified in any way to create these modules.  
(Allowing this sort of thing while still being GPL compatable with a larger 
work is, incidentally, the intent of the LGPL.  But he didn't use it.)

Binary modules created under this second license (and a verbal permission can 
be a legal license, as much as any oral agreement is ever likely to stand up 
in court), can therefore be distributed on a Linux compilation CD readily as 
any other piece of non-GPL code can (such as the binary-only version of 
netscape on the Red Hat CD's).  Nobody's claiming that such an anthology is 
creating a derived work, merely a collective distribution mechanism for the 
seperately licensed entities.  (Like an FTP site you can take with you.)

Run-time linking of the modules with the Linux code is a seperate issue, 
almost certainly falling under fair use.  You are not distributing the 
result, and you have a license for both components saying that they are in 
fact legal copies, therefore what you do with them is your business.  (What 
use a legal copy is put to is NOT subject to copyright law.  Contract law as 
part of the license terms maybe, but that's a can of worms we won't open just 
now, especially such fun aspects as "standing" and "informed consent"...)

The only real legal question is whether Linus has the authority to offer the 
second license allowing the creation of non-GPL binary modules.  A case could 
be made that he does, and not just due to the anthology copyright, but 
because posession really is 9/10 of the law.

The "binary modules" clause has been out there for years now without being 
challeneged.  Everybody's known about it, the statute of limitations for 
objecting to it has probably gone by.  Everyone submitting code to Linus for 
a long time has been implying acceptance of his license terms for 
distribution of that code.

A paralell could also be dawn between intellectual property law and regular 
property law, along the lines of homesteading.  If you find an abandoned 
house and live in it long enough, especially if you make significant changes 
like fixing it up, it's considered to have been abandoned to you, and you 
gain ownership of it.  If the original owner comes back after long enough and 
complains, the court basically decides which gets to keep it and it may very 
well go to the current occupant.  (I'm trying to remember the name of this 
legal principle, strangely enough they teach it in courses on real estate as 
"something to watch out about if you're a landlord".)

Linus has been maintainer of Linux since day 1.  There are other active 
copyright holders on portions of the code (alan, ingo, andrea, rik, stephen, 
etc.) but they've all pretty much gone along with Linus's license terms.  The 
only potential problem would be long-inactive participants, or contributors 
of very small patches, who might raise a stink.  The question of whether 
they'd have significant standing is something a judge honestly might throw 
out (for the same reason linking oracle against the linux headers ain't gonna 
make oracle GPL no matter what the license may say.)

Remember, we're talking civil court here, not criminal.  This is an offense 
against copyrights and contracts, not breaking laws passed by legislatures 
and committing a misdemeanor or a felony.  What you can really sue for in 
civil court (other than monetary damages, where you have to either prove 
financial harm or convince a judge/jury to punish the other guy with punitive 
damage awards) is injunctive relief in terms of a restraining order.  You can 
get them to stop distributing your code, either to stop offering it or to 
take your contribution out of what they offer. 

So the only practical recourse the minor copyright holder on a Linux snippet 
might have is to request the removal of their contribution from the whole.  
That probably WOULD be within their rights to do.  (In the oracle clase, we 
could say "you can't distribute the version linked against our headers!  Stop 
that!" and probably win in court.  But we couldn't get ownership of the rest 
of their source code because the magnitude of the "offense" wouldn't fit the 
scale of the "punishment", and because the scope of the case doesn't really 
extend to the rest of oracle's code.  Civil courts are big on that sort of 
thing.)

So the real-world danger is that somebody we haven't heard from since 1993 
objects to the concept of binary modules and requests we remove 10 lines from 
the serial driver.  Which we could do, and patch our way around, in about 15 
minutes, end of problem.

Of course, I'm not a lawyer either.  (And I have no trainign in stock market 
investing either, but I wrote a column on it for three years.  I'm 
self-taught in Java and taught a course on it at the local community college. 
 My respect for "credentials" is just amazing, as you can tell...)

Rob

Re: Controversy over dynamic linking -- how to end the panic

[Andrea Arcangeli]

> 1. Userland programs which request kernel services via normal system
							 ^^^^^^
>    calls *are not* to be considered derivative works of the kernel.

Please, at least don't say "normal" or it will be non obvious that it is
ok for the vsyscalls too (which aren't *that* normal system calls). I'd
rather use "via any kind of official system call (vsyscalls included)".
Otherwise I guess a malicious could try to say that the vsyscalls are
basically dynamically linking the userspace with the kernel (dynamically
linking GPL code in the kernel to whatever non GPL userspace).

vsyscalls cannot give any advantage to the dark side (satellite is
flooding me with the star wars movies sorry ;) anything you can do with
a vsyscall, you can do with a real syscall too, just slower.  They can
only improve performance when it is possible to provide the same
functionality without entering/exiting kernel. So nobody sane could ever
complain about the vsyscalls but since you're writing that stuff it
worth to make it explicit I think ;).

Thanks,

Andrea

Re: Controversy over dynamic linking -- how to end the panic

[David Woodhouse]

esr@snark.thyrsus.com said:
>  Earlier today I was contacted by a principal at a well-known Linux
> company who was in a mild panic over recent arguments by Alan Cox and
> David Miller.  This company (not VA or Red Hat, BTW) fears that their
> customers will run from Linux if they get the idea that linking
> drivers to the kernel might force them open. 

I'm not going to join the amateur lawyers' society debate about this. But I 
will point out that I disagree with your intentions here.

Personally, I don't _want_ authors or users of binary modules to be reassured.
I want them to write open source code, or go away. And I don't think I'm 
alone in that.

I think Linus said it best...

On 7 Feb 1999, at 08:15:24 GMT, Linus Torvalds said:
> Basically, I want people to know that when they use binary-only modules,
> it's THEIR problem.  I want people to know that in their bones, and I
> want it shouted out from the rooftops.  I want people to wake up in a
> cold sweat every once in a while if they use binary-only modules. 

Large companies are now basing their design and purchasing choices on the
availability of _real_ Linux support; not just binary-only drivers. Even if 
we _are_ primarily motivated by the desire to increase the market share of 
Linux (which is something I don't concede anyway), then we still don't lose 
much by letting binary-module people continue to sweat. 

--
dwmw2

Re: Controversy over dynamic linking -- how to end the panic

[Fabrice Gautier]

On Thu, 21 Jun 2001 14:14:42 -0400
"Eric S. Raymond" <esr@snark.thyrsus.com> wrote:
> >
> >As copyright holder of the Linux kernel, Linus is the only person with
> >standing to sue for license violation. [...] This means
> >that in order for them to lose, a court must rule that module linking
> >propagates derivative-work status *and* Linus must reverse himself and
> >sue.

I always thought that, Linus was not the sole copyright holder on the
linux kernel.

Hence, didn't think hat he is not the only person to be able to sue. Could
not "kernel hacker x" sue if indeed some part of his work was used in
(what he assumes to be) non GPL compliant derivative work ?

Scenario: hacker X write ethernet driver for card made by constructor Y.
Constructor Y provide binary module to exploit super capability of their
card. 

Could hacker X sue company Y ? 

(well more interresting could be to replace hacker X by company X)

-- 
Fabrice Gautier <gautier@email.enstfr>

Re: Controversy over dynamic linking -- how to end the panic

[Disconnect]

In-Reply-To: <E15D9u7-0001xo-00@the-village.bc.nu>

On Thu, 21 Jun 2001, Alan Cox did have cause to say:

> An application is clearly not a derivative work in the general case, and they
> are linked with glibc which is LGPL and gives the users the choice and right
> to run non-free apps. 

IANAL, and this may be a dumb question, but what about LGPLing the driver
abstraction layer and/or headers? (Presuming of course there -is- a driver
abstraction layer that would work for 99% of the drivers.)  That leaves
the kernel safe (since LGPL says link whatever under whichever license,
GPL is valid for kernel core) and -specifically- allows any license you
like for HW/SW vendors who want to make modules.

---
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P- L+++>+++++ 
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------

Re: Controversy over dynamic linking -- how to end the panic

[Alan Cox]

> IANAL, and this may be a dumb question, but what about LGPLing the driver
> abstraction layer and/or headers? (Presuming of course there -is- a driver

GPL + LGPL gives you GPL so it doesnt help. You can combine it with the driver
or with the kernel but not with both together.

Re: Controversy over dynamic linking -- how to end the panic

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
> "Eric S. Raymond" wrote:
> > ------------------------------------------------------------------------
> > The GPL license reproduced below is copyrighted by the Free Software
> > Foundation, but the Linux kernel is copyrighted by me and others who
> > actually wrote it.
> > 
> > The GPL license requires that derivative works of the Linux kernel
> > also fall under GPL terms, including the requirement to disclose
> > source.  The meaning of "derivative work" has been well established
> > for traditional media, and those precedents can be applied to
> > inclusion of source code in a straightforward way.  But as of
> > mid-2001, neither case nor statute law has yet settled under what
> > circumstances *binary* linkage of code to a kernel makes that code a
> > derivative work of the kernel.
> > 
> > To calm down the lawyers, I as the principal kernel maintainer and
> > anthology copyright holder on the code am therefore adding the
> > following interpretations to the kernel license:
> > 
> > 1. Userland programs which request kernel services via normal system
> >    calls *are not* to be considered derivative works of the kernel.
> > 
> > 2. A driver or other kernel component which is statically linked to
> >    the kernel *is* to be considered a derivative work.
> > 
> > 3. A kernel module loaded at runtime, after kernel build, *is not*
> >    to be considered a derivative work.
> > 
> > These terms are to be considered part of the kernel license, applying
> > to all code included in the kernel distribution.  They define your
> > rights to use the code in *this* distribution, however any future court
> > may rule on the underlying legal question and regardless of how the
> > license or interpretations attached to future distributions may change.
> 
> I disagree with 2.  Consider the following:
> 
> - GPL library foo is used by application bar.  bar must be GPL because
> foo is.  I agree with this.
> - Non-GPL library foo is used by GPL application bar.  foo does NOT
> become GPL just because bar is, even if bar statically linked foo in.
> 
> The kernel is the equivalent of an application.  If someone needs to
> statically link in a driver, which is the equivalent of a library, I
> don't see how that should make the driver GPL.

Isn't this all covered by the LGPL ? (Library GPL)

If the kernel is counted as a library (by the module, or the module
counted as a library by the kernel) doesn't that fit with the LGPL
definition? I believe the LGPL covers the runtime library.

This was hashed out some time ago - If I remember correctly Linus didn't
favor the LGPL for kernel because that ment the interface between
the kernel and modules had to become more "static", restricting the
future enhancements of the kernel/module interface.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Controversy over dynamic linking -- how to end the panic

[Timur Tabi]

** Reply to message from Andrew Pimlott <andrew@pimlott.ne.mediaone.net> on
Thu, 21 Jun 2001 17:30:06 -0400


> I'm not sure whether you are right or wrong--but such a conclusion
> would be grossly unfair.  I think a strong case would be made that
> existing practice wrt Linux is independent of existing practice wrt
> GNU, and that everyone involved knows that Linus's GPL is not the
> FSF's GPL.  And I think that the FSF (and their lawyers) would
> advance this claim vigorously.

Well, that's a can of worms we DON'T want to open.  What's to stop Microsoft
from claiming their own interpretaion of the GPL?  The whole point behind the
GPL (and any license) is that it cannot be vaguely interpreted by various
individuals and companies.

> (Besides, it's really in nobody's best interest to take the GPL
> before a judge, so I think that rough consensus and community
> dynamics will continue to drive the interpretation of the GPL.)

Well, what if one company create a Linux application and used the "Linus GPL"
instead of the "FSF GPL" to defend its practices?  I think there's some
situation going on right now about an company that released a non-GPL Linux
media player (or something like that) that links in someone else's GPL code.

Besides, isn't the "Linus GPL" somewhere between the "FSF GPL" and the LGPL?


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com


-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

Re: Controversy over dynamic linking -- how to end the panic

[Rick Hohensee]

andrew@pimlott.ne.mediaone.net (Andrew Pimlott)
>I agree entirely that Linus, as creator of the license, is
>privileged with respect to interpretation of the license.  I

Richard Stallman is the creator of the license. It's his greatest work.
Linus is in no way priviledged as to interpretation of it, other than
tolerance on the part of the parties that own the copyright to the
license.

The GPL is about "the program". As far as I'm concerned, modules are the
kernel, "the program".  The way to stem any panic that may exist, if you
want to allow binary-only modules (which sucks*, but whatever), is to LGPL
or "KGPL" the kernel. What is being allowed now is in violation of the
GPL. 


Rick Hohensee
www.clienux.com


*How 'bout a nice binary-only Forth running the kernel? Metacompiling
kernel routines into the Forth dictionary and such. Sound creepy? Good.

Re: Controversy over dynamic linking -- how to end the panic

[kumon]

Rick Hohensee writes:
 > Richard Stallman is the creator of the license. It's his greatest work.
 > Linus is in no way priviledged as to interpretation of it, other than
 > tolerance on the part of the parties that own the copyright to the
 > license.

So, GPL FAQ on FSF web-site <http://www.fsf.org/copyleft/gpl-faq.html>
is worth reading. It represents their thought.

* If a library is released under the GPL (not the LGPL), does that
  mean that any program which uses it has to be under the GPL?
  <http://www.fsf.org/copyleft/gpl-faq.html#IfLibraryIsGPL>

* Why are some GNU libraries released under the ordinary GPL rather
  than the Lesser GPL?
  <http://www.fsf.org/copyleft/gpl-faq.html#WhySomeGPLAndNotLGPL>

* I am writing free software that uses non-free libraries. What legal
  issues come up if I use the GPL?
  <http://www.fsf.org/copyleft/gpl-faq.html#TOCWritingFSWithNFLibs>

--
Computer Systems Laboratory, Fujitsu Labs.
kumon@flab.fujitsu.co.jp

Re: Controversy over dynamic linking -- how to end the panic

[Scott Wood]

On Thu, Jun 21, 2001 at 11:05:13PM -0400, Rick Hohensee wrote:
> Richard Stallman is the creator of the license. It's his greatest work.
> Linus is in no way priviledged as to interpretation of it, other than
> tolerance on the part of the parties that own the copyright to the
> license.

Neither is RMS, though; the license is the text of the GPL, not anything RMS
may have said about it since.

> The GPL is about "the program". As far as I'm concerned, modules are the
> kernel, "the program".

The modules are *not* "the kernel".  They are independent (except for header
files, but you didn't make that argument, and it's by no means certain to
hold up in court, especially if you don't use any code from the headers)
pieces of code that happen to interact with the kernel.  Why are modules,
from a legal standpoint, different from user programs?  And since when are
derivative works under copyright law determined by the opinion of the
copyright holder (much less any random third party that doesn't happen to be
a court), other than to be more lenient than the law requires?

> The way to stem any panic that may exist, if you want to allow binary-only
> modules (which sucks*, but whatever)

Sure, they suck, but only for the users that choose to use them and the
providers of the modules that have to deal with the maintenance issues. 
What sucks even more, though, is someone else making the choice for them.

> *How 'bout a nice binary-only Forth running the kernel? Metacompiling
> kernel routines into the Forth dictionary and such. Sound creepy? Good.

The only creepy thing here is the kernel being written in Forth; if you
don't want to run it in that binary-only implementation, find (or write) a
free one that will get the job done.  There's no need to get the courts and
lawyers involved, and no need to punish the users of the software by
restricting what they can do.

-Scott