I work for a company that will be developing an embedded Linux based
consumer electronic device.
I believe that new kernel modules will be written to support I/O
peripherals and perhaps other things. I don't know the details right
now. What I am trying to do is get an idea of what requirements there
are to make the source code available under the GPL.
I suspect the company will try to get away with releasing as little as
possible. I don't know much about the GPL or Linux kernel internals,
but I want to encourage the company I work for to give back to the
community.
I understand that modifications to GPL code must be released under the
GPL. So if they tweak a scheduler implementation, this must be
released. What if a new driver is written to support a custom piece
of hardware? Yes, the driver was written to work with the Linux
kernel, but it isn't based off any existing piece of code.
I'm posting anonymously because the company probably wouldn't want me
discussing this at all :(
-anonymouslinuxuser
On Wed, 2006-08-16 at 22:48 -0700, Anonymous User wrote:
> I work for a company that will be developing an embedded Linux based
> consumer electronic device.
>
> I believe that new kernel modules will be written to support I/O
> peripherals and perhaps other things. I don't know the details right
> now. What I am trying to do is get an idea of what requirements there
> are to make the source code available under the GPL.
you should talk to a lawyer, not LKML.
On Thursday 17 August 2006 01:48, Anonymous User wrote:
> I work for a company that will be developing an embedded Linux based
> consumer electronic device.
>
> I believe that new kernel modules will be written to support I/O
> peripherals and perhaps other things. I don't know the details right
> now. What I am trying to do is get an idea of what requirements there
> are to make the source code available under the GPL.
I am not a lawyer, and I suggest your company speak with one before doing
this. (And most likely, someone from the list will correct me if I get
something wrong).
However, your company only has to release any code they use, preferably in the
form of unmodified tarballs (pointing to project websites for downloads isn't
valid anymore) plus patches against said unmodified tarballs if modified. If
not modified, you still have to release the unmodified tarballs.
They don't have to release source code for any module you wrote from scratch
themselves, but said modules cannot say they are GPL (ie, they have to poison
the kernel).
Also, said kernel modules have to be real modules and not statically linked
into the kernel, and said modules have to have the compiled component objects
(ie, *.o) available so people can relink them into new modules to work with
new kernels.
In addition, you probably want to distribute the original source for any file
that uses a kernel API directly so people can fix things if/when the API
changes (which implies using dummy functions that access the kernel API and
call symbols in the closed source objects that do the actual work and form
the bulk of the code).
An example of what to do is what ATI and Nvidia did for their hardware access
modules. An example of what *not* to do is what Broadcom does for their wifi
AP drivers (which are broken on 2.6.x due to API change) and what Linuxant
does for their modem drivers (which are broken on nearly all kernels no
matter the version).
*However*, it would totally rock if your company did GPL any new modules and
send it to Linus; they'd get free patches/code from the community and lots of
karma as well. Having a built-in customer base is never bad...
Also, completely open sourcing the drivers means, if applicable, people can
use the hardware on platforms other than your processor architecture of
choice. ie, lots of people are screwed because of x86 only modules and they
want to run on PPC or Alpha or whatever.
--
Patrick McFarland || http://www.AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989
On Thu, 2006-08-17 at 02:42 -0400, Patrick McFarland wrote:
> On Thursday 17 August 2006 01:48, Anonymous User wrote:
> > I work for a company that will be developing an embedded Linux based
> > consumer electronic device.
> >
> > I believe that new kernel modules will be written to support I/O
> > peripherals and perhaps other things. I don't know the details right
> > now. What I am trying to do is get an idea of what requirements there
> > are to make the source code available under the GPL.
>
> I am not a lawyer, and I suggest your company speak with one before doing
> this. (And most likely, someone from the list will correct me if I get
> something wrong).
>
> However, your company only has to release any code they use, preferably in the
> form of unmodified tarballs (pointing to project websites for downloads isn't
> valid anymore) plus patches against said unmodified tarballs if modified. If
> not modified, you still have to release the unmodified tarballs.
>
> They don't have to release source code for any module you wrote from scratch
> themselves, but said modules cannot say they are GPL (ie, they have to poison
> the kernel).
Just as a warning: This is your own legal opinion/advice, one which is
apparently not shared with many other kernel developers, including me.
For example see Greg's OLS keynote:
http://www.kroah.com/log/2006/07/23/#ols_2006_keynote
or some of Linus' emails on this topic:
http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/kernel/devel/COPYING.modules?rev=1.5
I hope you have talked to a lawyer about your advice, but I sort of
doubt it since your answer doesn't sound like something a lawyer will
tell you (it sure doesn't match what the various lawyers I talked to
told me, not at all)
Anyway the best advice for anyone who asks such a question is to go talk
to a lawyer, and probably he should take a few of those links printed
out with him just to alert the lawyer about the controversial nature of
things.
Greetings,
Arjan van de Ven
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
On Thursday 17 August 2006 02:54, Arjan van de Ven wrote:
> On Thu, 2006-08-17 at 02:42 -0400, Patrick McFarland wrote:
> > On Thursday 17 August 2006 01:48, Anonymous User wrote:
> > > I work for a company that will be developing an embedded Linux based
> > > consumer electronic device.
> > >
> > > I believe that new kernel modules will be written to support I/O
> > > peripherals and perhaps other things. I don't know the details right
> > > now. What I am trying to do is get an idea of what requirements there
> > > are to make the source code available under the GPL.
> >
> > I am not a lawyer, and I suggest your company speak with one before doing
> > this. (And most likely, someone from the list will correct me if I get
> > something wrong).
> >
> > However, your company only has to release any code they use, preferably
> > in the form of unmodified tarballs (pointing to project websites for
> > downloads isn't valid anymore) plus patches against said unmodified
> > tarballs if modified. If not modified, you still have to release the
> > unmodified tarballs.
> >
> > They don't have to release source code for any module you wrote from
> > scratch themselves, but said modules cannot say they are GPL (ie, they
> > have to poison the kernel).
>
> Just as a warning: This is your own legal opinion/advice, one which is
> apparently not shared with many other kernel developers, including me.
> For example see Greg's OLS keynote:
> http://www.kroah.com/log/2006/07/23/#ols_2006_keynote
> or some of Linus' emails on this topic:
> http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/kernel/devel/COPYING.m
>odules?rev=1.5
>
> I hope you have talked to a lawyer about your advice, but I sort of
> doubt it since your answer doesn't sound like something a lawyer will
> tell you (it sure doesn't match what the various lawyers I talked to
> told me, not at all)
Like I told him, he needs to talk to a lawyer. Also, Linus probably won't
agree with me because I said closed source modules are possible. If Linus
wants those to not be possible, then hes going to have to change the
licensing agreement altogether; which, honestly, I wish he would.
Closed source modules are lame, and against the spirit of open source, but
that still doesn't make them against the license.
--
Patrick McFarland || http://www.AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989
On Thu, Aug 17, 2006 at 03:32:51AM -0400, Patrick McFarland wrote:
> On Thursday 17 August 2006 02:54, Arjan van de Ven wrote:
> > On Thu, 2006-08-17 at 02:42 -0400, Patrick McFarland wrote:
> > > On Thursday 17 August 2006 01:48, Anonymous User wrote:
> > > > I work for a company that will be developing an embedded Linux based
> > > > consumer electronic device.
> > > >
> > > > I believe that new kernel modules will be written to support I/O
> > > > peripherals and perhaps other things. I don't know the details right
> > > > now. What I am trying to do is get an idea of what requirements there
> > > > are to make the source code available under the GPL.
> > >
> > > I am not a lawyer, and I suggest your company speak with one before doing
> > > this. (And most likely, someone from the list will correct me if I get
> > > something wrong).
> > >
> > > However, your company only has to release any code they use, preferably
> > > in the form of unmodified tarballs (pointing to project websites for
> > > downloads isn't valid anymore) plus patches against said unmodified
> > > tarballs if modified. If not modified, you still have to release the
> > > unmodified tarballs.
> > >
> > > They don't have to release source code for any module you wrote from
> > > scratch themselves, but said modules cannot say they are GPL (ie, they
> > > have to poison the kernel).
> >
> > Just as a warning: This is your own legal opinion/advice, one which is
> > apparently not shared with many other kernel developers, including me.
> > For example see Greg's OLS keynote:
> > http://www.kroah.com/log/2006/07/23/#ols_2006_keynote
> > or some of Linus' emails on this topic:
> > http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/kernel/devel/COPYING.m
> >odules?rev=1.5
> >
> > I hope you have talked to a lawyer about your advice, but I sort of
> > doubt it since your answer doesn't sound like something a lawyer will
> > tell you (it sure doesn't match what the various lawyers I talked to
> > told me, not at all)
>
> Like I told him, he needs to talk to a lawyer. Also, Linus probably won't
> agree with me because I said closed source modules are possible. If Linus
> wants those to not be possible, then hes going to have to change the
> licensing agreement altogether; which, honestly, I wish he would.
>
> Closed source modules are lame, and against the spirit of open source, but
> that still doesn't make them against the license.
This is _your personal interpretation_ of what consists a "derived work"
under the GPL.
Other people have other opinions on this issue.
Other people even have asked lawyers that said they'd disagree with
interpretations like the one you expressed.
If someone needs advice about the legal risks of kernel modules with a
not GPL compatible licence, he has to ask lawyers knowing the copyright
laws of the countries he plans to distribute his products to.
This is a known grey area that has AFAIK not yet been brought to court
in any country, and neither your personal opinion on this issue nor my
personal opinion on this issue can replace legel advice.
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
(LKML readers please apologize this more or less off-topic posting.)
Patrick McFarland wrote:
> They don't have to release source code for any module you wrote from scratch
> themselves, but said modules cannot say they are GPL (ie, they have to poison
> the kernel).
>
> Also, said kernel modules have to be real modules and not statically linked
> into the kernel, and said modules have to have the compiled component objects
> (ie, *.o) available so people can relink them into new modules to work with
> new kernels.
I never heard that static vs. dynamic linking mattered WRT licensing, at
least if the unmodified GPL is involved. If a driver author doesn't want
to publish under the terms of GPL, an implementation in userspace may
make it possible to avoid linking with GPL code. But in the end, as has
been said multiple times: Consult a lawyer for such questions.
Here are a few pointers to the opinion of FSF as published in their FAQ.
(I doubt that the organization FSF is among the copyright holders of
Linux, but the FSF is copyright holder of the GPL and authors of GPL run
FSF. Therefore the FSF's statements are certainly relevant for you to
consider.)
About so-called modules, or "mere aggregation" versus "combining two
modules into one program" (highly relevant to Linux drivers):
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
About so-called libraries (a lot of parts of Linux are libraries or are
very similar to libraries):
http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL
About so-called plugins (hardly relevant for kernel drivers):
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLAndPlugins
--
Stefan Richter
-=====-=-==- =--- =---=
http://arcgraph.de/sr/
On Thursday 17 August 2006 04:02, Adrian Bunk wrote:
> This is _your personal interpretation_ of what consists a "derived work"
> under the GPL.
> This is a known grey area that has AFAIK not yet been brought to court
> in any country, and neither your personal opinion on this issue nor my
> personal opinion on this issue can replace legel advice.
And I never said anything different. Stop being hostile to other's opinions.
LKML isn't the place for a flamewar.
> cu
> Adrian
--
Patrick McFarland || http://www.AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989
Ar Mer, 2006-08-16 am 22:48 -0700, ysgrifennodd Anonymous User:
> I suspect the company will try to get away with releasing as little as
> possible. I don't know much about the GPL or Linux kernel internals,
> but I want to encourage the company I work for to give back to the
> community.
You should read the GPL license (its fairly plain English). Any matters
of doubt should be discussed with someone qualified to discuss then
(such as a lawyer).
In terms of general policy
- The GPL requires you make source available to your customers by one of
several means (mail in, zip archive on the CD with the manual etc). It
is considered "polite" to also make the changes available publically on
the web somewhere as well.
- There are bodies such as the CE Linux Forum that may be useful to you
and the company.
> I understand that modifications to GPL code must be released under the
> GPL. So if they tweak a scheduler implementation, this must be
> released. What if a new driver is written to support a custom piece
> of hardware? Yes, the driver was written to work with the Linux
> kernel, but it isn't based off any existing piece of code.
Basically if it is a derivative work (see your lawyer). This is a
non-trivial area of law so really you should ask your lawyer not a bunch
of programmers.
Alan
--
"Some people are like Slinkies...
Not really good for anything,
but they still bring a smile to your face
when you push them down a flight of stairs."
-- Gordon Wolfe.
On Thursday 17 August 2006 05:30, Alan Cox wrote:
> Ar Mer, 2006-08-16 am 22:48 -0700, ysgrifennodd Anonymous User:
> > I suspect the company will try to get away with releasing as little as
> > possible. I don't know much about the GPL or Linux kernel internals,
> > but I want to encourage the company I work for to give back to the
> > community.
>
> You should read the GPL license (its fairly plain English). Any matters
> of doubt should be discussed with someone qualified to discuss then
> (such as a lawyer).
(Yes, which I've basically said that about five times now)
> Basically if it is a derivative work (see your lawyer). This is a
> non-trivial area of law so really you should ask your lawyer not a bunch
> of programmers.
It's still important for programmers to understand licenses well. Maybe Linus
needs to put up a page somewhere detailing, in plain, yet non-legally
binding, English, what you can and cannot do.
Of course, this wouldn't be even an issue if companies understood how Linux,
operating system drivers, and computers historically work instead of having
to screw everything up with all these new ways new ways of screwing people
with IP rights and unwarrented paranoia.
Side question, would it ever be possible, with GPL code, to make modules and
plugins of non-GPL compatible origin a license violation? Would this be a
good idea for the kernel?
> Alan
--
Patrick McFarland || http://www.AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989
On Thursday 17 August 2006 04:32, Stefan Richter wrote:
> Patrick McFarland wrote:
> > They don't have to release source code for any module you wrote from
> > scratch themselves, but said modules cannot say they are GPL (ie, they
> > have to poison the kernel).
> >
> > Also, said kernel modules have to be real modules and not statically
> > linked into the kernel, and said modules have to have the compiled
> > component objects (ie, *.o) available so people can relink them into new
> > modules to work with new kernels.
>
> I never heard that static vs. dynamic linking mattered WRT licensing, at
> least if the unmodified GPL is involved.
AFAICT you can't link GPL to non-GPL code and ship the product without heading
deep into grey area territory. Both the GPL and LGPL has specific wording for
certain cases (such as allowing LGPL (possibly GPL too?) to link to closed
source system libraries and the reverse as well), but its really icky to link
GPL to closed source code in any form.
> If a driver author doesn't want
> to publish under the terms of GPL, an implementation in userspace may
> make it possible to avoid linking with GPL code.
But doesn't that force the GPL code to rely on closed source code, and not
function properly without it? I remember a part in the GPL about not allowing
that, but I can't seem to find it atm.
> Here are a few pointers to the opinion of FSF as published in their FAQ.
> (I doubt that the organization FSF is among the copyright holders of
> Linux, but the FSF is copyright holder of the GPL and authors of GPL run
> FSF. Therefore the FSF's statements are certainly relevant for you to
> consider.)
Now thats pretty useful information. I think everyone should bookmark those
and file those away for later, I sure am. Thanks for finding those.
--
Patrick McFarland || http://www.AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989
On Thu, 2006-08-17 at 02:42 -0400, Patrick McFarland wrote:
> They don't have to release source code for any module you wrote from scratch
> themselves, but said modules cannot say they are GPL (ie, they have to poison
> the kernel).
If you're distributing a product which contains both the kernel and some
modules, then there is a more important (or at least a more clear-cut)
caveat to bear in mind than the question of whether the module in itself
is a derived work.
Read section 2 of the GPL carefully:
"These requirements apply to the modified work as a whole. 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."
That's what Patrick is referring to, presumably, (and he's assuming that
your module would _not_ be derived from the kernel, which many people
are already disputing).
However, do not let that debate distract you from the fact that the GPL
continues as follows:
"But when you distribute the same sections as part of a whole
which is a work based on the Program, the distribution of the
whole must be on the terms of this License, whose permissions
for other licensees extend to the ENTIRE WHOLE, and thus to EACH
AND EVERY PART REGARDLESS OF WHO WROTE IT."
So when you distribute a product which combines the kernel and some
driver module, and which isn't 'mere aggregation on a storage medium'
but is actually a coherent whole which works together and wouldn't
function correctly if either the kernel or the module were missing, then
your module _must_ be released under the terms of the GPL too.
This is entirely separate to the question of whether the module should
be considered a derived work in itself -- if we consider the module a
derived work (as I personally do), then of course you must release the
module's source under the terms of the GPL, whatever happens.
But _even_ if GregKH, Arjan and all of IBM's lawyers are wrong and we
don't consider the module a derived work, then you may release the
module without source _only_ if you do so on its _own_ ("as separate
works"), and not as part of a product which also contains a Linux
kernel.
--
dwmw2
Arjan van de Ven <[email protected]> uttered the following thing:
> On Wed, 2006-08-16 at 22:48 -0700, Anonymous User wrote:
> > I believe that new kernel modules will be written to support I/O
> > peripherals and perhaps other things. I don't know the details right
> > now. What I am trying to do is get an idea of what requirements there
> > are to make the source code available under the GPL.
>
>
> you should talk to a lawyer, not LKML.
Minor gripe here...
Whilst it's true that a lawyer should get involved with these things, I
think it's also perfectly reasonable for someone to ask for input from
LKML, /. or other interesting places.
OP may already be planning to speak to a lawyer, and just wants to take
tidbits of info/experiences/etc from others to help the lawyer's
research.
BB
Ar Iau, 2006-08-17 am 05:36 -0400, ysgrifennodd Patrick McFarland:
> > If a driver author doesn't want
> > to publish under the terms of GPL, an implementation in userspace may
> > make it possible to avoid linking with GPL code.
>
> But doesn't that force the GPL code to rely on closed source code, and not
> function properly without it? I remember a part in the GPL about not allowing
> that, but I can't seem to find it atm.
It shouldn't generally be a grey area but that is why the Linux kernel
has always had this clarification in COPYING about the interpretation
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.
On Thursday August 17, [email protected] wrote:
> Ar Iau, 2006-08-17 am 05:36 -0400, ysgrifennodd Patrick McFarland:
> > > If a driver author doesn't want
> > > to publish under the terms of GPL, an implementation in userspace may
> > > make it possible to avoid linking with GPL code.
> >
> > But doesn't that force the GPL code to rely on closed source code, and not
> > function properly without it? I remember a part in the GPL about not allowing
> > that, but I can't seem to find it atm.
>
> It shouldn't generally be a grey area but that is why the Linux kernel
> has always had this clarification in COPYING about the interpretation
>
> 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.
Hmmm. I wonder what "normal" system calls are. And how they contrast
to "abnormal" system calls, which presumably aren't covered by the
above note.
I wonder if reading and writing to files in /sys and /proc are
'normal' in this context or not. Certainly I think that non-standard
ioctls could be considered to abnormal.
I guess that's one for the lawyers :-)
NeilBrown
On Thu, 17 Aug 2006, Ben B wrote:
> Arjan van de Ven <[email protected]> uttered the following thing:
>> On Wed, 2006-08-16 at 22:48 -0700, Anonymous User wrote:
>>> I believe that new kernel modules will be written to support I/O
>>> peripherals and perhaps other things. I don't know the details right
>>> now. What I am trying to do is get an idea of what requirements there
>>> are to make the source code available under the GPL.
>>
>>
>> you should talk to a lawyer, not LKML.
>
> Minor gripe here...
>
> Whilst it's true that a lawyer should get involved with these things, I
> think it's also perfectly reasonable for someone to ask for input from
> LKML, /. or other interesting places.
>
> OP may already be planning to speak to a lawyer, and just wants to take
> tidbits of info/experiences/etc from others to help the lawyer's
> research.
>
> BB
"Talk to a lawyer..." Good copout. I have talked to lawyers
about Linux, GPL, etc. "Don't touch that stuff with a 10-foot
pole," is the response. A couple years ago, I was all set to
make some very smart WiFi routers using Linux in a closely-held
company that I had invested in. We built prototypes and were
performing measurements for FCC approval. After buying a $15k
spectrum analyzer, we needed more money to advertise and start
production. A quick trip to a lawyer queered the deal. Undaunted,
we went to another lawyer with another investor. We couldn't get
any funding and had to give it up. Then Linksys got into that
area and you know the rest. We had a two-year head start.
Fortunately we didn't give up the "day jobs".
It's all about managing risk. Lawyers want to minimize risk,
accountants want to eliminate risk, engineers want to analyze
risk, and entrepreneurs want to manage risk. Software engineers
have a better "handle" on the risk analysis than the lawyers.
Let them be heard.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.62 BogoMips).
New book: http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Thu, 17 Aug 2006, Adrian Bunk wrote:
> On Thu, Aug 17, 2006 at 03:32:51AM -0400, Patrick McFarland wrote:
>> Closed source modules are lame, and against the spirit of open source, but
>> that still doesn't make them against the license.
>
> This is _your personal interpretation_ of what consists a "derived work"
> under the GPL.
>
> Other people have other opinions on this issue.
>
> Other people even have asked lawyers that said they'd disagree with
> interpretations like the one you expressed.
Right.
Then why not make some official and only right interpretation of what is
derived work for GPL2 in Linux and what is not, make it part of license or
COPYING file and end this type questions, doubts and flamewars once for
ever?
Why does Linus and others let lawyers and courts decide in such
(important?) thing like what is allowed in Linux (or with Linux) and what
is not?
Why not be brave, make the decission (preferably as liberal as possible)
and end all of this instead of letting others decide (worse: letting
others decide based on different and changing local, national rights and
probably also on who is paying them)?
If it would mean changing Linux license (and getting every contributor
agreement) then it could be made at least as a clear comment ("What is and
what is not derived work for GPL2 in Linux kernel in opinion of main Linux
kernel developers?") in the begining of the COPYING file, signed by most
important kernel developers (that produced 99% of the code and headers
used or touched by controversial modules anyway).
Thanks,
Grzegorz Kulewski
Ar Iau, 2006-08-17 am 14:39 +0200, ysgrifennodd Grzegorz Kulewski:
> Why does Linus and others let lawyers and courts decide in such
> (important?) thing like what is allowed in Linux (or with Linux) and what
> is not?
Because licenses are bounded and defined by the law. In the case of
copyright based rights they extend only to the thing that is copyrighted
and any derivatives so the grey area is not one the GPL could clarify
further.
Alan
On Thu, 17 Aug 2006, Alan Cox wrote:
> Ar Iau, 2006-08-17 am 14:39 +0200, ysgrifennodd Grzegorz Kulewski:
>> Why does Linus and others let lawyers and courts decide in such
>> (important?) thing like what is allowed in Linux (or with Linux) and what
>> is not?
>
> Because licenses are bounded and defined by the law. In the case of
> copyright based rights they extend only to the thing that is copyrighted
> and any derivatives so the grey area is not one the GPL could clarify
> further.
Ok, that could be a reason. But then at least make such strong comment as
proposed later in my post and put it where people will be searching for it
- in COPYING file. Even if it will not be legally enforceable, it will
show the intentions of main authors and will anwser many people
questions.
Grzegorz Kulewski
Anonymous User wrote:
> I work for a company that will be developing an embedded Linux based
> consumer electronic device.
>
> I believe that new kernel modules will be written to support I/O
> peripherals and perhaps other things. I don't know the details right
> now. What I am trying to do is get an idea of what requirements there
> are to make the source code available under the GPL.
>
> I suspect the company will try to get away with releasing as little as
> possible. I don't know much about the GPL or Linux kernel internals,
> but I want to encourage the company I work for to give back to the
> community.
Try to make them releasing more, pointing out that
holding onto almost anything concerning the kernel could
be dangerous for them. They can keep the userspace
part secret if they have to, of course.
>
> I understand that modifications to GPL code must be released under the
> GPL. So if they tweak a scheduler implementation, this must be
> released.
Correct.
> What if a new driver is written to support a custom piece
> of hardware? Yes, the driver was written to work with the Linux
> kernel, but it isn't based off any existing piece of code.
If the driver supports your custom piece of hardware, then you can
safely release the driver. Your competitors don't have that
hardware, after all. Releasing the driver can only increase sales,
because then customers know that the driver will be available
and fixable even if your company should stop supporting it sometime.
(Happens when companies die, and often when they release newer hardware.)
Smart customers think like this, and skip the closed stuff.
Remember, you don't make money from selling software. You make it
from selling hardware. Open free drivers will sell more hardware - simple!
> I'm posting anonymously because the company probably wouldn't want me
> discussing this at all :(
Sad.
Helge Hafting
On 8/16/06, Anonymous User <[email protected]> wrote:
> I work for a company that will be developing an embedded Linux based
> consumer electronic device.
>
> I believe that new kernel modules will be written to support I/O
> peripherals and perhaps other things. I don't know the details right
> now. What I am trying to do is get an idea of what requirements there
> are to make the source code available under the GPL.
>
> I suspect the company will try to get away with releasing as little as
> possible. I don't know much about the GPL or Linux kernel internals,
> but I want to encourage the company I work for to give back to the
> community.
>
> I understand that modifications to GPL code must be released under the
> GPL. So if they tweak a scheduler implementation, this must be
> released. What if a new driver is written to support a custom piece
> of hardware? Yes, the driver was written to work with the Linux
> kernel, but it isn't based off any existing piece of code.
>
> I'm posting anonymously because the company probably wouldn't want me
> discussing this at all :(
Thanks to everyone who has responded to my question so far.
It seems like the two issues that need to be addressed are:
1) Are the kernel modules being developed derived works? If they are,
they must be released along with the entire kernel source.
2) If they are not derived works, and shipped in a product, does the
fact that they are shipped in a product that uses the linux kernel
require that the new modules be licensed under the GPL?
Yes, I agree that the company I work for should talk to a lawyer. I
however, am not interested in picking up a big legal tab to satisfy my
curiosity.
On Thu, Aug 17, 2006 at 03:31:53PM +0200, Grzegorz Kulewski wrote:
> Ok, that could be a reason. But then at least make such strong comment as
> proposed later in my post and put it where people will be searching for it
> - in COPYING file. Even if it will not be legally enforceable, it will
> show the intentions of main authors and will anwser many people
> questions.
That assumes that the "main authors" want to spend time debating the
point and making an official statement --- one that might not be held
up in a court of law, afterwards. And in fact it assumes people want
to waste time discussing this further in LKML, as well.
When I asked the question of my IP Law professor when I was taking
some classes at the Sloan School of Management 12 years ago, in his
opinion a claim that the GPL could infect across a dynamic link would
be "laughed out of court". But that wasn't legal advice, and there
hasn't been legal precedent, and while as far as I know no court has
ruled directly on that point in the past 12 years, there may be others
that would cause a lawyer to be more or less certain about what might
happen should it ever go to court. However, I am not a lawyer, and
neither are most people on this list. Hence Alan's advice, "go see a
lawyer"; a lawyer will listen to the facts of your situation, apply it
to the law as it currently exists in a particular time and place, and
tender you legal advice.
But regardless of whether or not it is legal, a better and more
stronger argument is that companies that try to use proprietary binary
modules will not be able to service their customers as effectively,
and thus be at a competitive disadvantage. From a code maintenance,
and future-proofing point of view, you really, really, really want to
have your device drivers in mainline. In my opinion, the legal
arguments are only good for wasting bandwidth on mailing lists.
- Ted
Anonymous User wrote:
> Thanks to everyone who has responded to my question so far.
>
> It seems like the two issues that need to be addressed are:
> 1) Are the kernel modules being developed derived works? If they are,
> they must be released along with the entire kernel source.
> 2) If they are not derived works, and shipped in a product, does the
> fact that they are shipped in a product that uses the linux kernel
> require that the new modules be licensed under the GPL?
If you refer to "kernel modules" in the commonly used sense of the term,
i.e. modules that are linked into the kernel's address space and use its
symbols, then at least the FSF's lawyers' interpretation of the GPL is
unmistakable.
--
Stefan Richter
-=====-=-==- =--- =---=
http://arcgraph.de/sr/
linux-os (Dick Johnson) wrote:
> "Talk to a lawyer..." Good copout.
[...]
> It's all about managing risk. Lawyers want to minimize risk,
> accountants want to eliminate risk, engineers want to analyze
> risk, and entrepreneurs want to manage risk. Software engineers
> have a better "handle" on the risk analysis than the lawyers.
> Let them be heard.
You can do reliability analysis in mechanics (given the necessary data
are available). But you can't do so in jurisprudence. There are
differences between jurisprudence and mathematics and physics.
Of course somebody doesn't need to consult lawyers if he doesn't have
doubts about his compliance to law or if he can live with any such
doubts. The original poster seemed to want to clear up doubts.
--
Stefan Richter
-=====-=-==- =--- =---=
http://arcgraph.de/sr/
Anonymous User wrote:
> On 8/16/06, Anonymous User <[email protected]> wrote:
>> I work for a company that will be developing an embedded Linux based
>> consumer electronic device.
>>
>> I believe that new kernel modules will be written to support I/O
>> peripherals and perhaps other things. I don't know the details right
>> now. What I am trying to do is get an idea of what requirements there
>> are to make the source code available under the GPL.
>>
>> I suspect the company will try to get away with releasing as little as
>> possible. I don't know much about the GPL or Linux kernel internals,
>> but I want to encourage the company I work for to give back to the
>> community.
>>
>> I understand that modifications to GPL code must be released under the
>> GPL. So if they tweak a scheduler implementation, this must be
>> released. What if a new driver is written to support a custom piece
>> of hardware? Yes, the driver was written to work with the Linux
>> kernel, but it isn't based off any existing piece of code.
>>
>> I'm posting anonymously because the company probably wouldn't want me
>> discussing this at all :(
>
>
> Thanks to everyone who has responded to my question so far.
>
> It seems like the two issues that need to be addressed are:
> 1) Are the kernel modules being developed derived works? If they are,
> they must be released along with the entire kernel source.
> 2) If they are not derived works, and shipped in a product, does the
> fact that they are shipped in a product that uses the linux kernel
> require that the new modules be licensed under the GPL?
>
> Yes, I agree that the company I work for should talk to a lawyer. I
> however, am not interested in picking up a big legal tab to satisfy my
> curiosity.
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I suggest you take a look at http://gpl-violations.org/
Regards, Michiel de Boer
Arjan van de Ven wrote:
> On Wed, 2006-08-16 at 22:48 -0700, Anonymous User wrote:
>> I work for a company that will be developing an embedded Linux based
>> consumer electronic device.
>>
>> I believe that new kernel modules will be written to support I/O
>> peripherals and perhaps other things. I don't know the details right
>> now. What I am trying to do is get an idea of what requirements there
>> are to make the source code available under the GPL.
>
>
> you should talk to a lawyer, not LKML.
>
The easiest, no need to talk to a lawyer, most economical, way out of
this is to simply make all source code open and published under the GPL
or GPL compatible license with the appropriate "signed-off" entries.
As soon as you start trying to release some part of it as binary code,
then lawyers have to be involved and that tends to cost a lot more.
People on this list are NOT lawyers, so don't ask about that option on
this list.
>From the business perspective, it is likely to be far more profitable to
deliver an open source GPL licensed product to market, as you are then
likely to get a lot of free development effort work done for you by your
users.
James
James Courtier-Dutton wrote:
> Arjan van de Ven wrote:
>> On Wed, 2006-08-16 at 22:48 -0700, Anonymous User wrote:
>>> I work for a company that will be developing an embedded Linux based
>>> consumer electronic device.
>>>
>>> I believe that new kernel modules will be written to support I/O
>>> peripherals and perhaps other things. I don't know the details right
>>> now. What I am trying to do is get an idea of what requirements there
>>> are to make the source code available under the GPL.
>>
>> you should talk to a lawyer, not LKML.
>>
>
> The easiest, no need to talk to a lawyer, most economical, way out of
> this is to simply make all source code open and published under the GPL
> or GPL compatible license with the appropriate "signed-off" entries.
>
> As soon as you start trying to release some part of it as binary code,
> then lawyers have to be involved and that tends to cost a lot more.
>
> People on this list are NOT lawyers, so don't ask about that option on
> this list.
>
>>From the business perspective, it is likely to be far more profitable to
> deliver an open source GPL licensed product to market, as you are then
> likely to get a lot of free development effort work done for you by your
> users.
Well...
The problem is that in many cases AIUI, a large entry barrier to
someone taking CPU A, chip B, sticking it in a box, and selling
it, is that there is no linux driver for chip B.
If you (as someone who does not make chip B) release the GPL'd
driver, then you're making it a fair bit easier for competitors,
who can now simply copy your often not very novel in any way
other than you thought of it first - design, and use that driver.
On Fri, 18 Aug 2006 00:26:59 +0100
Ian Stirling <[email protected]> wrote:
> Well...
> The problem is that in many cases AIUI, a large entry barrier to
> someone taking CPU A, chip B, sticking it in a box, and selling
> it, is that there is no linux driver for chip B.
> If you (as someone who does not make chip B) release the GPL'd
> driver, then you're making it a fair bit easier for competitors,
> who can now simply copy your often not very novel in any way
> other than you thought of it first - design, and use that driver.
>
That seems like a very reasonable price to pay for the ability to
use all the work of the many developers who created Linux in the
first place. There are other operating systems available to use
if you're not happy with such a deal.
Sean
David Woodhouse wrote:
<snip>
> So when you distribute a product which combines the kernel and some
> driver module, and which isn't 'mere aggregation on a storage medium'
> but is actually a coherent whole which works together and wouldn't
> function correctly if either the kernel or the module were missing, then
> your module _must_ be released under the terms of the GPL too.
'function correctly' ?
As what?
I've bought a number of devices that I know will not have all the
advertised features available to me, because I install a different
version of linux on them.
It functions correctly, as delivered.
With the appropriate disclaimers on the box, it cannot function
incorrectly, as you will know that the thumb-print reader won't
work if you upgrade the kernel, and if you intend to do so,
you don't buy.
I've got a number of wireless routers that I don't have working
drivers for the wifi cards, happily wired into my network doing
things that they were not intended for, but they are functioning
'correctly' as I see it.
Ar Gwe, 2006-08-18 am 00:26 +0100, ysgrifennodd Ian Stirling:
> If you (as someone who does not make chip B) release the GPL'd
> driver, then you're making it a fair bit easier for competitors,
> who can now simply copy your often not very novel in any way
> other than you thought of it first - design, and use that driver.
If your product differentiator is "used a different ten cent ethernet
chip" then remind me no to buy your stock 8)
What many vendors have found is the fact that they can support chip B
under Linux by copying an existing driver and changing small parts of it
is far more important.
Alan
On Thursday 17 August 2006 08:41, Alan Cox wrote:
> Ar Iau, 2006-08-17 am 14:39 +0200, ysgrifennodd Grzegorz Kulewski:
> > Why does Linus and others let lawyers and courts decide in such
> > (important?) thing like what is allowed in Linux (or with Linux) and what
> > is not?
>
> Because licenses are bounded and defined by the law. In the case of
> copyright based rights they extend only to the thing that is copyrighted
> and any derivatives so the grey area is not one the GPL could clarify
> further.
>
IANAL, but I think there are 2 cases here:
1. The courts decide what "derived works" are when someone distributes code
that they wrote. So if NVIDIA writes nvidia.ko, the courts will decide if
nvidia.ko is a derived work.
2. However, the only valid license under which to distribute the Linux kernel
is GPL. If the GPL prohibits linking in non-GPL code, and Linux adds no
exception, then one clearly has no license to distribute Linux if they
distribute it alongside code that links in to Linux and does not carry the
GPL license. If they were just shipping binary modules, it's questionable
grey area. But if they distribute _Linux itself_, especially considering they
haven't paid for it (and hence have no 'natural' rights), they must comply
with the GPL and the GPL's definitions of its terms, else they have no
license at all to distribute Linux and are in violation of copyright.
NVIDIA might be able to skate closer to the cracks because they do not
distribute the Linux kernel. NVIDIA couldn't ship NVIDIA Linux with the
binary-only driver. TiVo has to obey the GPL to distribute Linux, so does
Linksys, etc. In the embedded case, you're distributing the kernel which
means you must execute whatever conditions GPL chooses to impose.
Thanks,
Chase
On Fri, 2006-08-18 at 01:26, Ian Stirling wrote:
> Well...
> The problem is that in many cases AIUI, a large entry barrier to
> someone taking CPU A, chip B, sticking it in a box, and selling
> it, is that there is no linux driver for chip B.
> If you (as someone who does not make chip B) release the GPL'd
> driver, then you're making it a fair bit easier for competitors,
> who can now simply copy your often not very novel in any way
> other than you thought of it first - design, and use that driver.
Well, AFAIK that's *exactely* the kind of behavior the GPL was made to
avoid. No wonder you should talk to a lawyer if you want to circumvent
it.
Xav
On Fri, 2006-08-18 at 00:45 +0100, Ian Stirling wrote:
> With the appropriate disclaimers on the box, it cannot function
> incorrectly, as you will know that the thumb-print reader won't
> work if you upgrade the kernel, and if you intend to do so,
> you don't buy.
As far as I can tell, the GPL does not contain the text "if you are
shipping a commercial product don't really want to comply with this
licence, you can just put a disclaimer on the box of your product and
that's OK instead".
> I've got a number of wireless routers that I don't have working
> drivers for the wifi cards, happily wired into my network doing
> things that they were not intended for, but they are functioning
> 'correctly' as I see it.
Both are fairly clear examples of GPL violations. The manufacturer has
_not_ granted you the freedom to copy, modify and distribute all the
Linux-based code in the device, as is required by the GPL.
--
dwmw2
On Fri, 2006-08-18 at 00:45 +0100, Ian Stirling wrote:
[...]
> With the appropriate disclaimers on the box, it cannot function
> incorrectly, as you will know that the thumb-print reader won't
Providing that a judge doesn't rule otherwise in court based on local
laws. And judges rule (most of the time) also based on common sense
(e.g. if you buy a copy-protected music CD/DVD and you cannot play it on
an ordinary CD/DVD player, the CD/DVD is "broken" and must be replaced
by the shop where you bought it or you get your money back returning the
defective CD/DVD).
And yes, there are (lots of other) issues you can't legally remove with
any disclaimer (at least in .at - and probably more continental European
countries).
> work if you upgrade the kernel, and if you intend to do so,
> you don't buy.
If you tamper with the product "as you like" (read: in unintended ways,
not through officially available interfaces, etc.), there are IMHO
(in .at) no disclaimers necessary - the producer has no responsibility
any more from the moment you start tampering.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Fri, 2006-08-18 at 10:53 +0200, Bernd Petrovitsch wrote:
> If you tamper with the product "as you like" (read: in unintended
> ways, not through officially available interfaces, etc.), there are
> IMHO (in .at) no disclaimers necessary - the producer has no
> responsibility any more from the moment you start tampering.
No responsibility under warranty, I agree. But that's entirely
irrelevant to the discussion at hand, as far as I can tell.
Your tampering does _not_ mean that they no longer have to comply with
the licence terms of the software they've shipped on the device. If it's
Windows, they still need to pay Microsoft for it. And if it's Linux they
still need to release all the relevant source code.
--
dwmw2
Ian Stirling wrote:
>
> Well...
> The problem is that in many cases AIUI, a large entry barrier to
> someone taking CPU A, chip B, sticking it in a box, and selling
> it, is that there is no linux driver for chip B.
> If you (as someone who does not make chip B) release the GPL'd
> driver, then you're making it a fair bit easier for competitors,
> who can now simply copy your often not very novel in any way
> other than you thought of it first - design, and use that driver.
Which is why the maker of chip B would do very well to make a basic
linux driver - perhaps not novel in any way, but now everybody want to
use B chips because it comes with working software.
And if linux powered gadgets with chip B becomes popular, surely
someone pick up the simple driver and improves it too.
Helge Hafting
On Fri, 2006-08-18 at 10:04 +0100, David Woodhouse wrote:
> On Fri, 2006-08-18 at 10:53 +0200, Bernd Petrovitsch wrote:
> > If you tamper with the product "as you like" (read: in unintended
> > ways, not through officially available interfaces, etc.), there are
> > IMHO (in .at) no disclaimers necessary - the producer has no
> > responsibility any more from the moment you start tampering.
>
> No responsibility under warranty, I agree. But that's entirely
And there are several other aspects (at least in .at).
> irrelevant to the discussion at hand, as far as I can tell.
OK.
> Your tampering does _not_ mean that they no longer have to comply with
> the licence terms of the software they've shipped on the device. If it's
Of course (sorry, that was apparently not enough).
> Windows, they still need to pay Microsoft for it. And if it's Linux they
> still need to release all the relevant source code.
Probably more on-topic:
We have law people in .at who think/propose/have the opinion that one
entity as seen by the user/consumer has one license. So if you pack a
GPL program on it, the whole entity is GPL.
Given the current common method of providing one firmware image per
device for download to upgrade/bugfix, the producer of that image must
adhere to the GPL for *all+ of the source code of that image (+
necessary toolchain etc.).
The reasoning is: The user/consumer sees one thing and that's it.
If such an interpretation is "good" or "bad" (and for whom) is another
question.
The counter strategies to work around that are probably obvious.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Combined responses.
> They don't have to release source code for any module you wrote
> from scratch
> themselves, but said modules cannot say they are GPL (ie, they
> have to poison
> the kernel).
Nonsense! You absolutely positively can lie about copyright (and even take
what would otherwise be protected by copyright) if the copyright notice or
statement itself is functional.
Otherwise, for example, a printer by Lexmark could require a poem with the
words 'Copyright, Lexmark Inc.' at the end to be in a chip in the printer
cartridge and refuse to work if it wasn't there. This would, if enforceable,
prevent anyone from making compatible cartridges.
The GPL notices that the Linux kernel uses to decide whether to taint or
allow access to GPL'd symbols are functional. The GPL prohibits the Linux
kernel from containing any license enforcement schemes (so do not even try
to argue that this is circumventing a license enforcement scheme). Which GPL
provision is being enforced?!
This is also true under the doctrine of scenes a faire, which basically
says, "when specific instructions are the only and essential means of
accomplishing a given task, their later use by another will not amount to
infringement" so if claiming you are GPL'd is the only way to accomplish a
given task (such as loading a module without poisoning the kernel), you
cannot use copyright to prevent the use of the instructions. (Similarly, if
taking the Linux kernel headers is the only practical way to make a Linux
kernel module, you can do so. Copyright does not cover the only way to
express an idea.)
IANAL. You should consult one if this matters to you in any significant
way.
Another caveat: If you need to access symbols marked GPL_ONLY, it is quite
likely that your module is in fact a derived work from the Linux kernel (as
it will contain details of its internals and not work without it). So you
wouldn't be able to distribute it without complying with the GPL anyway.
(There are legal arguments around this, mostly scenes a faire again, but you
would probably be quite foolish to rely on them as they are untested,
AFAIK.)
>It seems like the two issues that need to be addressed are:
>1) Are the kernel modules being developed derived works? If they are,
>they must be released along with the entire kernel source.
>2) If they are not derived works, and shipped in a product, does the
>fact that they are shipped in a product that uses the linux kernel
>require that the new modules be licensed under the GPL?
To 2, the answer is (I think) definitely no if you don't link anything
together on the medium, probably no if you do. It is my position that any
non-creative combination process is legally equivalent to mere aggregation,
with only a few specific exceptions set by statute. That is, linking two
works together does not create "a work" but two works that are linked
together. Therefore, it cannot create a derivative work, but two works each
with their own license. (Just like an ISO file of a CD with both GPL'd and
BSD-licensed code on it.)
To 1, the answer is that it's very hard to tell. My opinion is that it
almost definitely is notm assuming it doesn't include code taken from the
Linux kernel that isn't reasonably necessary to accomplish its function.
However, I strongly suggest that you try to convince the powers that be
that are they looking at this totally the wrong way. I don't know their
circumstances in enough detail to help you, but in many cases, releasing
more is more sensible than releasing less. Some of the benefits include more
value to the purchaser, the purchaser can contribute improvements back, the
purchaser can maintain the code. Goodwill is huge too. Also, there are a lot
of people on this list whose recommendation of your product may well hinge
on whether you are seen as predatory or cooperative.
If your company is not very well-known and your product is expensive,
knowing that I can maintain your product yourself may mean the difference
between being willing to pay for it and not willing to risk obsolesence. If
the product is at all aimed at experimenters, having the driver code makes
much more experimentation possible, increasing the value of your product.
Depending on the circumstances, many more such arguments may be made.
>However, the only valid license under which to distribute the Linux kernel
>is GPL. If the GPL prohibits linking in non-GPL code, and Linux adds no
>exception, then one clearly has no license to distribute Linux if they
>distribute it alongside code that links in to Linux and does not carry the
>GPL license.
The GPL cannot set its own scope and here you ask it to do just that. If
the GPL could specify how you could *use* covered works, then I could drop a
million copies of a poem from an airplane with a license that said anyone
had to pay me $25 if they read it.
>Both are fairly clear examples of GPL violations. The manufacturer has
>_not_ granted you the freedom to copy, modify and distribute all the
>Linux-based code in the device, as is required by the GPL.
Again, it doesn't matter what the GPL requires when the question is what is
or is not covered by the GPL. The GPL cannot set its own scope. The device
is not a work, it's an aggregation of multiple works and nothing requires
(or could require) they all be under the same license.
DS
Xavier Bestel wrote:
> On Fri, 2006-08-18 at 01:26, Ian Stirling wrote:
>
>> Well...
>> The problem is that in many cases AIUI, a large entry barrier to
>> someone taking CPU A, chip B, sticking it in a box, and selling
>> it, is that there is no linux driver for chip B.
>> If you (as someone who does not make chip B) release the GPL'd
>> driver, then you're making it a fair bit easier for competitors,
>> who can now simply copy your often not very novel in any way
>> other than you thought of it first - design, and use that driver.
>
> Well, AFAIK that's *exactely* the kind of behavior the GPL was made to
> avoid. No wonder you should talk to a lawyer if you want to circumvent
> it.
Oops. I forgot to add at the end - 'of course, you should also consider
that you've saved a lot of time/money using linux..., so I'm utterly
agreeing with you/...
David Woodhouse wrote:
> On Fri, 2006-08-18 at 00:45 +0100, Ian Stirling wrote:
>> With the appropriate disclaimers on the box, it cannot function
>> incorrectly, as you will know that the thumb-print reader won't
>> work if you upgrade the kernel, and if you intend to do so,
>> you don't buy.
>
> As far as I can tell, the GPL does not contain the text "if you are
> shipping a commercial product don't really want to comply with this
> licence, you can just put a disclaimer on the box of your product and
> that's OK instead".
Sorry, I was tired, and misread that you were making the
'not merely an archive' point as an argument for why the module
was a derived work, which makes little sense.
Ar Gwe, 2006-08-18 am 02:51 -0700, ysgrifennodd David Schwartz:
> Otherwise, for example, a printer by Lexmark could require a poem with the
> words 'Copyright, Lexmark Inc.' at the end to be in a chip in the printer
> cartridge and refuse to work if it wasn't there. This would, if enforceable,
> prevent anyone from making compatible cartridges.
True once upon a time (and people did this for IBM clone PC systems when
IBM tried that in graphics cards)
Once the phrase "Copyright, Lexamrk Inc." is checked to ascertain
permissions you are in the world of the EUCD and DMCA. You are
subverting a rights management system which places you on interestingly
vague ground.
EXPORT_SYMBOL_GPL is clearly a rights management systems. Thats one of
its little charms.
Alan
On Thu, Aug 17, 2006 at 05:03:03AM -0400, Patrick McFarland wrote:
> On Thursday 17 August 2006 04:02, Adrian Bunk wrote:
> > This is _your personal interpretation_ of what consists a "derived work"
> > under the GPL.
> > This is a known grey area that has AFAIK not yet been brought to court
> > in any country, and neither your personal opinion on this issue nor my
> > personal opinion on this issue can replace legel advice.
>
> And I never said anything different. Stop being hostile to other's opinions.
> LKML isn't the place for a flamewar.
You said:
<-- snip -->
Closed source modules are lame, and against the spirit of open source, but
that still doesn't make them against the license.
<-- snip -->
And exactly the question whether modules with not GPL compatible
licences are against the license is the grey area.
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
> Ar Gwe, 2006-08-18 am 02:51 -0700, ysgrifennodd David Schwartz:
Re the DMCA issues with printers, courts seem to be holding that the rights
management system has to enforce an actual right. Since a printer
manufacturer has no right to limit you to cartridges he makes, the DMCA does
not apply. (This would be very good if more courts would hold it more
consistenly on other issues as well. Sadly, that may not be happening.)
> EXPORT_SYMBOL_GPL is clearly a rights management systems. Thats one of
> its little charms.
No, it is not. If it was, it would violate the GPL. The GPL prohibits any
restrictions not contained in the GPL, and the GPL doesn't say anything
about EXPORT_SYMBOL_GPL. To the contrary, the GPL prohibits restrictions on
use. So EXPORT_SYMBOL_GPL violates the GPL if you are not free to circumvent
or remove it.
We had this same discussion a few years ago, and my recollection was that
you agreed that EXPORT_SYMBOL_GPL could not be a license enforcement scheme.
Which term of the GPL do you think it enforces exactly?
Whose rights does it enforce? (Considering that nobody has the right to
prevent me from using the Linux kernel with an undistributed derivative work
that is not covered by the GPL.)
DS
David Schwartz wrote:
>> Ar Gwe, 2006-08-18 am 02:51 -0700, ysgrifennodd David Schwartz:
>> EXPORT_SYMBOL_GPL is clearly a rights management systems. Thats one of
>> its little charms.
>
> No, it is not. If it was, it would violate the GPL. The GPL prohibits any
> restrictions not contained in the GPL, and the GPL doesn't say anything
> about EXPORT_SYMBOL_GPL. To the contrary, the GPL prohibits restrictions on
> use. So EXPORT_SYMBOL_GPL violates the GPL if you are not free to circumvent
> or remove it.
>
> We had this same discussion a few years ago, and my recollection was that
> you agreed that EXPORT_SYMBOL_GPL could not be a license enforcement scheme.
> Which term of the GPL do you think it enforces exactly?
I thought the EXPORT_SYMBOL_GPL had a role in rights _management_ insofar as it
would shows that anyone circumventing it took a conscious act to do so. This may
or may not be valuable in subsequent, possibly legal, discussions.
It's not a rights _enforcement_ scheme on it's own (presumably enforcement
would ultimately involve men with big sticks - aka the legal system). It simply
helps manage (GPL) rights.
David
On Fri, Aug 18, 2006 at 03:42:10PM -0700, David Schwartz wrote:
>
> > Ar Gwe, 2006-08-18 am 02:51 -0700, ysgrifennodd David Schwartz:
>
> Re the DMCA issues with printers, courts seem to be holding that the rights
> management system has to enforce an actual right. Since a printer
> manufacturer has no right to limit you to cartridges he makes, the DMCA does
> not apply. (This would be very good if more courts would hold it more
> consistenly on other issues as well. Sadly, that may not be happening.)
>
> > EXPORT_SYMBOL_GPL is clearly a rights management systems. Thats one of
> > its little charms.
>
> No, it is not. If it was, it would violate the GPL. The GPL prohibits any
> restrictions not contained in the GPL, and the GPL doesn't say anything
> about EXPORT_SYMBOL_GPL. To the contrary, the GPL prohibits restrictions on
> use. So EXPORT_SYMBOL_GPL violates the GPL if you are not free to circumvent
> or remove it.
>
> We had this same discussion a few years ago, and my recollection was that
> you agreed that EXPORT_SYMBOL_GPL could not be a license enforcement scheme.
> Which term of the GPL do you think it enforces exactly?
>
> Whose rights does it enforce? (Considering that nobody has the right to
> prevent me from using the Linux kernel with an undistributed derivative work
> that is not covered by the GPL.)
Unlike other rights management systems you are allowed to circumvent or
remove the EXPORT_SYMBOL_GPL mechanism. The GPL lets you.
It is still a rights management system, even if it isn't
forced upon the users.
Now, if someone actually distributes a closed-source module that
circumvents EXPORT_SYMBOL_GPL, or relies on an accompagnying
open source patch that removes the mechanism, this happens:
1. By doing this, they clearly showed that their module is outside the
gray area of "allowed binary-only modules". They definitively
made a "derived work" and distributed it.
2. Anybody who received this module may now invoke the GPL
(and the force of law, if necessary) to extract the
module source code from the maker. And then this source
can be freely redistributed to all interested.
The vendor will be powerless to stop this, no amount of "third
party" patents / trade secrets / intellectual property
inside that module source can prevent its opening. The
module vendor broke all of that the moment they distributed
this nasty module, and set themselves up for this. The vendor
is then the one who have to pay these third parties for
opening their source. They must bear the cost of
free licences for all on any third-party copyright.
Any _patented_ stuff may still be covered
of course, making the source less useable. But the "trade secrets"
broke at the point of distributing a module with the GPL workaround.
So the rights management system works really well - it provides an
enforceable "the price for using these symbols is your code".
Sure, they can patch out the mechanism, but doing so will force them
to hand over the code, and then the module will be trivially rewritten
in a more appropriate way. I.e. now that it is open, it can
use the GPL symbols without any workaround.
The mechanism itself is not protected by laws like the DMCA, because
its removal is explicitly allowed. The great thing is, protection
of the _content_ is not lost when this happens.
The same applies to everything else - before the DMCA, you could
legally break any copy protection scheme. The content was still
protected by law. In our case, enforcing it is easier though.
Helge Hafting
On Saturday 19 August 2006 13:30, Helge Hafting wrote:
> 2. Anybody who received this module may now invoke the GPL
> (and the force of law, if necessary) to extract the
> module source code from the maker. And then this source
> can be freely redistributed to all interested.
Not "Anybody" but only the Copyright Holder of the GPL
code can do that. That's exactly why the FSF requires
to transfer the copyright to FSF before code contribution.
--
Greetings Michael.
On Saturday 19 August 2006 06:48, David Greaves wrote:
> David Schwartz wrote:
> It's not a rights _enforcement_ scheme on it's own (presumably enforcement
> would ultimately involve men with big sticks - aka the legal system). It
> simply helps manage (GPL) rights.
Then how is it not a rights enforcement scheme? It helps me enforce the GPL
(see Helge Hafting's post: http://lkml.org/lkml/2006/8/19/50 for example
why).
--
Patrick McFarland || http://www.AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989
Patrick McFarland wrote:
> On Saturday 19 August 2006 06:48, David Greaves wrote:
>> David Schwartz wrote:
>> It's not a rights _enforcement_ scheme on it's own (presumably enforcement
>> would ultimately involve men with big sticks - aka the legal system). It
>> simply helps manage (GPL) rights.
>
> Then how is it not a rights enforcement scheme? It helps me enforce the GPL
> (see Helge Hafting's post: http://lkml.org/lkml/2006/8/19/50 for example
> why).
Semantics - I think we agree:
See where I said "not ... on it's own" and "It simply helps manage rights".
Well that equates with your statement where you accept that you are the enforcer
and this tool is an aide: "It _helps_ _me_ enforce the GPL".
As Helge says:
It is still a rights management system, even if it isn't
forced upon the users.
Which is what I meant - it's trivial to bypass - unlike some rights management
systems which are intrusive and designed to be hard to bypass. If it was
designed to be hard to bypass and actually worked (ie the deviant developer
couldn't simply lie) then it would be an enforcement system. As it is it wasn't
designed to enforce (it's bloody hard to design an open source system that you
can't work around - Tivo did it - hence GPLv3... but let's not <grin>)
The DVD's CSS and Macrovision OTOH were designed to be enforcement systems (not
perfect and lots of arguments that they hurt the wrong people and don't stop
pirates but...)
This tool/system serves to state one (- not the only) boundary that the
copyright owners feel strongly about and it clearly communicates that boundary
to other developers. It's like a "Private Property - No Trespassing" sign - if
you have a big glowing one then people later find it harder to argue that they
didn't know or that there was an implicit invitation because the gate was open...
David
--
> Now, if someone actually distributes a closed-source module that
> circumvents EXPORT_SYMBOL_GPL, or relies on an accompagnying
> open source patch that removes the mechanism, this happens:
> 1. By doing this, they clearly showed that their module is outside the
> gray area of "allowed binary-only modules". They definitively
> made a "derived work" and distributed it.
How do you figure? This seems to me to be an amazing leap with no rationale
of any kind to justify it.
> 2. Anybody who received this module may now invoke the GPL
> (and the force of law, if necessary) to extract the
> module source code from the maker. And then this source
> can be freely redistributed to all interested.
A trivial patch to the kernel just to remove a deliberate incompatibility
isn't sufficient alone to change the status of the module. The patch to
remove EXPORT_SYMBOL_GPL could even be developed by a completely different
group of people from the kernel module, with no overlap of any kind, so it
is absurd to say that the kernel patch somehow changes the status of the
module.
To give you an analogy, suppose I made a closed-source filesystem for
FreeBSD. Somebody made a patch to the Linux kernel to allow it to emulate
the BSD filesystem interface well enough that with that patch, Linux can use
my module. By any stretch of the imagination, can this Linux patch change
the copyright status of my module, given that it was developed by different
people?
Yes, the patch to modify the kernel is clearly a derivative work, but the
module the patch is needed for is still not if it wasn't before.
In fact, any arguments you could make before, you can still make. But no
new ones arise. For example, if you could argue that the kernel and the
module were too tightly integrated in their design to be considered separate
works or that the module includes too much of the kernel, you still can. But
those are the arguments you'd need to make, and needing a kernel patch that
is independent of the module (authorwise) doesn't strengthen any of them.
> So the rights management system works really well - it provides an
> enforceable "the price for using these symbols is your code".
It can't do that. The module must be GPL'd if and only if it's a derivative
work of the Linux kernel. This has to do with whether it contains portions
of the Linux kernel beyond what is covered by things like fair use and
scenes a faire. How does EXPORT_SYMBOL_GPL change that?
> The mechanism itself is not protected by laws like the DMCA, because
> its removal is explicitly allowed. The great thing is, protection
> of the _content_ is not lost when this happens.
Huh?
I do agree with the point that you do need to explicitly act to circumvent
EXPORT_MODULE_GPL and that pointing out that you did that may be helpful in
subsequent legal fights that may arise. But I don't think anyone today can
specify precisely how. (Perhaps if someone claimed they had no idea that
they might be making their module a derivative work, that they must have
known could affect a damage award.)
DS
On Saturday 19 August 2006 06:30, Helge Hafting wrote:
> Now, if someone actually distributes a closed-source module that
> circumvents EXPORT_SYMBOL_GPL, or relies on an accompagnying
> open source patch that removes the mechanism, this happens:
>
> 1. By doing this, they clearly showed that their module is outside the
> gray area of "allowed binary-only modules". They definitively
> made a "derived work" and distributed it.
>
> 2. Anybody who received this module may now invoke the GPL
> (and the force of law, if necessary) to extract the
> module source code from the maker. And then this source
> can be freely redistributed to all interested.
Actually, you can't just force the vendor to open up all of their source code.
The GPL isn't a contract - it's a license. If a vendor makes a derived work
from the Linux kernel and does not GPL-license said derived work, they are
indeed violating copyright as the license the GPL provides no longer supports
their ability to redistribute.
However, the court decides what happens to the vendor. The court might force
the vendor to open up their code, but to my knowledge this would be breaking
brand new ground. I think it is more likely that the plaintiff could be
awarded monetary damages and the defendant enjoined from further
redistribution.
The charge is not "violating the GPL" (since the GPL is not a contract) --
it's distributing copyrighted materials without a license. See Eben Moglen's
discussion on this subject for more details.
Thanks,
Chase
On Thu, Aug 17, 2006 at 10:37:11AM +0100, David Woodhouse wrote:
> But _even_ if GregKH, Arjan and all of IBM's lawyers are wrong and we
I agree about the rest and I'm certainly not trying to make life easy
to the binary only drivers, but for completeness I'd like to add that
IBM at some point released binary only drivers for some virtual device
on s390. I think they're all GPL by now, but my point remains that
even IBM must have thought they could legally ship binary only drivers
in the past (like everybody else did until recently after all).
My only worry is what's the legal status of the vsyscall if the only
thing that matters is the COPYING file and not its generally agreed
interpretation.
> My only worry is what's the legal status of the vsyscall if the only
> thing that matters is the COPYING file and not its generally agreed
> interpretation.
> -
I've yet to see a generally agreed interpretation on any kind of
exception to the COPYING file (afaik there is none), and if there's no
exception..... I don't think there's a generally agreed interpretation
on when exactly something becomes a derived work either. That is where
lawyers come in, and I suspect that it will even vary from country to
country to some degree, depending on the fine details on exactly how and
what you do. And since I'm not a lawyer, all I can say is: if you want
to live your life on that particular edge, make sure you talk to a good
lawyer or two (and most will give you the advice to really try hard to
not live on that edge, precisely because it's so unclear and varying on
jurisdiction) . Anything else you or I say on this topic is sort of
meaningless since neither of us are lawyers.
On the vsyscall page... I thought it was BSD licensed, and if not, it
probably should be, and I agree with you that that probably wants to be
made explicit somewhere if it's not already.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Chase Venters wrote:
> On Saturday 19 August 2006 06:30, Helge Hafting wrote:
>
>> Now, if someone actually distributes a closed-source module that
>> circumvents EXPORT_SYMBOL_GPL, or relies on an accompagnying
>> open source patch that removes the mechanism, this happens:
>>
>> 1. By doing this, they clearly showed that their module is outside the
>> gray area of "allowed binary-only modules". They definitively
>> made a "derived work" and distributed it.
>>
>> 2. Anybody who received this module may now invoke the GPL
>> (and the force of law, if necessary) to extract the
>> module source code from the maker. And then this source
>> can be freely redistributed to all interested.
>>
>
> Actually, you can't just force the vendor to open up all of their source code.
Not all their source of course, just the source for the derived work.
I.e. we'll get their driver, but not anything else they might have.
>
> The GPL isn't a contract - it's a license. If a vendor makes a derived work
> from the Linux kernel and does not GPL-license said derived work, they are
> indeed violating copyright as the license the GPL provides no longer supports
> their ability to redistribute.
>
> However, the court decides what happens to the vendor. The court might force
> the vendor to open up their code, but to my knowledge this would be breaking
> brand new ground. I think it is more likely that the plaintiff could be
> awarded monetary damages and the defendant enjoined from further
> redistribution.
>
Yes the GPL is a licence. By using the code, they have accepted
the licence. If I use a copy of windows, I'll be forced to pay.
The reason courts usually award monetary damages is that
money is what almost everybody wants. Commercial software,
books, CDs, DVSs are all traded for money, so copying one
means you must pay the copyright holder's loss.
The GPL should work exactly the same way: You distribute
software derived from GPL software, you pay the usual price.
But the usual price for GPLed software is not money,
the usual price is the derived source.
That is what IBM pays when porting linux to their processors,
that is what various hardware vendors pay when they make an
open driver based on small changes to existing drivers.
And that is how I believe a vendor should be forced to pay,
should he have the nerve to distribute a driver that blatantly
works around the EXPORT_SYMBOL_GPL mechanism.
> The charge is not "violating the GPL" (since the GPL is not a contract) --
> it's distributing copyrighted materials without a license. See Eben Moglen's
> discussion on this subject for more details.
>
Interesting text. Seems the FSF takes a 'nicer' approach, and that
works well enough. Still, if someone tries to be difficult, I hope
they'll be forced to pay the usual price - which isn't money.
It'd be hard to set a price anyway, given that GPL software
isn't usually sold. The price of having a professional programmer
developing the same driver perhaps?
Helge Hafting
Helge Hafting wrote:
[...]
> Yes the GPL is a licence. By using the code, they have accepted
> the licence. If I use a copy of windows, I'll be forced to pay.
> The reason courts usually award monetary damages is that
> money is what almost everybody wants. Commercial software,
> books, CDs, DVSs are all traded for money, so copying one
> means you must pay the copyright holder's loss.
>
> The GPL should work exactly the same way: You distribute
> software derived from GPL software, you pay the usual price.
> But the usual price for GPLed software is not money,
> the usual price is the derived source.
[...]
> if someone tries to be difficult, I hope
> they'll be forced to pay the usual price - which isn't money.
> It'd be hard to set a price anyway, given that GPL software
> isn't usually sold. The price of having a professional programmer
> developing the same driver perhaps?
There may also be damage due to unfair competition. But then the
plaintiff probably had to be a competitor (or perhaps a body that is
generally entitled to go against unfair competition, if such a body
exists anywhere). The copyright holders of relevant parts of Linux may
sometimes not be competitors to the violator.
--
Stefan Richter
-=====-=-==- =--- =-=-=
http://arcgraph.de/sr/
Ar Llu, 2006-08-21 am 09:58 +0200, ysgrifennodd Helge Hafting:
> > brand new ground. I think it is more likely that the plaintiff could be
> > awarded monetary damages and the defendant enjoined from further
> > redistribution.
That is the history with gpl-violations.org, although almost everyone
has settled out of court.
> The reason courts usually award monetary damages is that
> money is what almost everybody wants. Commercial software,
I've no idea about Norway but in the UK and US money is just a
convenient shorthand for transferring and measuring the harm caused by
the action in accordance with civil law rules on equity. In some
countries large scale commercial copyright violation is also a criminal
offence.
> It'd be hard to set a price anyway, given that GPL software
> isn't usually sold. The price of having a professional programmer
> developing the same driver perhaps?
A good US lawyer would no doubt ask for the cost of developing an
equivalent open source driver, reverse engineering, and lost
opportunities caused by the time this will take, trebled for being
intentional, and class action on behalf of all the rights-holders.
What a court would award is unknown, there is AFAIK no useful US caselaw
on either class action copyright infringement suits or GPL violation
penalties.
Alan
Helge Hafting <[email protected]> wrote:
> Chase Venters wrote:
> > On Saturday 19 August 2006 06:30, Helge Hafting wrote:
> >
> >> Now, if someone actually distributes a closed-source module that
> >> circumvents EXPORT_SYMBOL_GPL, or relies on an accompagnying
> >> open source patch that removes the mechanism, this happens:
> >>
> >> 1. By doing this, they clearly showed that their module is outside the
> >> gray area of "allowed binary-only modules". They definitively
> >> made a "derived work" and distributed it.
> >>
> >> 2. Anybody who received this module may now invoke the GPL
> >> (and the force of law, if necessary) to extract the
> >> module source code from the maker. And then this source
> >> can be freely redistributed to all interested.
> >>
> > Actually, you can't just force the vendor to open up all of their
> > source code.
> Not all their source of course, just the source for the derived work.
Not even that.
> I.e. we'll get their driver, but not anything else they might have.
You could perhaps get the driver.
> > The GPL isn't a contract - it's a license. If a vendor makes a
> > derived work from the Linux kernel and does not GPL-license said
> > derived work, they are indeed violating copyright as the license the
> > GPL provides no longer supports their ability to redistribute.
> >
> > However, the court decides what happens to the vendor. The court
> > might force the vendor to open up their code, but to my knowledge
> > this would be breaking brand new ground. I think it is more likely
> > that the plaintiff could be awarded monetary damages and the
> > defendant enjoined from further redistribution.
> Yes the GPL is a licence. By using the code, they have accepted
> the licence.
No. GPL kicks in when they distribute code.
> If I use a copy of windows, I'll be forced to pay.
Windows is under a different "license" (they try to make it a contract,
which is another kettle of fish altogether, so don't go there).
> The reason courts usually award monetary damages is that
> money is what almost everybody wants.
They tell the offender to pay the owner for the actual damages they
suffered, and perhaps a punishment on top. If Bad Corp distributes my code,
which I don't make money off by virtue of distributing it GPLed, there are
no damages that I could ask to be restituted to me. If I write a book and
keep in to myself in my drawer, you grab a copy and publish it on the
Internet, no judge will ask you to pay damages as if it was the loss of
revenue for history's best selling bestseller.
In any case this is wildly off-topic here, so take your comments
elsewhere. If you want to know what really happens here, talk to a lawyer
or visit sites clueful on the matter and learn.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513