Greg just withdrew the whole thing
Greg just withdrew the whole thing
Posted Dec 14, 2006 11:16 UTC (Thu) by coriordan (guest, #7544)In reply to: Greg just withdrew the whole thing by linus
Parent article: Binary-only kernel modules may be banned
I got the impression that GHK withdrew the particular implementation. The general idea hasn't been withdrawn, has it?
Posted Dec 14, 2006 11:51 UTC (Thu)
by linus (subscriber, #26348)
[Link] (11 responses)
Posted Dec 14, 2006 12:56 UTC (Thu)
by coriordan (guest, #7544)
[Link] (8 responses)
The idea of making the kernel refuse to load the drivers has been withdrawn, but maybe another solution is possible such as publicly stating that proprietary drivers are derived works, and giving the public 12 months prior warning of this position.
Linus has said that he doesn't like copyright law stretching that way, but he also seems open to being convinced that copyright law does stretch that way, and that it's useful that it stretches that way.
Posted Dec 14, 2006 19:22 UTC (Thu)
by jonabbey (guest, #2736)
[Link]
Posted Dec 15, 2006 8:57 UTC (Fri)
by hummassa (subscriber, #307)
[Link] (6 responses)
Posted Dec 15, 2006 17:03 UTC (Fri)
by man_ls (guest, #15091)
[Link] (5 responses)
Posted Dec 17, 2006 14:17 UTC (Sun)
by hummassa (subscriber, #307)
[Link] (4 responses)
Posted Dec 17, 2006 14:29 UTC (Sun)
by man_ls (guest, #15091)
[Link] (3 responses)
Posted Dec 18, 2006 11:43 UTC (Mon)
by hummassa (subscriber, #307)
[Link] (2 responses)
Posted Dec 18, 2006 23:40 UTC (Mon)
by man_ls (guest, #15091)
[Link] (1 responses)
If, however, you just want those symbols not to be filtered, then the result might not be a derivative work; the kernel should run an "abstraction, filtration, comparison" test right away and decide that on the fly, and if the test is negative load the poor module. I'm afraid that is not how it works.
Note that I didn't say that GPL_ONLY is an "effective protection measure"; just that it can be argued to be. The distinction is not bizantine in this case; you can invoke the DMCA even if it is later proved to be invalid, causing lots of grief in the process.
As a conclusion to this (too lengthy) message, I would say that the kernel provides for use restrictions where they like, not governed by copyright law.
Posted Dec 19, 2006 8:33 UTC (Tue)
by hummassa (subscriber, #307)
[Link]
> a technological measure "effectively controls access to a work" if the
I don't know if the GPL_ONLY mechanism would need "in the course of its
I obviouly agree with the rest of your post, with this additional remark:
> If, however, you just want those symbols not to be filtered, then the
Yup. I don't know of any program that can do
But one must notice, both the existence of [1] a non-derivative of the
That being said, I am pretty positively sure that, as an example, the
Posted Dec 14, 2006 22:37 UTC (Thu)
by Ross (guest, #4065)
[Link]
Posted Dec 16, 2006 5:07 UTC (Sat)
by tgall (subscriber, #217)
[Link]
What seems to be really desired is a system that kicks in at distribution time and is constructed in such a way that all kernel modules are GPL yet have such a low barrier of entry that anyone can build modules. Simple.
Why not include with the kernel a system for building kernel modules which attaches to every kernel module built a small piece of GPL code. Central to the core kernel which loads the module which executes the GPL code and would otherwise not work without it.
The person in their basement is not affected. Those that would distribute binary kernel modules would not longer be able to do so, least not without them being under the GPL.
Now sure someone could fork and remove said feature, but in the grand scheme I suspect there would be little interest in such a kernel after all, without this the world will remained closed in technologies that really should be sharing their specs with the kernel community.
Regards,
Tom
Posted Dec 14, 2006 11:58 UTC (Thu)
by grouch (guest, #27289)
[Link]
First, this is adding the measure at module load time. Any copyright
infringment happens on distribution; module load isn't (necessarily)
that; if I write random code and load it, without ever sending it
to anyone, I'm not violating the license, and this would prevent that.
So it seems somewhat misplaced.
There's more to that article and a reply from Greg Kroah-Hartman. See the thread.
Posted Dec 14, 2006 12:08 UTC (Thu)
by drag (guest, #31333)
[Link] (1 responses)
The idea that just allowing a few binary modules to link to the kernel and eventually you'd be able to just convince other manufacturers to release specs have blown up in the kernel developer's faces.
It's NOT WORKING. Every year it seems more and more difficult to get hardware support for Linux. Devices are more complicated, hardware makers are more paranoid and they know they can absolutely get away with binary drivers if they feel like it.
Kernel developers and even the most fanatical Linux users now have a solid track record of just rolling over and taking the hit just for the convience.
Meanwhile OpenBSD has a gotten a better track record for getting hardware makers to cooperate and their license doesn't even require it.
Their making fun of everybody..
Posted Dec 14, 2006 14:46 UTC (Thu)
by rfunk (subscriber, #4054)
[Link]
The general idea of refusing binary module loading, which is the subject at hand, was withdrawn since any licence violation happens at distribution time, not module loading time.Greg just withdrew the whole thing
Yes, but it seems there was some support for the position that life would be better without proprietary drivers (because it would help those writing free drivers).Greg just withdrew the whole thing
Notice who you're responding to? ;-)Greg just withdrew the whole thing
copyright law does not stretch that way.The problem with this position is...
Derivative works, as I have stated many times, are those selected by the
test "abstraction, filtration, comparison". If you say "I'm licensing this
under the GPL but I consider any linking object's source as a derivative
work" you are adding a restriction over the GPL terms (*), and the
GPL forbids that (in section 6: "You may not impose any further
restrictions on the recipients' exercise of the rights granted
herein").
(*) because the GPL terms refer to the copyright law, not to your new,
redefined "derivative works".
Since when is kernel development motivated solely by copyright law? Are GPL_ONLY symbols governed by copyright law? I would assume they aren't, since they change over time while the law (and the international treaties it is based upon) remains the same.
Motivations outside copyright
GPL_ONLY symbols are AFAICT a "declaration of intent". They mean "if you Motivations outside copyright
link to this symbol, then we (the kernel developers in genereal) think you
are thinkering too deep with the linux internals, so your module OUGHT to
be a derivative work of the kernel (and consequentially must be licensed
under terms compatible with the GPLv2)."
Where is copyright law in that "declaration of intent"? Where is "abstraction, filtration, comparison"? Paraphrasing yourself up in this thread:
Motivations outside copyright
If you say "I'm licensing this under the GPL but I consider any linked module that uses this symbol as a derivative work" you are adding a restriction over the GPL terms (*), and the GPL forbids that (in section 6: [...])
Note that the GPL_ONLY mechanism doesn't just display a warning (as would be expected from a "declaration of intent"); it effectively prevents your use of the symbol at runtime, and therefore it might be argued that it constitutes an "effective protection measure" against copyright violations, as stated in the DMCA and the equivalent EU directive. Spooky.
And, as English is not my mother tongue, I'll try to sum it up I think we are having a communication problem, ...
(apologizing for the loooong post):
Initially, coriordan has said: """The idea of making the kernel refuse to
load the drivers has been withdrawn, but maybe another solution is
possible such as publicly stating that proprietary drivers are derived
works, and giving the public 12 months prior warning of this position.
Linus has said that he doesn't like copyright law stretching that way, but
he also seems open to being convinced that copyright law does stretch that
way, and that it's useful that it stretches that way"""
In fewer words: "I suggest kernel developers make a joint statement saying
that they consider anything linking to the kernel or loaded in kernelspace
as a derivative work of Linux"
And I responded to it: """copyright law does not stretch that way.
Derivative works, as I have stated many times, are those selected by the
test "abstraction, filtration, comparison". If you say "I'm licensing this
under the GPL but I consider any linking object's source as a derivative
work" you are adding a restriction over the GPL terms (*), and the GPL
forbids that (in section 6: "You may not impose any further restrictions
on the recipients' exercise of the rights granted herein")."""
In (not really) fewer words: "they cannot do that, because [1] they can't
redefine what is or is not a derivative work and [2] if they do (in the
context of the kernel license) the kernel becomes undistributable because
it will be licensed GPLv2 + additional restriction (considering things
that are _not_ derivative works as if they were)"
You: "Since when is kernel development motivated solely by copyright law?"
I did not respond -- it never was motivated by copyright law, but GPL_ONLY
symbols are a clever hack that make _use_ of copyright law.
You: "Are GPL_ONLY symbols governed by copyright law?"
Me: """GPL_ONLY symbols are AFAICT a "declaration of intent". They mean
"if you link to this symbol, then we (the kernel developers in genereal)
think you are thinkering too deep with the linux internals, so your
module OUGHT to be a derivative work of the kernel (and consequentially
must be licensed under terms compatible with the GPLv2)."""
I.e., the GPL_SYMBOLS in the kernel are similar to the Copyright (C)
assingments: they are declarations contained in the text of the kernel,
for copyright law purposes.
You: "I would assume they aren't, since they change over time while the
law (and the international treaties it is based upon) remains the same"
They change over time because the definition that the kernel developers
have of "this and this symbols are part of an intimate part of the kernel,
so if people use this they are probably developing a derivative work"
change. But this has nothing to do with changing the copyright law. It's
more akin to re-licensing a part of the kernel.
In the parent post, you said: """Where is copyright law in that
"declaration of intent"? Where is "abstraction, filtration,
comparison"?"""
I hope I have stated clearly that the GPL_ONLY symbol declaration is for
_purposes_ of copyright, exactly to give _some_ clue for the people that
are applying "abstraction, filtration, comparison" over the kernel that
things that use those symbols probably should _not_ be filtered. That is
AFAIK (and I know a little bit about this) the extent of the GPL_ONLY
declarations.
Instead of writing:
EXPORT_SYMBOL_GPL(cascade_irq);
The kernel developer could have written:
/* Copyright (C) Copyright (C) 2005 Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
** CAVEAT EMPTOR:
** If you use the symbol cascade_irq, then you are probably making a
** derivative work of this file. If this is the case, you must license
** your work under the GPL if you ever distribute it. */
Things above have the exact same legal value AFAICT.
Now, you raised the DMCA thing: """Note that the GPL_ONLY mechanism
doesn't just display a warning (as would be expected from a "declaration
of intent"); it effectively prevents your use of the symbol at runtime,
and therefore it might be argued that it constitutes an "effective
protection measure" against copyright violations, as stated in the DMCA
and the equivalent EU directive. Spooky."""
To this, I have to comment:
1. The DMCA is not only spooky, but downright evil.
2. Notwithstanding that, the GPL_ONLY symbols as "effective measure" would
not fly, because it is enough that you declare your module as GPL falsely
to the the GPL_ONLY mechanism (remember the "GPL\0 something else" trick?)
or that you compile a kernel where the GPL_ONLY mechanism is disabled.
2a. Notice that a kernel where the GPL_ONLY mechanism is disabled is a
valid, legal derivative work of the kernel ... as long as it is
distributed under the terms of the GPLv2. _NOTHING_ (legal) stops a distro
from distributing such a kernel. They just don't because it's easier for
support purposes to know if there is a non-GPLd module tainting the
kernel...
2b. Notice further, that as the kernel (via GPLv2) expressely allows for
the licensee to make any kind of derivative work (modulo the exceptions on
the GPL section [2]) including those circumventing GPL_ONLY restrictions,
this is /de/ /facto/ a waiver on the "effective measures" thing.
Certainly a communication problem
And, as English is not my mother tongue, I'll try to sum it up
(apologizing for the loooong post):
English is not my mother tongue either, and no need to apologize; we are here to understand these things better, and if someone is not interested she is free to skip the discussion.
GPL_ONLY
symbols are a clever hack that make _use_ of copyright law. [...] I.e., the GPL_SYMBOLS in the kernel are similar to the Copyright (C)
assingments: they are declarations contained in the text of the kernel,
for copyright law purposes.
If you say so. I don't see anywhere in copyright law the meaning of GPL_ONLY symbols, while the (C) assignments are clearly regulated in title 17, 401.
I hope I have stated clearly that the GPL_ONLY symbol declaration is for
_purposes_ of copyright, exactly to give _some_ clue for the people that
are applying "abstraction, filtration, comparison" over the kernel that
things that use those symbols probably should _not_ be filtered. That is
AFAIK (and I know a little bit about this) the extent of the GPL_ONLY
declarations.
That does not seem a valid thing to do; GPL_ONLY symbols belong in modules with GPL license, and this in turn is required only for derivative works of the kernel -- as you so explicitly stated, you cannot place additional restrictions on distribution if your code is to be GPL.
The kernel developer could have written:
This statement would have no effect on loading the module, but declaring the symbol GPL_ONLY would. So it is hardly the same, even from a legal point of view -- see below.
/* Copyright (C) Copyright (C) 2005 Yoichi Yuasa
** CAVEAT EMPTOR:
** If you use the symbol cascade_irq, then you are probably making a
** derivative work of this file. If this is the case, you must license
** your work under the GPL if you ever distribute it. */
2. Notwithstanding that, the GPL_ONLY symbols as "effective measure" would
not fly, because it is enough that you declare your module as GPL falsely
to the the GPL_ONLY mechanism (remember the "GPL\0 something else" trick?)
or that you compile a kernel where the GPL_ONLY mechanism is disabled.
Those would be circumvention acts. Title 17, 1201 says:
No person shall circumvent a technological measure that effectively controls access to a work protected under this title. [...]
a technological measure effectively controls access to a work if the measure, in the ordinary course of its operation, requires the application of information, or a process or a treatment, with the authority of the copyright owner, to gain access to the work.
It would seem to be the case with GPL_ONLY symbols, since modules have to declare their license at runtime and the mechanism prevents "access to the work" to infringing modules.
2b. Notice further, that as the kernel (via GPLv2) expressely allows for
the licensee to make any kind of derivative work (modulo the exceptions on
the GPL section [2]) including those circumventing GPL_ONLY restrictions,
this is /de/ /facto/ a waiver on the "effective measures" thing.
If you can in fact waive such a thing. Software licenses cannot allow illegal things; if Microsoft's EULA said "Microsoft can silently kill you and not go to jail", this clause is invalid. Very different from the wording in GPLv3, which states that the licensed code cannot be considered an "effective protection measure". It is not clear that you can change the definition of a law in a license, but it is anyway different from our case.
Then it is far more evil then I initially thought of it... because it can If you are right about the DMCA,
forbid certain modifications to GPL'd code that the GPL itself would
allow!! (like removing the GPL_ONLY loading mechanism from the kernel)
But:
> measure, in the ordinary course of its operation, requires the
> application of information, or a process or a treatment, with the
> authority of the copyright owner, to gain access to the work.
operation a process or treatment with the authority of the copyright
owner" and, more, the copyright owner of the module being loaded _is_ the
person that is putting MODULE_LICENSE("GPL\0 I don't like it") on it. It's
equivalent to what DVD Jon is doing nowadays: he licenses a program that
encrypts your .aac files so they can be read only on the authorized iPods.
> result might not be a derivative work; the kernel should run
> an "abstraction, filtration, comparison" test right away and decide that
> on the fly, and if the test is negative load the poor module. I'm afraid
> that is not how it works.
the "abstraction/filtration/comparison" test :-)
kernel work that uses a GPL_ONLY symbol and [2] a derivative work that
uses no GPL_ONLY symbols are completely possible. That's why I said that
GPL_ONLY symbols are only hints... for the technically-savvy
lawyer/paralegal that is verifying if something is or not a derivative
work of the kernel.
nvidia binary driver is not a derivative work of the kernel, nor can the
kernel devs "declare" it to be a derivative work of the kernel (without
making the kernel undistributable), nor can they make anything Effective
(as opposed to "effective" as per USC 17, 1201 in your interpretation)
that would prevent forever the loading of the nvidia binary driver.
But it could be disallowed in a technical sense even without the DMCA backing it up legally. People could work around it, but not without patching. Not that I necessarily advocate doing that...Greg just withdrew the whole thing
I wouldn't think this is a new idea, but none the less I'll post it and really it should probably go on lkml but it's late and I'm tired and well this is where i'm posting it.Greg should reimplement and resubmit...
I think this may have been the clincher for Greg KH:
Greg just withdrew the whole thing
The general idea is a good one.Greg just withdrew the whole thing
ftp://ftp.openbsd.org/pub/OpenBSD/songs/song39.ogg
That's why I've started checking the OpenBSD hardware compatibility list (in addition to OpenBSD hardware support
checking for Linux support) before buying hardware. I figure if both Linux and OpenBSD
support it, it must be fine, and if only OpenBSD supports it then it's just a matter of time
before Linux does -- but if OpenBSD doesn't support it, any Linux support may be
unreliable in the long term.
Thus, the last wireless card I bought was based on the Ralink rt2500.