I've been looking at the MTD (memory technology device) additions to the
linux 2.4.0 kernels. In particular I'm very interested in the DiskOnChip
2000 and NFTL drivers. However, as terribly useful as this driver is, was
I the only one who caught the following notice at the top of the driver
source:
/*
The contents of this file are distributed under the GNU Public
Licence version 2 ("GPL"). The legal note below refers only to the
_use_ of the code in some jurisdictions, and does not in any way
affect the copying, distribution and modification of this code,
which is permitted under the terms of the GPL.
Section 0 of the GPL says:
"Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope."
You may copy, distribute and modify this code to your hearts'
content - it's just that in some jurisdictions, you may only _use_
it under the terms of the licence below. This puts it in a similar
situation to the ISDN code, which you may need telco approval to
use, and indeed any code which has uses that may be restricted in
law. For example, certain malicious uses of the networking stack
may be illegal, but that doesn't prevent the networking code from
being under GPL.
In fact the ISDN case is worse than this, because modification of
the code automatically invalidates its approval. Modificiation,
unlike usage, _is_ one of the rights which is protected by the
GPL. Happily, the law in those places where approval is required
doesn't actually prevent you from modifying the code - it's just
that you may not be allowed to _use_ it once you've done so - and
because usage isn't addressed by the GPL, that's just fine.
[email protected]
6/7/0
LEGAL NOTE: The NFTL format is patented by M-Systems. They have
granted a licence for its use with their DiskOnChip products:
"M-Systems grants a royalty-free, non-exclusive license under
any presently existing M-Systems intellectual property rights
necessary for the design and development of NFTL-compatible
drivers, file systems and utilities to use the data formats with,
and solely to support, M-Systems' DiskOnChip products"
A signed copy of this agreement from M-Systems is kept on file by
Red Hat UK Limited. In the unlikely event that you need access to it,
please contact [email protected] for assistance. */
Now firstly, let's eliminate the ISDN red-herring from consideration
because the authors of the code do not place any additional restrictions
on the GPL whatsoever, they simply bring it to your attention that using
an un-certified ISDN stack may be illegal in some countries.
Now that we've cleared *that* up, let's look at the rest of the NFTL
restriction. I've already brought this to the attention, of course, of
RMS and ESR.
Richard believes that this violates the GPL because it places additional
restrictions not found in the GPL.
In any case, it seems pretty obvious that this restriction violates
section 6 of the Open Source Definition which states:
"The license must not restrict anyone from making use of the program in
a specific field of endeavor...."
In this case, the field of endeavor is to use it with another vendor's
product.
In any case, as terribly useful as this driver is (I'm working on a system
that needs the Disk-On-Chip/NTFL support) I am also conerned with the
stock Linux kernel getting tainted with non-Open Source code.
Comments welcome and appreciated.
Mark
> Now firstly, let's eliminate the ISDN red-herring from consideration
> because the authors of the code do not place any additional restrictions
> on the GPL whatsoever, they simply bring it to your attention that using
> an un-certified ISDN stack may be illegal in some countries.
The authors of the NTFL layer dont place any additional restrictions on your
use of the code either. They are merely warning you that if you use it in
some ways you are going to get your ass kicked by a third party. WHats the
difference, do you want to be sued by M-Systems or sqaushed by Deutsche Telecon
Alan
On Sat, Oct 28, 2000 at 05:24:19PM +0100, Alan Cox wrote:
> The authors of the NTFL layer dont place any additional restrictions on your
> use of the code either. They are merely warning you that if you use it in
> some ways you are going to get your ass kicked by a third party. WHats the
> difference, do you want to be sued by M-Systems or sqaushed by Deutsche Telecon
See section 7 of the GPL.
This is similar sort of GPL violation that kept Debian from shipping KDE
because QT was not GPL compatible and there is GPLed code linked to QT in
KDE without obvious explicit permission for the authors of every piece of
GPLed code in KDE.
In this case, Debian (or any organization who isn't big enough not to fear
M-systems) may not ship the standard kernel because it has additional patent
restrictions.
There is a clear ability here for the author of the driver and m-systems to
conspire to retroactively revoke anyones privilege to use, modify, or
distribute the stock kernel because of this code.
It's nice that the potential patent violation is made clear (I'm sure there
are patents that could potentially apply elsewhere in the kernel) but it
doesn't change the fact that the patents fundamentally limit the 'freedom'
of the kernel code.
> In this case, Debian (or any organization who isn't big enough not to fear
> M-systems) may not ship the standard kernel because it has additional patent
> restrictions.
Why. There are no distribution restrictions
> There is a clear ability here for the author of the driver and m-systems to
> conspire to retroactively revoke anyones privilege to use, modify, or
> distribute the stock kernel because of this code.
I fail to see how
Alan Cox wrote:
>
> > In this case, Debian (or any organization who isn't big enough not to fear
> > M-systems) may not ship the standard kernel because it has additional patent
> > restrictions.
>
> Why. There are no distribution restrictions
>
> > There is a clear ability here for the author of the driver and m-systems to
> > conspire to retroactively revoke anyones privilege to use, modify, or
> > distribute the stock kernel because of this code.
>
> I fail to see how
>
Alan is right. The way it's worded, they could never show a case for
"irreparable harm" to any sitting judge in the US. This means they
could say "we've changed our minds, and revoke this persons or that
person's license" but given it's been released with this language, no
case for harm or damages, or even a petition for injunctive relief would
have a snowball's change in hell of succeeding.
If you release code under the GPL, you basically waive any rights to
seek enforcement because in the US, you must be able to show
"irreparable harm" from some parties use of the code. It's tough to do
this if you've given the code away (which the GPL does) without a
contractural requirement for "consideration" ($$$). The GPL in the
strictest legal sense is the ultimate IP legal virus because it not only
removes the basis for damages claims for use of present code released
under it's terms, but since it covers derivative works, it's effect
contaminates all future incarnations of the code.
It's true with how this is worded, the party could come back and attempt
to modify the scope, but they would be hard pressed to make a case for
an injunction to halt someone's use of the code.
:-)
Jeff
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
On Sat, 28 Oct 2000, Mark Spencer wrote:
> Now firstly, let's eliminate the ISDN red-herring from consideration
> because the authors of the code do not place any additional restrictions
> on the GPL whatsoever, they simply bring it to your attention that using
> an un-certified ISDN stack may be illegal in some countries.
I am the author of the code in question. I have placed it under GPL. I do
not place any additional restrictions on the GPL whatsoever, I simply
bring it to your attention that using it on some hardware may be illegal
in some countries.
Besides, you misquoted. What the GPL in fact says is:
"You may not impose any further restrictions on the recipients'
exercise of the rights granted herein."
So in order for it to be a problem:
1. _I_ must impose the restriction. Not your local laws.
2. The right in question (in this case, the right to use the
NFTL code) must be 'granted [t]herein'.
So the NFTL is fine on both counts, then, because:
1. I don't.
2. It isn't (see below...)
Reading on will explain my answer to #2...
"Activities other than copying, distribution and modification are
not covered by this License; they are outside its scope."
That's good. Not only is the right to use not explicitly granted therein,
but the GPL is fairly explicit about the fact that it's not relevant.
Immediately after that quote, it does say:
"The act of running the Program is not restricted, ..."
Note the wording "is not", not "must not be" - it is saying that the GPL
does not of itself place restrictions on the act of running the program -
which serves to verify what it said above, about being _only_ to do with
"copying, distribution and modification".
> Richard believes that this violates the GPL because it places additional
> restrictions not found in the GPL.
I have discussed this with Richard before. I disagree, for the reasons
stated above:
1. The licence does _not_ restrict the use of the code. Your
local laws do. This is _precisely_ the same as the
ISDN situation.
Also 2. The right to use isn't 'granted [t]herein' anyway.
The last conversation I had with Richard on this topic, IIRC, ended in him
all but admitting that the GPL doesn't in fact prevent this. Of course he
didn't actually _say_ that, but he did fall back to claiming that it was
his _intention_ that was legally binding, not the text of the licence.
AFAIK his statement is incorrect, except where the actual text of the
licence is ambiguous. I see no ambiguity in the sentence "Activities other
than copying, distribution and modification are not covered by this
License; they are outside its scope."
> In any case, it seems pretty obvious that this restriction violates
> section 6 of the Open Source Definition which states:
Irrelevant. I neither know nor care in this context whether it meets this
Open Source Definition of which you speek. I care whether it can be merged
with Linux, which is under the GPL - and IMO it can. As Linus accepted the
code after I notified him of the situation, I infer that he shares my
opinion. Note that even in the case of an ambiguity in the text of the
GPL, I believe in this case that it it Linus' intention, not RMS', which
would be relevant.
Go persuade the Debian folks to stop distributing the Linux kernel because
my code doesn't meet the OSD, and get back to me when they've taken you
seriously. While you're at it, note that the sendfile() code is covered by
patents too. ISTR there are other instances as well.
Don't get me wrong - I detest the practice of patenting software, but I
don't believe that the existence of a patent should prevent us from using
the algorithm either
1. Where it is legal to do so - which is either in the Free
World where the insane patent doesn't apply, or on
DiskOnChip hardware, for which M-Systems have granted
permission.
or 2. Even where it is not legal, if someone wishes to challenge
the patent or 'call the bluff' of the patent-holder.
> "The license must not restrict anyone from making use of the program in
> a specific field of endeavor...."
Oh, that's good. It's not the licence which makes the restriction, it's
some entirely separate local legislation, just like in the ISDN case. So
it looks like the code _does_ meet the OSD. As I said, take it up with the
Debian people. Until they threaten to remove the Linux kernel, I don't
want to know.
> In this case, the field of endeavor is to use it with another vendor's
> product.
I know of nobody else who wants to do so, rendering the whole exercise a
rather pedantic Gedankenexperiment. Emulating a block device using a kind
of journalling pseudo-filesystem, and then having to put a 'normal'
journalling filesystem on top of that, is just insane. Except where it's
the status quo, nobody would want to use it - using a JFFS filesystem
directly on the flash is far more appropriate.?
Besides, if you want to do so, then my code has given you the _freedom_ to
use it and challenge the patent which IMO should not have been granted in
the first place. There's nothing in my code or its licence which prevents
you from doing just that.
> Comments welcome and appreciated.
Please don't take my tone the wrong way - it's just that I've had this
discussion too many times before.
--
dwmw2
? We'll have JFFS working on NAND flash RealSoonNow(tm).
On Sat, 28 Oct 2000, Gregory Maxwell wrote:
> See section 7 of the GPL.
"If you cannot distribute so as to satisfy simultaneously your obligations
under this License and any other pertinent obligations, then as a
consequence you may not distribute the Program at all."
But I can, so I may. See the rest of the GPL, along with my response to
the original mail.
> In this case, Debian (or any organization who isn't big enough not to fear
> M-systems) may not ship the standard kernel because it has additional patent
> restrictions.
Fine. Then get Debian to stop shipping the Linux kernel because the NFTL
and sendfile() code (and maybe others) are covered by patents, and I may
consider taking this seriously.
> There is a clear ability here for the author of the driver and m-systems to
> conspire to retroactively revoke anyones privilege to use, modify, or
> distribute the stock kernel because of this code.
I'll assume for the moment that I'm liable to suffer some form of brain
h?morrhage and go along with this dastardly plan - so enlighten me. How
would I conspire with M-Systems to do so?
--
dwmw2
> I'll assume for the moment that I'm liable to suffer some form of brain
> h=E6morrhage and go along with this dastardly plan - so enlighten me. H=
> ow
> would I conspire with M-Systems to do so?
Not a lot. Even if you joined M-Systems you could make no difference. In fact
as it stands now M-Systems are the one bunch of people in the world who cannot
in fact distribute the code because they would be placing their own restriction
on it or have to grant patent rights ;)