GPL vs non-GPL device drivers

GPL vs non-GPL device drivers

[v j]

This is in reference to the following thread:

http://lkml.org/lkml/2006/12/14/63

I am not sure if this is ever addressed in LKML, but linux is _very_
popular in the embedded space. We (an embedded vendor) chose Linux 3
years back because of its lack of royalty model, robustness and
availability of infinite number of open-source tools.

We recently decided to move to Linux 2.6 for our next product, mainly
because Linux has worked so well for us in the past, and we would like
to move up to keep up with the latest and greatest.

However in moving to  2.6, we noticed a number of alarming things.
Porting drivers over from devfs to udev, though easy raised a number
of alarming issues. Driver's no longer could dynamically allocate
their MAJOR/MINOR numbers. Doing so would mean they would have to use
sysfs. However it seems that sysfs (and the class_ interface) is only
available to GPL modules. This is very concerning. The drivers which
we have written over the last three years are suddenly under threat.
We don't mind statically assigning MAJOR/MINOR numbers to our drivers.
We can do this and modify our user space applications too.

However we have a worrying trend here. If at some point it becomes
illegal to load our modules into the linux kernel, then it is
unacceptable to us. We would have been better off choosing VxWorks or
OSE 3 years ago when we made an OS choice. The fact that Linux is
becoming more and more closed is very very alarming.

vj.

Re: GPL vs non-GPL device drivers

[v j]

No its not. It wasn't common knowledge 3 years ago when we chose Linux
as an embedded platform. If it indeed is common knowledge that
loadable modules in Linux have to be open-source then it is very
probable that we wouldn't have chosen Linux as the platform of choice.
If this indeed is the case and is common knowledge, then I predict
that Linux will soon drop in popularity as the OS of choice in
embedded systems.

On 2/14/07, Lee Revell <rlrevell@joe-job.com> wrote:
> Um... it's been common knowledge for years that the legal status of
> non-GPL kernel modules is an open issue.  Specifically, whether a
> device driver written for the Linux kernel is a derived work of the
> kernel.  Sounds like you didn't do your homework 3 years ago.
>
> Why did you assume that linking a non-GPL module into the GPL Linux
> kernel was legal?  You have read the GPL right?
>
> Lee
>
> On 2/15/07, v j <vj.linux@gmail.com> wrote:
> > This is in reference to the following thread:
> >
> > http://lkml.org/lkml/2006/12/14/63
> >
> > I am not sure if this is ever addressed in LKML, but linux is _very_
> > popular in the embedded space. We (an embedded vendor) chose Linux 3
> > years back because of its lack of royalty model, robustness and
> > availability of infinite number of open-source tools.
> >
> > We recently decided to move to Linux 2.6 for our next product, mainly
> > because Linux has worked so well for us in the past, and we would like
> > to move up to keep up with the latest and greatest.
> >
> > However in moving to  2.6, we noticed a number of alarming things.
> > Porting drivers over from devfs to udev, though easy raised a number
> > of alarming issues. Driver's no longer could dynamically allocate
> > their MAJOR/MINOR numbers. Doing so would mean they would have to use
> > sysfs. However it seems that sysfs (and the class_ interface) is only
> > available to GPL modules. This is very concerning. The drivers which
> > we have written over the last three years are suddenly under threat.
> > We don't mind statically assigning MAJOR/MINOR numbers to our drivers.
> > We can do this and modify our user space applications too.
> >
> > However we have a worrying trend here. If at some point it becomes
> > illegal to load our modules into the linux kernel, then it is
> > unacceptable to us. We would have been better off choosing VxWorks or
> > OSE 3 years ago when we made an OS choice. The fact that Linux is
> > becoming more and more closed is very very alarming.
> >
> > vj.
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/15/07, v j <vj.linux@gmail.com> wrote:
> The drivers which we have written over the last three years are suddenly
> under threat.
> [..]
> The fact that Linux is becoming more and more closed is very very alarming.

Sigh.  Someone remind me of the rules against "politics" on the list
before I get into why vj should play nice with the other children.

Trent

Re: GPL vs non-GPL device drivers

[v j]

On 2/14/07, v j <vj.linux@gmail.com> wrote:
> This has nothing to do with politics. I am not a Linux contributor. I realize that people who have contributed to the Linux Kernel have very valid points. It is their sweat and blood. They have a right to protect what they have worked on. I am purely commenting from a user perspective. If Linux becomes closed to external drivers, then it will have repercussions in the embedded space. I can say for certain that a company evaluating OSes and realizing that their drivers will have to be open-source will almost certainly go for the alternative.
>
>
>
> On 2/14/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> >  On 2/15/07, v j <vj.linux@gmail.com> wrote:
> > > The drivers which we have written over the last three years are suddenly
> > > under threat.
> > > [..]
> > > The fact that Linux is becoming more and more closed is very very alarming.
> >
> > Sigh.  Someone remind me of the rules against "politics" on the list
> > before I get into why vj should play nice with the other children.
> >
> > Trent
> >
>
>

Re: GPL vs non-GPL device drivers

[Neil Horman]

On Wed, Feb 14, 2007 at 10:16:44PM -0800, v j wrote:
> On 2/14/07, v j <vj.linux@gmail.com> wrote:
> >This has nothing to do with politics. I am not a Linux contributor. I 
> >realize that people who have contributed to the Linux Kernel have very 
> >valid points. It is their sweat and blood. They have a right to protect 
> >what they have worked on. I am purely commenting from a user perspective. 
> >If Linux becomes closed to external drivers, then it will have 
> >repercussions in the embedded space. I can say for certain that a company 
> >evaluating OSes and realizing that their drivers will have to be 
> >open-source will almost certainly go for the alternative.
> >
So, to summarize:

1) You don't contribute to the kernel
2) You recognize the rights of contributors to do with their work what they
please
3) you aren't willing to open source your kernel code.

Why don't you just go with vxWorks or some other embedded OS?  You've recognized
that you are officially getting something (alot of something) for free here, and
are unwilling to play by the rules those who have donated to you set out.  Its
not like you're doing anyone who contributes any favors by using Linux.
Granted, its always good to have more linux devices out there, but if you can't
play by the rules, don't play.

And just so you know, making it easier for open source drivers to operate with
the kernel than closed source drivers isn't "closing" the kernel, its reminding
you that keeping your source closed in linux comes at a price.

Neil

> >
> >
> >On 2/14/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> >>  On 2/15/07, v j <vj.linux@gmail.com> wrote:
> >> > The drivers which we have written over the last three years are 
> >suddenly
> >> > under threat.
> >> > [..]
> >> > The fact that Linux is becoming more and more closed is very very 
> >alarming.
> >>
> >> Sigh.  Someone remind me of the rules against "politics" on the list
> >> before I get into why vj should play nice with the other children.
> >>
> >> Trent
> >>
> >
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/15/07, v j <vj.linux@gmail.com> wrote:
> This has nothing to do with politics. I am not a Linux contributor.

Here-in lies the problem.  I am one of the few people willing to state
openly that I wish those who can, would use their legal claims to stop
people like you from writing proprietary drivers.  Although you (or
your company) clearly has the ability to contribute to Linux, you have
chosen not to.  Instead, you just leach off those that do.  As such, I
believe you and your ilk are ethically deplorable and the fact that
you would come here to try to point out to the contributors that they
are going to lose people like you if they don't stop "threatening"
your drivers not only baffles me, it sickens me.

At least with NVIDIA and ATI they're not actually profiting from the
existence of Linux, but you're actually selling the stuff and you
don't even consider the very reasonable proposition of sharing your
source code in return.  It's not like they're asking for money.. man,
this is the Linux project, they don't even ask for copyright
assignment or allegiance to an ideology..

Do the right thing, cough up your source code, get it integrated into
the tree and let the community do what it does so well.

Trent

Re: GPL vs non-GPL device drivers

[v j]

You don't get it do you. Our source code is meaningless to the Open
Source community at large. It is only useful to our tiny set of
competitors that have nothing to do with Linux. The Embedded space is
very specific. We are only _using_ Linux. Just as we could have used
VxWorks or OSE. Using our source code would not benefit anybody but
our competitors. Sure we could make our drivers open-source. This is a
decision that is made FIRST when evaluating an OS. If we we were
required to make our drivers/HW open, we would just not have chosen
Linux. It is as simple as that.

On 2/14/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> On 2/15/07, v j <vj.linux@gmail.com> wrote:
> > This has nothing to do with politics. I am not a Linux contributor.
>
> Here-in lies the problem.  I am one of the few people willing to state
> openly that I wish those who can, would use their legal claims to stop
> people like you from writing proprietary drivers.  Although you (or
> your company) clearly has the ability to contribute to Linux, you have
> chosen not to.  Instead, you just leach off those that do.  As such, I
> believe you and your ilk are ethically deplorable and the fact that
> you would come here to try to point out to the contributors that they
> are going to lose people like you if they don't stop "threatening"
> your drivers not only baffles me, it sickens me.
>
> At least with NVIDIA and ATI they're not actually profiting from the
> existence of Linux, but you're actually selling the stuff and you
> don't even consider the very reasonable proposition of sharing your
> source code in return.  It's not like they're asking for money.. man,
> this is the Linux project, they don't even ask for copyright
> assignment or allegiance to an ideology..
>
> Do the right thing, cough up your source code, get it integrated into
> the tree and let the community do what it does so well.
>
> Trent
>

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/15/07, v j <vj.linux@gmail.com> wrote:
> You don't get it do you.

I think everyone on the list was thinking the same thing about you.

> We are only _using_ Linux.

Yes, I think we all can see that.

> Using our source code would not benefit anybody but our competitors.

Without knowing what your drivers are, I can't argue about this.

Maybe someday, embedded devices will move into the 21st century and
I'll be able to get a DVD player, microwave oven or home security
system that is user programmable, but I doubt your company will make
it.

Trent

Re: GPL vs non-GPL device drivers

[Dave Jones]

On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote:
 > You don't get it do you. Our source code is meaningless to the Open
 > Source community at large.

Linux supports entire _architectures_ of which there are single figures
of people using it.  What makes your hardware special ?
 
 > We are only _using_ Linux.

If you're adding kernel modules, you're more than using Linux, you're
developing _for_ linux.  You're just choosing to keep the fruits of
those labors to yourself.
 
 > Just as we could have used VxWorks or OSE.

You could.  But would you have had access to thousands of worldwide
contributors making your code better?
This is what you've missed out on with your current stance.
 
 > Using our source code would not benefit anybody but
 > our competitors.

This excuse has been given time and time again, and repeatedly been 
proven false.  And as soon as one of your competitors makes their
drivers open, guess which one gets 1000+ free developers working
on their code ?

 > Sure we could make our drivers open-source. This is a
 > decision that is made FIRST when evaluating an OS. If we we were
 > required to make our drivers/HW open, we would just not have chosen
 > Linux. It is as simple as that.

Please, revisit the 1990s. Read the cathedral and the bazaar.[1]
Listen to MC Hammer.   Realise the funky horror.  Then when you're ready
to revisit us with some points that haven't already been dismissed
please post again. Until then, you're offering nothing new.

		Dave

[1] Jesus, I'm recommending ESR texts, I must be desperate.

-- 
http://www.codemonkey.org.uk

Re: GPL vs non-GPL device drivers

[Jeff Garzik]

Dave Jones wrote:
> On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote:
>  > Using our source code would not benefit anybody but
>  > our competitors.
> 
> This excuse has been given time and time again, and repeatedly been 
> proven false.  And as soon as one of your competitors makes their
> drivers open, guess which one gets 1000+ free developers working
> on their code ?


Customers also like to buy hardware where they -know- support will not 
disappear in a year, when the vendor releases a new chip.

In fact, in some markets, the engineers who wrote the code have often 
moved to the next project, by the time the customers actually get their 
hands on the end result.  Open source means that problems found in real 
world field testing can be readily debugged and fixed.

	Jeff

Re: GPL vs non-GPL device drivers

[Dave Jones]

On Thu, Feb 15, 2007 at 04:44:51AM -0500, Jeff Garzik wrote:
 > Dave Jones wrote:
 > > On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote:
 > >  > Using our source code would not benefit anybody but
 > >  > our competitors.
 > > 
 > > This excuse has been given time and time again, and repeatedly been 
 > > proven false.  And as soon as one of your competitors makes their
 > > drivers open, guess which one gets 1000+ free developers working
 > > on their code ?
 > 
 > 
 > Customers also like to buy hardware where they -know- support will not 
 > disappear in a year, when the vendor releases a new chip.

Absolutely. This is a very good point.
And users of binary blobs like nvidia.ko are already beginning to see
this problem.   (Nvidia dropped support for "legacy" cards a while back)

Only open drivers ensure ongoing vendor-independant support, which
is an important thing.   I'd not be happy buying a device that I know
the vendor is going to ship security updates for a year after release.
VJ, how long does your company support each product? And how much
engineering effort is spent doing so, vs effort that you could get
for free by opening your driver(s) ?

 > In fact, in some markets, the engineers who wrote the code have often 
 > moved to the next project, by the time the customers actually get their 
 > hands on the end result.  Open source means that problems found in real 
 > world field testing can be readily debugged and fixed.

Even open drivers have the same problem.  Take for example longhaul.c.
I lost interest in this a while ago and moved on to shinier new hardware
(whilst it still had numerous problems) and rafal picked this up and has
been fixing it up like something possessed since.
If this were a closed driver, it would have been doomed never to improve.

It's a great example of one of the strengths of the open process.

		Dave

-- 
http://www.codemonkey.org.uk

Re: GPL vs non-GPL device drivers

[Jan De Luyck]

On Thursday 15 February 2007, Dave Jones wrote:
> On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote:
>
>  > Using our source code would not benefit anybody but
>  > our competitors.
>
> This excuse has been given time and time again, and repeatedly been
> proven false.  And as soon as one of your competitors makes their
> drivers open, guess which one gets 1000+ free developers working
> on their code ?

I think a nice example of that might be the Linksys WRT54G routers. 

Jan

-- 
Speaking of purchasing a dog, never buy a watchdog that's on sale.
After all, everyone knows a bargain dog never bites!

Re: GPL vs non-GPL device drivers

[Benny Amorsen]

>>>>> "JDL" == Jan De Luyck <ml_linuxkernel_20060528@kcore.org> writes:

JDL> I think a nice example of that might be the Linksys WRT54G
JDL> routers.

They don't ship with Linux anymore, except the WRT54GL. Apparently
switching was worth it to save 2MB flash.


/Benny

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Thu, 2007-02-15 at 15:37 +0100, Benny Amorsen wrote:
> >>>>> "JDL" == Jan De Luyck <ml_linuxkernel_20060528@kcore.org> writes:
> 
> JDL> I think a nice example of that might be the Linksys WRT54G
> JDL> routers.
> 
> They don't ship with Linux anymore, except the WRT54GL. Apparently
> switching was worth it to save 2MB flash.

If you sell that many of them (several thousand per month?), it is it
worth.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Jan Knutar]

On Thursday 15 February 2007 16:37, Benny Amorsen wrote:
> >>>>> "JDL" == Jan De Luyck <ml_linuxkernel_20060528@kcore.org>
> >>>>> writes:
>
> JDL> I think a nice example of that might be the Linksys WRT54G
> JDL> routers.
>
> They don't ship with Linux anymore, except the WRT54GL. Apparently
> switching was worth it to save 2MB flash.

Though apparently there are enough people out there who want the
benefits of Linux that it's viable for them to make the L version which 
is capable of running Linux :)

Amusingly, the place I acquired my GL from sells the non-Linux WRT54G 
for 65.90€ and the WRT54GL for €64.90. The WRT54GS (S for speedboost?) 
is €81.90.

Re: GPL vs non-GPL device drivers

[Neil Brown]

On Wednesday February 14, vj.linux@gmail.com wrote:
> You don't get it do you. Our source code is meaningless to the Open
> Source community at large. It is only useful to our tiny set of
> competitors that have nothing to do with Linux. The Embedded space is
> very specific. We are only _using_ Linux. Just as we could have used
> VxWorks or OSE. Using our source code would not benefit anybody but
> our competitors. 

It would also benefit your *customers*.  And you might find that
providing such benefits increases the number of your customers.

NeilBrown

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Wed, 2007-02-14 at 22:46 -0800, v j wrote:
> You don't get it do you. Our source code is meaningless to the Open
> Source community at large. It is only useful to our tiny set of

Perhaps you should leave that decision to the open source community at
large.

[ Useless fullquote deleted ]

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Chris Snook]

v j wrote:
> You don't get it do you. Our source code is meaningless to the Open
> Source community at large. It is only useful to our tiny set of
> competitors that have nothing to do with Linux. The Embedded space is
> very specific. We are only _using_ Linux. Just as we could have used
> VxWorks or OSE. Using our source code would not benefit anybody but
> our competitors. Sure we could make our drivers open-source. This is a
> decision that is made FIRST when evaluating an OS. If we we were
> required to make our drivers/HW open, we would just not have chosen
> Linux. It is as simple as that.

Collaborating with the competition ("coopetition") on a common 
technology platform reduces costs for anyone who chooses to get 
involved, giving them a collective competitive edge against anyone who 
doesn't.  This is why there is so much industry interest in F/OSS, and 
mortal enemies in the business world happily work together on technical 
issues in Linux.

If you choose to actively participate in the community, you will benefit 
from this phenomenon, as well as the patches you will receive from very 
smart kernel hackers who don't even own your hardware, and the pool of 
mature GPL code you can use to improve your drivers.

If you do not choose to actively participate in the community, you can 
still keep using existing versions of the kernel that work fine for you, 
even if future versions do not.  There are plenty of embedded devices 
out there using 2.4 or even 2.2 kernels that do what they need.

Your competitors who do participate in the community (and there are a 
lot in the embedded space) enjoy reduced development costs, more stable 
and better-reviewed code, continuous compatibility with the latest 
versions, and influence in the community over the direction of future 
development.  If you want to cede this advantage to your competitors, 
that's between you and your investors.

	-- Chris

Re: GPL vs non-GPL device drivers

[Jeff Garzik]

Chris Snook wrote:
> Collaborating with the competition ("coopetition") on a common 
> technology platform reduces costs for anyone who chooses to get 
> involved, giving them a collective competitive edge against anyone who 
> doesn't.  This is why there is so much industry interest in F/OSS, and 
> mortal enemies in the business world happily work together on technical 
> issues in Linux.
[...]
> Your competitors who do participate in the community (and there are a 
> lot in the embedded space) enjoy reduced development costs, more stable 
> and better-reviewed code, continuous compatibility with the latest 
> versions, and influence in the community over the direction of future 
> development.  If you want to cede this advantage to your competitors, 
> that's between you and your investors.

I definitely agree that the above is an accurate assessment.

There is a flip side too.  For hardware vendors, there is an interesting 
dynamic of cooperation /and/ competition.  Hardware vendors still 
compete based on features, IP, and many other levels.

A hardware vendor that is unaware of how to compete in an open source 
world is a hardware vendor with a big fat hole in their business model.

It isn't usually politically correct to state this out loud, but, 
hardware vendors still compete quite heavily using "closed" intellectual 
property.  With open source, the lines just shift.

	Jeff

Re: GPL vs non-GPL device drivers

[Alexandre Oliva]

On Feb 15, 2007, Chris Snook <csnook@redhat.com> wrote:

> v j wrote:

>> You don't get it do you. Our source code is meaningless to the Open
>> Source community at large.

You don't have to offer it to the community at large.  You only have
to pass it on to your customers, under the terms of the GPL.

> Collaborating with the competition ("coopetition") on a common
> technology platform reduces costs for anyone who chooses to get
> involved, giving them a collective competitive edge against anyone who
> doesn't.

http://www.lsd.ic.unicamp.br/~oliva/papers/free-software/BMind.pdf

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL vs non-GPL device drivers

[Dave Jones]

On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote:
 > This is in reference to the following thread:
 > 
 > http://lkml.org/lkml/2006/12/14/63
 > 
 > I am not sure if this is ever addressed in LKML, but linux is _very_
 > popular in the embedded space. We (an embedded vendor) chose Linux 3
 > years back because of its lack of royalty model, robustness and
 > availability of infinite number of open-source tools.
 
Welcome to three months ago.
Here in the future, this was deemed a non-issue.
However this does highlight another problem.
End-users who take linux for use in embedded systems (especially)
tend to live in their own little world rarely contributing anything
back to upstream, popping up occasionally when months after decisions
have been made on things.   Remind me again why we should care about
your out of tree binary only modules ?

 > The drivers which
 > we have written over the last three years are suddenly under threat.

Were they part of the kernel tree, people might care enough to
a) fix them so that they work and b) care enough that they _keep working_
even if people changing APIs etc don't have the necessary hardware.

This isn't the 1990s any more, we shouldn't need to explain how all this works.

 > However we have a worrying trend here. If at some point it becomes
 > illegal to load our modules into the linux kernel, then it is
 > unacceptable to us. We would have been better off choosing VxWorks or
 > OSE 3 years ago when we made an OS choice. The fact that Linux is
 > becoming more and more closed is very very alarming.

The question is "do you care about giving back" or are you intending
to leech of Linux and just complain when it changes in ways that
don't mesh with your plans?

		Dave

-- 
http://www.codemonkey.org.uk

Re: GPL vs non-GPL device drivers

[v j]

On 2/14/07, Dave Jones <davej@redhat.com> wrote:
> On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote:
>
> Welcome to three months ago.
> Here in the future, this was deemed a non-issue.
> However this does highlight another problem.
> End-users who take linux for use in embedded systems (especially)
> tend to live in their own little world rarely contributing anything
> back to upstream, popping up occasionally when months after decisions
> have been made on things.   Remind me again why we should care about
> your out of tree binary only modules ?

You are right. I have not contributed anything to Linux. Except one
small patch to the MTD code. However, I don't think that is the point
here. I am perfectly willing to live with the way Linux is today. I am
telling you as a user that if Linux continues on the current path it
will become less and less attractive to Embedded Users.

Not everybody has to be a contributor. The reason Linux is popular is
because of its openness. Take that away and see where it goes.

Re: GPL vs non-GPL device drivers

[Neil Brown]

On Wednesday February 14, vj.linux@gmail.com wrote:
> You are right. I have not contributed anything to Linux. Except one
> small patch to the MTD code. However, I don't think that is the point
> here. I am perfectly willing to live with the way Linux is today. I am
> telling you as a user that if Linux continues on the current path it
> will become less and less attractive to Embedded Users.

Every user should be free to choose which OS to use, Embedded users
included.   You are free to look elsewhere.

While having lots of users is good for Linux, it is not a short-term
goal.  Openness/freedom plus quality are the short-term goals.  Lots of
users (aka world domination) is the long term goal that we believe
will follow.

> 
> Not everybody has to be a contributor. The reason Linux is popular is
> because of its openness. Take that away and see where it goes.

So tell us?  where does it go?

You seem to have the experience already.  You took an open linux,
added some closed drivers and so made it closed.  So you yourself (or
your company) have taken that (the openness) away - where did the
result go?

I'm guessing it went into a dead-end or you wouldn't be here talking to
us now.

NeilBrown

Re: GPL vs non-GPL device drivers

[v j]

On 2/14/07, Neil Brown <neilb@suse.de> wrote:
> > Not everybody has to be a contributor. The reason Linux is popular is
> > because of its openness. Take that away and see where it goes.
>
> So tell us?  where does it go?
>
> You seem to have the experience already.  You took an open linux,
> added some closed drivers and so made it closed.  So you yourself (or
> your company) have taken that (the openness) away - where did the
> result go?
>
> I'm guessing it went into a dead-end or you wouldn't be here talking to
> us now.

If adding closed drivers to Linux is illegal, I am perfectly fine with
that. Just say so. I am not at a dead-end yet, until you make that
statement. Once you make that statement, then all bets are off. I am
betting that most companies will not even consider Linux as an
alternative in the embedded space if this were the case.

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/15/07, v j <vj.linux@gmail.com> wrote:
> If adding closed drivers to Linux is illegal, I am perfectly fine with
> that. Just say so. I am not at a dead-end yet, until you make that
> statement. Once you make that statement, then all bets are off. I am
> betting that most companies will not even consider Linux as an
> alternative in the embedded space if this were the case.

Greg KH has already made that statement.

http://www.kroah.com/log/linux/ols_2006_keynote.html

half way down, "Closed source Linux kernel modules are illegal".  As
was said, welcome to 6 months ago.

Trent

Re: GPL vs non-GPL device drivers

[v j]

I am well aware of what Greg KHs position is, in fact he is the reason
I started the whole rant. This is only a plea to the "higher
authorities". Linus, please save Linux!

vj

On 2/14/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> On 2/15/07, v j <vj.linux@gmail.com> wrote:
> > If adding closed drivers to Linux is illegal, I am perfectly fine with
> > that. Just say so. I am not at a dead-end yet, until you make that
> > statement. Once you make that statement, then all bets are off. I am
> > betting that most companies will not even consider Linux as an
> > alternative in the embedded space if this were the case.
>
> Greg KH has already made that statement.
>
> http://www.kroah.com/log/linux/ols_2006_keynote.html
>
> half way down, "Closed source Linux kernel modules are illegal".  As
> was said, welcome to 6 months ago.
>
> Trent
>

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/15/07, v j <vj.linux@gmail.com> wrote:
> I am well aware of what Greg KHs position is, in fact he is the reason
> I started the whole rant. This is only a plea to the "higher
> authorities". Linus, please save Linux!

Oh boy.  Guess what?

  $ head -3  Documentation/ABI/testing/sysfs-class
  What:           /sys/class/
  Date:           Febuary 2006
  Contact:        Greg Kroah-Hartman <gregkh@suse.de>

Yeah, that's right.

Trent

Re: GPL vs non-GPL device drivers

[Neil Brown]

On Wednesday February 14, vj.linux@gmail.com wrote:
> I am well aware of what Greg KHs position is, in fact he is the reason
> I started the whole rant. This is only a plea to the "higher
> authorities". Linus, please save Linux!

Linus is not in any position to do anything.  The die is cast.

You should speak to a lawyer.

The key issue is this:  
   Does combining your work with Linux create a derived work.

  If it does not, you have nothing to worry about.
  If it does, then maybe you should worry.

  If someone who owns copyright in part of the Linux kernel that you
  are using, decides that they think you have created a derived work,
  then they might bring this to your attention and ask you to abide by
  the conditions in the license under which you obtained the Linux
  kernel.  If no suitable resolution can be found, they might take you
  to court for using their protected work without a valid license (The
  GPL becomes void if you breach it's requirements).

  And then the judge might or might not find against you.  But it is
  very hard to know in advance how the judge will decide in a
  particular case.  Hence the best advice is to speak to a lawyer,
  They have the best chance of advising your how to minimise your
  risk.


I hope that makes the situation clear enough.

NeilBrown

Re: GPL vs non-GPL device drivers

[Adrian Bunk]

On Thu, Feb 15, 2007 at 06:30:33PM +1100, Neil Brown wrote:
> On Wednesday February 14, vj.linux@gmail.com wrote:
> > I am well aware of what Greg KHs position is, in fact he is the reason
> > I started the whole rant. This is only a plea to the "higher
> > authorities". Linus, please save Linux!
> 
> Linus is not in any position to do anything.  The die is cast.
> 
> You should speak to a lawyer.
> 
> The key issue is this:  
>    Does combining your work with Linux create a derived work.
> 
>   If it does not, you have nothing to worry about.
>   If it does, then maybe you should worry.
> 
>   If someone who owns copyright in part of the Linux kernel that you
>   are using, decides that they think you have created a derived work,
>   then they might bring this to your attention and ask you to abide by
>   the conditions in the license under which you obtained the Linux
>   kernel.  If no suitable resolution can be found, they might take you
>   to court for using their protected work without a valid license (The
>   GPL becomes void if you breach it's requirements).
> 
>   And then the judge might or might not find against you.  But it is
>   very hard to know in advance how the judge will decide in a
>   particular case.  Hence the best advice is to speak to a lawyer,
>   They have the best chance of advising your how to minimise your
>   risk.
> 
> 
> I hope that makes the situation clear enough.

You missed one point:

In every country you distribute your product, a local kernel developer 
could bring the case to a local court based on local copyright law.

> NeilBrown

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: GPL vs non-GPL device drivers

[Randy Dunlap]

On Wed, 14 Feb 2007 22:27:10 -0800 v j wrote:

> On 2/14/07, Dave Jones <davej@redhat.com> wrote:
> > On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote:
> >
> > Welcome to three months ago.
> > Here in the future, this was deemed a non-issue.
> > However this does highlight another problem.
> > End-users who take linux for use in embedded systems (especially)
> > tend to live in their own little world rarely contributing anything
> > back to upstream, popping up occasionally when months after decisions
> > have been made on things.   Remind me again why we should care about
> > your out of tree binary only modules ?
> 
> You are right. I have not contributed anything to Linux. Except one
> small patch to the MTD code. However, I don't think that is the point
> here. I am perfectly willing to live with the way Linux is today. I am
> telling you as a user that if Linux continues on the current path it
> will become less and less attractive to Embedded Users.

At least one of us is confused about that an embedded User is.
It seems to me that you are an embedded developer, not User.
I doubt that most Embedded Users care what their OS is,
or even know what an OS is.

> Not everybody has to be a contributor. The reason Linux is popular is
> because of its openness. Take that away and see where it goes.

We seem to have different definitions of open and closed.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: GPL vs non-GPL device drivers

[v j]

On 2/14/07, Randy Dunlap <rdunlap@xenotime.net> wrote:
> At least one of us is confused about that an embedded User is.
> It seems to me that you are an embedded developer, not User.
> I doubt that most Embedded Users care what their OS is,
> or even know what an OS is.

I am not sure what the difference is. We are trying to use Linux to
support our application. It may be that Linux has a bug, or our
application. When it is Linux, that has the problem, I  have tried to
inform the community of that.

>
> > Not everybody has to be a contributor. The reason Linux is popular is
> > because of its openness. Take that away and see where it goes.
>
> We seem to have different definitions of open and closed.

Open = 3rd party Linux drivers can be loaded. Closed = No third party
Linux drivers can be loaded.

Re: GPL vs non-GPL device drivers

[Neil Brown]

On Wednesday February 14, vj.linux@gmail.com wrote:
> On 2/14/07, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > We seem to have different definitions of open and closed.
> 
> Open = 3rd party Linux drivers can be loaded. Closed = No third party
> Linux drivers can be loaded.

Loading a driver is not at issue.  Anyone may load a driver.

The issue is when you *distribute* a driver.
If that driver is a derived work or the Linux kernel, then you may
only distribute it under the terms of the GPLv2, which essentially
means that you make the source code available - under the GPLv2 - to
everyone you give the driver to.

How do you know if the driver is a derived work?
 Well, if it uses POSIX syscalls only, it isn't. (You can write USB
 drivers in user-space which do this).

 If it uses symbols exported with EXPORT_SYMBOL_GPL, then the author of the
 code which provides those symbols thinks that the driver is a derived
 work.

 If it uses EXPORT_SYMBOL symbols, then it is less clear what people
 believe, though there are certainly some who believe it will still
 be a derived work.

But of course the person who's opinion really counts is the judge.  So
you need to get legal advice.

NeilBrown

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/15/07, Neil Brown <neilb@suse.de> wrote:
>  [..] then it is less clear what people believe

Another area where it is less clear what people believe is if you are
distributing the module separately to the kernel, but, as I understand
it, vj says he is not.

> But of course the person who's opinion really counts is the judge.

The judge's opinion only counts if you actually get to court and
manage to put up a legal defense.

> So you need to get legal advice.

Or, ya know, you could take the moral/ethical advice that you're being
a worm and stop now.

Trent

Re: GPL vs non-GPL device drivers

[Neil Brown]

On Thursday February 15, trent.waddington@gmail.com wrote:
> On 2/15/07, Neil Brown <neilb@suse.de> wrote:
> >  [..] then it is less clear what people believe
> 
> Another area where it is less clear what people believe is if you are
> distributing the module separately to the kernel, but, as I understand
> it, vj says he is not.
> 
> > But of course the person who's opinion really counts is the judge.
> 
> The judge's opinion only counts if you actually get to court and
> manage to put up a legal defense.
> 
> > So you need to get legal advice.
> 
> Or, ya know, you could take the moral/ethical advice that you're being
> a worm and stop now.

I don't think we do ourselves any favours by calling people names....

And as I understand it, an important principle in out community is
freedom.  If vj wants to take a particular moral/ethical stance, then
he should be free to do that.  Of course he will have to live with any
consequences, as do we all.

He (or maybe she? I don't know but English is forcing me to use
gender-specific pronouns) or his company sees a business risk in open
sourcing their code.  They now see a legal risk it not doing so.  They
get to choose how to respond.

This list is a great place to seek technical advice on the different
options.   It is not such a good place to get business or legal
advice.

NeilBrown

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/15/07, Neil Brown <neilb@suse.de> wrote:
> And as I understand it, an important principle in out community is
> freedom.  If vj wants to take a particular moral/ethical stance, then
> he should be free to do that.  Of course he will have to live with any
> consequences, as do we all.

Yes, and one of the consequences is that people who disagree with his
stance tell him off for it.  Him, and everyone else who profits from
distributing GPL licensed code without abiding by the very simple
requirements of the GPL are parasites.  They should stop.  Legally
they might not be required to.. and some of the best legal minds in
the world think they are, if only the copyright holders would sue
already.. but that's just a side issue.

Trent

RE: GPL vs non-GPL device drivers

[David Schwartz]

> Or, ya know, you could take the moral/ethical advice that you're being
> a worm and stop now.

Actually, the people who are being worms are the people who are trying to
use the GPL as a club to coerce people into not exercising the rights the
GPL gave them. The people trying to change the rules in the middle of the
game are the worms, not the people trying to play by them.

DS

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/16/07, David Schwartz <davids@webmaster.com> wrote:
> Actually, the people who are being worms are the people who are trying to
> use the GPL as a club to coerce people into not exercising the rights the
> GPL gave them. The people trying to change the rules in the middle of the
> game are the worms, not the people trying to play by them.

I must have missed something, who is trying to coerce people into not
exercising the rights the GPL gave them?  I don't debate that people
are trying to coerce people into passing on the rights the GPL gave
them when they distribute the kernel... coercion, that's what software
licenses are.  Who's changing the rules?

Trent

RE: GPL vs non-GPL device drivers

[David Schwartz]

> I must have missed something, who is trying to coerce people into not
> exercising the rights the GPL gave them?

Anyone who claims that it is unlawful to "circumvent" the EXPORT_SYMBOL_GPL
stuff. Anyone who adds copyright or license enforcement mechansims to GPL'd
code and distributes the result. Anyone who tries to frighten people into
openening their code based on a crazy notion of what constitutes a
derivative work. Anyone who tries to use copyrights as if they were patents
and claims they can own *every* *way* to do a particular thing. (Especially
if those same people *oppose* software patents!)

> I don't debate that people
> are trying to coerce people into passing on the rights the GPL gave
> them when they distribute the kernel... coercion, that's what software
> licenses are.  Who's changing the rules?

Anyone who adds a mechanism to the Linux kernel, distributes the result, and
then argues that one is subjected to new restrictions on how you can modify
and distributed GPL'd works (restrictions not found in the GPL) as a result
of the code that they added.

Just to be perfectly clear, it is an outrageous claim that *every*
*possible* kernel module must be a derivative work of the kernel. Copyright
*cannot* protect every possible way to accomplish a particular function (and
"a Linux driver for the X800 graphics chipset" is a function). Copyright can
*only* protect the one possible way you chose to do something out of a large
number of equally good possible ways. (See, for example, Lexmark v. Static
Controls where courts held that Static Controls could take Lexmark's TLP
software because that was the only practical way to make a compatible toner
cartridge.)

This is an absurd claim.

DS

Re: GPL vs non-GPL device drivers

[Adrian Bunk]

On Thu, Feb 15, 2007 at 04:38:41PM -0800, David Schwartz wrote:
>...
> Just to be perfectly clear, it is an outrageous claim that *every*
> *possible* kernel module must be a derivative work of the kernel. Copyright
> *cannot* protect every possible way to accomplish a particular function (and
> "a Linux driver for the X800 graphics chipset" is a function).

This is just your personal opinion.

"derivative work" is a term with many grey areas.
Does linking create a derivative work?
Or including the code of one "static inline" function in your binary?
There is no border everyone agrees on.

And even judges in different jurisdictions might decide differently
based on different copyright laws.

Perhaps some module would be considered legal in the USA and Russia but 
illegal in Germany and China, or the other way round.

> Copyright can
> *only* protect the one possible way you chose to do something out of a large
> number of equally good possible ways. (See, for example, Lexmark v. Static
> Controls where courts held that Static Controls could take Lexmark's TLP
> software because that was the only practical way to make a compatible toner
> cartridge.)
>...

It's always funny seeing people making univeral claims only based on 
laws and court cases that have zero relevance for > 95% of all people...

> DS

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

RE: GPL vs non-GPL device drivers

[David Schwartz]

> On Thu, Feb 15, 2007 at 04:38:41PM -0800, David Schwartz wrote:

> > Just to be perfectly clear, it is an outrageous claim that *every*
> > *possible* kernel module must be a derivative work of the
> > kernel. Copyright
> > *cannot* protect every possible way to accomplish a particular
> > function (and
> > "a Linux driver for the X800 graphics chipset" is a function).

> This is just your personal opinion.

Umm, no. It's clearly the law. Again, see Lexmark v. Static Controls, among
other cases.

> "derivative work" is a term with many grey areas.
> Does linking create a derivative work?

I don't think that's grey at all. I think it's perfectly clear that linking
cannot create a derivative work. No automated process can -- it takes
creativity to create a derivative work. (That doesn't mean that just because
you can link A to B, a cannot be a derivative work of B or vice verse, of
course. It just means that if A is not a derivative work of B, linking A to
B cannot make it so, nor can the result be a derivative work.)

> Or including the code of one "static inline" function in your binary?

That would be a tricky border case. I wouldn't presume to be able to predict
the result of an inquiry into a case like that.

> There is no border everyone agrees on.

That's not the issue. The fact that we can't agree on precisely where red
ends and orange begins is not a counter-argument to a claim that a
particular thing is *clearly* red.

> And even judges in different jurisdictions might decide differently
> based on different copyright laws.

Sure, in border cases, but not in cases where it's perfectly clear.

> Perhaps some module would be considered legal in the USA and Russia but
> illegal in Germany and China, or the other way round.

I agree. I am mostly talking about US law.

> > Copyright can
> > *only* protect the one possible way you chose to do something
> > out of a large
> > number of equally good possible ways. (See, for example,
> > Lexmark v. Static
> > Controls where courts held that Static Controls could take Lexmark's TLP
> > software because that was the only practical way to make a
> > compatible toner
> > cartridge.)
> >...

> It's always funny seeing people making univeral claims only based on
> laws and court cases that have zero relevance for > 95% of all people...

I cite the case only because it does a good job of explaining the principle.
Copyright cannot allow you to own every practical way of accomplishing
something. It can only allow you to own the one particular way you chose to
do something out of a universe of other possible equally good ways. Only
patent allows you to protect the "best way" or "every way" to perform a
function.

DS

RE: GPL vs non-GPL device drivers

[Neil Brown]

On Friday February 16, davids@webmaster.com wrote:
>
> I cite the case only because it does a good job of explaining the principle.
> Copyright cannot allow you to own every practical way of accomplishing
> something. It can only allow you to own the one particular way you chose to
> do something out of a universe of other possible equally good ways. Only
> patent allows you to protect the "best way" or "every way" to perform a
> function.

I think you have over-simplified this principle.

Suppose someone created a work of fiction titled - for example -
"Picnic at Hanging Rock".  And suppose further that this someone left
some issues unresolved at the end of the story, leaving many readers
feeling that they wanted one more chapter to complete the story and
give them a sense of closure.

Suppose that a number of independent individuals wrote such a chapter
that in very different ways completed the story.

You seem the be claiming that because copyright "Cannot allow you to
own every practical way of accomplishing something" that the original
author has no rights over any of these "final chapters" as they are
all ways to accomplish "complete the story of A Picnic at Hanging
Rock".

But I'm fairly sure you would find that isn't true.  All of those
final chapters would be derived works of the original work of fiction
so that the original author would have some rights over how they were
used.

They are derived works because they borrow the characters, the setting,
the theme, etc of the original work, and build on it.

In a similar way, people claim that any driver written for Linux will
inevitably borrow some creative content that is in Linux, via the
various interfaces that are used (and it is the nature of kernel
modules that the interface between the module and the kernel is quite
intimate).  And so, they claim that any driver written for Linux will
ipso-facto be a derived work.  The interface that ties the kernel and
the module together is certainly more intimate than the interface
between the Printer and the Toner in the Lexmark case.

Also, the "every practical way" point doesn't entirely apply.  In a
growing number of cases, it is possible to write a driver in
user-space.  This is apparently true for USB and is becoming true for
PCI.  And writing drivers as user-space programs is explicitly not a
derived work for the purposes of the Linux kernel license.

So while that case sets an interesting precedent, I don't think it can
apply to the general issue of Linux kernel modules.

NeilBrown

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/17/07, Neil Brown <neilb@suse.de> wrote:
> Suppose someone created a work of fiction titled - for example -
> "Picnic at Hanging Rock".  And suppose further that this someone left
> some issues unresolved at the end of the story, leaving many readers
> feeling that they wanted one more chapter to complete the story and
> give them a sense of closure.
>
> Suppose that a number of independent individuals wrote such a chapter
> that in very different ways completed the story.
[snip]
> They are derived works because they borrow the characters, the setting,
> the theme, etc of the original work, and build on it.

Very well put.  That doctrine is sometimes known as "mise en scene",
and is every bit as applicable to software as to any other sort of
creative work.  When, that is, the software has characters, setting,
theme, etc.  See Micro Star v. Formgen (available anywhere Google hits
are sold).

> In a similar way, people claim that any driver written for Linux will
> inevitably borrow some creative content that is in Linux, via the
> various interfaces that are used (and it is the nature of kernel
> modules that the interface between the module and the kernel is quite
> intimate).  And so, they claim that any driver written for Linux will
> ipso-facto be a derived work.  The interface that ties the kernel and
> the module together is certainly more intimate than the interface
> between the Printer and the Toner in the Lexmark case.

Yes, people claim these things.  It's just that they're wrong.  Read
Lexmark.  Read the First Circuit opinion in Lotus v. Borland.  For
some really eye-opening dialogue, read the transcript of oral argument
before the Supreme Court in the Lotus v. Borland certioriari
proceeding.  For some long-winded but cogent discourse, read the
amicus curiae brief of the League for Programming Freedom in Lotus v.
Borland, submitted to the Supremes by one Eben Moglen.  If you can
read that and still tolerate the stench of the FSF's argument that
linking against readline means they 0wn your source code, you have a
stronger stomach than I.

> Also, the "every practical way" point doesn't entirely apply.  In a
> growing number of cases, it is possible to write a driver in
> user-space.  This is apparently true for USB and is becoming true for
> PCI.  And writing drivers as user-space programs is explicitly not a
> derived work for the purposes of the Linux kernel license.

"Possible" doesn't mean "practical".  Compare Galoob and Micro Star,
Atari v. Nintendo and Sega v. Accolade.  There's a fine line, and
Judge Sutton walked up one side of it and down the other, and his
fellow panelists ably advocated drawing it either to the left or to
the right of where he had.  When the Supremes denied cert. -- in a
case where the appellate court had vacated and remanded to the
district court, meaning that they had to demonstrate that the lower
court had erred _as_a_matter_of_law_ -- they endorsed Judge Sutton's
reading of the record.  Lexmark is now settled law.
MODULE_LICENSE("GPL") on a binary-only turd is -- insofar as you can
demonstrate to the court of fact that it resembles the Lexmark fact
pattern, anywhere in the US -- as legal as an 8.5" x 14" pad of yellow
paper.  IANAL, TINLA.

> So while that case sets an interesting precedent, I don't think it can
> apply to the general issue of Linux kernel modules.

I mean this in the nicest possible way:  Think again.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/18/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> If you can
> read that and still tolerate the stench of the FSF's argument that
> linking against readline means they 0wn your source code, you have a
> stronger stomach than I.

Such a strange attitude.. to go to all this effort to quote carefully
and correctly one set of people and to then total misconstrue the
words of another.

The FSF's argument in regards to readline is that you may not
distribute readline with proprietary software linked to it.  They
don't claim they "0wn" your source code.

Trent

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

This screed is the last that I am going to pollute LKML with, at least
for a while.  I'll write again if and when I have source code to
contribute, and if my off-topic vitriol renders my technical
contributions (if and when) unwelcome, I'll understand.  FSF
skulduggery is not very relevant to the _engineering_ of the kernel,
but it is (or ought to be) relevant to people's beliefs about whether
EXPORT_SYMBOL_GPL is the right thing to do.

On 2/17/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> On 2/18/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> > If you can
> > read that and still tolerate the stench of the FSF's argument that
> > linking against readline means they 0wn your source code, you have a
> > stronger stomach than I.
>
> Such a strange attitude.. to go to all this effort to quote carefully
> and correctly one set of people and to then total misconstrue the
> words of another.

Dammit, the world at large has been far too nice to these people for
far too long.  There's no sin in people getting rich and/or famous,
but how they did it deserves some scrutiny.  The FSF is leading
thousands of idealistic young people all over the world up the garden
path by bullshitting about the nature of US law, and if Moglen at
least isn't making bank doing it, it isn't for lack of trying.  For
starters, read http://lists.debian.org/debian-legal/2005/07/msg00531.html
(another self-reference that doesn't need flowing in).  Google around
for his letters of opinion (not pro bono, I assure you) to Fluendo and
Vidomi.  How do they smell to you?

The GPL is big money, folks; the FSF General Counsel's designing "GPL
circumvention" schemes for other people's software -- and estopping
away his ability to contest them in court, one letter of opinion (and
one hefty lump-sum fee) at a time -- isn't a tenth of it.  Ask the
OSDL, who (I am very sorry to report) funneled $4M of certain hardware
makers' money to the SFLC to bankroll the expansion of Moglen's
protection racket.  Yes, protection racket.  What other phrase could
possibly describe the Software Freedom Conservancy?

Speaking of protection rackets, how about Moglen's plaintive comments,
back in the day, to the effect of (not a direct quote):  "The
conditions of the GPL can't touch Red Hat's new trademark policy,
subscription agreement, and ISV support lock-ins because they aren't
about copyright.  The GPL, as we all know, is a creature of copyright
law.  Even though the GPL says plainly, 'You must cause any work that
you distribute or publish, that in whole or in part contains or is
derived from the Program or any part thereof, to be licensed as a
whole at no charge to all third parties under the terms of this
License', that can't possibly be taken as an 'entire agreement'
clause, because the GPL isn't an offer of contract.  Don't like having
to pay per seat for RHEL?  Sorry, we can't help you."

This would be the same Red Hat that bought Cygnus Solutions in 1999 at
an estimated price of 674 MILLION dollars (in stock, of course).  That
made some individual Cygnus stockholders rich; see
http://www.salon.com/tech/feature/1999/11/18/red_hat/print.html.  Want
to bet Moglen held a Cygnus share or two, along with (via the FSF)
control over all the source code Cygnus had ever produced?  How does
it smell now?

There's yet more money in the toolchain oligopoly that Moglen and
Redmond tacitly share, and in embedded targets generally.  (Have you
ever asked yourself how the XCode and Tornado IDEs happened?  Have you
ever tried to obtain their source code?  Now do you understand why the
FSF fetishizes the fork/exec boundary?)  Redmond is not the FSF's
enemy; the phantom menace called "software patents" is, because they
protect other software makers from the FSF's volunteer army of reverse
engineers.  All those crocodile tears over TiVo, just because they
forked GCC, put the lower layers of MPEG into silicon, and wrote their
own damn DRM in RTL, instead of toeing Moglen's line on "give me naked
ripped media or give me death".  (No, I don't have first-hand
knowledge of any of these dealings; do your own research if you want
the sordid details.)

The FSF doesn't bother with kernels.  The HURD (nee Alix) is RMS's pet
project, and there are some charming young fellows who truly believe
it's going to win time trials and cure cancer someday, but I doubt
anyone in the know ever put cash money into it.  Some kernels are
better than others but once they work they're pretty interchangeable
for desktop and low-grade network server workloads.  They do, however,
take more engineering skill than the world's most prolific cloner of
other people's interfaces (RMS, in case that isn't blindingly obvious)
has ever been able to muster.  (RMS's skill exceeds mine, or used to;
but not by the light-years that Linus's, or even Theo's, does.)

However, the FSF is very careful not to let kernel authors' peanut
butter into _their_ chocolate, because the money is in supporting
toolchains for _proprietary_ kernels (VxWorks, anyone? Darwin?
whatever the iPod is running?).  Someday they're going to screw Linus,
and all of us, over big-time with artful text in LGPL v3.  Have you
ever done the gcc / glibc / kernel-headers dance?  Has it ever
occurred to you to wonder what's going to happen when gcc's and
glibc's licenses are no longer "compatible" with the v2-only kernel?
(Thank God and Linus the kernel is v2-only; see
http://lists.debian.org/debian-legal/2005/05/msg00122.html, again a
self-reference.)  Do /usr/include, libc.so.6, and libstdc++ become
"undistributable"?  How are you going to like being forced to fork the
entire GNU corpus in whatever state it's in the day before the v3
conversion hits SVN?  Xorg is going to look like a cakewalk by
comparison.

> The FSF's argument in regards to readline is that you may not
> distribute readline with proprietary software linked to it.  They
> don't claim they "0wn" your source code.

Let us deconstruct the most polished and redacted variant I can find
of Stallman's readline saga, found at
http://www.oreilly.com/catalog/opensources/book/stallman.html:

<RMS>
The GNU Library GPL

The GNU C library uses a special kind of copyleft called the GNU
Library General Public License (LPGL), which gives permission to link
proprietary software with the library. Why make this exception?

It is not a matter of principle; there is no principle that says
proprietary software products are entitled to include our code. (Why
contribute to a project predicated on refusing to share with us?)
Using the LGPL for the C library, or for any library, is a matter of
strategy.

The C library does a generic job; every proprietary system or compiler
comes with a C library. Therefore, to make our C library available
only to free software would not have given free software any
advantage--it would only have discouraged use of our library.

One system is an exception to this: on the GNU system (and this
includes GNU/Linux), the GNU C library is the only C library. So the
distribution terms of the GNU C library determine whether it is
possible to compile a proprietary program for the GNU system. There is
no ethical reason to allow proprietary applications on the GNU system,
but strategically it seems that disallowing them would do more to
discourage use of the GNU system than to encourage development of free
applications.

That is why using the Library GPL is a good strategy for the C
library. For other libraries, the strategic decision needs to be
considered on a case-by-case basis. When a library does a special job
that can help write certain kinds of programs, then releasing it under
the GPL, limiting it to free programs only, is a way of helping other
free software developers, giving them an advantage against proprietary
software.

Consider GNU Readline, a library that was developed to provide
command-line editing for BASH. Readline is released under the ordinary
GNU GPL, not the Library GPL. This probably does reduce the amount
Readline is used, but that is no loss for us. Meanwhile, at least one
useful application has been made free software specifically so it
could use Readline, and that is a real gain for the community.

Proprietary software developers have the advantages money provides;
free software developers need to make advantages for each other. I
hope some day we will have a large collection of GPL-covered libraries
that have no parallel available to proprietary software, providing
useful modules to serve as building blocks in new free software, and
adding up to a major advantage for further free software development.
</RMS>

On second thought, let's not deconstruct this.  It's too much work,
and it's a waste of time.  Because if you can't read "anything other
people wrote is fair game, but what we write is sacred; our strategy
is to cajole when we can and strong-arm when we can't, and the law be
damned" into that, no amount of verbiage from me is going to change
your mind.

I will end with something I wrote to debian-legal a year and a half
ago.  A pretty decent guy said it constituted "character
assassination" and "destroys my credibility".  It distresses me that
he should have reacted that way, and it distresses me that chastising
me for "misconstruing" the FSF's attitude and public statements should
take precedence in your mind over assessing the evidence I bring to
bear on the legal issues at hand.  Distresses, but does not surprise;
they've gotten away with it on sheer holier-than-thou effrontery for
almost twenty years now, and that seems unlikely to change until
someone with deep pockets grows the cojones to challenge them in court
with a winnable fact pattern.

<me, back then, exasperated>
> Let me try again.  Eben Moglen has a J. D. from Yale.  He has been
> admitted to the bar in New York and before the Supreme Court.  He has
> clerked in district court and for Justice Thurgood Marshall.  He has
> held a professorship of law and legal history at Columbia for over a
> decade.  He is not ignorant of the law.  It is my opinion that he
> knows damn well that there is no such thing as "copyright-based
> license" and never has been.
>
> It's very useful as a propaganda device to make it appear that there
> is some rich vein of unmined law in this area, and therefore some
> difficulty in applying the mountain of case law relevant to any given
> fact pattern involving the GPL.  But the truth as I see it (and I am
> not alone) is that the GPL is a somewhat unconventionally drafted but
> otherwise completely routine contract of adhesion.  If this is in fact
> the truth, then many of the things that he, and other attorneys
> closely associated with the FSF, say in public about the GPL are
> untrue, perhaps even deliberately misleading.  That doesn't inspire my
> respect.
</me, now, no less exasperated>

- Michael

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

> On second thought, let's not deconstruct this.  It's too much work,
> and it's a waste of time.  Because if you can't read "anything other
> people wrote is fair game, but what we write is sacred; our strategy
> is to cajole when we can and strong-arm when we can't, and the law be
> damned" into that, no amount of verbiage from me is going to change
> your mind.

Er, that would be, "cajole when we must and strong-arm whenever we
can".  That didn't stay on the floor long enough to pick up any germs;
doesn't count.  :-)

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Oleg Verych]

> From: "Michael K. Edwards"
> Newsgroups: gmane.linux.kernel
> Subject: Re: GPL vs non-GPL device drivers
> Date: Sat, 17 Feb 2007 22:56:00 -0800
[]
> How are you going to like being forced to fork the entire GNU corpus in
> whatever state it's in the day before the v3 conversion hits SVN?  Xorg
> is going to look like a cakewalk by comparison.

Don't worry, just help ;)

Ulrich Drepper is known to be against current FSF's position on glibc
licence changing.

Linus Torvalds has wrote sparse, which got it's maintainer. Maybe Google,
if it will, will do some job(backend) to get GCS (Google Compiling
Serivice ;), no need in compiler here (tm;).

Jeff Garzik doing his POSIX utilites.

There are many other alternatives to GNU software, and they are working
and being maintained, being "nongnu.org" or in their open source zoos,
rather than in savannah(.gnu.org (:

- dash / busybox (rip GNU bash)
- builders (many, rip GNU make)
- s-lang lib (rip GNU ncurses)
- jed, Xemacs (rip GNU Emacs)
....

After making live alternative to GNU software, you may *say* and *do*
everything you like against it. Indeed, i think Linux Kernel club is one
of such creatures (not with bull's head ;)

So, as you can see it's OK. Just grab your "non-GNU-Emacs" and join
the club!

Cheers.

p.s. i can be very naive, of course.
--
-o--=O`C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found      o (    yes --- R.I.P. FSF+RMS    )
<___=E M  man gcc    : not found    `-- ( viva Debian Operating System )

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

Eensy weensy follow-up.  No screed.  Well, maybe just a _little_ screed.

On 2/18/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> Ulrich Drepper is known to be against current FSF's position on glibc
> licence changing.

Will that stop the FSF?  Will it stop Red Hat, MontaVista, or
CodeSourcery?  Even if Ulrich tells the FSF to stuff it where the sun
don't shine, and hosts his new fork on Google Code along with the rest
of the GNU corpus, the moment he or you or any of us wants to run any
binary that was compiled against a newer FSF glibc, we're screwed.
All it takes is for that binary to have a post-v3-switch symbol in its
link table (which can easily happen _without_ any change in the
application source code).

It's all very well to say we can live without anything that ships as a
binary, but commercial applications atop glibc are a big part of how
Linux left the hobbyist ghetto, and I don't want to go back there.  Do
you?  Or do you really want to spend the rest of your precious time on
Earth shimming clean-room reverse-engineered crap into
glibc-GPLv2-fork to keep Oracle running on a distro that Moglen
doesn't have by the 'nads?  Not that it really matters whether you're
using Oracle or MySQL -- an RDBMS, like any racing thoroughbred, goes
lame if you look at it funny, and once you've gotten burned once in
production by the unreproducibility of the golden bits, you won't try
it again.

The existence of GNU-free userlands is nice for us embedded folk but
ultimately useless for desktops and servers.  Talk to the people who
have spent untold person-years scrubbing bashisms out of Debian's
/etc/init.d.  Talk to the people who have ported their
industrial-scale multithreaded apps from linuxthreads (with its
annoying non-POSIX behaviors) to NPTL (with its equally annoying POSIX
behaviors).  Talk to the people struggling to package Gnome and KDE
for anything other than glibc, libstdc++, and (worst of all) ld.so.2.
Portability ain't all it's cracked up to be.

If you think "embrace, extend, destroy" is tattooed on Ballmer's
forehead, you should take a good look at an RMS word-portrait
sometime.  And imagine a nice private chat with the
if-you-can't-beat-'em-join-'em club -- from IBM and HP to Apple, Wind
River, and Sun.  Say what you will about Steve Jobs, he's a survivor
-- but the ex-CEOs of all the rest will give you an earful about being
shot out of the saddle by the "free software" mafia and replaced with
people who know how to do a deal with the devil and call it a
come-to-Jesus moment in the press release.

Intel is keeping mum -- they've made an industry out of playing both
ends against the middle, and they've got a compiler that can more or
less do Linux anyway, so they don't really care.  Google doesn't care
either -- they've got more cash than they can spend and can afford to
fork internally and go their merry way.  The only heavyweight that had
refused to get on board until very recently was Oracle.  Not just
because Larry Ellison likes to fly solo, either -- read
http://www.internetnews.com/dev-news/article.php/3614721.  Then read
http://www.internetnews.com/dev-news/article.php/3655261.  Larry, too,
is a survivor.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Theodore Tso]

On Sun, Feb 18, 2007 at 01:26:47PM +1000, Trent Waddington wrote:
> Such a strange attitude.. to go to all this effort to quote carefully
> and correctly one set of people and to then total misconstrue the
> words of another.
> 
> The FSF's argument in regards to readline is that you may not
> distribute readline with proprietary software linked to it.  They
> don't claim they "0wn" your source code.

Actually, the FSF and many of its representatives, has claimed, on
many occassions, that the GPL infects across dynamic linking.  That
is, if you write your own code that calls readline which links via a
dynamically linked shared library, and perhaps even across dlopen(),
they claim that the GPL applies to the code which you write.  Given
that the only way this could happen is via copyright law, they are
basically saying that if you use the readline interface, you have
created a derived work and they therefore 0wn your source code.

Whether or not this would be laughed out of court or not will very
much depend on the local legal precedents (and Trent Waddington has
quoted some very interesting legal cases based on US court decisions,
including an entertaining brief written by Eben Moglen decrying
interface copyrights which on the surface seems to go against
everything else the FSF has said since the Lotus case), but the
kernel-mailing list isn't the place to debate how law can be applied
to facts, or whether or not Eben Moglen is a hypocrite or not.

So can we please stop now?  I doubt anyone is going to be able to
convince anyone else on this matter; people's opinions are pretty well
formed by now, and until someone chooses to litigate on this specific
point about whether or not the GPL (v2 or v3) can infect across a
dynamic link in various jurisdictions, we're not going to settle it here.

Regards,

						- Ted

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/18/07, Theodore Tso <tytso@mit.edu> wrote:
> Actually, the FSF and many of its representatives, has claimed, on
> many occassions, that the GPL infects across dynamic linking.  That
> is, if you write your own code that calls readline which links via a
> dynamically linked shared library, and perhaps even across dlopen(),
> they claim that the GPL applies to the code which you write.  Given
> that the only way this could happen is via copyright law, they are
> basically saying that if you use the readline interface, you have
> created a derived work and they therefore 0wn your source code.

Is that so?

> Whether or not this would be laughed out of court or not will very
> much depend on the local legal precedents (and Trent Waddington has
> quoted some very interesting legal cases based on US court decisions,

Wow?  I did?  Really?  I must have been sleep typing.

Trent

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/17/07, David Schwartz <davids@webmaster.com> wrote:
> I don't think that's grey at all. I think it's perfectly clear that linking
> cannot create a derivative work. No automated process can -- it takes
> creativity to create a derivative work. (That doesn't mean that just because
> you can link A to B, a cannot be a derivative work of B or vice verse, of
> course. It just means that if A is not a derivative work of B, linking A to
> B cannot make it so, nor can the result be a derivative work.)

Sigh.  VJ is distributing the linux kernel with proprietary
extensions.  If you want to argue that the proprietary extensions in
isolation are not derivative works of the kernel, fine, you might have
a case, but the combined work, which VJ is distributing is *clearly* a
derivative work and must be distributed under the terms of the GPL.

Despite which, legal bullshit is best left for lawyers.. the *intent*
of the GPL is that if you distribute *any* changes, extensions or
plugins for a GPL work, you do so under the GPL.  The law may not
allow for this to be enforced, but it shouldn't need to.. one should
read the GPL as 100% enforceable and follow it without looking for
"loop holes" as it is the stated desire of how the author of the code
wants you to use his work.  Looking for loop holes, and worse yet,
discussing those loop holes in a public place, is just insulting.

Trent

Re: GPL vs non-GPL device drivers

[David Lang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed, Size: 3821 bytes --]

On Sun, 18 Feb 2007, Trent Waddington wrote:

> Despite which, legal bullshit is best left for lawyers.. the *intent*
> of the GPL is that if you distribute *any* changes, extensions or
> plugins for a GPL work, you do so under the GPL.  The law may not
> allow for this to be enforced, but it shouldn't need to.. one should
> read the GPL as 100% enforceable and follow it without looking for
> "loop holes" as it is the stated desire of how the author of the code
> wants you to use his work.  Looking for loop holes, and worse yet,
> discussing those loop holes in a public place, is just insulting.

by this same logic the EULA's that various commercial vendors use are completely 
valid, and the e-mail sigs that make you liable for reading e-mail are also 
valid.

it doesn't matter what the intent is if it's not a legal thing to require.

in the case of the GPL the key is the border of being a drivitive work or not.

some people would like to interpret this so broadly as to make it impossible to 
run userspace code on a GPL OS, however everyone who is sane recognises that 
this is beyond the boundry.

in the case of kernel modules, this is very murky territory, and it's one that 
nobody has felt compelled (and confident enough in the outcome) to litigate.

I've heard many people express their opinion on what it takes to be a derivitive 
work, but very few lawyers

one of the few that I have seen is from IBM's lawyers in the SCO case

quote:
  Second, SCO's claim that Dynix/ptx is a "derivative work" within the meaning of SCO's definition is likewise unhelpful to its motion. As an initial matter, the assertion is untenable because it is based on a definition of "derivative works based on such SOFTWARE PRODUCT" that is unsupported and in dispute (as stated above). Moreover, SCO fails even to identify the versions and components of the SOFTWARE PRODUCT and Dynix/ptx to which SCO refers. It is impossible to determine whether one product is a derivative work of another product without specific reference to what is at issue. See Gates Rubber Co. v. Bando Chem. Indus., 9 F.3d 823, 834 (10th Cir. 1993) (indicating that, in determining whether one work is a derivative of another, a court should "dissect", "examine", and "compare" the two specific works in question).

To support the proposition that Dynix/ptx is a derivative work of UNIX System V, SCO relies entirely on the testimony of its experts, Mr. Marc Rochkind and Dr. Thomas Cargill. However, as SCO admits, Mr. Rochkind's testimony is based solely on a "computer-science perspective". (SCO Br. at 14.) There is no basis for importing into the Agreement the perspective of a single computer scientist offered two decades after the Agreement was signed and providing no objective standard for his testimony. 4 See Fed. R. Evid. 702 (requiring that expert testimony be "the product of reliable principles and methods"). The term "derivative work" is a term of art under copyright law and is explicitly defined in the Copyright Act as "a work that is based on (or derived from) one or more already existing works. . . in which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship". 17 U.S.C.A. § 101 (West 2006). In the absence of a provision in the Agreement to the contrary, the term "derivative work" should be understood to have the meaning that it has under federal law. One of IBM's experts, Professor Randall Davis, has provided unrebutted testimony that the portions of Dynix specifically challenged by SCO are not derivative works of UNIX System V. (Ex. 181 ¶50.)

this seems to be saying that the boundries of derivitive work as far as 
copyright goes are much more limited then just about anyone in computer science 
would define the term

David Lang

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/18/07, David Lang <david.lang@digitalinsight.com> wrote:
> by this same logic the EULA's that various commercial vendors use are
> completely valid,
>
> it doesn't matter what the intent is if it's not a legal thing to require.

Yes, it does matter.. the author of the work has defined the terms
under which you may use it.. if you don't like it, don't use the work.

There's a name for people who look at everything in terms of "you
can't make me".

Trent

RE: GPL vs non-GPL device drivers

[David Schwartz]

> Sigh.  VJ is distributing the linux kernel with proprietary
> extensions.  If you want to argue that the proprietary extensions in
> isolation are not derivative works of the kernel, fine, you might have
> a case, but the combined work, which VJ is distributing is *clearly* a
> derivative work and must be distributed under the terms of the GPL.

There is no such thing as the "combined work". If I put a DVD of The Phantom
Menace in the same box as a DVD of The Big Lebowski, the box is not a
"combined work".

VJ is, presumably, distributing the Linux kernel and some additional works
that he has written. There is no "combined work" just because the two works
are distributed on the same media. There isn't even a "combined work" just
because the two works were designed to work together. (The DVD of the
Phantom Menace was designed to work with the firmware in my DVD player, but
it's absurd to argue that there is a "combined work" or that one is
derivative of the other.)

> Despite which, legal bullshit is best left for lawyers.. the *intent*
> of the GPL is that if you distribute *any* changes, extensions or
> plugins for a GPL work, you do so under the GPL.

Suppose the intent of the Microsoft EULA was that if you ever used Windows,
Microsoft owned every work of software you ever wrote. Should this "intent"
be honored? This kind of intent -- the intent of a license author to try to
leverage the license to own someone else's work, should be ridiculed and
dishonored.

> The law may not
> allow for this to be enforced, but it shouldn't need to.. one should
> read the GPL as 100% enforceable and follow it without looking for
> "loop holes" as it is the stated desire of how the author of the code
> wants you to use his work.  Looking for loop holes, and worse yet,
> discussing those loop holes in a public place, is just insulting.

I think this is a completely irrational view. The GPL *is* the rule we've
all been playing by. Not something in RMS' head. People who have chosen to
apply the GPL know what the GPL says, and only to some extent know what
other people meant or intended by it. The GPL *is* the rule.

As for law and loop holes, that's the supreme irony. The same people who
argue that people have too little freedom and intellectual property rights
are too great (and who oppose software patents) still seem to argue that
when *their* intellectual property is at stake, not even the law and the
text of their license limits their powers and control.

Let's not be a bunch of hypocrites.

> Yes, it does matter.. the author of the work has defined the terms
> under which you may use it.. if you don't like it, don't use the work.

Right, don't believe all that crap about "freedom". That's just PR speak.

DS

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, David Schwartz <davids@webmaster.com> wrote:
> There is no such thing as the "combined work". If I put a DVD of The Phantom
> Menace in the same box as a DVD of The Big Lebowski, the box is not a
> "combined work".

If you can't even agree on that the legal concept of a combined work
exists then you're obviously too far from reality for anyone to reason
with.

Trent

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/19/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> If you can't even agree on that the legal concept of a combined work
> exists then you're obviously too far from reality for anyone to reason
> with.

Bah.  Show us a citation to treaty, statute, or case law, anywhere in
the world, Mr. Consensus-Reality.

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> Bah.  Show us a citation to treaty, statute, or case law, anywhere in
> the world, Mr. Consensus-Reality.

It's a given.. are you seriously contending that if you combine two
copyright works you are not obliged to conform with the conditions of
the license on one of them when making a copy of the combined work?

If you are just arguing about the term, what term do you find more
appropriate?  Compilation?

You guys seem to love pointless semantic arguments.  Are you always in
violent agreement?

Trent

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/19/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> On 2/20/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> > Bah.  Show us a citation to treaty, statute, or case law, anywhere in
> > the world, Mr. Consensus-Reality.
>
> It's a given.. are you seriously contending that if you combine two
> copyright works you are not obliged to conform with the conditions of
> the license on one of them when making a copy of the combined work?

There is no legal meaning to "combining" two works of authorship under
the Berne Convention or any national implementation thereof.  If you
"compile" or "collect" them, you're in one area of law, and if you
create a work that "adapts" or "recasts" (or more generally "derives
from") them, you're in another area of law.  A non-exclusive license
can authorize one of these categories of conduct and not the other, or
can slice and dice the scope of the license along almost any axis of
law or fact.  But what it can't do is use the phrase "derivative work"
passim -- a legal term of art invented by US judges and legislators to
corral a class of infringing works and treat them differently from
compilations -- and pretend that it also encompasses compilations
(copyrightable and otherwise; there is an originality threshold here
too) and use by reference.

> If you are just arguing about the term, what term do you find more
> appropriate?  Compilation?

If the amount of "adapting, translating, and recasting" done to the
pre-existing works crosses a minimum threshold of creative expression
(not "sweat of the brow", at least not under Feist), then you've
created a derivative work.  If the amount of "selecting and arranging"
done to create a compilation crosses a similar threshold of creative
expression, you've created a copyrightable compilation or collective
work.  If neither, then all you've done is copy and distribute.
That's how the law works.  IANAL, TINLA.

> You guys seem to love pointless semantic arguments.  Are you always in
> violent agreement?

Perhaps pointless if you were the sole audience, since you seem
disinclined to evaluate the accuracy of your beliefs given novel
information backed by extensive citations to the primary literature.
Not pointless if it disabuses other people, with less deeply ingrained
errors of understanding, of the notion that they can trust certain
very heavily financially interested parties to tell them the truth
about what the law says.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> There is no legal meaning to "combining" two works of authorship under
> the Berne Convention or any national implementation thereof.  If you
> "compile" or "collect" them, you're in one area of law, and if you
> create a work that "adapts" or "recasts" (or more generally "derives
> from") them, you're in another area of law.

As I said, you're having a purely semantic argument.

Regardless of what you *call* it, shoving two works together does not
excuse you from the conditions of the license on one of those works,
*when you make a copy*.  And that's the GPL in a nutshell, if you want
to copy the work, you need a license, if you want a license, you must
abide the conditions, and one of the conditions is that you may not
combine it with a work that is under an incompatible license unless it
is mere aggregation.

Of course, now you're going to argue that there's no such thing as an
"incompatible license" or "mere aggregation" and that these are just
words that were made up for the GPL, so they can be ignored.. another
pointless semantic argument because it doesn't change the very simple
fact that you don't have any rights to copy the work unless you have a
license and you don't have a license if you fail to abide the
conditions of the license.

Trent

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/19/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> Of course, now you're going to argue that there's no such thing as an
> "incompatible license" or "mere aggregation" and that these are just
> words that were made up for the GPL, so they can be ignored.. another
> pointless semantic argument because it doesn't change the very simple
> fact that you don't have any rights to copy the work unless you have a
> license and you don't have a license if you fail to abide the
> conditions of the license.

I don't have to argue these points, because they're obvious to anyone
who cares to do their own homework.  Appellate court decisions _are_
the law, my friend; read 'em and weep.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> I don't have to argue these points, because they're obvious to anyone
> who cares to do their own homework.  Appellate court decisions _are_
> the law, my friend; read 'em and weep.

Hang on, you're actually debating that you have to abide by conditions
of a license before you can copy a copyright work?

Please, tell us the names of these appellate court decisions so that
we can read them and weep.

Trent

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/19/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> Hang on, you're actually debating that you have to abide by conditions
> of a license before you can copy a copyright work?
>
> Please, tell us the names of these appellate court decisions so that
> we can read them and weep.

Can we put the gamesmanship on "low" here for a moment?  Ask yourself
which is more likely: am I a crank who spends years researching the
legal background of the GPL solely for the purpose of ranting
incoherently on debian-legal and LKML, or am I a mid-career embedded
software developer with an obsessive streak who has come to a
realization how dangerous this whole EXPORT_SYMBOL_GPL business is to
his niche in the industry?  Do I have an irrational hatred for people
named Eben, or am I sick to the heart of seeing decent young kids'
beliefs about the law perverted by a racketeer in attorney's clothing
with (at an informed guess) somewhere between $300K and $2M a year in
easy money from his web of "non-profit" shell companies?  I may be
_wrong_ -- but I'm not _witless_.

Now, if you want to play games, get yourself a copy of this
new-fangled invention called a "web browser", and Google for each set
of capitalized words with a "v." in between that has appeared in my
posts to LKML in the last few days.  For extra credit, follow links to
older posts, cleverly signposted with "http://".  Repeat ad nauseam.
When you have an argument to offer that isn't already a blenderized
equine, preferably associated with a citation to one of those shiny
URL thingies with an "edu" or a "findlaw" in it, or even one of those
phrases with the magic "v.", I'm all ears.  Good morning -- and if I
don't see ya, good afternoon, good evening, and good night.

- Michael

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> Can we put the gamesmanship on "low" here for a moment?  Ask yourself
> which is more likely: am I a crank who spends years researching the
> legal background of the GPL solely for the purpose of ranting
> incoherently on debian-legal and LKML,

that's what I figured yes, as you're obviously not interested in
convincing anyone of your opinions, otherwise you wouldn't mind
repeating yourself when someone asks you a simple question.

Trent

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/19/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> that's what I figured yes, as you're obviously not interested in
> convincing anyone of your opinions, otherwise you wouldn't mind
> repeating yourself when someone asks you a simple question.

No, dear, I'm just not interested in convincing you if you can't be
bothered to look back in the thread and Google a bit.  Think of it as
a penny ante, which is pretty cheap in a card game with billion-dollar
table stakes.

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> No, dear, I'm just not interested in convincing you if you can't be
> bothered to look back in the thread and Google a bit.  Think of it as
> a penny ante, which is pretty cheap in a card game with billion-dollar
> table stakes.

Well, with that attitude I can't imagine why people would think you're
a crackpot.. Maybe if you cut back on what you believe the motive is
for Eben Moglen wanting to misconstrue the law and focus on what you
actually claim the law is then people wouldn't mind trawling through
your insane ramblings to find the references that you claim back up
your extraordinary claims.

Now if you care to repeat your references here, without rambling on,
I'm happy to go read them and temporarily suspend my belief that
you're a crackpot.

Trent

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

And for those reading along at home, _surely_ you understand the
meanings of "ambiguities in an offer of contract must be construed
against the offeror", "'derivative work' and 'license' are terms of
art in copyright law", and "not a valid limitation of scope".  If not,
I highly recommend to you that master of exposition who goes by "Op.
Cit.".

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> And for those reading along at home, _surely_ you understand the
> meanings of "ambiguities in an offer of contract must be construed
> against the offeror", "'derivative work' and 'license' are terms of
> art in copyright law", and "not a valid limitation of scope".  If not,
> I highly recommend to you that master of exposition who goes by "Op.
> Cit.".

You're really not helping yourself in making a convincing argument here.

Trent

Re: GPL vs non-GPL device drivers

[Trent Waddington]

Just in case anyone cares, after speaking with Michael for a few hours
I've found he's not nearly as abrasive as this mailing list banter
might suggest.  He makes some good arguments once you stop him from
spouting conspiracy stuff and, although I don't agree with all of
them, I think he has some good points.  He suggested posting a
transcript of our chat but, frankly, I don't think anyone wants to
read that.

Trent

Re: GPL vs non-GPL device drivers

[v j]

On 2/19/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> Just in case anyone cares, after speaking with Michael for a few hours
> I've found he's not nearly as abrasive as this mailing list banter
> might suggest.  He makes some good arguments once you stop him from
> spouting conspiracy stuff and, although I don't agree with all of
> them, I think he has some good points.  He suggested posting a
> transcript of our chat but, frankly, I don't think anyone wants to
> read that.

If you can translate what he had to say in English, I certainly would
be willing to hear about it.

vj.

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> I don't think anyone wants to read that.

I guess that was a stupid thing to say.  Ok, fine people, Michael is
ok with me posting this, so enjoy:

http://rtfm.insomnia.org/~qg/chat-with-michael-k-edwards.html

There ya go.

Trent

RE: GPL vs non-GPL device drivers

[David Schwartz]

Combined responses

> On 2/20/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> > There is no legal meaning to "combining" two works of authorship under
> > the Berne Convention or any national implementation thereof.  If you
> > "compile" or "collect" them, you're in one area of law, and if you
> > create a work that "adapts" or "recasts" (or more generally "derives
> > from") them, you're in another area of law.

> As I said, you're having a purely semantic argument.

When someone uses a term that can mean more than one possible thing and then
uses the fact that it's true for one meaning to argue that it must be true
for the other, what else can you do other than point out that the term they
are using has multiple meanings?

> Regardless of what you *call* it, shoving two works together does not
> excuse you from the conditions of the license on one of those works,
> *when you make a copy*.

Nobody is arguing otherwise. Nobody is saying "you don't have to comply with
the GPL". We're saying that the GPL doesn't mean what people think it means.
In some cases it's because of the GPL's wording, but in other cases it's
because the GPL cannot set its own scope.

> And that's the GPL in a nutshell, if you want
> to copy the work, you need a license, if you want a license, you must
> abide the conditions, and one of the conditions is that you may not
> combine it with a work that is under an incompatible license unless it
> is mere aggregation.

Right. And all the cases we are talking about are mere aggregation (that is,
they do not create derivative works).

> Of course, now you're going to argue that there's no such thing as an
> "incompatible license" or "mere aggregation" and that these are just
> words that were made up for the GPL, so they can be ignored.. another
> pointless semantic argument because it doesn't change the very simple
> fact that you don't have any rights to copy the work unless you have a
> license and you don't have a license if you fail to abide the
> conditions of the license.

The issue is about what the license *means* and what its scope is. For
example, if the license said "if you ever use a work that is subject to this
license, you must place every work you create after that under the license",
that would obviously not be enforceable. The question of the *scope* of the
license is critical, and you can't read the license to understand its scope.

> Hang on, you're actually debating that you have to abide by conditions
> of a license before you can copy a copyright work?

Well, there are certainly cases where you can. Necessary step, first sale,
and fair use all provide possible situations where you can copy a
copyrighted work without complying with the license. But more generally, the
argument is over the scope of the license.

The GPL doesn't restrict the distribution of mere aggregations not because
the authors felt this was a wise decision, but because it *can't*. That is
outside the GPL's power. So the question of what's a "mere aggregation" is a
legal question about the scope of the GPL, and you have to look at law and
case law to understand it, not the text of the GPL.

The GPL grants you the permission to modify and distribute the original work
if you distribute the source of the original work. The GPL also puts certain
requirements on the distribution of derivative works. This is, as far as I
can tell, the maximum of the scope it can have.

You are trying to cram this in a simple yes or no box, and it just doesn't
fit. There are questions nobody knows the answers to (such as what rights
you need to distribute a derivative work or whether compiling code makes a
translation).

DS

Re: GPL vs non-GPL device drivers

[v j]

> You are trying to cram this in a simple yes or no box, and it just doesn't
> fit. There are questions nobody knows the answers to (such as what rights
> you need to distribute a derivative work or whether compiling code makes a
> translation).

Thanks, all for the discussion. I certainly learnt a lot. I definitely
expected to be flamed and roasted for posting my original message, and
was not disappointed :)

I do not possess all the knowledge ("legal" and technical) that people
who have contributed to this discussion possess. However I will still
comment from a user's perspective, which was my original point.

Many companies in the embedded field still mistakenly feel (or felt
until a while ago) that Linux was not right for them. That they would
have to open source their code, that they would not get adequate
support, and that Linux was too big and heavy to perform well in an
embedded platform. People like me who were Linux Desktop junkies were
actually trying to convince companies of the opposite.

Now the popularity of Linux is exploding in the embedded space. Nobody
talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be
a worthwhile experiment to study this surge in popularity. I am not an
expert, but perhaps the reason is "it works so goddamn well and has a
wealth of third party FREE software". Sure its a bit of work to make
it work on our platform and we don't have to Enea or Windriver to
write our gripes to. But it definitely is worth it.

Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
does to this popularity. I don't know. I am just giving you my
opinion. The moment companies learn of something like this, alarm
bells start to go off. This is not rational. I personally have nothing
against open-sourcing all software. *But*, this is not how companies
think.

Let's think about why Linux became so popular and strive towards
keeping it that way instead of resorting to innovative ways of just
confusing a lot of people.

Having said this, I am committed to contribute back to the Linux
community in any way I can, not withstanding my present employer. Keep
up the good work guys!

> DS

vj.

Re: GPL vs non-GPL device drivers

[Nick Piggin]

v j wrote:

> Now the popularity of Linux is exploding in the embedded space. Nobody
> talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be
> a worthwhile experiment to study this surge in popularity. I am not an
> expert, but perhaps the reason is "it works so goddamn well and has a
> wealth of third party FREE software". Sure its a bit of work to make
> it work on our platform and we don't have to Enea or Windriver to
> write our gripes to. But it definitely is worth it.

And do you think it works well because of all those companies that
don't contribute anything back? For that matter, do they do a single
thing to help anyone or anything to do with Linux except themselves?


> Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
> does to this popularity. I don't know. I am just giving you my
> opinion. The moment companies learn of something like this, alarm
> bells start to go off. This is not rational. I personally have nothing
> against open-sourcing all software. *But*, this is not how companies
> think.

Opinions or motivations, or the people working for companies don't really
have any relevance at all. What matters is their actions.

You would think that those people who think their IP is so priceless that
it can't be opened would respect the rights of others. Sadly that doesn't
appear to be the case.


> Let's think about why Linux became so popular and strive towards
> keeping it that way instead of resorting to innovative ways of just
> confusing a lot of people.

Linux has become popular _in spite_ of parasites, rather than because of
them. The main reason for its popularity is its quality. And a big reason
for its quality is the GPL.

-- 
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Mon, 2007-02-19 at 21:19 -0800, v j wrote:
[...]
> Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
> does to this popularity. I don't know. I am just giving you my

The big problem with such discussions (as this) are: It is a law
decision which license applies in which situation. And preprocessor can
solve this (so EXPORT_SYMBOL_GPL may mean that or may only express the
wish of one/several/many/a lot of people).

Flame bait alert:
I heard a talk from an Austrian lawyer an according to his believes (and
I don't know if he is the only one or if there lots of) one must see
from the "users" view if the GPL spreads over or not (and the usual
technical terms like "linking" are basically irrelevant).
E.g.:
- You are distributing an application which links against a GPL-library.
If you provide a link and the user/customer has to get and install that
library, your application can have any license you wish.
- If you distribute an application and it installs automatically a
library (e.g. from the CD where your application is installed), your
applications license must "fit" wit the library license.

Guess now what this implies for (typical) embedded systems with one
piece of GPL code in it where you download complete firmware images -
and he explicitly confirmed that.

So this whole thing is not really defined yet and one (read: we) must
also educate such free-software-illiterate people on how it is intended
to work.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Tue, 20 Feb 2007 12:00:51 +0100, Bernd Petrovitsch said:
> Flame bait alert:
> I heard a talk from an Austrian lawyer an according to his believes (and
> I don't know if he is the only one or if there lots of) one must see
> from the "users" view if the GPL spreads over or not (and the usual
> technical terms like "linking" are basically irrelevant).
> E.g.:
> - You are distributing an application which links against a GPL-library.
> If you provide a link and the user/customer has to get and install that
> library, your application can have any license you wish.
> - If you distribute an application and it installs automatically a
> library (e.g. from the CD where your application is installed), your
> applications license must "fit" wit the library license.

So tell me - if RedHat distributes a non-GPL program that uses a GPL
library that is included as part of the distribution, but *not* one that's
usually installed, which rules apply?

Even better - does this mean that I can *intentionally* bypass the licensing by
including a installer script that removed a problematic library, and then
forces the user to re-install it?



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Tue, 2007-02-20 at 10:14 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 20 Feb 2007 12:00:51 +0100, Bernd Petrovitsch said:
> > Flame bait alert:
> > I heard a talk from an Austrian lawyer an according to his believes (and
> > I don't know if he is the only one or if there lots of) one must see
> > from the "users" view if the GPL spreads over or not (and the usual
> > technical terms like "linking" are basically irrelevant).
> > E.g.:
> > - You are distributing an application which links against a GPL-library.
> > If you provide a link and the user/customer has to get and install that
> > library, your application can have any license you wish.
> > - If you distribute an application and it installs automatically a
> > library (e.g. from the CD where your application is installed), your
> > applications license must "fit" wit the library license.
> 
> So tell me - if RedHat distributes a non-GPL program that uses a GPL
> library that is included as part of the distribution, but *not* one that's
> usually installed, which rules apply?

I'm well aware that there are (probably lots of) contradictions with
this "idea".
IANAL and we must ask that lawyer actually for this. And he will
probasbly do not understand the question since he very probably doesn't
know all the usual software distribution methods.

> Even better - does this mean that I can *intentionally* bypass the licensing by
> including a installer script that removed a problematic library, and then
> forces the user to re-install it?

A good question which belongs in the same category as above.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Helge Hafting]

v j wrote:
>> You are trying to cram this in a simple yes or no box, and it just 
>> doesn't
>> fit. There are questions nobody knows the answers to (such as what 
>> rights
>> you need to distribute a derivative work or whether compiling code 
>> makes a
>> translation).
>
> Thanks, all for the discussion. I certainly learnt a lot. I definitely
> expected to be flamed and roasted for posting my original message, and
> was not disappointed :)
>
> I do not possess all the knowledge ("legal" and technical) that people
> who have contributed to this discussion possess. However I will still
> comment from a user's perspective, which was my original point.
>
> Many companies in the embedded field still mistakenly feel (or felt
> until a while ago) that Linux was not right for them. That they would
> have to open source their code, that they would not get adequate
> support, and that Linux was too big and heavy to perform well in an
> embedded platform. People like me who were Linux Desktop junkies were
> actually trying to convince companies of the opposite.
>
> Now the popularity of Linux is exploding in the embedded space. Nobody
> talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be
> a worthwhile experiment to study this surge in popularity. I am not an
> expert, but perhaps the reason is "it works so goddamn well and has a
> wealth of third party FREE software". Sure its a bit of work to make
> it work on our platform and we don't have to Enea or Windriver to
> write our gripes to. But it definitely is worth it.
>
> Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
> does to this popularity. I don't know. I am just giving you my
> opinion. The moment companies learn of something like this, alarm
> bells start to go off. This is not rational. I personally have nothing
> against open-sourcing all software. *But*, this is not how companies
> think.
>
> Let's think about why Linux became so popular and strive towards
> keeping it that way instead of resorting to innovative ways of just
> confusing a lot of people.
>
> Having said this, I am committed to contribute back to the Linux
> community in any way I can, not withstanding my present employer. Keep
> up the good work guys!
>
As linux becomes popular, there will always be some people looking
at it that find that it don't fit them perfectly.  That don't mean
we have to make sure linux fits them too - they may be better off
with something else, or we may be better off without them.
Linux has a price - you can use it compeltely free but we want
any useful changes you might make. If everybody sat on their stuff,
linux wouldn't be useful to you today.

There are embedded developers who don't have a problem with
writing GPL drivers.  And there are embedded developers who
don't need any special hardware driver.  No _kernel_ change,
no open-sourcing of company code.  It was never a problem, and
will never be a problem, to run proprietary user processes "apps"
on a linux kernel.

If you have a need for "secret" source code, stuff most of it
in userspace.  Make the drivers truly minimal; perhaps their
open/closed status won't matter that much when the bulk
of the code and the cleverness is kept safe in userspace.

Note that keeping drivers small this way is the recommended
way of working anyway. It isn't merely a way to keep your
code away from the GPL - you always want a small kernel.

Helge Hafting

Re: GPL vs non-GPL device drivers

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

On Tue, 2007-02-20 15:36:56 +0100, Helge Hafting <helge.hafting@aitel.hist.no> wrote:
> If you have a need for "secret" source code, stuff most of it
> in userspace.  Make the drivers truly minimal; perhaps their
> open/closed status won't matter that much when the bulk
> of the code and the cleverness is kept safe in userspace.
> 
> Note that keeping drivers small this way is the recommended
> way of working anyway. It isn't merely a way to keep your
> code away from the GPL - you always want a small kernel.

Keeping the legal stuff out of sight for a second, this'll solve the
"problem" for the embedded developer, but surely not for the Linux
community. Would you ever expect that eg. the thin GPL layer used by
ATI/NVidia would be merged iff the rest would run in userland?

It's just a workaround for the
linking-the-object-file-into-the-kernel-image problem, but after all,
it doesn't lead to a working driver being freely available.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
 Signature of:                            If it doesn't work, force it.
 the second  :                   If it breaks, it needed replacing anyway.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: GPL vs non-GPL device drivers

[Helge Hafting]

Jan-Benedict Glaw wrote:
> On Tue, 2007-02-20 15:36:56 +0100, Helge Hafting <helge.hafting@aitel.hist.no> wrote:
>   
>> If you have a need for "secret" source code, stuff most of it
>> in userspace.  Make the drivers truly minimal; perhaps their
>> open/closed status won't matter that much when the bulk
>> of the code and the cleverness is kept safe in userspace.
>>
>> Note that keeping drivers small this way is the recommended
>> way of working anyway. It isn't merely a way to keep your
>> code away from the GPL - you always want a small kernel.
>>     
>
> Keeping the legal stuff out of sight for a second, this'll solve the
> "problem" for the embedded developer, but surely not for the Linux
> community. Would you ever expect that eg. the thin GPL layer used by
> ATI/NVidia would be merged iff the rest would run in userland?
>   
A thin layer - no.  To get merged, a driver would have to
be of good quality.  I didn't think like that - I was thinking of
embedded developers that sometimes implement the
entire embedded application inside their device driver.

Which is crazy from a linux design standpoint, but sometimes
reasonable for an embedded developer when the sole purpose of
the embedded computer is to control the single "device" and
perhaps a little display with a couple of buttons.
The "app" part might not be that much
bigger than the device driver itself - it is then tempting to
cut some corners and put all in one place.

Of course this kind of "driver" ends up containing everything,
and nobody wants to GPL that.  Separating driver and app(s)
properly lets them keep a proprietary app, and a driver or two
that might be small and simple enough to be released.
> It's just a workaround for the
> linking-the-object-file-into-the-kernel-image problem, but after all,
> it doesn't lead to a working driver being freely available.
>
> MfG, JBG

Good point.  Fortunately, most devices are much simpler than
a card with accelerated 3D-graphichs.

Helge Hafting

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

Actually, it's quite clear under US law what a derivative work is and
what rights you need to distribute it, and equally clear that
compiling code does not make a "translation" in a copyright sense.
Read Micro Star v. Formgen -- it's good law and it's funny and
readable.

I've drafted summaries from a couple of different angles since VJ
requested a "translation into English", and I think this is the most
coherent (and least foaming-at-the-mouth) I've crafted yet.  It was
written as an answer to a private query to this effect:  "I write a
POP server and release it under the GPL.  The Evil Linker adds some
hooks to my code, calls those hooks (along some of the existing ones)
from his newly developed program, and only provides recipients of the
binaries with source code for the modified POP server.  His code
depends on, and only works with, this modified version of my POP
server.  Doesn't he have to GPL his whole product, because he's
combined his work with mine?"

This is a fundamental misconception.  A <<product>> is not a "work
of authorship".  Copyright is about "works of authorship" and cannot
be used to allow or disallow behavior based on whether you have
<<combined>> two things at an engineering level to make a product.  A
contract can be used to allow or disallow, and assign penalties to,
all sorts of things, and the GPL is an "offer of contract"; but its
plain text does _not_ disallow this <<combination>> -- largely because
the drafter was trying to put one over on you and me by pretending that
he could do that without recourse to contract law.

The fact that your Evil Linker's program will not do anything
interesting without your program is no more relevant than the fact
that Borland's spreadsheet program will not do anything interesting
without a spreadsheet document loaded.  Borland's interest lay in
making their macro language compatible with Lotus's so that users
didn't have to rewrite their documents from scratch.  The Evil
Linker's interest lies in making their program compatible with other
clients of your POP server so they don't have to rewrite your POP
server from scratch.  Borland won in court, and so will the Evil
Linker.  IANAL, TINLA.

Now, Borland _almost_ lost at the Supreme Court level.  Why?  Because
while they had a good case that it wasn't practical to copy the 1-2-3
macro language without copying its entire user interface, that gets
awfully close to the sort of expression that copyright is supposed to
protect.  You can take a picture of a skyscraper and sell copies of
that picture, not because it isn't in some sense an infringement on
the architect's copyright, but because it's "fair use" -- mostly
because it doesn't interfere with the architect's ability to make
money licensing _architectural_ replicas of her work.  When you take a
screenshot of a spreadsheet, you're on safe ground; but if you use
that screenshot to clone the spreadsheet, you're pushing your luck.

Borland won, sort of, when the Supremes split 4-4 (one was out sick or
recused or something).  If you want to know why, you can get hold of a
transcript of the oral argument before the Supreme Court, which is
mostly in plain English and about half debate between the Justices
about where they ought to draw the line.  For an example where
screenshots can be over the line, and where even unlicensed
distribution of data files can be held to infringe the copyright on
the program that reads them, read Micro Star v. Formgen (9th Circuit).
 That involved a very different theory though, infringement on the
"characters and mise en scene" of a fictional work (Duke Nukem 3D),
and will not avail you against the Evil Linker.  All of this stuff is
covered in Lexmark v. Static Control (6th Circuit, cert. denied) --
the law of the land throughout the U. S. of A.

But wait, you say -- the Evil Linker modified, copied, and distributed
my POP server too!  That makes him subject to the terms of the GPL.
And you're right; but to understand what that means, you're going to
need to understand how a lawsuit for copyright infringement works.
The very, very, very concise version is:

You claim "copyright infringement".
He claims "copyright license" -- "acceptance through conduct" of a
"valid offer of contract".
You claim conduct outside the "scope of the license".
He claims the terms about distributing modified versions together with
source code are "covenants of return performance", which he duly
performed.
You claim the license covers the whole <<work based on the Program>>,
including his application.
He points out that <<work based on the Program>> is explicitly defined
in GPL Section 0 to be a "derivative work under copyright law", and
that while the paraphrase following this overstates the extent of the
"derivative works" category, a raft of case law says that his program
is not a "derivative work" of yours.  Furthermore, it would be
"contrary to the public interest" to allow a "contract of adhesion in
rem" to disallow the "universal industry practice" of <<aggregating>>,
for engineering purposes, many differently licensed works on common
media, whether or not they <<function together>> in different and
better ways than they would without one another's presence.
He moves for "judgment as a matter of law", saying that the skeletal
outline of facts already on the table is sufficient to demonstrate
that none of your "legal theories" can possibly succeed.

Judge agrees with him, saying that the parties have formed an
incontestably "valid contract", contracts must be "construed against
the offeror" in the presence of ambiguity, and any "defects in
performance" that you might be able to demonstrate would almost
certainly not "strike to the heart of the contract".  Therefore
you have no grounds for "rescission", and the license stands with
respect to the original work and the "modified", <<compiled to object
code>>, "copied", and "distributed" version created by the Evil
Linker.  No other "infringing work" has been created, because the
<<combination>> of your work and his is neither a "derivative work"
nor a "copyrightable compilation", merely a "parcel of goods".  You
have not been "harmed" in any way that you have not already "waived
the right to sue" for, so you have no recourse under "tort"; you have
no "contract in personam", so you cannot sue for "breach of contract";
you owe "costs" to the court and "cost of defense" to the defendant.

Judge sends you home, a sadder but a wiser man.  Or, if not wiser,
preparing to cost yourself a lot more money by appealing the judgment.

Everything in "double quotes" in that analysis is a legal term of art,
_throughout_the_developed_world_.  Everything in <<angle quotes>> is
not.  (I am not a lawyer, this is not legal advice.)  Anyone, even a
Justice of the US Supreme Court, who tells you that he has the
authority to bend the meaning of a legal term of art, in the presence
of a mountain of applicable case law, is a shyster and a poltroon.
When he's been doing it for twenty years, ten of them with the
ostensible authority of a professor of law and legal history, and
making $500K a year or so doing it, he's a charlatan and a racketeer.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Nuno Silva]

Michael K. Edwards wrote:
> Actually, it's quite clear under US law what a derivative work is and
> what rights you need to distribute it, and equally clear that
> compiling code does not make a "translation" in a copyright sense.
> Read Micro Star v. Formgen -- it's good law and it's funny and
> readable.

Hello.

[Sorry for deleting the rest of the email but it was quite large]

I can see that your argument is all about the defenition of a
"derivative work".

We all know that #include <anything.h> is mostly non copyrightable, so I
mostly agree that some - very very simple - modules may not need to
include the source when distributing the resulting module.ko. (need =
from a legal standpoint... The intended spirit of the GPL is another story)

In this context what do you think about porting Linux to another arch?
Does the people porting the OS needs to distribute the source with the
[compiled] kernel?

(Yes, it's a trick question)

IANAL too.

Regards,
Nuno Silva

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/21/07, Nuno Silva <nuno.silva@vgertech.com> wrote:
> I can see that your argument is all about the defenition of a
> "derivative work".

Far from it.  Try reading to the end.

> We all know that #include <anything.h> is mostly non copyrightable, so I
> mostly agree that some - very very simple - modules may not need to
> include the source when distributing the resulting module.ko. (need =
> from a legal standpoint... The intended spirit of the GPL is another story)

The "intended spirit of the GPL" is very different from what you think
it is, as $674 million of Red Hat stock can testify.  It is also
utterly irrelevant except when the circumstances surrounding someone's
acceptance of the GPL indicate that the two parties negotiated more or
less directly before settling on its terms.

> In this context what do you think about porting Linux to another arch?
> Does the people porting the OS needs to distribute the source with the
> [compiled] kernel?

Of course.  They're distributing a derivative work of the kernel, or
perhaps even (for legal purposes) distributing Linus's work of
authorship with trivial editorial changes that do not create a new
copyrightable work.  They need license to do so, and the only license
on offer is GPL v2, which conditions the license on distribution of
source code.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[David Lang]

On Wed, 21 Feb 2007, Michael K. Edwards wrote:

> But wait, you say -- the Evil Linker modified, copied, and distributed
> my POP server too!  That makes him subject to the terms of the GPL.
> And you're right; but to understand what that means, you're going to
> need to understand how a lawsuit for copyright infringement works.
> The very, very, very concise version is:

<argument snipped for brevity>

I understand why you say that the Evil Linker's program isn't covered by the 
GPL, but your argument makes it sound like the modified POP server doesn't need 
to have it's source released. This I don't understand, it contains the origional 
source code, so what right does Evil Linker have to distribute it (or a modified 
version).

you are comeing dangerously close to saying that the GPL is meaningless and 
putting something under it is the same as putting it under public domain. There 
is case law now that says that this isn't the case (although I agree that it's 
not nearly as broad as it's proponents would like it to be)

David Lang

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

I think you just misread.  I said that the Evil Linker has cheerfully
shipped the source code of the modified POP server.  He may not have
given you the compiler he compiled it with, wihout which the source
code is a nice piece of literature but of no engineering utility; but
that's the situation the GPL is DESIGNED TO PRODUCE.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[D. Hazelton]

On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote:
> I think you just misread.  I said that the Evil Linker has cheerfully
> shipped the source code of the modified POP server.  He may not have
> given you the compiler he compiled it with, wihout which the source
> code is a nice piece of literature but of no engineering utility; but
> that's the situation the GPL is DESIGNED TO PRODUCE.

Actually, if memory serves, when you license a work under the GPL, part of the 
terms is that you have to provide the source and any scripts needed to 
produce a functioning executable.

*checks a local copy of GPLv2 for the exact wording*

Third clause of the license:
"For an executable work, complete source code means all the source code for 
all modules it contains, plus any associated interface definition files, plus 
the scripts used to control compilation and installation of the executable."

So yes, someone could produce a work that compiles on a specific compiler, but 
there is then nothing stopping someone from fixing the problems that cause it 
to not compile using another compiler and releasing that source code - 
distributing it as a patch, AFAICT, falls outside coverage by the GPLv2. The 
build tool-chain, libraries and other works that are not a direct part of the 
program produced by compilation of the source code. (the wording of the GPL 
is: "However, as a special exception, the source code distributed need not 
include anything that is normally distributed (in either source or binary 
form) with the major components (compiler, kernel, and so on) of the 
operating system on which the executable runs, unless that component itself 
accompanies the executable.")

As a side note: The distinct wording of the GPL actually *invalidates* the 
GNU/FSF claim that dynamically linking a work with, say, the readline 
library,  means the work is a derivative of said library. The GPL states (in 
clause 0) that the license only covers copying, modification and 
distribution. Unless they are confusing "Linking" with "copying" or "creating 
a derivative work" the claim is invalid - because, as it has been shown, a 
mechanical process such as compilation or linking *cannot* create a 
derivative work.

Related to that... Though a parser generated by Bison and a tokenizer 
generated by Flex both contain large chunks of GPL'd code, their inclusion in 
the source file that is to be compiled is mechanical - the true unique work 
is in writing the file that is processed by the tool to produce the output. 
Since the aggregation of the GPL'd code into the output source is done 
mechanically - via mechanical translation (which is what compilation is as 
well) - the result is *not* and under US copyright law *cannot* be a 
derivative work. What this means is that the GNU/FSF "special" terms applied 
to parsers generated by Bison and tokenizers generated by Flex is 
unnecessary - they are granting you a right you already have.

Anyway, it's been fun watching this thread. If I've made a mistake somewhere 
in there, let me know - IANAL and I am just starting to really get into the 
meat of Copyright and related laws in independant study.

DRH

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/21/07, D. Hazelton <dhazelton@enter.net> wrote:
> On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote:
> > I think you just misread.  I said that the Evil Linker has cheerfully
> > shipped the source code of the modified POP server.  He may not have
> > given you the compiler he compiled it with, wihout which the source
> > code is a nice piece of literature but of no engineering utility; but
> > that's the situation the GPL is DESIGNED TO PRODUCE.
>
> Actually, if memory serves, when you license a work under the GPL, part of the
> terms is that you have to provide the source and any scripts needed to
> produce a functioning executable.

Absolutely.  But not the toolchain, just the "scripts".  This is part
historical, since after all GNU got started when Sun started to
monetize its toolchain independently of its O/S, RMS got annoyed
enough to kick off another cloning project, and more competent
compiler people caught on to the economic opportunity.  Ever pay $5K
for a CD full of GNU binaries for a commercial UNIX?  I did, after
deciding that getting all their shit to compile was more Morlock-work
than I was up to.  So like I say, it's part historical -- RMS didn't
want to owe me a copy of Sun's toolchain along with that CD -- but
it's no accident that it's still in there, because THAT'S HOW CYGNUS
MADE MEGABUCKS.

> As a side note: The distinct wording of the GPL actually *invalidates* the
> GNU/FSF claim that dynamically linking a work with, say, the readline
> library,  means the work is a derivative of said library. The GPL states (in
> clause 0) that the license only covers copying, modification and
> distribution. Unless they are confusing "Linking" with "copying" or "creating
> a derivative work" the claim is invalid - because, as it has been shown, a
> mechanical process such as compilation or linking *cannot* create a
> derivative work.

Of course.  The FSF smokescreen around "derivative work" exists not
only to frighten potential commercial users of GPL libraries but to
squelch people like Eric A. Young (principal OpenSSL author) who have
the presumption to retain their own copyrights.  Eric has a quite
solid case (IMHO, IANAL) against the FSF and Eben Moglen personally
under at least three different U. S. antitrust and racketeering laws,
and it would be really entertaining to watch him take it up.

> Related to that... Though a parser generated by Bison and a tokenizer
> generated by Flex both contain large chunks of GPL'd code, their inclusion in
> the source file that is to be compiled is mechanical - the true unique work
> is in writing the file that is processed by the tool to produce the output.
> Since the aggregation of the GPL'd code into the output source is done
> mechanically - via mechanical translation (which is what compilation is as
> well) - the result is *not* and under US copyright law *cannot* be a
> derivative work. What this means is that the GNU/FSF "special" terms applied
> to parsers generated by Bison and tokenizers generated by Flex is
> unnecessary - they are granting you a right you already have.

Half true.  It's not a derivative work exactly, but it could
conceivably be held to infringe against the copyright in Flex/Bison,
if you could prove that the amount of _creative_expression_ copied
into the output exceeds a "de minimis" standard and doesn't constitute
a "fair use".  Those nifty photomosaics would probably infringe
against the photographers' copyright in the photos they're made up of,
if they weren't licensed through the graphic industry's "stock photo
archive" mechanism.  You could probably defend on "fair use" with
respect to Flex/Bison and the vanilla GPL, since the fact that I can
get some random program with a parser in it from you without needing
my own copy of bison doesn't cost the FSF anything.  But it's a
gamble, especially if that random program competes with something the
FSF makes $$$ off of; and I'd want that extra bit of estoppel in my
back pocket.

The LGPL is a very different story.  It's not just GPL with extra
estoppel, it's a booby trap.  It goes a lot farther to put over its
own perverse definition of "derivative work", and it tries to compel
you to provide all the "data and utility programs needed for
reproducing the executable from it".  I don't use the LGPL for my own
work, I wouldn't touch it with a ten-foot pole if it didn't have the
"GPL upgrade" clause in it, and I advise my employers and consulting
clients to go through the "GPL (v2 only!) upgrade" rigmarole with
respect to anything they so much as recompile.  They don't all take
that advice, but that's not my problem.

> Anyway, it's been fun watching this thread. If I've made a mistake somewhere
> in there, let me know - IANAL and I am just starting to really get into the
> meat of Copyright and related laws in independant study.

Ditto.  If you see a mistake in something I write, please please
pretty please point it out, in public -- I am not a lawyer, absolutely
everything I say could be wrong, and I don't really want these
messages lying around without the context of every rebuttal anyone in
the audience can think of.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[D. Hazelton]

On Wednesday 21 February 2007 21:05, Michael K. Edwards wrote:
> On 2/21/07, D. Hazelton <dhazelton@enter.net> wrote:
<snip>
> > Related to that... Though a parser generated by Bison and a tokenizer
> > generated by Flex both contain large chunks of GPL'd code, their
> > inclusion in the source file that is to be compiled is mechanical - the
> > true unique work is in writing the file that is processed by the tool to
> > produce the output. Since the aggregation of the GPL'd code into the
> > output source is done mechanically - via mechanical translation (which is
> > what compilation is as well) - the result is *not* and under US copyright
> > law *cannot* be a derivative work. What this means is that the GNU/FSF
> > "special" terms applied to parsers generated by Bison and tokenizers
> > generated by Flex is unnecessary - they are granting you a right you
> > already have.
>
> Half true.  It's not a derivative work exactly, but it could
> conceivably be held to infringe against the copyright in Flex/Bison,
> if you could prove that the amount of _creative_expression_ copied
> into the output exceeds a "de minimis" standard and doesn't constitute
> a "fair use".  Those nifty photomosaics would probably infringe
> against the photographers' copyright in the photos they're made up of,
> if they weren't licensed through the graphic industry's "stock photo
> archive" mechanism.  You could probably defend on "fair use" with
> respect to Flex/Bison and the vanilla GPL, since the fact that I can
> get some random program with a parser in it from you without needing
> my own copy of bison doesn't cost the FSF anything.  But it's a
> gamble, especially if that random program competes with something the
> FSF makes $$$ off of; and I'd want that extra bit of estoppel in my
> back pocket.

Actually, on re-reading the GPL, I see exactly why they made that pair of 
exceptions. Where it's quite evident that a small to mid scale parsers that 
could have been written *without* the use of Bison is clearly a 
non-derivative work - Bison was not required, but was used as a mean of 
expediency. When you reach a large scale parser, such as one that meets all 
requirements to act as the parser for an ANSI C99 compiler, Bison stops being 
expedient - it'd likely take just as much time to hand craft the parser as it 
would to debug the Bison input. However, it makes maintaining the parser 
easier.

But the fact is that it's the small to medium scale parsers that have a lower 
ratio of original to GPL'd code that are at risk of being declared derivative 
works. All of this because the GPL contains the following text in section 0:
"The act of running the Program is not restricted, and the output from the 
Program is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does."

That clause, to me, seems specifically tailored to cover programs such as 
Bison and Flex. (and is the reason that I try to use Byacc and when I need 
to, write tokenizers by hand) This frankly stinks of attempts to cover all 
possible code. (I actually started studying Copyright law in my free time 
because I was wondering how legal the GPL was and was also puzzled by some 
major online entities actually complaining about it)

> The LGPL is a very different story.  It's not just GPL with extra
> estoppel, it's a booby trap.  It goes a lot farther to put over its
> own perverse definition of "derivative work", and it tries to compel
> you to provide all the "data and utility programs needed for
> reproducing the executable from it".  I don't use the LGPL for my own
> work, I wouldn't touch it with a ten-foot pole if it didn't have the
> "GPL upgrade" clause in it, and I advise my employers and consulting
> clients to go through the "GPL (v2 only!) upgrade" rigmarole with
> respect to anything they so much as recompile.  They don't all take
> that advice, but that's not my problem.

Since I tailor the license I apply to code I produce to meet the needs of the 
person or entity I am writing it for, I've never run into this. In truth, the 
LGPL is, IMHO, a piece of garbage. (as is the GPL - if you release code under 
the GPL you no longer have a legal right to it. Note the following text that 
appears in the GPL:

"  We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software."
--IE: Once you release the code under the GPL, it becomes the *copyrighted* 
*property* of the FSF and you are just another person that the GPL is applied 
to. This means that if you later change your mind and decide to revoke the 
GPL on your code and replace it with say, the Larry Wall's "Artistic License" 
you are breaking the terms of the GPL and therefore lose all rights to modify 
and distribute your code.

A similar clause appears in the LGPL:
"We protect your rights with a two-step method: (1) we copyright the library, 
and (2) we offer you this license, which gives you legal permission to copy, 
distribute and/or modify the library."
-- In this case I think the first item is bogus - the "library" is generally 
considered to be the compiled version of the source. Since it is the product 
of a machine translation it *cannot* be copyrighted. What it actually means 
is they copyright the "human readable machine source code" of the library - 
at which point the bad things I've pointed out about the standard GPL become 
true.

> > Anyway, it's been fun watching this thread. If I've made a mistake
> > somewhere in there, let me know - IANAL and I am just starting to really
> > get into the meat of Copyright and related laws in independant study.
>
> Ditto.  If you see a mistake in something I write, please please
> pretty please point it out, in public -- I am not a lawyer, absolutely
> everything I say could be wrong, and I don't really want these
> messages lying around without the context of every rebuttal anyone in
> the audience can think of.

Will do. Now I think I'll get back to work on a private project that I've got 
in front of me. (When I release it the code will not be under *any* of the 
various GNU/FSF licenses - I'll probably wind up crafting one specifically 
for the project)

DRH

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/22/07, D. Hazelton <dhazelton@enter.net> wrote:
> "  We protect your rights with two steps: (1) copyright the software, and
> (2) offer you this license which gives you legal permission to copy,
> distribute and/or modify the software."
> --IE: Once you release the code under the GPL, it becomes the *copyrighted*
> *property* of the FSF and you are just another person that the GPL is applied
> to.

Put *down* the crack pipe.

Trent

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/21/07, D. Hazelton <dhazelton@enter.net> wrote:
> Actually, on re-reading the GPL, I see exactly why they made that pair of
> exceptions. Where it's quite evident that a small to mid scale parsers that
> could have been written *without* the use of Bison is clearly a
> non-derivative work - Bison was not required, but was used as a mean of
> expediency. When you reach a large scale parser, such as one that meets all
> requirements to act as the parser for an ANSI C99 compiler, Bison stops being
> expedient - it'd likely take just as much time to hand craft the parser as it
> would to debug the Bison input. However, it makes maintaining the parser
> easier.

I repeat, that is not what "derivative work" means.  Do not try to
reason about the phrase "derivative work" without reference to its
definition in statute and its legal history in appellate decisions.
You will get it wrong every time.  You have not "recast, transformed,
or adapted" the _creative_expression_ in Bison or Flex in the course
of using it; so whether or not you have infringed the FSF's copyright,
you have NOT created a "derivative work".

If Bison and Flex were offered under the "bare" GPL, and you used them
to build a parser, and the FSF sued you for offering that parser to
other people on terms other than the GPL's, you don't defend by
claiming license under the GPL with regard to your parser.  You attack
the claim of "copying" itself by saying that the _creative_expression_
copied from Bison/Flex into your parser is "de minimis" under the
Altai Abstraction-Filtration-Comparison test.  You also point out
that, even if it weren't "de minimis", it's "fair use"; that's a
complex four-factor test, but the main thing is that you're not
interfering with the FSF's ability to monetize its copyright in
Bison/Flex.

If you have any sense, you will strenuously argue that the various
"special exceptions" for things like Bison/Flex and GNU Classpath are
_not_ part of the offer of contract contained in the GPL, any more
than the Preamble is.  They're declarations of intent on the part of
the copyright holder, and can be used to _estop_ the FSF from making
the copyright infringement claim against you in court in the first
place.  They promised you they wouldn't, not as part of the contract
terms, but as part of the inducement to form a contract with them by
acceptance through conduct.

> But the fact is that it's the small to medium scale parsers that have a lower
> ratio of original to GPL'd code that are at risk of being declared derivative
> works. All of this because the GPL contains the following text in section 0:
> "The act of running the Program is not restricted, and the output from the
> Program is covered only if its contents constitute a work based on the
> Program (independent of having been made by running the Program).
> Whether that is true depends on what the Program does."

I'm sorry, but that "ratio test" has nothing to do with whether
something is a derivative work or not.  It comes up mostly in
evaluating a "fair use" defense, and it's the ratio of the amount of
creative expression _copied_ to the amount of creative expression in
the _original_work_ that matters.  Just because you're writing a
49-volume encyclopedia does not give you the right to copy two thirds
of my one-page essay.  Those weasel-words about "depending on what the
Program does" are nonsense.  It depends on what _creative_expression_
from the Program winds up in the output.

> That clause, to me, seems specifically tailored to cover programs such as
> Bison and Flex. (and is the reason that I try to use Byacc and when I need
> to, write tokenizers by hand) This frankly stinks of attempts to cover all
> possible code. (I actually started studying Copyright law in my free time
> because I was wondering how legal the GPL was and was also puzzled by some
> major online entities actually complaining about it)

I've written tokenizers in at least six different languages to date,
including Fortran.  It's a pain in the butt.  The last thing I want to
be worrying about when I write a tokenizer is whether somebody else's
peanut butter is winding up in my chocolate.  So I will only use a
tool which, like bison and flex, is accompanied by a promise not to
claim that its output infringes the tool author's copyright or is
otherwise encumbered in any way.  M$ VC++ is actually more trustworthy
in that respect than G++.  If you don't believe (as I do) that it is
arrant nonsense to claim that the use of interface headers or linking
of any kind creates a derivative work, then you must believe that any
programs compiled with G++ can only be distributed under the terms of
the GPL.  libstdc++ is GPL, not LGPL.

> Since I tailor the license I apply to code I produce to meet the needs of the
> person or entity I am writing it for, I've never run into this.

That's kind of silly.  I use the GPL for my own from-scratch programs
all the time.  It's quite a sensible set of terms for source code
created as a side effect of a consulting project, when interpreted
according to real law instead of Eben Moglen's bullshit FAQ.  I don't
get paid to muck about with contract language, any more than I get
paid for turning knobs; I get paid for knowing which knob to turn.

> In truth, the
> LGPL is, IMHO, a piece of garbage. (as is the GPL - if you release code under
> the GPL you no longer have a legal right to it. Note the following text that
> appears in the GPL:
>
> "  We protect your rights with two steps: (1) copyright the software, and
> (2) offer you this license which gives you legal permission to copy,
> distribute and/or modify the software."

Er, that's the preamble, which has no legal force other than as a bit
of backstory and possibly grounds for estoppel against the FSF.  It's
also obviously an artifact of the original drafting of the GPL as a
license for FSF software alone.  No judge on earth would listen to a
claim that the FSF has obtained copyright on your work without
copyright assignment papers or a "work made for hire" paper trail.

> --IE: Once you release the code under the GPL, it becomes the *copyrighted*
> *property* of the FSF and you are just another person that the GPL is applied
> to. This means that if you later change your mind and decide to revoke the
> GPL on your code and replace it with say, the Larry Wall's "Artistic License"
> you are breaking the terms of the GPL and therefore lose all rights to modify
> and distribute your code.

Er, you're in the crack zone here.

> Will do. Now I think I'll get back to work on a private project that I've got
> in front of me. (When I release it the code will not be under *any* of the
> various GNU/FSF licenses - I'll probably wind up crafting one specifically
> for the project)

Personally, I don't see any reason not to use GPL or BSD (with or
without "obnoxious attribution clause") or MIT X11, other than the
ever-present danger of negligence suits due to incompetently crafted
"notice of no warranty" (it's smartest to make it clear that the only
person responsible for a failure to communicate the lack of warranty
is the person from whom the end user received the compiled program).
I don't lose sleep over that because I rarely, if ever, deliver a
binary to someone without a separate signed contract that makes the
warranty provisions crystal clear.  Avoid most other "open source"
licenses -- they frequently have booby-traps.  IANAL, TINLA.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Jon K Hellan]

D. Hazelton wrote:
(as is the GPL - if you release code under
> the GPL you no longer have a legal right to it. Note the following text that 
> appears in the GPL:
> 
> "  We protect your rights with two steps: (1) copyright the software, and
> (2) offer you this license which gives you legal permission to copy,
> distribute and/or modify the software."
> --IE: Once you release the code under the GPL, it becomes the *copyrighted* 
> *property* of the FSF and you are just another person that the GPL is applied 
> to. 

"We" means "whoever is issuing" the license. I.e. you, if it's your 
work, and you didn't reassign it to somebody else.

Jon Kåre

Re: GPL vs non-GPL device drivers

[Theodore Tso]

On Wed, Feb 21, 2007 at 11:17:16PM -0500, D. Hazelton wrote:
> Since I tailor the license I apply to code I produce to meet the needs of the 
> person or entity I am writing it for, I've never run into this. In truth, the 
> LGPL is, IMHO, a piece of garbage. (as is the GPL - if you release code under 
> the GPL you no longer have a legal right to it. Note the following text that 
> appears in the GPL:
> 
> "  We protect your rights with two steps: (1) copyright the software, and
> (2) offer you this license which gives you legal permission to copy,
> distribute and/or modify the software."
> --IE: Once you release the code under the GPL, it becomes the *copyrighted* 
> *property* of the FSF and you are just another person that the GPL is applied 
> to. 

That's simply not true.  If you release the code under the GPL, you
are still the copyright holder.  You are simply using the terms of the
GPL to allow what *others* can do with your code.  So you are always
free to make it available under another license, including a
propietary one.  For example, way back when I was the only author of
all of the e2fsprogs code, I once sold a license allowing to allow the
PartitionMagic program to use portions of the e2fsprogs codebase in
their propietary Windows product; it help pay for the downpayment of
my house, too...

Now, if other people contribute code to your project, and you accept
it without a copyright assignment, then their code is generally
presumed to be implicitly licensed under the same license as the
original program, and so that would presumably restrict your ability
to relicense the project without getting their permission as well,
since some of the code or documentation is theirs.

The only way GPL'ed code can be become copyrighted by the FSF is if
you explicitly sign a copyright statement (and before you do that,
take a very close look at the FSF copyright assignment letter, and if
you don't know what "indemnify" menas, and have any kind of
significant assets, such as a house, or anticipate having significant
assets in the future, run, don't walk, to a lawyer and talk to them
first), or if you explicitly release the code into the public domain
and then they grab it and make some changes which are copyrighted by
the FSF.   

But saying that just by licensing your code under the GPL means that
the FSF owns your code?  That's just crazy talk.

						- Ted

Re: GPL vs non-GPL device drivers

[D. Hazelton]

On Thursday 22 February 2007 11:45, Theodore Tso wrote:
<snip>

> But saying that just by licensing your code under the GPL means that
> the FSF owns your code?  That's just crazy talk.
>
> 						- Ted

Actually, I've replied with private messages to several mails that arrived in 
reply to this explaining that the copyright clause I noted does, in fact, 
refer to the person releasing the code and the FSF. However, because it is 
located in the preamble and outside the terms of the license it has no legal 
bearing. As I've noted in those private mails, I pointed it out because I 
could see the FSF (in the person of Eben Moglen (or another attorney)) using 
it in a strong-arm tactic to gain copyright to the code.

DRH

Re: GPL vs non-GPL device drivers

[Adrian Bunk]

On Thu, Feb 22, 2007 at 11:45:22AM -0500, Theodore Tso wrote:
>...
> The only way GPL'ed code can be become copyrighted by the FSF is if
> you explicitly sign a copyright statement
>...
 
And even this is only possible if permitted by copyright law.

E.g. German copyright law explicitely states that copyright is not 
transferable except through inheritage. [1]

And German copyright law says that if you are granting exclusive usage 
rights, you must get an appropriate payment. [2]

Often much might depend on which copyright law applies in a specific 
case...

> 						- Ted

cu
Adrian

[1] http://bundesrecht.juris.de/urhg/__29.html
[2] http://bundesrecht.juris.de/urhg/__32.html

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: GPL vs non-GPL device drivers

[Alan]

> compiler people caught on to the economic opportunity.  Ever pay $5K
> for a CD full of GNU binaries for a commercial UNIX?  I did, after

No because I just downloaded them. Much easier and since they are GPL I
was allowed to do so, then rebuilt them all which took about 30 minutes
of brain time and a day of CPU time.

<Balmer impersonation deleted>

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/22/07, Alan <alan@lxorguk.ukuu.org.uk> wrote:
> > compiler people caught on to the economic opportunity.  Ever pay $5K
> > for a CD full of GNU binaries for a commercial UNIX?  I did, after
>
> No because I just downloaded them. Much easier and since they are GPL I
> was allowed to do so, then rebuilt them all which took about 30 minutes
> of brain time and a day of CPU time.

Oh yeah?  For IRIX in 1991?  Or for that matter, for Linux/ARM EABI
today?  Tell me, how many of what sort of users do you support
singlehandedly in an environment where you are a minority architecture
and everyone else takes the GNU tools for granted?  God knows I've got
better things to do with my time than roll the compiler-flag dice
again and again trying to get a sketchy GCC port not to ICE or, worse,
generate subtly broken code.  If it's so bloody easy, how do
CodeSourcery and MontaVista and Red Hat stay in business?  Not with
the quality of their code or their customer service, I'll tell you
that -- although Mark Mitchell is probably the best release manager
that any GNU project has ever had.

> <Balmer impersonation deleted>

Oh, please.  Steve Ballmer doesn't waste his time trying to explain to
overpaid GNU/Linux Morlocks (among which I number myself) how the
legal and economic underpinnings of their industry work and why they
shouldn't RAPE THEMSELVES playing stupid EXPORT_SYMBOL_GPL games and
cryptographically signing kernel modules.  But don't worry -- neither
do I beyond a couple of weeks after something really dunderheaded sets
me off, and in the meantime, you know where to find your keyboard's
"stick my fingers in my ears and shout la-la-la-I-can't-hear-you" key.
 :-)

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Alan]

> Oh yeah?  For IRIX in 1991?  Or for that matter, for Linux/ARM EABI
> today?  Tell me, how many of what sort of users do you support

Solaris (NTL - very large ISP/Telco), Dec server 5000 (for fun), Irix (and
linux cross for Irix removal), MIPS embedded (including the port to Linux
of Algorithmics toolchain) for Sonix then 3COM routers.

It's not a hard problem. gcc 2.x wasn't too hot on MIPS but it worked
although the Irix compiler generated vastly better code (and AFAIK still
does).

There are folks who maintain cross devel chains for just about every
Linux platform specifically for testing and while it isn't a small job
they do seem to be coping quite happily.

> CodeSourcery and MontaVista and Red Hat stay in business?  Not with
> the quality of their code or their customer service, I'll tell you
> that -- although Mark Mitchell is probably the best release manager

Lots of people would disagree with you about that (and independant
surveys would back the disagreement), like they would disagree with you
about most things.

> that any GNU project has ever had.

> me off, and in the meantime, you know where to find your keyboard's
> "stick my fingers in my ears and shout la-la-la-I-can't-hear-you" key.
>  :-)

I was hoping you'd take the pseudo-legal noise elsewhere.

Re: GPL vs non-GPL device drivers

[Randy Dunlap]

On Fri, 23 Feb 2007 00:18:26 +0000 Alan wrote:

> > me off, and in the meantime, you know where to find your keyboard's
> > "stick my fingers in my ears and shout la-la-la-I-can't-hear-you" key.
> >  :-)
> 
> I was hoping you'd take the pseudo-legal noise elsewhere.

Yes.  I find it interesting, but it should be on linux-legal@example.com
instead of here.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/22/07, Alan <alan@lxorguk.ukuu.org.uk> wrote:
> > Oh yeah?  For IRIX in 1991?  Or for that matter, for Linux/ARM EABI
> > today?  Tell me, how many of what sort of users do you support
>
> Solaris (NTL - very large ISP/Telco), Dec server 5000 (for fun), Irix (and
> linux cross for Irix removal), MIPS embedded (including the port to Linux
> of Algorithmics toolchain) for Sonix then 3COM routers.

My list of GNUs maintained is about the same:  SunOS 4.x, Solaris 2.x,
IRIX, ConvexOS, embedded MIPS and ARM and x86.  I've used, but didn't
maintain, GCC for embedded PowerPC and m68k, and until I found a
distro I could more or less trust to be point fixable, I did my own
desktop/server Linux toolchains for x86, PowerPC, and x86_64.  The
only one for which I resorted to coughing up the university's money to
the FSF was IRIX, and that's because it had to reach functional parity
with the Sun and Convex boxes pronto.

> It's not a hard problem. gcc 2.x wasn't too hot on MIPS but it worked
> although the Irix compiler generated vastly better code (and AFAIK still
> does).

It worked until you tried a 64-bit target or stressed the floating
point.  I had one of the first R4400s that ever left SGI, in an Indigo
with the IndigoVideo board when it was still in alpha.  Part of the
horse-trade between the university and the start-up I worked for was
that they got to run batch jobs on the thing when I wasn't physically
at the keyboard.  I had built several experimental toolchains for the
thing but concluded rapidly that I didn't want to tech-support that
shit.  Best $5K of someone else's money I ever spent.

> There are folks who maintain cross devel chains for just about every
> Linux platform specifically for testing and while it isn't a small job
> they do seem to be coping quite happily.

Er, I'm one of them.  :-)  When the ARM-based device I'm currently
working on first ships as an out-of-form-factor prototype to OEM
customers, it will be accompanied by a complete toolchain, kernel, and
userland, built from scratch using crosstool and ptxdist and extensive
patches I wrote, all of them to be contributed upstream because I
convinced my client that it's the right thing to do.  This includes
the latest upstream editions of each userland component, a gdbserver
that has been tested on multi-threaded soft-float NPTL binaries, the
first (public) ltrace to work correctly on Linux/ARM in at least three
years, the first (public) strace to understand ALSA ioctls, and
infrastructure for unit testing and system latency analysis.

It will be delivered as a set of git repositories with the complete
development history and tracking branches for outside projects, and
the only bits that aren't open source will be those encumbered by
inescapable trade secret agreements with chip vendors.  With the
exception of those closed binaries, everything from soup to nuts is
exactly reproducible from source on any Linux distro with a moderately
current native toolchain and autotools.  Before the first unit ships
retail, these git repositories will be carefully scrubbed of
encumbered material and opened to the public.  Pull one git repository
and run one script, and a few hours later you have your own JFFS2
image that you can burn to flash using facilities we will leave in
U-Boot for end-users' benefit.

Absolutely everything in the system can be point-fixed and recompiled
by the end user, with results as predictable and reproducible as I
know how to make them for myself.  Updates from third-party upstreams
can be merged using the tools that I believe to be best-in-class for
the purpose and use myself, daily.  No binary ever ships without
passing through an autobuild and unit test framework that I provide as
part of the end user source code release.  That's my personal standard
of release quality.  Now tell me, how does that compare to your
employer's?

> > CodeSourcery and MontaVista and Red Hat stay in business?  Not with
> > the quality of their code or their customer service, I'll tell you
> > that -- although Mark Mitchell is probably the best release manager
>
> Lots of people would disagree with you about that (and independant
> surveys would back the disagreement), like they would disagree with you
> about most things.

I have never particularly feared being in the minority, as long as I'm
right.  :-)  But seriously, if you haven't heard the complaints about
unreproducibility of Red Hat toolchains going back to the "GCC 2.96"
debacle, you haven't been listening -- and MontaVista became notorious
in the industry for deliberately mucking with kernel APIs as a vendor
lock-in tactic.  (They appear to have reformed substantially since the
2.4.x days.)  I don't know Mark personally but he appears to be as
open about CodeSourcery's processes and priorities as any toolchain
vendor has ever been, and GCC 4.1.2 looks like it's going to be as
stable as any upstream GCC release has ever been and perform decently
as well, so I don't have much to complain about in that department.
YMMV.

> I was hoping you'd take the pseudo-legal noise elsewhere.

You crack me up, Alan, you really do.  But in any case I have probably
responded as often to this thread (which I did not start and to which
I have perhaps contributed one message in ten) as is of use to anyone.
 HTH, HAND.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Alan]

> As a side note: The distinct wording of the GPL actually *invalidates* the 
> GNU/FSF claim that dynamically linking a work with, say, the readline 
> library,  means the work is a derivative of said library. The GPL states (in 

Not that I can see no, but you could take this to a list with lawyers not
programmers on and improve life for both parties

> clause 0) that the license only covers copying, modification and 
> distribution. Unless they are confusing "Linking" with "copying" or "creating 
> a derivative work" the claim is invalid - because, as it has been shown, a 
> mechanical process such as compilation or linking *cannot* create a 
> derivative work.

If you take the microsoft windows source code and compile it yourself
believe me you will get sued if you ship the resulting binaries and you
will lose in court.

Copyright law deals with the right to copy hence the name. Generally
speaking your right to use a work you have a copy of isn't constrained
(and isn't constrainable) by pure copyright, only by contract. The author
of a book for example has no power to stop you boiling the book if you
don't like it, or using it as bog paper. 

I would also note that the FSF makes no claim about dynamic v static
linking, merely about derivative works - which is the boundary the law is
interested in. Indeed the GPLv2 was written in the days where dynamic
linking was quite novel which is one reason the LGPL talks about

"For example, if you distribute copies of the library, whether gratis
 or for a fee, you must give the recipients all the rights that we gave
 you.  You must make sure that they, too, receive or can get the source
 code.  If you link a program with the library, you must provide
 complete object files to the recipients so that they can relink them
 with the library, after making changes to the library and recompiling
 it.  And you must show them these terms so they know their rights."

and says nothing about dynamic/static linking.

> Related to that... Though a parser generated by Bison and a tokenizer
> generated by Flex both contain large chunks of GPL'd code, their inclusion in 
> the source file that is to be compiled is mechanical - the true unique work 
> is in writing the file that is processed by the tool to produce the output. 

Flex is more complex because the resulting binary contains both compiled
work of yours and a support library of FSF owned code (-lfl). The non
computing analogy here is the difference between using a paint program to
create a work, and using a paint program to create a work but also
including other artwork (eg clipart). The same is true of the GCC compiler
as it merges your work with supporting library helper code modules which
are themselves creative works. Clearly you could replace those helper
modules with your own work and the result would be different.

A better example for your case might be indent where the program
processes your work mechanically and produces an output that doesn't
contain any other creative works, or most of intltools which merges
translations mechanically. (the merge code is sometimes a little creative
but thats in the sense of being a nuisance not in the legal sense of
creative work)

Alan

Re: GPL vs non-GPL device drivers

[D. Hazelton]

On Thursday 22 February 2007 09:10, Alan wrote:
> > As a side note: The distinct wording of the GPL actually *invalidates*
> > the GNU/FSF claim that dynamically linking a work with, say, the readline
> > library,  means the work is a derivative of said library. The GPL states
> > (in
>
> Not that I can see no, but you could take this to a list with lawyers not
> programmers on and improve life for both parties

See Section/clause 0 of the GPL. 

> > clause 0) that the license only covers copying, modification and
> > distribution. Unless they are confusing "Linking" with "copying" or
> > "creating a derivative work" the claim is invalid - because, as it has
> > been shown, a mechanical process such as compilation or linking *cannot*
> > create a derivative work.
>
> If you take the microsoft windows source code and compile it yourself
> believe me you will get sued if you ship the resulting binaries and you
> will lose in court.

But that's because it is *WINDOWS*, which, unless specifically granted to you, 
does not include a transfer of the right to distribute in *ANY* form. Every 
PC manufacturer that wants to distribute Windows on new machines they produce 
*MUST* sign an agreement with M$. As I have never seen any of those 
agreements I cannot state what the terms are and whether they are different 
for each company holding such a license.

And unless you've signed a licensing agreement over the source code to 
Windows, you're more than likely to have another lawsuit on your hands for 
possessing it. 

<snip>
> I would also note that the FSF makes no claim about dynamic v static
> linking, merely about derivative works - which is the boundary the law is
> interested in. Indeed the GPLv2 was written in the days where dynamic
> linking was quite novel which is one reason the LGPL talks about

Granted.

> "For example, if you distribute copies of the library, whether gratis
>  or for a fee, you must give the recipients all the rights that we gave
>  you.  You must make sure that they, too, receive or can get the source
>  code.  If you link a program with the library, you must provide
>  complete object files to the recipients so that they can relink them
>  with the library, after making changes to the library and recompiling
>  it.  And you must show them these terms so they know their rights."

Eh? Complete *object* files so that after making changes and recompiling they 
can relink it? Umm... I don't know about you, but that makes me laugh. What 
is the purpose of providing "Complete Object Files" to everyone if they are 
just going to recompile and relink the library?

Yes, I know this quite likely refers to any object files (or other binaries) 
that are part of the library but not part of the source. (and *are* required 
for the library to be completely functional)

> and says nothing about dynamic/static linking.
>
> > Related to that... Though a parser generated by Bison and a tokenizer
> > generated by Flex both contain large chunks of GPL'd code, their
> > inclusion in the source file that is to be compiled is mechanical - the
> > true unique work is in writing the file that is processed by the tool to
> > produce the output.
>
> Flex is more complex because the resulting binary contains both compiled
> work of yours and a support library of FSF owned code (-lfl). 

Copyright *doesn't* extend to compiled code. It cannot, because compiled code 
is a machine generated translation. A machine generated translation isn't the 
product of a creative process. And you can also provide all the routines 
normally provided by the support library. This means that the support library 
is *NOT* a necessary part of the system.

> The non 
> computing analogy here is the difference between using a paint program to
> create a work, and using a paint program to create a work but also
> including other artwork (eg clipart). 

Yes, but in both cases the result is *CLEARLY* the result of a creative 
process, and said clipart, unless it is in the form of an entirely machine 
generated image, is a separate work (and one resulting from a creative 
process) that you are using under license. (Unless said clipart was released 
into the public domain)

> The same is true of the GCC compiler 
> as it merges your work with supporting library helper code modules which
> are themselves creative works. 

Again you are confusing a mechanical translation process with a creative 
process. But it doesn't matter, in this case. The binary form of a program 
*technically* falls under the copyright on the source code - a mechanical 
process that translates a copyrighted work into another form *cannot* remove 
the original copyright.

But said modules have clearly defined and limited purposes.

> Clearly you could replace those helper 
> modules with your own work and the result would be different.

Yes.  And you've noted that yes, they can be replaced. Which means that they 
are also not a necessary part of the system. 

Claiming that any library (that can be replaced), either dynamically or 
statically linked to a program, is a requirement isn't smart. That also means 
that claiming a program that uses those libraries is a derivative work is 
bull.

Further, if such a library or module has an interface that must be accessed in 
one specific way, then said interface cannot be copyright. (As has been 
pointed out to me several times in other threads on LKML)

> A better example for your case might be indent where the program
> processes your work mechanically and produces an output that doesn't
> contain any other creative works, or most of intltools which merges
> translations mechanically. (the merge code is sometimes a little creative
> but thats in the sense of being a nuisance not in the legal sense of
> creative work)

True. But in those cases there isn't the gray area that exists surrounding 
claims of a Flex generated scanner or a Bison generated parser being 
derivative works of either program. 

> Alan

DRH

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/22/07, D. Hazelton <dhazelton@enter.net> wrote:
> > If you take the microsoft windows source code and compile it yourself
> > believe me you will get sued if you ship the resulting binaries and you
> > will lose in court.

"misappropriation of trade secrets" as well as copyright infringement

> But that's because it is *WINDOWS*, which, unless specifically granted to you,
> does not include a transfer of the right to distribute in *ANY* form. Every
> PC manufacturer that wants to distribute Windows on new machines they produce
> *MUST* sign an agreement with M$. As I have never seen any of those
> agreements I cannot state what the terms are and whether they are different
> for each company holding such a license.

contract in personam, creating causes of action for breach of contract
(for which remedies of specific performance are available) and
strengthening the case for misappropriation of trade secrets

> And unless you've signed a licensing agreement over the source code to
> Windows, you're more than likely to have another lawsuit on your hands for
> possessing it.

Not for possessing it.  For acquiring it unlawfully, and for doing
things with it that violate M$ copyright.

> <snip>
> > I would also note that the FSF makes no claim about dynamic v static
> > linking, merely about derivative works - which is the boundary the law is
> > interested in. Indeed the GPLv2 was written in the days where dynamic
> > linking was quite novel which is one reason the LGPL talks about

The FSF makes lots of such claims, all the time, and Eben Moglen uses
them to finesse his letter-of-opinion / affidavit racket, along with
the fork/exec fetish.  Fluendo.  Vidomi.  XCode.  Tornado.  NeXT.
Progress Software.

> > "For example, if you distribute copies of the library, whether gratis
> >  or for a fee, you must give the recipients all the rights that we gave
> >  you.  You must make sure that they, too, receive or can get the source
> >  code.  If you link a program with the library, you must provide
> >  complete object files to the recipients so that they can relink them
> >  with the library, after making changes to the library and recompiling
> >  it.  And you must show them these terms so they know their rights."
>
> Eh? Complete *object* files so that after making changes and recompiling they
> can relink it? Umm... I don't know about you, but that makes me laugh. What
> is the purpose of providing "Complete Object Files" to everyone if they are
> just going to recompile and relink the library?

Complete object files for the rest of the non-GPL application.  This
applies principally to static linking.  It also makes it much easier
to reverse engineer the application, because unless the person
jockeying the linker is really, really good, all of the interfaces
between the application components are visible with nm and objdump,
and you can use tools like ltrace to watch the calling sequences
between modules.  Selective symbol stripping and obfuscation on
partially linked binaries takes skill.

> > Flex is more complex because the resulting binary contains both compiled
> > work of yours and a support library of FSF owned code (-lfl).

No, flex is simpler because libfl is obviously a separate work of
authorship with a stable external interface, and the application that
links against it is not a derivative work of any of the creative
expression inside libfl.

> Copyright *doesn't* extend to compiled code. It cannot, because compiled code
> is a machine generated translation. A machine generated translation isn't the
> product of a creative process. And you can also provide all the routines
> normally provided by the support library. This means that the support library
> is *NOT* a necessary part of the system.

That's rubbish.  Copyright in compiled code is very nearly identical
to copyright in the source code from which it was generated; see
references in Lexmark, especially the seminal Altai case.  Copyright
in silicon is _not_ identical to copyright in the RTL from which it
was synthesized -- the term of protection for a "mask work" is limited
to 10 years -- 2 if it's not registered properly.  This prima facie
bizarre situation reflects the difference in national origin and
lobbying power between software and hardware makers, as well as the
greater difficulty of extracting the theory of operation of a complex
chip using an electron microscope.  The chip design oligopoly is bound
by a web of contractual covenants not to do this anyway, and they like
being able to snap up key people from upstart maverick companies and
rip off their designs without pesky legal interference.

> > The non
> > computing analogy here is the difference between using a paint program to
> > create a work, and using a paint program to create a work but also
> > including other artwork (eg clipart).

Not really.  Using stock images to illustrate a manuscript requires
license to copy and distribute them but rarely, if ever, creates a
derivative work.

> Yes, but in both cases the result is *CLEARLY* the result of a creative
> process, and said clipart, unless it is in the form of an entirely machine
> generated image, is a separate work (and one resulting from a creative
> process) that you are using under license. (Unless said clipart was released
> into the public domain)

Right.

> > The same is true of the GCC compiler
> > as it merges your work with supporting library helper code modules which
> > are themselves creative works.

Still nonsense.  It does not "merge your work" in any sense relevant
to copyright.  Insofar as any text has been copied from the library or
its sample applications to your application code, it is overwhelmingly
likely (IANAL, TINLA) to be considered part of the "scenes a faire" of
making engineering use of the library.  (This is, ironically, part of
the "doctrine of merger" of ideas and expression, which always, always
works against the party claiming copyright infringement.)  Insofar as
you have glued together program and library to form an engineering
product, it is again overwhelmingly likely to be considered a mere
"parcel of goods" and require authority from the library copyright
holder to copy and distribute.  See, however, Mirage Editions v.
Albuquerque A.R.T. -- you had better be relying on a valid license,
not "fair use", if your work may interfere with the library copyright
holder's ability to monetize his.

> Again you are confusing a mechanical translation process with a creative
> process. But it doesn't matter, in this case. The binary form of a program
> *technically* falls under the copyright on the source code - a mechanical
> process that translates a copyrighted work into another form *cannot* remove
> the original copyright.

Right.

> But said modules have clearly defined and limited purposes.

Doesn't matter to copyright.  Copyright is not about engineering use or purpose.

> > Clearly you could replace those helper
> > modules with your own work and the result would be different.

Not for any copyright purpose.  They are separate works of authorship,
whether or not the same entity holds copyright on them.

> Yes.  And you've noted that yes, they can be replaced. Which means that they
> are also not a necessary part of the system.

Irrelevant to copyright.  Copyright is not about engineering
necessity.  Some defenses against a claim of copyright infringement
are (again, see Lexmark), but you don't need any of those defenses --
you are operating under the terms of a valid contract containing
license from the copyright holder.

> Claiming that any library (that can be replaced), either dynamically or
> statically linked to a program, is a requirement isn't smart. That also means
> that claiming a program that uses those libraries is a derivative work is
> bull.

Whether it is a derivative work is determined, solely and exclusively,
by whether it "recasts, transforms, or adapts" the creative expression
in the original -- whether or not it could have been created in its
present form without reference to the original.  See Lotus v. Borland.

> Further, if such a library or module has an interface that must be accessed in
> one specific way, then said interface cannot be copyright. (As has been
> pointed out to me several times in other threads on LKML)

"scenes a faire"

> > A better example for your case might be indent where the program
> > processes your work mechanically and produces an output that doesn't
> > contain any other creative works, or most of intltools which merges
> > translations mechanically. (the merge code is sometimes a little creative
> > but thats in the sense of being a nuisance not in the legal sense of
> > creative work)

These are indeed obvious; but no more obvious (in terms of the
mountain of case law) than flex or bison or readline.

> True. But in those cases there isn't the gray area that exists surrounding
> claims of a Flex generated scanner or a Bison generated parser being
> derivative works of either program.

Ain't gray.  It's the blinding, shining, white of spotless innocence.
You just haven't awakened completely from Eben Moglen's opium dream in
which white is black and the question is who's to be master, that's
all.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Pavel Machek]

Hi!

> Actually, it's quite clear under US law what a derivative work is and
> what rights you need to distribute it, and equally clear that
> compiling code does not make a "translation" in a copyright sense.
> Read Micro Star v. Formgen -- it's good law and it's funny and
> readable.
> 
> I've drafted summaries from a couple of different angles since VJ
> requested a "translation into English", and I think this is the most
> coherent (and least foaming-at-the-mouth) I've crafted yet.  It was
> written as an answer to a private query to this effect:  "I write a
> POP server and release it under the GPL.  The Evil Linker adds some
> hooks to my code, calls those hooks (along some of the existing ones)
> from his newly developed program, and only provides recipients of the
> binaries with source code for the modified POP server.  His code
> depends on, and only works with, this modified version of my POP
> server.  Doesn't he have to GPL his whole product, because he's
> combined his work with mine?"
> 
> This is a fundamental misconception.  A <<product>> is not a "work

Ok, but this is not realistic. I agree that if Evil Linker only adds
two hooks "void pop_server_starting(), void pop_server_stopping()", he
can get away with that.

But... how does situation change when Evil Linker does #include
<pop3/gpl_header_file_with_some_inline_functions.h> from his
binary-only part?

I believe situation in this case changes a lot... And that's what
embedded people are doing; I do not think they are creating their own
headers or their own inline functions where headers contain them.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: GPL vs non-GPL device drivers

[David Schwartz]

> But... how does situation change when Evil Linker does #include
> <pop3/gpl_header_file_with_some_inline_functions.h> from his
> binary-only part?

Right, but *why* is he doing that? The answer: It is the most practical way
to write his driver.

> I believe situation in this case changes a lot... And that's what
> embedded people are doing; I do not think they are creating their own
> headers or their own inline functions where headers contain them.

They don't have to. You *cannot* use copyright to make ideas harder to
express. That's what patents are for.

All the people who make this linking argument seem to be completely missing
the entire *point* of copyright. A copyright protects the *one* way you
chose to express a particular idea. It cannot protect function. It cannot
make other ideas harder to express.

This is not some loophole or something. This is the most fundamental thing
about copyrights that there is. This is the reason they're so easy to get.
This is the reason they last so long. They *cannot* impede interoperation.
They cannot make other ideas harder to express. They can't even make the
very same idea you expressed harder to express.

Copyrights are not patents.

It is clear, at least in the United States, that something like "a kernel
driver to make <some particular version of Linux> work with <some particular
piece of hardware>" is an idea. You cannot own all the most practical ways
to express that idea. When practical engineering concerns make one way (or
one group of ways) the most reasonable, you simply *cannot* own them all
with copyright.

DS

Re: GPL vs non-GPL device drivers

[Pavel Machek]

On Sun 2007-02-25 03:33:38, David Schwartz wrote:
> 
> > But... how does situation change when Evil Linker does #include
> > <pop3/gpl_header_file_with_some_inline_functions.h> from his
> > binary-only part?
> 
> Right, but *why* is he doing that? The answer: It is the most practical way
> to write his driver.

Most practical way to get something Windows compatible is to pirate
Windows; I do not think that gives me permission to do so.

Similary, there are many ways to write inline functions present in
headers, and no, embedded developer being lazy does not mean they can
copy those functions into their proprietary module.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: GPL vs non-GPL device drivers

[David Schwartz]

> > Right, but *why* is he doing that? The answer: It is the most
> > practical way
> > to write his driver.

> Most practical way to get something Windows compatible is to pirate
> Windows; I do not think that gives me permission to do so.

This is comparing apples to oranges because Windows has an EULA. EULAs,
shrink-wraps, or the like change everything.

However, your statement is self-contradictory. By definition, to "pirate"
something is not to take what is practically needed to make it interoperate
with something else.

My point is that taking what you practically need to make something
interoperate with something else is *not* pirating. It is *not* taking
protected content, it is taking function.

How hard is this to understand -- you *cannot* use copyright to make any
ideas harder to express. A kernel driver to make a particular piece of
hardware work with a particular version of Linux *IS* an idea. You cannot
own the most practical ways to express an idea -- you can only own the one
way you chose to express that particular idea.

> Similary, there are many ways to write inline functions present in
> headers, and no, embedded developer being lazy does not mean they can
> copy those functions into their proprietary module.

Yes, it does. Have you read Lexmark v. Static Controls? You can take what
you need to interoperate.

DS

Re: GPL vs non-GPL device drivers

[D. Hazelton]

On Sunday 25 February 2007 19:47, David Schwartz wrote:
<snip>
>
> > Similary, there are many ways to write inline functions present in
> > headers, and no, embedded developer being lazy does not mean they can
> > copy those functions into their proprietary module.
>
> Yes, it does. Have you read Lexmark v. Static Controls? You can take what
> you need to interoperate.

This is apples and oranges, to use your idiom. In that case Lexmark had the 
code in the toner cartridges had to have a specific SHA1 hash in order for 
the printer to recognize them. Because the only way, then, to produce a 
functional toner cartridge for the printer was to *copy* that code *exactly*. 
In the case of a system where this is not the case, then you are free to 
write your own interface functions. If Lexmark had *not* been using a SHA1 
hash to validate that the cartridge was produced by them (and that is the 
real reason - Lexmark wanted to lock users of their printers into buying new 
toner cartridges from them) the case would have gone against Static Controls. 
The Lexmark v Static Controls decision applies only to interfaces where there 
is only, literally, one way to do it. What this means is that, yes, any use 
of the code in a GPL'd product that could be written in another manner is not 
covered by the "interoperability standard" that Lexmark v Static Controls 
describes. (No argument here, people: Lexmark v. Static Controls basically 
says "Since the only way for this replacement toner cartridge to work was to 
have the 'Toner Loading Program' exactly copied from one of the cartridges 
produced by Lexmark doing such is fair use." All application of this 
precedent to other things must show the exact same thing - namely that the 
*one* and *only* way for something you have designed/written to fulfill its 
purpose is to rely on a copy of a copyrighted work.  This ruling *only* 
applies to making computers, peripherals or parts of those peripherals and 
the copyrighted item that makes it interoperable.

Lexmark v. Static Controls does not give people carte blanche to use 
interfaces to programs that could be re-implemented by them without causing 
the output to stop functioning. In the given example the work including the 
GPL'd header file and using its functions is in violation of the GPL if not 
released under the GPL but is distributed. Why? Because unless there was some 
form of lock-in making those functions a requirement for interoperability 
the "Evil Hacker" could have written and used his own versions and his 
plugin/program would still have been interoperable.

DRH

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/25/07, Pavel Machek <pavel@ucw.cz> wrote:
> Ok, but this is not realistic. I agree that if Evil Linker only adds
> two hooks "void pop_server_starting(), void pop_server_stopping()", he
> can get away with that.
>
> But... how does situation change when Evil Linker does #include
> <pop3/gpl_header_file_with_some_inline_functions.h> from his
> binary-only part?

There is no such thing as a "GPL header file".  There is an original
work of authorship, that is, your POP server.  There is a modified
work of authorship (not exactly a "derivative work", but let's call it
an Annotated Edition in order to bring it into the "derivative works"
category), that is, your POP server as altered by the Evil Linker in a
coherent and readable way.  There is an independent work of
authorship, the Evil Linker's program.  And there is a claim that the
independent work of authorship infringes on the original author's
copyright in the POP server.

If the sole factual basis for that claim is that the Evil Linker's
program contains #include "what_you_said.h", then it's not going to
fly in court (IANAL, TINLA).  The #include directive itself is not
protectable expression, and anything that winds up in the Evil
Linker's binary is either a "method of operation" or "fair use" under
a "minimum practical amount of copying needed to accomplish a
sanctioned purpose" standard.  Interoperation, even competitive
interoperation and circumvention of partner licensing programs, is a
sanctioned purpose under US law.  You have to go pretty far out of
your way to find a case like Atari v. Nintendo in which the court
ruled that the competitor had been too lazy or venal in its reverse
engineering methodology not to be entitled to copy the bits needed to
interoperate.

> I believe situation in this case changes a lot... And that's what
> embedded people are doing; I do not think they are creating their own
> headers or their own inline functions where headers contain them.

Remember, I am not defending people who hack the kernel and then don't
release the source code to their hacked kernel.  (I'm not really
defending people who hack the kernel and write a closed-source
application locked to those hacks, either, although I am saying that
calling such tactics "illegal" or "GPL violation" is irrelevant and
wrong-headed.)  And when what they in fact did was to riffle shuffle
together two drivers from Linus's tarball and change the names of the
symbolic constants to match their hardware interface (itself doubtless
a half-assed clone of someone else's), there's no excuse for GPLing
the result.

But a 20KLoC 3-D graphics driver that happens to #include
<linux/whatever.h> is not thereby a "derivative work" of the kernel,
no matter how many entrypoints are labeled EXPORT_SYMBOL_GPL or
provided as inline functions.  And under the Lexmark standard,
MODULE_LICENSE("GPL") with a disclaimer in the doco is by far the
sanest way to deal with the EXPORT_SYMBOL_GPL mind games, and likely
(IANAL, TINLA) to be endorsed by any court in the US and probably lots
of other places too.  Especially when the graphics chip maker explains
that keeping their driver source code closed isn't really an attempt
to hide their knowledge under a bushel basket.  It's a defensive
measure against having their retail margins destroyed by nitwits who
take out all the busy-wait loops and recompile with -O9 to get another
tenth of a frame per second, and then pretend ignorance when
attempting to return their slagged GPU at Fry's.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Alan]

> of other places too.  Especially when the graphics chip maker explains
> that keeping their driver source code closed isn't really an attempt
> to hide their knowledge under a bushel basket.  It's a defensive
> measure against having their retail margins destroyed by nitwits who
> take out all the busy-wait loops and recompile with -O9 to get another
> tenth of a frame per second, and then pretend ignorance when
> attempting to return their slagged GPU at Fry's.

Wrong as usual...

The Nvidia driver and ATI drivers aren't full of magical delay loops and
if there was a way to fry those cards easily in hardware the virus folks
would already be doing it. The reverse engineering teams know what is in
the existing code thank you. Creating new open source drivers from it is
however hard because of all the corner cases.

You will instead find that both vendors stopping providing Linux related
source code at about the point they got Xbox related contracts. A matter
which has been pointed out to various competition and legal authorities
and for now where it seems to lie.

Fortunately at the moment there is a simple cure - buy Intel hardware.
That also has the advantage that you are more likely to get help because
some of us only look at AMD processor related problems as part of
official work duties nowdays, and plan to do so until AMD (as owner
of ATI) behave.

Alan

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/25/07, Alan <alan@lxorguk.ukuu.org.uk> wrote:
> > of other places too.  Especially when the graphics chip maker explains
> > that keeping their driver source code closed isn't really an attempt
> > to hide their knowledge under a bushel basket.  It's a defensive
> > measure against having their retail margins destroyed by nitwits who
> > take out all the busy-wait loops and recompile with -O9 to get another
> > tenth of a frame per second, and then pretend ignorance when
> > attempting to return their slagged GPU at Fry's.
>
> Wrong as usual...

If this is an error, it's the first one _you've_ caught me in.  Or did
I miss something conformant to external reality in your earlier
critiques?

> The Nvidia driver and ATI drivers aren't full of magical delay loops and
> if there was a way to fry those cards easily in hardware the virus folks
> would already be doing it. The reverse engineering teams know what is in
> the existing code thank you. Creating new open source drivers from it is
> however hard because of all the corner cases.

Several years ago I worked on a MIPS-based set-top prototype mated to
a graphics+HDTV board from a major PC 3-D vendor.  We had full
documentation and a fair amount of sample code under NDA.  We were on
the vendor's board spin 52 -- 52! and they'd sometimes spun the chip a
couple times internally between released boards -- before it could be
persuaded to do the documented thing with regard to video textures.
In the meantime, we frotzed a lot of boards and chips before we
decided to stick a triple-size fan to the damn thing with thermal
grease and to avoid taking any chances with new VRAM timings except in
the oversized chassis with the jet-engine fans.  Maybe things have
gotten better since then, but I doubt it.

Busy-wait loops were a rhetorical flourish, I grant you.  But software
interlocks on data movement that protect you against some "corner
case" you're unlikely to think of on your own are the norm, as is
software-assisted clock scaling guided by temperature sensors in half
a dozen places on chip and package.  You can drive enough watts
through a laptop GPU to fry an egg on it -- which is not kind to the
BGA bonds.  Yes, I have killed a laptop this way -- one that's
notorious for popping its GPU, but it's no accident that the last
thing I did to it was run a game demo that let me push my luck on the
texture quality.

It's also quite common, or used to be, for the enforcement of limits
on monitor sync timings to be done in software, and it's quite
possible to kill an underdesigned monitor or grossly exceed regulatory
emissions limits by overdriving its resolution and frame rate.  (I've
never actually blown one up myself, but I've pushed my luck
overdriving a laptop dock's DVI and gotten some lovely on-screen
sparklies and enough ultrasonics to set the neighbor's dog to
whining.)  Viruses that kill your monitor may be urban legend, but
it's a can of worms that a smart graphics vendor doesn't want to be
liable for opening.  The FCC also frowns on making it too easy for
hobbyists to turn a Class B device into a two-block-radius FM jammer.

> You will instead find that both vendors stopping providing Linux related
> source code at about the point they got Xbox related contracts. A matter
> which has been pointed out to various competition and legal authorities
> and for now where it seems to lie.

I know it's fun to blame everything on Redmond, but how about a
simpler explanation?  The technology and market for 3-D graphics is
now sufficiently mature to allow revenue maximization through market
segmentation -- in other words, charging some people more than others
for the same thing because they're willing and able to pay extra.  The
volumes are also high enough to test chips as they come out of fab and
bin them by maximum usable clock speed, just like Intel has done with
its CPUs for the last decade.  Blow a couple of dozen fuses to set a
chip ID, laser trim a couple of resistors to set a default clock
multiplier, and sell one for ten times what you get for the other.
It's the only way to survive in a mature competitive environment.

Now, suppose the silicon process for GPUs has stabilized to where chip
yields have greatly improved, and maybe 80% of the chips that work at
all are good enough to go in any but the top-of-the-line gamer
specials.  So where do they get the chips for a motherboard that sells
for $69 at Fry's?  They artificially bin them by target spec, blow
those fuses and trim those resistors, and charge what the market will
bear, niche by niche.  The driver picks up on the chip ID and limits
its in-system performance to the advertised spec, and everyone goes
home happy.

The graphics chip vendors are not utterly stupid.  They have seen what
has happened to the retail distribution of x86 CPUs, in which
overclocker types take six mid-range chips home, see which one they
can clock into the stratosphere for 24 hours without actually setting
the motherboard on fire (they don't mind a little toxic outgassing
from the thermal grease), and return the other five, not visibly the
worse for wear.  (Yes, I know people who have done this.)  They are
not about to hand their own heads to you on a silver platter along
with the source code that implements their market segmentation -- and
I, for one, don't blame 'em.

You go on believing that the X-Box contracts say "don't let Alan see
your source code any more".  Or if you prefer, believe that ATI and
NVidia don't know everything there is to know about each other's
external interfaces, or that they fear their source code will help
some VLSI sweatshop in Nowheristan clone chips that are protected by
hundreds of patents and are way more complicated inside than the
average CPU.  Because we all know how big the market for first-person
shooters is in the places in central Asia where patents can't reach.
Me, I'm going to stick to the explanation that's staring me in the
face when I read the annual reports.

> Fortunately at the moment there is a simple cure - buy Intel hardware.
> That also has the advantage that you are more likely to get help because
> some of us only look at AMD processor related problems as part of
> official work duties nowdays, and plan to do so until AMD (as owner
> of ATI) behave.

Taking your marbles and going home?  Now _there's_ a way to win
friends and influence people.  Personally, I don't exactly buy AMD or
Intel for desktop use; I buy a complete, working system that I'm never
going to be tempted to crack open and find out what's in it.  In
recent years that has meant Macs at home and whatever IT gave me at
work (preferably a craptop with lots of dots; I promise not to fry
them with game demos in the future).  And I certainly don't look at
processor related problems on my own time -- my hobbies are choral
singing and my rose garden.  Guess which one of us is a better
predictor of future market trends?

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Alan]

> Busy-wait loops were a rhetorical flourish, I grant you.  

Thats a complicated fancy way of saying you were talking rubbish ?

Alan

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/25/07, Alan <alan@lxorguk.ukuu.org.uk> wrote:
> > Busy-wait loops were a rhetorical flourish, I grant you.
>
> Thats a complicated fancy way of saying you were talking rubbish ?

No, it's a way of saying "yes, there are deliberate performance limits
in the driver code, but they're harder to explain than busy-wait
loops".  Ask anyone who has worked inside a peripheral device company,
especially one that sells into the OEM/ODM market.  It is
_standard_practice_ to fab a single chip design that runs as fast as
you know how, and then dumb it down in firmware to meet the spec that
the board vendor is willing to pay for.  If you don't, those guys will
steal you blind, diverting chips intended (and priced) for low-margin
commodity mobos into the high-margin gamer market.

There is, however, a gross error in my latest explanation of why ATI
and NVidia don't provide full driver source code.  Really an
embarrassing oversight.  Wouldn't blame you for ripping me a new one
over it.  Pity you were busy taking cheap shots at my tortured syntax.
 Here's what I forgot:

Macrovision.

Not that any of the stuff about market segmentation, retail margins,
and the FCC isn't true, but it's not the scariest thing in a PC
graphics vendor's world.  The scariest thing in their world is the
possibility that it will become widely known how to defeat the
"Macrovision in, Macrovision out" mechanism (and the equivalent for
DVD playback and HDMI).

Just so you know I'm not making this up:  I know where the "defeat
Macrovision" bits are on certain devices, and if I told you, Jack
Valenti would personally come to my house and ream me out with a
red-hot poker.  (Alan, that's a special kind of "talking rubbish"
known as "comic hyperbole".  I learned it from your Monty Python.  :-)
 Seriously though, those bits are in there, they're software
controlled (or were when I last fiddled with set-tops), and there are
large security deposits and large threats of being shut out of the
MPEG/DVD and DVI/HDMI patent pools riding on the graphics card makers'
promises to keep them hidden.  Not that they're that hard to reverse
engineer -- but they're not going to help you.

You're going to say this cat is already out of the bag; a quarter of
the teenagers in developed countries have the MaD sKiLlZ to rip DVDs
and pass them around on BitTorrent like so much 1970s kiddie porn.
And maybe that's so; but imagine next year's family PC with the HDMI
port attached to the 62" HDTV, dual-booting pirated Windows for
pirated first-person shooters and Linux for pirated DVDs, both of them
conveniently pre-installed by the neighborhood store-front beige-box
assembler.  That's the MPAA's worst nightmare -- and frankly, I'm not
too keen on it either.  I like seeing old movies lovingly restored and
published on DVD.  I'd like to see them come out someday in 16:9 720p,
preferably while my eyes are still good enough to tell the difference.

Anyway, that's more than enough purple prose.  Believe what you want to believe.

Re: GPL vs non-GPL device drivers

[Alan]

> Macrovision.

Just about every vendors hardware can do Macrovision. They just forget to
include the Macrovision control in published code, or hide it in a tiny
extra driver (Matrox) or in the BIOS switching firmware (SiS)

> Just so you know I'm not making this up:  I know where the "defeat
> Macrovision" bits are on certain devices, and if I told you, Jack

They've been published repeatedly, people have even released source code
with some of the macrovision functions included. One of the DVD hardware
vendors for example released complete Macrovision programming code for
their DVD hardware to the public.

The Nvidia driver code sets that have been investigated show no sign of
either secret macrovision code or delay loops, or stuff crippling the
chip. There is a reason for the last twopeople do speed limiting with
hardware traces because every kiddie on the planet can do software or
jumper based ones. 

Alan

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/26/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> I know it's fun to blame everything on Redmond, but how about a
> simpler explanation?

Says the master of conspiracy.

Trent

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/25/07, Trent Waddington <trent.waddington@gmail.com> wrote:
> On 2/26/07, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> > I know it's fun to blame everything on Redmond, but how about a
> > simpler explanation?
>
> Says the master of conspiracy.

Yes, I rather chuckled at the irony as I wrote that one.  :-)  But
there is a difference.  I've provided you with independent sources for
the basic data -- Nimmer and Corbin and dozens of appellate opinions
for the universal contract nature of copyright licenses, guidestar.org
for Form 990s, links that you can follow a couple of hops to two
actual letters of opinion that Moglen has written suggesting "GPL
circumvention" techniques, facts that you can verify about the
financial dealings surrounding the formation and acquisition of Cygnus
Solutions, the campaign to squeeze OpenSSL out of the GNUniverse, and
the unreproducibility of commercial cross-compilers built around GCC.
You don't have to believe a damn thing I say -- read the law and
follow the money trail for yourself.

If you care to know more about how the racket works, you can do your
own damn homework and see if you reach the same conclusions I did two
years ago.  Subsequent events -- the forced merger of OSDL into the
Linux Foundation, the flowering of the SFLC into the Software Freedom
Conservancy, the sunset of Oracle on Sun and rise of Unbreakable
Linux, the hocus-pocus around "license compatibility" as first Intel
and HP, then Sun, knuckle under, switch to the GPL, and start pressing
IBM and Oracle to do the same, the war of the "patent pledges" -- fit
into the same pattern.  I was disgusted then, and I haven't seen any
reason to become less so.  I don't actually enjoy this sort of
muckraking -- it's dirty work and I have better things to do.

Watch for more posturing about Microsoft/Novell -- funny how the
distro that regularly pays Eben Moglen to give keynote speeches has
been charging by the seat for years, but the distro that does a deal
with the _other_ devil is threatened with being written out of GPL v3.
 Watch for -- but wait, I gave up ranting for Lent.  Watch for
anything you like, keep scanning the horizon for Moby Ballmer and his
secret deals to keep you dual-booting into Windows for your
frag-fests.  When your pet shark in law professor's clothing decides
_your_ arm would be tasty next, don't come crying to me.  This really
is the absolute last I have to say on this topic in a public forum, in
2007 anyhow.

Re: GPL vs non-GPL device drivers

[D. Hazelton]

On Sunday 25 February 2007 06:54, Michael K. Edwards wrote:
> On 2/25/07, Pavel Machek <pavel@ucw.cz> wrote:
<snip>
> But a 20KLoC 3-D graphics driver that happens to #include
> <linux/whatever.h> is not thereby a "derivative work" of the kernel,
> no matter how many entrypoints are labeled EXPORT_SYMBOL_GPL or
> provided as inline functions.  And under the Lexmark standard,
> MODULE_LICENSE("GPL") with a disclaimer in the doco is by far the
> sanest way to deal with the EXPORT_SYMBOL_GPL mind games, and likely
> (IANAL, TINLA) to be endorsed by any court in the US and probably lots
> of other places too.  Especially when the graphics chip maker explains
> that keeping their driver source code closed isn't really an attempt
> to hide their knowledge under a bushel basket.  It's a defensive
> measure against having their retail margins destroyed by nitwits who
> take out all the busy-wait loops and recompile with -O9 to get another
> tenth of a frame per second, and then pretend ignorance when
> attempting to return their slagged GPU at Fry's.

At that point, Mike, you are treading on *very* thin ice. With Intel having 
released the complete source to their chipsets and with the number of totally 
free 3D drivers that don't slag GPU's...

However - if the hardware is really that fickle then why is it on the market? 
Yes, it can run hot enough to slag itself - all modern CPU's run the same 
risk. Yet people, mostly the "Power Gamers", will push a CPU beyond their 
rated spec's and have it riding the edge of thermal breakdown. Because of the 
nature of the 3D accelerator market most manufacturers (of the chips 
themselves) have already pushed their chips to that thermal edge, and some of 
the makers of the boards will even provide the end user means to push the 
chips even further.

However, even *with* some hardware manufacturers providing a way for the 
end-user to do it, pushing the componets to the edge of thermal breakdown (or 
beyond and keeping them in check through an active cooling system) is 
not "normal and expected use". As well, if the that is the argument that 
NVidia and ATI use (that they are worried about people recompiling the code 
with busy-loops stripped out) then they don't know the Open Source community 
well. In general the people that are most likely to recompile the driver with 
the busy-loops removed don't run Open Source systems - they run Windows. 
Those people are called "competetive gamers" and 99% of the games they play 
are only available for Windows.

What I'm trying to say is: Just like the "It gives away too much information 
on our IP" claim, the "People will recompile it with code needed to keep it 
from destroying itself" claim is bunk. Even moreso if their code is 
documented well enough that the purpose of the busy-wait loop is clear.

DRH

Re: GPL vs non-GPL device drivers

[Stephen Clark]

Pavel Machek wrote:

>Hi!
>
>  
>
>>Actually, it's quite clear under US law what a derivative work is and
>>what rights you need to distribute it, and equally clear that
>>compiling code does not make a "translation" in a copyright sense.
>>Read Micro Star v. Formgen -- it's good law and it's funny and
>>readable.
>>
>>I've drafted summaries from a couple of different angles since VJ
>>requested a "translation into English", and I think this is the most
>>coherent (and least foaming-at-the-mouth) I've crafted yet.  It was
>>written as an answer to a private query to this effect:  "I write a
>>POP server and release it under the GPL.  The Evil Linker adds some
>>hooks to my code, calls those hooks (along some of the existing ones)
>>from his newly developed program, and only provides recipients of the
>>binaries with source code for the modified POP server.  His code
>>depends on, and only works with, this modified version of my POP
>>server.  Doesn't he have to GPL his whole product, because he's
>>combined his work with mine?"
>>
>>This is a fundamental misconception.  A <<product>> is not a "work
>>    
>>
>
>Ok, but this is not realistic. I agree that if Evil Linker only adds
>two hooks "void pop_server_starting(), void pop_server_stopping()", he
>can get away with that.
>
>But... how does situation change when Evil Linker does #include
><pop3/gpl_header_file_with_some_inline_functions.h> from his
>binary-only part?
>
>I believe situation in this case changes a lot... And that's what
>embedded people are doing; I do not think they are creating their own
>headers or their own inline functions where headers contain them.
>									Pavel
>  
>
The amount copied has to be significant. A few lines against the 
millions in the kernel would
not be enough to be copyright infringement.

-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)

RE: GPL vs non-GPL device drivers

[David Schwartz]

> On 2/20/07, David Schwartz <davids@webmaster.com> wrote:
> > There is no such thing as the "combined work". If I put a DVD
> > of The Phantom
> > Menace in the same box as a DVD of The Big Lebowski, the box is not a
> > "combined work".

> If you can't even agree on that the legal concept of a combined work
> exists then you're obviously too far from reality for anyone to reason
> with.

The term "combined work" is sometimes used to mean a combination of two or
more works whether or not the result is a work. It is also sometimes used to
refer to a work that contains literal elements from one or more other works.
There is a very important distinction between these two uses. (And it's
sometimes used to mean something that contains literal elements from one or
more works, whether or not that thing is a work and whether or not the
elements taken are protectable.)

In your example, there is no "the combined work" because the combination
does not produce a work. Look at my example, if you put a DVD of The Phantom
Menace in the same box as a DVD of The Big Lebowski, is the box a "combined
work"? Obviously not, it simply contains two works.

In any event, I've been unable to find anything remotely resembling a clear
definition of "combined work". It's not clear whether a "combined work" is
supposed to be a type of work or can be a combination of works that is not
itself a work.

I have seen many people say that something is "legally considered a combined
work", but as far as I can tell, there is no such legal term. If you have a
citation to the contrary, I'd very much like to see it.

> It's a given.. are you seriously contending that if you combine two
> copyright works you are not obliged to conform with the conditions of
> the license on one of them when making a copy of the combined work?

The problem with statements like the above is that it's imposisble to tell
what you're talking about. You use terms like "combined work", which as far
as I can tell, could mean almost anything. You talk about when you "combine
two works", but there are many different types of combination that have very
many different meanings. (For example, mere aggregation versus creative
selective combination.)

The short answer to your question is yes. Owners of intellectual property
have some rights but not all rights, and in many cases, the right you are
talking about is not one of the rights they have. This is not arbitrary or
some kind of loophole, this is for very fundamental and important reasons.

Copyright is not supposed to make any ideas any more difficult to express.
You are only supposed to be able to protect the one way you chose to express
an idea. It is a serious abuse of copyright to claim that your copyright
protects certain functional ideas such that all those who try to express
them must follow your rules.

DS

Re: GPL vs non-GPL device drivers

[Jan Engelhardt]

On Feb 15 2007 18:43, Neil Brown wrote:

>> > We seem to have different definitions of open and closed.
>> 
>> Open = 3rd party Linux drivers can be loaded. Closed = No third party
>> Linux drivers can be loaded.
>
>Loading a driver is not at issue.  Anyone may load a driver.

And, after all, because loading is not distribution, you may
rip out export_symbol_gpl and use sysfs directly. It does not
make legal things any safer though, I'd say [ianal].


Jan
-- 

Re: GPL vs non-GPL device drivers

[Nick Piggin]

v j wrote:
> On 2/14/07, Randy Dunlap <rdunlap@xenotime.net> wrote:
> 
>> At least one of us is confused about that an embedded User is.
>> It seems to me that you are an embedded developer, not User.
>> I doubt that most Embedded Users care what their OS is,
>> or even know what an OS is.
> 
> 
> I am not sure what the difference is. We are trying to use Linux to
> support our application. It may be that Linux has a bug, or our
> application. When it is Linux, that has the problem, I  have tried to
> inform the community of that.


The difference is that you are selling it and not contributing back.

I think the legal term is something like distributing copyright
material without a license.


>> > Not everybody has to be a contributor. The reason Linux is popular is
>> > because of its openness. Take that away and see where it goes.
>>
>> We seem to have different definitions of open and closed.
> 
> 
> Open = 3rd party Linux drivers can be loaded. Closed = No third party
> Linux drivers can be loaded.


So most linux kernel developers chose to contribute to Linux because
they prefer something closer to the GPL's notion of open (assuming
your definitions are in the context of the legality of redistributing
the end result).

Don't take offence, but most of us don't _want_ the embedded
developers who contribute nothing back. Even if you tripled the total
Linux userbase, how would that be a good thing for anyone but yourself?

Now imagine if nobody contributed anything back.

The reason Linux is good enough that you chose in the first place is
because of everyone contributing back. Why would we want to undermine
that? My aim for Linux is not to have it shut down VxWorks, or to have
a huge userbase, but to be the best OS out there.

Maybe that helps explain the why others here don't share your opinion?

With that said, there are some reasonable free BSD licensed operating
systems out there that you can use without opening your source.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: GPL vs non-GPL device drivers

[Xavier Bestel]

On Wed, 2007-02-14 at 23:28 -0800, v j wrote:
> Open = 3rd party Linux drivers can be loaded. Closed = No third party
> Linux drivers can be loaded.

Then go ahead and use Windows CE or VxWorks. By your silly definition
they are pretty open.

	Xav

Re: GPL vs non-GPL device drivers

[Mohammed Gamal]

I am still a kernel newbie, and I am still not very much aware about
the GPL vs. Non-GPL drivers debate. I personally think it'd be better
that all drivers should be GPL'd but if that's the case, what would be
the legal position of such vendors as ATI or NVIDIA who supply closed
source drivers? Would it be illegal to use them?

I know this question might sound silly, but as I said before I have
only little awareness about the issue.

Re: GPL vs non-GPL device drivers

[Xavier Bestel]

On Thu, 2007-02-15 at 12:51 +0200, Mohammed Gamal wrote:
> I am still a kernel newbie, and I am still not very much aware about
> the GPL vs. Non-GPL drivers debate. I personally think it'd be better
> that all drivers should be GPL'd but if that's the case, what would be
> the legal position of such vendors as ATI or NVIDIA who supply closed
> source drivers? Would it be illegal to use them?

Yeah, this is a recurrent debate, and the positions are mixed. Linus
said that the nvidia driver isn't developed only for linux but also for
windows, so it's not a true derivative of the kernel, so the GPL doesn't
really apply. But not everyone (I mean core developpers) fully agrees
IIRC.
But that's not the case with VJ's drivers, which are apparently solely
for linux, so should be distributed under the GPL.

	Xav

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/15/07, Xavier Bestel <xavier.bestel@free.fr> wrote:
> But that's not the case with VJ's drivers, which are apparently solely
> for linux, so should be distributed under the GPL.

In any case, you're free to use any driver, regardless of license..
copyright does not cover use, only "copying" and most, if not all,
jurisdictions make it clear that "copying into memory" is not a
copyright matter.

Trent

Re: GPL vs non-GPL device drivers

[Dave Jones]

On Thu, Feb 15, 2007 at 09:05:11PM +1000, Trent Waddington wrote:
 > On 2/15/07, Xavier Bestel <xavier.bestel@free.fr> wrote:
 > > But that's not the case with VJ's drivers, which are apparently solely
 > > for linux, so should be distributed under the GPL.
 > 
 > In any case, you're free to use any driver, regardless of license..
 > copyright does not cover use, only "copying" and most, if not all,
 > jurisdictions make it clear that "copying into memory" is not a
 > copyright matter.

One area that is clear however is distribution of the result.
You're free to do whatever you want to my code as long as it
never leaves your computer.  As soon as you give it to someone else,
you're bound by the conditions of the license to give copies
of the modified source.

		Dave

-- 
http://www.codemonkey.org.uk

Re: GPL vs non-GPL device drivers

[Dave Jones]

On Thu, Feb 15, 2007 at 12:00:56PM +0100, Xavier Bestel wrote:
 > On Thu, 2007-02-15 at 12:51 +0200, Mohammed Gamal wrote:
 > > I am still a kernel newbie, and I am still not very much aware about
 > > the GPL vs. Non-GPL drivers debate. I personally think it'd be better
 > > that all drivers should be GPL'd but if that's the case, what would be
 > > the legal position of such vendors as ATI or NVIDIA who supply closed
 > > source drivers? Would it be illegal to use them?
 > 
 > Yeah, this is a recurrent debate, and the positions are mixed. Linus
 > said that the nvidia driver isn't developed only for linux but also for
 > windows, so it's not a true derivative of the kernel, so the GPL doesn't
 > really apply. But not everyone (I mean core developpers) fully agrees
 > IIRC.

to further expand on the above question it isn't really crystal clear
whether this (from the ATI driver) is legal..
(psuedo diff vs the kernel agp drivers)



+#ifdef STANDALONE_AGPGART
 MODULE_AUTHOR("Jeff Hartmann <jhartmann@precisioninsight.com>");
 MODULE_PARM(agp_try_unsupported, "1i");
 #ifdef MODULE_LICENSE
 MODULE_LICENSE("GPL and additional rights");
+#endif


and then linking the result to their binary blob.
I assume ATI's lawyers think its legal, as it's been a year and
a half since I first brought this questionable act to their
attention.

		Dave

-- 
http://www.codemonkey.org.uk

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/15/07, Dave Jones <davej@redhat.com> wrote:
> I assume ATI's lawyers think its legal, as it's been a year and
> a half since I first brought this questionable act to their
> attention.

Lawyers don't think X is legal.. that's not how lawyers think.  If
ATI's lawyers have advised ATI on this at all, and ATI has taken their
lawyers' advice, then the advice would have been:  we believe the risk
of liability is acceptable.

The only reason I can imagine why a lawyer would advise a client that
it is an acceptable risk to do something legally questionable with the
linux kernel is that so few kernel people have been sued for, or given
notice of, an infringement.

If any of the kernel developers, other than Harald Welte, are
enforcing their copyright, they don't tend to publicize it.

I, personally, don't know why anyone who owned copyright on any GPL
software and had no desire to enforce that copyright, would not offer
to assign their copyright to the FSF so they can defend it.. but I
imagine people have their reasons.

Trent

Re: GPL vs non-GPL device drivers

[Jan Engelhardt]

Hi,


On Feb 15 2007 21:35, Trent Waddington wrote:
>
> I, personally, don't know why anyone who owned copyright on any GPL
> software and had no desire to enforce that copyright, would not offer
> to assign their copyright to the FSF so they can defend it.. but I
> imagine people have their reasons.

They would possibly change it to GPLv3.


Jan
-- 

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Wed, 2007-02-14 at 23:28 -0800, v j wrote:
> On 2/14/07, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > At least one of us is confused about that an embedded User is.
> > It seems to me that you are an embedded developer, not User.
> > I doubt that most Embedded Users care what their OS is,
> > or even know what an OS is.
> 
> I am not sure what the difference is. We are trying to use Linux to
> support our application. It may be that Linux has a bug, or our
> application. When it is Linux, that has the problem, I  have tried to
> inform the community of that.

It would be much more helpful - especially for your product - to fix the
bug. And to stay "open" you can also submit the patch.

> > > Not everybody has to be a contributor. The reason Linux is popular is
> > > because of its openness. Take that away and see where it goes.
> >
> > We seem to have different definitions of open and closed.
> 
> Open = 3rd party Linux drivers can be loaded. Closed = No third party
> Linux drivers can be loaded.

You can always load 3rd party drivers - even if you compile module
support out of it.
Or do you really meant: Closed == No closed source 3rd party drivers
will be loaded because it is the decision of the company that pays the
developers.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

RE: GPL vs non-GPL device drivers

[Stuart MacDonald]

From: On Behalf Of v j
> On 2/14/07, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > We seem to have different definitions of open and closed.
> 
> Open = 3rd party Linux drivers can be loaded. Closed = No third party
> Linux drivers can be loaded.

That is BSD-openness; the freedom to do anything with the code you
receive, including making it so that others who receive modified code
from you *don't* have the same freedom.

Linux is GPLed, and thus uses GPL-openness:
Open = All source code is available to all, so that the code may
survive and freedoms be preserved. Closed = Non-available source code.

This ensures that others who receive modified code from you also
receive the same freedoms you received.

From: On Behalf Of v j
> Sent: February 15, 2007 12:39 AM
> No its not. It wasn't common knowledge 3 years ago when we chose Linux
> as an embedded platform. If it indeed is common knowledge that
> loadable modules in Linux have to be open-source then it is very
> probable that we wouldn't have chosen Linux as the platform of choice.

Counter-example: we've been using uClinux in an embedded system since
2002, over 4 years. It was common knowledge at that time that many
people, including some lawyers, considered drivers to be a derived
work of the kernel and thus the GPL would apply to them. That's how I
found out about it.

Linus does allow for one exception; drivers written for other OSes
that happen to compile for Linux as well. I believe this is the POSIX
exception mentioned elsethread. However, from your description of
requiring GPL-only symbols, I'm pretty sure your driver is a derived
work. Since you're distributing it (inside your device), the code must
be made available, under the GPL.

You also asserted that the code is only useful to your competitors.
That simply is not true. No company suppports a product forever, even
if they believe they will. Once that support is gone, the only way to
fix bugs or improve the product is to **have the code in hand**. THAT
is what the GPL-openness is all about. THAT is when the code is useful
to the open source community at large. Since that need is inevitable,
the code must be provided up-front, when distribution starts.

..Stu

Re: GPL vs non-GPL device drivers

[Scott Preece]

On 2/15/07, Stuart MacDonald <stuartm@connecttech.com> wrote:

> Linus does allow for one exception; drivers written for other OSes
> that happen to compile for Linux as well. I believe this is the POSIX
> exception mentioned elsethread. However, from your description of
> requiring GPL-only symbols, I'm pretty sure your driver is a derived
> work. Since you're distributing it (inside your device), the code must
> be made available, under the GPL.
---

It really is legally unclear. There is substantial case law that
supports the idea that interfacing for interoperability does not
create a derived work. I agree that it's uncivil to ignore the
author's intentions, but I think that it's very unclear whether it's
"illegal". The company I work for has made the choice to avoid the
question and ship only GPL kernel modules, which seems like the right
answer to me.

---
>
> You also asserted that the code is only useful to your competitors.
> That simply is not true. No company suppports a product forever, even
> if they believe they will. Once that support is gone, the only way to
> fix bugs or improve the product is to **have the code in hand**. THAT
> is what the GPL-openness is all about. THAT is when the code is useful
> to the open source community at large. Since that need is inevitable,
> the code must be provided up-front, when distribution starts.
---

Note that it is possible that what vj said is strictly true. IF the
product they ship is non-modifiable, then it's hard to argue that
anyone else could maintain it. And if the drivers are for devices
proprietary to their hardware, then they have no real value to anyone
else. And the drivers MIGHT contain information useful to their actual
competitors. I have no knowledge as to whether those conditions
actually apply.

scott

Re: GPL vs non-GPL device drivers

[Xavier Bestel]

On Thu, 2007-02-15 at 18:36 -0600, Scott Preece wrote:
> if the drivers are for devices
> proprietary to their hardware, then they have no real value to anyone
> else. And the drivers MIGHT contain information useful to their actual
> competitors.

Don't you feel like a contradiction in those two sentences ? :)

	Xav

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Thu, 2007-02-15 at 18:36 -0600, Scott Preece wrote:
[...]
> Note that it is possible that what vj said is strictly true. IF the
> product they ship is non-modifiable, then it's hard to argue that
> anyone else could maintain it. And if the drivers are for devices

The GPL has no special handling for that case.

> proprietary to their hardware, then they have no real value to anyone
> else. And the drivers MIGHT contain information useful to their actual
> competitors. I have no knowledge as to whether those conditions

And that may a (BTW invalid) reason for lots of companies but you
probably won't find an exception in the GPLv2 for this.
And if you infringe on others' patents, you should probably look
elsewhere for a solution of that problem.

> actually apply.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Dave Jones]

On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:

 > Not everybody has to be a contributor. The reason Linux is popular is
 > because of its openness. Take that away and see where it goes.

please expand on this openness.
Especially wrt your add-ons.

		Dave

-- 
http://www.codemonkey.org.uk

Re: GPL vs non-GPL device drivers

[Xavier Bestel]

On Wed, 2007-02-14 at 22:27 -0800, v j wrote:
> You are right. I have not contributed anything to Linux. Except one
> small patch to the MTD code. However, I don't think that is the point
> here. I am perfectly willing to live with the way Linux is today. I am
> telling you as a user that if Linux continues on the current path it
> will become less and less attractive to Embedded Users.

Guess what ? No one cares. If being serious about the GPL means that
free-riders like you, who take and never give back, prefer to go
elsewhere, that's not a problem. No one looses anything.

BTW, the thousands of different predictions "if linux doesn't do X,
it'll never be successful" get old pretty quicly.

	Xav

Re: GPL vs non-GPL device drivers

[Neil Horman]

On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:
> On 2/14/07, Dave Jones <davej@redhat.com> wrote:
> >On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote:
> >
> >Welcome to three months ago.
> >Here in the future, this was deemed a non-issue.
> >However this does highlight another problem.
> >End-users who take linux for use in embedded systems (especially)
> >tend to live in their own little world rarely contributing anything
> >back to upstream, popping up occasionally when months after decisions
> >have been made on things.   Remind me again why we should care about
> >your out of tree binary only modules ?
> 
> You are right. I have not contributed anything to Linux. Except one
> small patch to the MTD code. However, I don't think that is the point
> here. I am perfectly willing to live with the way Linux is today. I am
> telling you as a user that if Linux continues on the current path it
> will become less and less attractive to Embedded Users.
> 
No, it will become less attractive to those who are so paranoid about thier own
percieved inteleectual property that they can't see the value add of sharing
their source code with the community.  Take a look at digium (to name just one
company off the top of my head).  how much has sharing their source code drivers
for their FSX/FSO cards helped them out?  The embedded people who get the model
understand what contributing buys them.  Those who don't get it, aren't of a
concern to the community, and they'll be stuck paying royalties to Wind River /
OSE / etc. .  Take your pick.

> Not everybody has to be a contributor. The reason Linux is popular is
> because of its openness. Take that away and see where it goes.
You're right.  Not everyone has to be a contributor, people can be users and not
contribute anything.  About the only thing you cannot do is develop for linux
without contributing source, and whine about it when the development model
doesn't go your way.  What exactly did you expect here?

Neil

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Wed, 2007-02-14 at 22:27 -0800, v j wrote:
[...]
> here. I am perfectly willing to live with the way Linux is today. I am
> telling you as a user that if Linux continues on the current path it
> will become less and less attractive to Embedded Users.

Which is only (or more accurate: at most) true if the kernel module
developers actually work for the company selling the product.

And it is not (necessarily) true if the company selling the product
hires external people or companies for such a job - than it is much
better (and cheaper) if you get the whole source. It takes a lot of time
(both work time and calendar time) to coordinate debugging of 2rd party
closed source modules.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Rik van Riel]

v j wrote:

> Not everybody has to be a contributor. The reason Linux is popular is
> because of its openness. Take that away and see where it goes.

A few posts ago you said that your company had decided to take
away the openness by shipping closed source drivers to your
customers.

It is good to know that you see value in openness.

I hope your customers will see the value too, and make their
purchases accordingly.

-- 
All Rights Reversed

Re: GPL vs non-GPL device drivers

[Theodore Tso]

On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:
> You are right. I have not contributed anything to Linux. Except one
> small patch to the MTD code. However, I don't think that is the point
> here. I am perfectly willing to live with the way Linux is today. I am
> telling you as a user that if Linux continues on the current path it
> will become less and less attractive to Embedded Users.

But so what?  How will that hurt *Linux*?  If the Embedded developers
don't contribute changes back, it doesn't hurt us any if they go away
and start paying $$$ to VxWorks instead of using Linux for free.  

Contrawise, if Embedded developers do contribute their device driver
changes back to the kernel, they will be fine.  Note that we don't
even force them to do the work to make it be mainline acceptable; they
just have to make the sources available.  It could be crap code, but
it will fulfill the requirements of the the GPL.  Others in the
community can make the decision about whether they want to clean up
the code and get it mainlined, or it ignore it if it truly is a
one-off driver.  All you have to do is make the driver available.

And if you don't, why do you think that it is at all a credible
threat, or that we should shed even one tear, if you go away and use
some other OS for your embedded product?  It's not like in the case of
VxWorks where you get to say, "Do X or we take away a million dollars
worth of business."  And on the flip side, what I think you will find
is that if you do contribute to the community and be a good community
member, others will cut you some slack when the time comes because
you've built up the good karma.  But that requires that you be a good
community member.  If in contrast you find that it's cheaper to pay
$$$ to some embedded OS company, please feel free to do this.  No one
is forcing you to move from Linux 2.4 to Linux 2.6, or even to stay
with Linux.

							- Ted

Re: GPL vs non-GPL device drivers

[v j]

So far I have heard nothing but, "if you don't contribute, screw you."
All this is fine. Just say so. Make it black and white. Make it
perfectly clear what is and isn't legal. If we can't load proprietary
modules, then so be it. It will help everybody if this is out in the
clear, instead of resorting to stupid half measures like
EXPORT_SYMBOL_GPL.

On 2/15/07, Theodore Tso <tytso@mit.edu> wrote:
> On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:
> > You are right. I have not contributed anything to Linux. Except one
> > small patch to the MTD code. However, I don't think that is the point
> > here. I am perfectly willing to live with the way Linux is today. I am
> > telling you as a user that if Linux continues on the current path it
> > will become less and less attractive to Embedded Users.
>
> But so what?  How will that hurt *Linux*?  If the Embedded developers
> don't contribute changes back, it doesn't hurt us any if they go away
> and start paying $$$ to VxWorks instead of using Linux for free.
>
> Contrawise, if Embedded developers do contribute their device driver
> changes back to the kernel, they will be fine.  Note that we don't
> even force them to do the work to make it be mainline acceptable; they
> just have to make the sources available.  It could be crap code, but
> it will fulfill the requirements of the the GPL.  Others in the
> community can make the decision about whether they want to clean up
> the code and get it mainlined, or it ignore it if it truly is a
> one-off driver.  All you have to do is make the driver available.
>
> And if you don't, why do you think that it is at all a credible
> threat, or that we should shed even one tear, if you go away and use
> some other OS for your embedded product?  It's not like in the case of
> VxWorks where you get to say, "Do X or we take away a million dollars
> worth of business."  And on the flip side, what I think you will find
> is that if you do contribute to the community and be a good community
> member, others will cut you some slack when the time comes because
> you've built up the good karma.  But that requires that you be a good
> community member.  If in contrast you find that it's cheaper to pay
> $$$ to some embedded OS company, please feel free to do this.  No one
> is forcing you to move from Linux 2.4 to Linux 2.6, or even to stay
> with Linux.
>
>                                                         - Ted
>

Re: GPL vs non-GPL device drivers

[Josh Boyer]

On 2/15/07, v j <vj.linux@gmail.com> wrote:
> So far I have heard nothing but, "if you don't contribute, screw you."
> All this is fine. Just say so. Make it black and white. Make it
> perfectly clear what is and isn't legal. If we can't load proprietary
> modules, then so be it. It will help everybody if this is out in the
> clear, instead of resorting to stupid half measures like
> EXPORT_SYMBOL_GPL.

That does not prevent you from loading proprietary modules.  If your
legal team finds it acceptable to use non-GPL modules, then at your
risk it is possible to modify the kernel source to remove the
restriction anyway.

You are not blocked by this.  Your largest gripe seems to be the fact
that the community does not want to endorse proprietary modules.  For
_your_ use, with advice from _your_ legal team, with _your_ company
assuming any risk, you can certainly continue to use Linux because the
very people you're whining at _did_ contribute the code and provide it
under an Open Source license.  However, I would not want to be in your
position should your company choose to go that avenue and a lawsuit
occurred.

The fact that you're asking for the community to care about
proprietary modules seems odd to me.  It's as if you almost know that
it's legally questionable and you want the community somehow make it
ok to use proprietary modules so you feel better.

Anyway, Linux is not BSD.  If you want something you can take and not
have to care about giving back to, perhaps you should look into that.

josh

Re: GPL vs non-GPL device drivers

[Lennart Sorensen]

On Thu, Feb 15, 2007 at 12:41:45PM -0600, Josh Boyer wrote:
> You are not blocked by this.  Your largest gripe seems to be the fact
> that the community does not want to endorse proprietary modules.  For
> _your_ use, with advice from _your_ legal team, with _your_ company
> assuming any risk, you can certainly continue to use Linux because the
> very people you're whining at _did_ contribute the code and provide it
> under an Open Source license.  However, I would not want to be in your
> position should your company choose to go that avenue and a lawsuit
> occurred.

How could the community endorse closed source drivers?  The community
can't actually get a consensus on whether the GPL allows such things or
not and under what circumstances.  Linux uses the GPLv2 and whatever it
says, and whatever a court decides that means in a given lawsuit is
really what matters.  Even if 1000 people that were major contributers
to the linux kernel were to say "we think binary closed source drivers
are OK" doesn't mean that there isn't 1 other person who doesn't think
so, and wrote some part of what you decided to use with a closed source
driver and then decides to sue you and then you are back to what the
courts say in that particular case in whatever juristiction it takes
place in.  Maybe the opinion of those 1000 developers makes a difference
to the judge, maybe it doesn't.  That is all tha matters.  Whatever is
put into the kernel to make life inconvinient for closed source drivers
doesn't matter, since you could always remove that from your particular
copy of the kernel that you distribute.  The only thing that matters is
what happens if you do something that some developer believes violates
the GPLv2 and decides to sue you over violating the license of his
particular piece of the code.

If you don't want to deal with that, then don't use GPL'd code.  Go use
BSD or some commercial option that only wants money and the promise that
you not share their code with others.

--
Len Sorensen

Re: GPL vs non-GPL device drivers

[Xavier Bestel]

Le jeudi 15 février 2007 à 10:20 -0800, v j a écrit :
> So far I have heard nothing but, "if you don't contribute, screw you."
> All this is fine. Just say so. Make it black and white. Make it
> perfectly clear what is and isn't legal. If we can't load proprietary
> modules, then so be it. It will help everybody if this is out in the
> clear, instead of resorting to stupid half measures like
> EXPORT_SYMBOL_GPL.

Well, it's written in plain english in the GPL, so you can't pretend you
didn't know it.

And then, that was what guaranteed you you could use linux for your
product in the first place. You're being rude denying the same right to
others.

	Xav

Re: GPL vs non-GPL device drivers

[Miguel Ojeda]

On 2/15/07, v j <vj.linux@gmail.com> wrote:
> So far I have heard nothing but, "if you don't contribute, screw you."

Well, so far I have heard from you is "let me use my closed-source
drivers in Linux or bye bye".

> All this is fine. Just say so. Make it black and white. Make it

It is not black and white: You are the one who is using Linux; not the
other way.

In other words, you use Linux freely and don't help in any way;
however, you come to demand things and criticize hundreds of persons
who colaborated here.

> perfectly clear what is and isn't legal. If we can't load proprietary
> modules, then so be it. It will help everybody if this is out in the
> clear, instead of resorting to stupid half measures like
> EXPORT_SYMBOL_GPL.
>

Stupid, maybe. But some people just don't want closed-source
projects/companies like yours using their free work, without any kind
of feedback. Some others don't care, but they could in the future, as
it is their code, and that is your risk.

PD: Please don't top post.

-- 
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm

Re: GPL vs non-GPL device drivers

[Scott Preece]

On 2/15/07, Miguel Ojeda <maxextreme@gmail.com> wrote:

> Stupid, maybe. But some people just don't want closed-source
> projects/companies like yours using their free work, without any kind
> of feedback. Some others don't care, but they could in the future, as
> it is their code, and that is your risk.
>
---

So, how are such companies any different from the myriad individuals
and companies that use Linux on the desktop or in their server rooms
without ever modifying it and who also contribute nothing back to the
community? They are also, in many (most?) cases taking advantage of
the free (as in beer) nature of Linux - saving money by using the work
of others without returning anything, but the product builders seem to
get a lot more abuse...

scott

Re: GPL vs non-GPL device drivers

[David Lang]

On Thu, 15 Feb 2007, Scott Preece wrote:

> On 2/15/07, Miguel Ojeda <maxextreme@gmail.com> wrote:
>
>> Stupid, maybe. But some people just don't want closed-source
>> projects/companies like yours using their free work, without any kind
>> of feedback. Some others don't care, but they could in the future, as
>> it is their code, and that is your risk.
>> 
> ---
>
> So, how are such companies any different from the myriad individuals
> and companies that use Linux on the desktop or in their server rooms
> without ever modifying it and who also contribute nothing back to the
> community? They are also, in many (most?) cases taking advantage of
> the free (as in beer) nature of Linux - saving money by using the work
> of others without returning anything, but the product builders seem to
> get a lot more abuse...

if they don't modify it and don't distribute it there is not issue.

it's people who modify it (by creating a derived work) and then redistribute it 
that get the abuse.

now if your kernel module is _not_ a derived work (and such things can exist, 
much as some people don't want to admit it) then you don't have a problem 
either.

but the definition of what is a derived work is not cut-and-dry, and that is 
where you have to get lawyers involved if you care.

I am _not_ a lawyer, but there are two basic approaches you can take

1. The easy way out is to release the module source under a GPL compatable 
license.

2. If you don't want to do this you need to involve the lawyers to tell you if 
they think that your development work is derived or not, and even if you decide 
that it isn't you may have to prove that it's not in court, potentially in 
multiple juristrictions (in the relativly unlikly event that you offend enough 
different kernel developers that they take the time to sue you individually).

I believe that it's extremely unusual for a lawyer to give a cut-and-dry answer 
to a liability question, so from a liability point of view it seems clear cut.

what your company needs to decide is if they consider the risk to their "IP" to 
be outweight the costs of #2, including the risk that the lawyer is wrong and a 
cour may order you to stop distributing the product unless you comply with the 
GPL.

David Lang

Re: GPL vs non-GPL device drivers

[v j]

> > So, how are such companies any different from the myriad individuals
> > and companies that use Linux on the desktop or in their server rooms
> > without ever modifying it and who also contribute nothing back to the
> > community? They are also, in many (most?) cases taking advantage of
> > the free (as in beer) nature of Linux - saving money by using the work
> > of others without returning anything, but the product builders seem to
> > get a lot more abuse...
>
> if they don't modify it and don't distribute it there is not issue.

This is only because of the terms of GPL. Morally, as many here have
pointed out this should fall into the same category.

> it's people who modify it (by creating a derived work) and then redistribute it
> that get the abuse.

Atleast we try and report genuine bugs and submit patches when
necessary. We get abuse however because it is not clear what the terms
of GPL are WRT loadable modules. If this were written in black and
white and we knew what we were fighting against, this would not be an
issue. We only get crap because no one here yet knows how to interpret
proprietary modules loaded into the kernel.

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/16/07, v j <vj.linux@gmail.com> wrote:
> This is only because of the terms of GPL. Morally, as many here have
> pointed out this should fall into the same category.

I say it does.  If you have the ability, and enjoy Linux, you should
try and make the time to contribute some code or other assistance to
the Linux project.

> Atleast we try and report genuine bugs and submit patches when
> necessary.

Good stuff.

> We get abuse however because it is not clear what the terms
> of GPL are WRT loadable modules. If this were written in black and
> white and we knew what we were fighting against, this would not be an
> issue. We only get crap because no one here yet knows how to interpret
> proprietary modules loaded into the kernel.

It's written in black and white, in the license.  Apart from that,
Greg KH has made his opinion clear, and you have said you understand
and don't debate that he holds this opinion, and his code is what you
said you were linking to (the sysfs/class stuff), so why do you keep
saying that "it is not clear".

Do you think that, somehow, Linus' opinion trumps Greg KH's opinion on
his own code?

Trent

Re: GPL vs non-GPL device drivers

[v j]

> It's written in black and white, in the license.

Please point me to where it says I cannot load proprietary modules in
the Kernel.

>  Apart from that,
> Greg KH has made his opinion clear, and you have said you understand
> and don't debate that he holds this opinion, and his code is what you
> said you were linking to (the sysfs/class stuff), so why do you keep
> saying that "it is not clear".

I know his opinion. I don't debate his opinion. It is his code. I
choose not to use his code because of the license issue.

> Do you think that, somehow, Linus' opinion trumps Greg KH's opinion on
> his own code?

No, just that the trend is disturbing. If enough Kernel Developers
choose to write their Software in a way that prevents others from
using it freely, then that is troubling. Especially when these Kernel
Developers are substituting existing interfaces in the Kernel with
ones that are NEW and require specific licenses.

vj.

Re: GPL vs non-GPL device drivers

[Miguel Ojeda]

On 2/16/07, v j <vj.linux@gmail.com> wrote:
> > It's written in black and white, in the license.
>
> Please point me to where it says I cannot load proprietary modules in
> the Kernel.
>
> >  Apart from that,
> > Greg KH has made his opinion clear, and you have said you understand
> > and don't debate that he holds this opinion, and his code is what you
> > said you were linking to (the sysfs/class stuff), so why do you keep
> > saying that "it is not clear".
>
> I know his opinion. I don't debate his opinion. It is his code. I
> choose not to use his code because of the license issue.
>
> > Do you think that, somehow, Linus' opinion trumps Greg KH's opinion on
> > his own code?
>
> No, just that the trend is disturbing. If enough Kernel Developers
> choose to write their Software in a way that prevents others from
> using it freely, then that is troubling. Especially when these Kernel

Isn't there a big difference between "use GPL code" and "modify GPL
code, link closed modules to it & redistribute everything as
binaries"?

-- 
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/16/07, v j <vj.linux@gmail.com> wrote:
> > It's written in black and white, in the license.
>
> Please point me to where it says I cannot load proprietary modules in
> the Kernel.

It doesn't.  It does, however, say you can't distribute your module
unless you make it available under the same terms as the kernel.  It
makes that really clear.

I'll say that again, for everyone else who is reading this: the GPL
makes it really clear that extensions to a GPL work are required to be
distributed under the terms of the GPL.  All this junk about
"derivative works" is just the legal jargon used to implement the
intent of the GPL.  You can argue that a particular extension isn't a
derivative work if you want, but you can't argue with the intent..
cause it is written in plain english.

> I know his opinion. I don't debate his opinion. It is his code. I
> choose not to use his code because of the license issue.

That's good.

> No, just that the trend is disturbing. If enough Kernel Developers
> choose to write their Software in a way that prevents others from
> using it freely, then that is troubling. Especially when these Kernel
> Developers are substituting existing interfaces in the Kernel with
> ones that are NEW and require specific licenses.

It's hardly a new trend.. the kernel has always been GPL.. the intent
has always been that all extensions that are distributed be
distributed under the GPL.  This whole EXPORT_SYMBOL_GPL thing is
new.. but it doesn't require your module to be under the GPL to load,
it requires that your module export a license declaration that claims
it is GPL - you can do that without changing your license.  Frankly, I
don't understand why you're willing to ignore the intent of the GPL
but you don't appear to be willing to just make your module export a
license declaration of "GPL".

Trent

RE: GPL vs non-GPL device drivers

[David Schwartz]

> I'll say that again, for everyone else who is reading this: the GPL
> makes it really clear that extensions to a GPL work are required to be
> distributed under the terms of the GPL.  All this junk about
> "derivative works" is just the legal jargon used to implement the
> intent of the GPL.  You can argue that a particular extension isn't a
> derivative work if you want, but you can't argue with the intent..
> cause it is written in plain english.

I don't think it was the intent of the GPL that if you want to make drivers
for a GPL'd operating system, you must make the drivers GPL'd. That seems
like precisely the sort of software-patent oligopoly (owning every way to do
a particular thing) that the GPL was intended to combat.

I quote from Stallman: "Nobody is trying to patent specific programs; that
isn't allowed, but nobody would bother even if it was allowed. A patent
covering one specific program would not really matter to anyone. The reason
why these patents create an issue is that they're not about specific
programs, they're much more general. Each of these patents covers an idea
that you might use in implementing various different programs, that lots of
different programmers might use, might put into the programs that they are
writing. And that's what makes them obstacles and dangers to software
development activity."

This is precisely what "every Linux driver is a derivative work of my work"
is saying. It is totally counter to the spirit and intent of the GPL.

Every time you say, "that's a derivative work and you need to follow the
rules", that's one less situation where you can say, "this is fair use" in
an analogous case with a commercial work. If closed source drivers are
against the spirit of the GPL, then it's not fair use to tinker with a
commercial work to get it to work with your hardware.

Most certainly the spirit of the GPL is that it's fair use to tinker with a
work to get it to work on your hardware. Is it not fair use to share that
with other licensees of the original work? Should Microsoft be able to
prevent me from distributing patches to Windows that fix bugs or add
features?

It is so funny that the GPL community is succumbing to the same desire to
expand intellectual property rights to get more control over their work that
they condemn in the closed source world. The open source community should be
trying to expand fair use, not expand derivative works.

In addition, it is quite clear legally that if you take only what every
attempt to perform the same function must take, you are not a derivative
work. That is, if you are writing a Linux driver for an X1950 graphics card,
you can take what any Linux driver for an X1950 graphics could would
reasonably need to take. (See, among other cases, Lexmark. v. Static
Controls.) A copyright is not a patent, you can only own something if there
are multiple equally good ways to do it and you claim *one* of them.

DS

Re: GPL vs non-GPL device drivers

[Joshua Simmons]

> I quote from Stallman: "Nobody is trying to patent specific programs; that
> isn't allowed, but nobody would bother even if it was allowed. A patent
> covering one specific program would not really matter to anyone. The reason
> why these patents create an issue is that they're not about specific
> programs, they're much more general. Each of these patents covers an idea
> that you might use in implementing various different programs, that lots of
> different programmers might use, might put into the programs that they are
> writing. And that's what makes them obstacles and dangers to software
> development activity."

What are you talking about?  This is not about software patents AT ALL.
Not one person is claiming they have a patent on whatever it is that
V J's company is putting out (especially since we have no idea what
that might be).  Patents != copyright.


Software patents: This super cool red button idea is mine.  If you make
a red button, you have to give me money.

Copyright: This code is mine.  You can't copy my code without my permission.

GPL: You can copy my code all you want, BUT if you add on to it and give out
the results, you have to give out your code too!

Your argument might have some sort of merit, but I gave up trying to work
through it.  Stop confusing patents and copyright and try again.

Joshua Simmons

RE: GPL vs non-GPL device drivers

[David Schwartz]

> What are you talking about?  This is not about software patents AT ALL.

Yes, it is. The difference between a copyright and a patent is this
simple -- a copyright protects the one particular way you chose to do
something and a patent protects every possible way of doing the same thing
(or employing the same method).

> Not one person is claiming they have a patent on whatever it is that
> V J's company is putting out (especially since we have no idea what
> that might be).  Patents != copyright.

That's exactly what they're doing. Knowing only the *function* of his
program, they are claiming it must obey their licensing terms. They have no
idea exactly how he chose to implement that function, but claim they must
own it anyway.

> Software patents: This super cool red button idea is mine.  If you make
> a red button, you have to give me money.

> Copyright: This code is mine.  You can't copy my code without my
> permission.

Not quite. Copyright is: This particular implementation is mine, but you are
free to implement any idea any *other* way you want. You simply can't
implement an idea precisely the way I did it, but all ideas are open to you.

> GPL: You can copy my code all you want, BUT if you add on to it
> and give out
> the results, you have to give out your code too!

But that's not what's happening here. "A Linux driver for graphics cards
based on the X1950 chipset" is not an "add on" to Linux. It's an idea and a
function all on its own.

> Your argument might have some sort of merit, but I gave up trying to work
> through it.  Stop confusing patents and copyright and try again.

I do not have them confused. You cannot own "any practical way to make a
driver for Linux" under copyright, only patent gives you that kind of power.
You can, of course, own "the particular way I chose to make a Linux driver,
out of many other equally-good ways".

DS

RE: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Fri, 2007-02-16 at 03:42 -0800, David Schwartz wrote:
[...]
> Not quite. Copyright is: This particular implementation is mine, but you are
> free to implement any idea any *other* way you want. You simply can't
> implement an idea precisely the way I did it, but all ideas are open to you.

Actually you can legally (at least/even with author's rights hereover).
But it will be very hard to convince a judge and/or lawyers that you
didn't actually copy it.

And the question is moot anyways since it is extremely unlikely you end
up with the same implementation for the same problem (unless the problem
is small/simple/trivial enough like "binary search in a sorted array on
int's").

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Joshua Simmons]

> > Not one person is claiming they have a patent on whatever it is that
> > V J's company is putting out (especially since we have no idea what
> > that might be).  Patents != copyright.
> 
> That's exactly what they're doing. Knowing only the *function* of his
> program, they are claiming it must obey their licensing terms. They have no
> idea exactly how he chose to implement that function, but claim they must
> own it anyway.

They are not claiming ownership of his code.  They are claiming ownership of THEIR
code.  V J is taking their code, adding on to it and selling the result.  Without
the GPL, V J cannot legally do this.  With the GPL, he can legally do this IF he
also gives out the complete source.  I fail to see how anything you are saying
absolves him of this requirement.

Joshua Simmons

RE: GPL vs non-GPL device drivers

[David Schwartz]

> > That's exactly what they're doing. Knowing only the *function* of his
> > program, they are claiming it must obey their licensing terms.
> > They have no
> > idea exactly how he chose to implement that function, but claim
> > they must
> > own it anyway.

> They are not claiming ownership of his code.

When you claim that somoene else's work is a derivative work of yours, that
is precisely what you are doing. You are arguing that they could not have
even created that work without your permission.

> They are claiming
> ownership of THEIR
> code.  V J is taking their code, adding on to it and selling the
> result.  Without
> the GPL, V J cannot legally do this.

Not so. See any of the numerous cases that explain that you cannot own a
function using copyright. They are saying that because V J did X, he *MUST*
be taking their code because there is no other practical way to *do* X. This
is precisely what copyright *DOES* *NOT* *LET* *YOU* *DO*.

> With the GPL, he can
> legally do this IF he
> also gives out the complete source.  I fail to see how anything
> you are saying
> absolves him of this requirement.

The fact that they are claiming rights that are impossible with copyright
and inconsistent with its logic. Copyright covers the one way you chose to
do something out of the many possible ways to do it. To argue "you must have
taken my code because you were able to *DO* X" is arguing you own every
practical way to do X. This is what software patents do, but this is beyond
the scope of copyright.

How can they know he took their code to accomplish a particular function
unless they are claiming they own every way to accomplish that function?
This is precisely what the open source community stands *AGAINST*.
(Ownership of functions.)

DS

Re: GPL vs non-GPL device drivers

[Alexandre Oliva]

On Feb 17, 2007, "David Schwartz" <davids@webmaster.com> wrote:

> Not so. See any of the numerous cases that explain that you cannot own a
> function using copyright. They are saying that because V J did X, he *MUST*
> be taking their code because there is no other practical way to *do* X. This
> is precisely what copyright *DOES* *NOT* *LET* *YOU* *DO*.

So, since there's no other way to do Yesterday, exactly as performed
by the Beatles in the 1965 album Help!, I'm free to copy it, perform
it, create derived versions thereof and perform them, without paying
royalties to the current copyright holders?

> The fact that they are claiming rights that are impossible with copyright
> and inconsistent with its logic. Copyright covers the one way you chose to
> do something out of the many possible ways to do it. To argue "you must have
> taken my code because you were able to *DO* X" is arguing you own every
> practical way to do X. This is what software patents do, but this is beyond
> the scope of copyright.

You're on to something, but I think you're taking it too far.

One could always create a clean-room implementation of kernel headers
and use them to build a module that presumably wouldn't be a derived
work, as long as the binary is indeed created using these clean-room
headers.  But who does that, considering how quickly kernel headers
change, and that if you build the object code using the actual kernel
headers, then the binary is likely to be a derived work of the kernel,
even if the sources still aren't?

#include <std/IANAL.h>

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL vs non-GPL device drivers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

On Sat, 17 Feb 2007 04:44:36 -0200, Alexandre Oliva said:
> On Feb 17, 2007, "David Schwartz" <davids@webmaster.com> wrote:
> > Not so. See any of the numerous cases that explain that you cannot own a
> > function using copyright. They are saying that because V J did X, he *MUST*
> > be taking their code because there is no other practical way to *do* X. This
> > is precisely what copyright *DOES* *NOT* *LET* *YOU* *DO*.
> 
> So, since there's no other way to do Yesterday, exactly as performed
> by the Beatles in the 1965 album Help!, I'm free to copy it, perform
> it, create derived versions thereof and perform them, without paying
> royalties to the current copyright holders?

No, because there's other musically valid ways to perform the song - in the
style of Wayne Newton, or the band Slipknot, or restyled as a Bach cantata.

(Incidentally - in the case of the song Yesterday, there are *two* different
performance rights to consider.  The right to play the version that's on the
album Help!, which (usually) means you (as a radio station, or background-music
vendor, or DJ at a party, etc) need to pay royalties to somebody (usually the
record label), via ASCAP or BMI (two large payment clearinghouses - usually a
radio station or DJ just pays a lump-sum per month/year and ASCAP and BMI sort
it out).  Then there's the *music* copyright, which means that Wayne Newton's
manager gets to negotiate with the group that administers the copyright on
the song *itself* for how much it will cost Wayne to record his version.  Then
the record label gets to screw Wayne out of his share of the money that ASCAP
and BMI sends the label, but that's another rant.. ;)

But trying to call a kernel function in any other way than the one intended
by the function's author *isn't* valid - it may not even compile, if the
function's parameter list is formally incorrect, or it will likely OOPS
(perhaps later, after a stray pointer does a fandango on core).  And since
there *is* only one valid way to call (for instance) kzalloc(), it becomes
a 'scenes au faire', which is what the Lexmark ruling was about.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: GPL vs non-GPL device drivers

[Richard Knutsson]

David Schwartz wrote:
> Most certainly the spirit of the GPL is that it's fair use to tinker with a
> work to get it to work on your hardware. Is it not fair use to share that
> with other licensees of the original work? Should Microsoft be able to
> prevent me from distributing patches to Windows that fix bugs or add
> features?
>   
Yes they can, since you have (most likely) breached the contract! To fix 
a bug in Windows you will have to de-assemble their code (if you are not 
on their pay-role, of course) and that is explicitly forbidden. You are 
in no way allowed to read how Windows does things.
Or you may just have made random changes and it happens to work, I still 
don't think they would like it (what other thing may happened by that 
patch?)

Richard Knutsson

Re: GPL vs non-GPL device drivers

[Dave Neuer]

On 2/16/07, David Schwartz <davids@webmaster.com> wrote:
>
> (See, among other cases, Lexmark. v. Static
> Controls.) A copyright is not a patent, you can only own something if there
> are multiple equally good ways to do it and you claim *one* of them.

Only in a world where "write a Linux module" is a "functional idea." I
don't think that the legal world in the US is an example of such a
world, though you clearly do.

Dave

Re: GPL vs non-GPL device drivers

[Scott Preece]

On 2/16/07, Dave Neuer <mr.fred.smoothie@pobox.com> wrote:
> On 2/16/07, David Schwartz <davids@webmaster.com> wrote:
> >
> > (See, among other cases, Lexmark. v. Static
> > Controls.) A copyright is not a patent, you can only own something if there
> > are multiple equally good ways to do it and you claim *one* of them.
>
> Only in a world where "write a Linux module" is a "functional idea." I
> don't think that the legal world in the US is an example of such a
> world, though you clearly do.
---

"Interface the xyz device to the Linux kernel" is a functional idea in
pretty much the same sense that the Lexmark case involved. You
generally can't copyright functional interfaces; there is a strong
prejudice towards allowing interoperability.

[IANAL and this is, as noted preivously, subject to the winds of
judicial favor.]

Re: GPL vs non-GPL device drivers

[Pavel Machek]

Hi!

> >> (See, among other cases, Lexmark. v. Static
> >> Controls.) A copyright is not a patent, you can only 
> >own something if there
> >> are multiple equally good ways to do it and you claim 
> >*one* of them.
> >
> >Only in a world where "write a Linux module" is a 
> >"functional idea." I
> >don't think that the legal world in the US is an 
> >example of such a
> >world, though you clearly do.
> ---
> 
> "Interface the xyz device to the Linux kernel" is a 
> functional idea in
> pretty much the same sense that the Lexmark case 
> involved. You
> generally can't copyright functional interfaces; there 
> is a strong
> prejudice towards allowing interoperability.

You are welcome to write kernel modules without including *any* header
files. That may be ok in parts of US based on precedent you cite.

Somehow I do not think v j is doing, so he is violating our copyright.
Seems simple to me...

							Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: GPL vs non-GPL device drivers

[David Schwartz]

> On 2/16/07, David Schwartz <davids@webmaster.com> wrote:

> > (See, among other cases, Lexmark. v. Static
> > Controls.) A copyright is not a patent, you can only own
> > something if there
> > are multiple equally good ways to do it and you claim *one* of them.

> Only in a world where "write a Linux module" is a "functional idea." I
> don't think that the legal world in the US is an example of such a
> world, though you clearly do.

I'm not arguing "write a Linux module" is a functional idea. But "write code
so that a graphics card with a X1950 chipset works with a Linux kernel"
certainly is.

Again, see Lexmark v. Static Controls. If "make a toner cartridge that works
with a particular Lexmark printer" is a functional idea, why is "make a
graphics driver that works with a particular Linux kernel" not? What is the
difference you think matters?

DS

RE: GPL vs non-GPL device drivers

[Giuseppe Bilotta]

On Saturday 17 February 2007 03:42, David Schwartz wrote:

> Again, see Lexmark v. Static Controls. If "make a toner cartridge that
works
> with a particular Lexmark printer" is a functional idea, why is "make a
> graphics driver that works with a particular Linux kernel" not? What is
the
> difference you think matters?

That you cannot build such modules without integrating parts of actual Linux
kernel code (via #includes etc), whereas you can build compatible toner
cartridges without using any original component.

-- 
Giuseppe "Oblomov" Bilotta

RE: GPL vs non-GPL device drivers

[David Schwartz]

> On Saturday 17 February 2007 03:42, David Schwartz wrote:
>
> > Again, see Lexmark v. Static Controls. If "make a toner cartridge that
> > works
> > with a particular Lexmark printer" is a functional idea, why is "make a
> > graphics driver that works with a particular Linux kernel" not? What is
> > the
> > difference you think matters?

> That you cannot build such modules without integrating parts of
> actual Linux
> kernel code (via #includes etc), whereas you can build compatible toner
> cartridges without using any original component.

Static Controls actually put a copy of Lexmark's 'Toner Loading Program' on
each compatible cartridge they made. The printer actually copies the TLP off
the cartridge. In other words, to make a compatible catridge, you do have to
use an original component. (Or at least, it's much more difficult not to.)

Static Controls argued that taking the TLP was the only practical way to
make a cartridge that would work with that printer. The court held that you
cannot use copyright to own every practical way to perform some function, so
as used in the compatible cartridge, the TLP was not protectable by
copyright. (The same work and the same elements can be protectable in one
context and not another.)

But in any event, your entire argument makes no sense. I was citing Lexmark
v. Static Controls here for the point that making an object to make X work
with Y is a function. I was responding to the argument that "Linux driver
for a particular piece of hardware" is more like a specific expression of an
idea than an idea. The court in this case held that a "toner cartridge that
works with a particular Lexmark printer" was an idea, not an expression.
It's hard to see how a "X1950 driver that works with a particular Linux
kernel" is similarly not an idea.

The implicit argument is that while you could not own every driver, you
might be able to own every Linux driver. That is, that while a "driver" is
an idea, a "Linux driver" might be a particular expression of an idea. But
if that were true, why couldn't Lexmark own every cartridge that worked with
this particular printer? (With a "toner cartridge" being an idea but a
"toner cartridge that works with this particular printer" being an
expression.)

DS

RE: GPL vs non-GPL device drivers

[Giuseppe Bilotta]

On Saturday 17 February 2007 15:19, David Schwartz wrote:

> Static Controls argued that taking the TLP was the only practical way to
> make a cartridge that would work with that printer.

Which shows how that case is different from writing Linux drivers. For
example, looking at the example the OP was himself proposing a few
alternative approaches to work around the limitation they were hitting:
could just switch to static major/minors instead of dynamics ones, they
could skip sysfs, or they could even reimplement something like sysfs
themselves, or whatever other interface they deem useful for the purpose of
plopping in their own binary blob on top of it, sort of like what nVidia
and ATi do for their stuff.

-- 
Giuseppe "Oblomov" Bilotta

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/17/07, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> Which shows how that case is different from writing Linux drivers. For
> example, looking at the example the OP was himself proposing a few
> alternative approaches to work around the limitation they were hitting:
> could just switch to static major/minors instead of dynamics ones, they
> could skip sysfs, or they could even reimplement something like sysfs
> themselves, or whatever other interface they deem useful for the purpose of
> plopping in their own binary blob on top of it, sort of like what nVidia
> and ATi do for their stuff.

Or they could run:
    find . -type f -exec perl -i.bak -pe 's/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g'
and be done with it.  Or even just MODULE_LICENSE("GPL") in their
module -- that's not "lying about the module license", it's "doing the
minimum necessary in order to interoperate efficiently with the
kernel".  Atari v. Nintendo is still good law, but _only_ to the
extent that it does not conflict with Lexmark, which now has the seal
of Supreme Court approval.  And (IMHO, IANAL) if writing
MODULE_LICENSE("GPL") is obviously the only remotely efficient way to
achieve the goal of interoperation with the kernels that people
already have on their systems, through the documented, tested,
currently recommended APIs (like sysfs), then you have a Sega / Altai
/ Lexmark fact pattern, not an Atari v. Nintendo fact pattern.

So what's the penalty for MODULE_LICENSE("GPL") on code that is not
actually offered under the GPL?  Being shunned by the kernel
community.  Maintaining a fork.  Getting to keep both halves when it
breaks.  Friends don't let friends write non-GPL drivers.  But friends
also don't let friends go off into delusional spasms of denial.
nVidia and ATI do what they do so that their code has more than a
snowball's chance in hell of running on people's desktops, not out of
fear that the Big Bad LKML Wolf will come blow down their houses.
Their hardware is doubtless so fiddly and buggy and crash-prone that
four out of five attempts to compile a driver for it reorder the
instructions enough to slag the GPU, under Windows or Linux.  _That's_
why they ship binary drivers.  Capisce?

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Giuseppe Bilotta]

On Sunday 18 February 2007 00:55, Michael K. Edwards wrote:

> Or they could run:
>     find . -type f -exec
perl -i.bak -pe 's/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g'
> and be done with it.  Or even just MODULE_LICENSE("GPL") in their
> module -- that's not "lying about the module license", it's "doing the
> minimum necessary in order to interoperate efficiently with the
> kernel".  Atari v. Nintendo is still good law, but only to the
> extent that it does not conflict with Lexmark, which now has the seal
> of Supreme Court approval.  And (IMHO, IANAL) if writing
> MODULE_LICENSE("GPL") is obviously the only remotely efficient way to
> achieve the goal of interoperation with the kernels that people
> already have on their systems

Except that this is not about a driver that is supposed to interoperated
with the kernels people already have on their systems. This is about
shipping new (embedded) systems with a modified (if you go the s/_GPL//g
route, even more so) Linux kernel, and distribution a modified kernel *has*
to comply with the GPL, since this is *exactly* what the GPL is about:
redistribution of modified copies of the work.

-- 
Giuseppe "Oblomov" Bilotta

RE: GPL vs non-GPL device drivers

[David Schwartz]

> On Saturday 17 February 2007 15:19, David Schwartz wrote:

> > Static Controls argued that taking the TLP was the only practical way to
> > make a cartridge that would work with that printer.

> Which shows how that case is different from writing Linux drivers. For
> example, looking at the example the OP was himself proposing a few
> alternative approaches to work around the limitation they were hitting:
> could just switch to static major/minors instead of dynamics ones, they
> could skip sysfs, or they could even reimplement something like sysfs
> themselves, or whatever other interface they deem useful for the
> purpose of
> plopping in their own binary blob on top of it, sort of like what nVidia
> and ATi do for their stuff.

These are all different functional ideas.

It is no response to an argument like this to say, "you could always express
a different idea". Copyright only protects the one way the author chose to
express an idea. You should not ever need to change an idea to get around
copyright.

I hate to sound like a broken record, but have you read Lexmark v. Static
Controls? There was a section where they talked about how perhaps you could
have used a different algorithm to measure the toner level.

You may have to change your idea to get around a patent, but you should
never, ever have to change a functional idea to get around a copyright.

Do you realize that you are arguing for software patents? And worse, for
patents that are easy to get (and last as long) as copyrights.

DS

Re: GPL vs non-GPL device drivers

[Alexandre Oliva]

On Feb 17, 2007, "David Schwartz" <davids@webmaster.com> wrote:

>> On Saturday 17 February 2007 03:42, David Schwartz wrote:
>> 
>> > Again, see Lexmark v. Static Controls. If "make a toner cartridge
>> > that works with a particular Lexmark printer" is a functional
>> > idea, why is "make a graphics driver that works with a particular
>> > Linux kernel" not? What is the difference you think matters?

>> That you cannot build such modules without integrating parts of
>> actual Linux kernel code (via #includes etc), whereas you can build
>> compatible toner cartridges without using any original component.

> Static Controls actually put a copy of Lexmark's 'Toner Loading Program' on
> each compatible cartridge they made. The printer actually copies the TLP off
> the cartridge. In other words, to make a compatible catridge, you do have to
> use an original component. (Or at least, it's much more difficult not to.)

Besides, you *can* build a module for Linux without using any kernel
code.  It just takes a lot of work to implement all you'd otherwise
need from the kernel in a clean-room fashion.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL vs non-GPL device drivers

[Dave Neuer]

On 2/16/07, David Schwartz <davids@webmaster.com> wrote:
>
> > On 2/16/07, David Schwartz <davids@webmaster.com> wrote:
>
> > > (See, among other cases, Lexmark. v. Static
> > > Controls.) A copyright is not a patent, you can only own
> > > something if there
> > > are multiple equally good ways to do it and you claim *one* of them.
>
> > Only in a world where "write a Linux module" is a "functional idea." I
> > don't think that the legal world in the US is an example of such a
> > world, though you clearly do.
>
> I'm not arguing "write a Linux module" is a functional idea. But "write code
> so that a graphics card with a X1950 chipset works with a Linux kernel"
> certainly is.
>
> Again, see Lexmark v. Static Controls. If "make a toner cartridge that works
> with a particular Lexmark printer" is a functional idea, why is "make a
> graphics driver that works with a particular Linux kernel" not? What is the
> difference you think matters?

I think you are reading Lexmark wrong. First off, Lexmark ruled that
scenes a faire applied to the toner-level calculation, not "make a
toner cartridge that works with a particular Lexmark printer." It was
the toner-calculation algorithm that could't be done any other sane
way, which made the TLP unprotectable via copyright. The opinion says,
"Both prongs of the infringement test, in other words, consider
'copyrightability,' which at its heart turns on the principle that
copyright protection extends to expression, not to ideas."

You're saying that there's no other way to interface device drivers to
an operating system than the current Linux driver model? That's
strange, since it's a different driver model than Linux had
previously, and it's also different from the BeOS driver interface,
etc. If the Linux driver interface is protectable, it doesn't seem
like scenes a faire applies.

RE: GPL vs non-GPL device drivers

[David Schwartz]

> You're saying that there's no other way to interface device drivers to
> an operating system than the current Linux driver model?

Interfacing an X1900 graphics card to FreeBSD and interfacing an X1900
graphics card to Linux are two different ideas. They are *not* two
expressions of the same idea.

> That's
> strange, since it's a different driver model than Linux had
> previously, and it's also different from the BeOS driver interface,
> etc. If the Linux driver interface is protectable, it doesn't seem
> like scenes a faire applies.

These are all diferent ideas. Scenes a faire applies to how you express a
given idea, not other ideas you could possibly express. (This is explicitly
addressed in the decision.)

Otherwise, there would be no scenes a faire. Perhaps you cannot make a
western without a shootout at high noon, but you can make a romance.

DS

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/17/07, Dave Neuer <mr.fred.smoothie@gmail.com> wrote:
> I think you are reading Lexmark wrong. First off, Lexmark ruled that
> scenes a faire applied to the toner-level calculation, not "make a
> toner cartridge that works with a particular Lexmark printer." It was
> the toner-calculation algorithm that could't be done any other sane
> way, which made the TLP unprotectable via copyright. The opinion says,
> "Both prongs of the infringement test, in other words, consider
> 'copyrightability,' which at its heart turns on the principle that
> copyright protection extends to expression, not to ideas."

David S. is reading Lexmark right (IMHO, IANAL).  The byte-for-byte
content of the TLP had to be copied in order to interoperate with the
printer, because the printer checksummed it (apparently using SHA-1,
but possibly truncating the result to 8 bits, which is rather comical;
it is not 100% clear to me based on the appellate decision, which also
seems to say that the printer cartridge contains the SHA-1 algorithm,
which is probably just an error).  That rendered it a "lock-out code"
within the sense of Sega v. Accolade, and ultimately that's why the
circuit court vacated the district court's decision in Lexmark's
favor.

In order to vacate and remand, the appellate court had to demonstrate
that the district court's grant of preliminary injunction to Lexmark
was wrong _as_a_matter_of_law_.  So they had to construe the facts of
the case in a light as favorable to Lexmark as humanly possible.  They
concluded that, _even_ if the TLP contained copyrightable expression,
and _even_ if all of the district court's reasoning about the other
prongs of a preliminary injunction test (potential for irreparable
harm, balance of harms, the public interest) were correct, neither the
Copyright Act nor the DMCA could be used to establish the fourth
prong: likelihood of success on the merits.

Cloners rejoice:  the US Supreme Court has, by denying certioriari on
Judge Sutton's opinion, given you carte blanche to copy and distribute
freely any software or firmware whose author has been so stupid as to
cryptographically checksum it as an anti-interoperability measure.
Using copyrighted software as a "lock-out code" to create a cause of
action against reverse engineers has the paradoxical effect of
rendering it uncopyrightable _as_a_matter_of_law_ in the US, unless
and until Congress or a later Supreme Court creates new law to the
contrary.  I am not a lawyer, this is not legal advice, on your own
head be it.

> You're saying that there's no other way to interface device drivers to
> an operating system than the current Linux driver model? That's
> strange, since it's a different driver model than Linux had
> previously, and it's also different from the BeOS driver interface,
> etc. If the Linux driver interface is protectable, it doesn't seem
> like scenes a faire applies.

The Linux driver interface is, as a matter of law, not copyrightable
in the U. S. of A., no matter how many EXPORT_SYMBOL_GPLs and dactylic
hexameters you adorn it with.  That was already true under Baker v.
Selden, and didn't get any less so as a result of Lotus v. Borland,
and is now inescapable (IMHO) under Lexmark, and it's not likely to
get any less true unless RMS is elected president and appoints Eben
Moglen to the Supreme Court.  Sorry, folks; I'm just the messenger.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

On Thu, 15 Feb 2007 22:25:12 PST, v j said:
> > It's written in black and white, in the license.
> 
> Please point me to where it says I cannot load proprietary modules in
> the Kernel.

Nobody can point you there, because it doesn't say that anywhere.

What you do to *your* kernel is *your* business.

The question is what the code you *distribute* to *other* people does. It's
perfectly legal to load proprietary modules into the kernel.  The open question
is whether you're allowed to ship a proprietary module to somebody else.

And that will depend in *great* detail on *exactly* what your module does,
what code it uses, and how it does it.  As others have pointed out, NVidia
and ATI think they're in an OK spot with the way *they* do *their* module,
while many embedded companies, shipping a much different product, have almost
unanimously given in rather than risk a court fight about the GPL.

Of course, most companies will cave in and license rather than fight a
patent troll as well - so you *really* need to discuss *your* case with
a clueful lawyer.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/16/07, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> As others have pointed out, NVidia and ATI think they're in an OK spot with
> the way *they* do *their* module,

Man, your sentence is so vague here that I almost don't feel the need
to correct you, almost.  I don't think NVIDIA or ATI think they can
get away with distributing a binary only kernel module because of any
of the technical measures they take to seperate themselves from the
kernel code.. That's done for good technical reasons, they ship *BSD
drivers too.

I think the reason why they feel safe that no-one will sue them (and
no company wants to be sued, even big ones by individual kernel
developers) is because so few kernel developers have actually sued
anyone for writing proprietary drivers.

So here's my message to VJ, from a legal standpoint: don't worry about
it.  No-one who authored code you're linking your code against is
likely to go on a suing spree anytime soon, they're too busy coding.

You've already got my message from a moral point of view (and I'm
still terribly confused about your reply).

Trent

Re: GPL vs non-GPL device drivers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

On Thu, 15 Feb 2007 22:25:12 PST, v j said:

(Damn, hit send too soon)

> No, just that the trend is disturbing. If enough Kernel Developers
> choose to write their Software in a way that prevents others from
> using it freely, then that is troubling. Especially when these Kernel
> Developers are substituting existing interfaces in the Kernel with
> ones that are NEW and require specific licenses.

Again - there's nothing stopping you from fixing *your* copy to work
any way you want. I freely admit that *my* kernel is quite often running
code that I don't want to release under the GPL (usually because it's too
ghastly for submission in-tree :) - but that's OK, because I don't let that
sort of code escape. :)

There's nothing stopping you from shipping a GPL'ed patch that fixes it the way
you want it to work, to any and all who want to install your patch. I've done
that too - posted "provably incorrect, but works for me" patches for bugs I've
hit. Once in a while, my "provably incorrect" assertion even turns out to be
itself incorrect. ;)

There's nothing stopping you from shipping GPL'ed code that lies about
its MODULE_LICENSE.  But if you're shipping *non*-GPL'ed code that does
that sort of thing, you demonstrate that you *knew* what the author thought
about derivative works.

So you really have 4 options:

0) Don't ship code.  Send a board and a spec sheet to Greg KH. :)
1) Release it properly under the GPL.
2) Consult a lawyer, and decide to risk shipping it non-GPL.
3) Rebase your code so it runs on a *BSD or vxworks or other OS where
your code's licence and the OS license are known to be compatible.

Pick one, and live with it.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Thu, 2007-02-15 at 22:25 -0800, v j wrote:
[...]
> No, just that the trend is disturbing. If enough Kernel Developers
> choose to write their Software in a way that prevents others from
> using it freely, then that is troubling. Especially when these Kernel

You can use it freely - your definitions of "free" and "closed" are
broken (at least on LKML).

> Developers are substituting existing interfaces in the Kernel with
> ones that are NEW and require specific licenses.

That claimed "specific license" is the very same license that the rest
of the kernel has since day 1. So what?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Neil Horman]

On Thu, Feb 15, 2007 at 10:25:12PM -0800, v j wrote:
> >It's written in black and white, in the license.
> 
> Please point me to where it says I cannot load proprietary modules in
> the Kernel.
> 
It doesn't, but EXPORT_SYMBOL_GPL makes it quite clear what you can not do if
you are not a GPL module.

> > Apart from that,
> >Greg KH has made his opinion clear, and you have said you understand
> >and don't debate that he holds this opinion, and his code is what you
> >said you were linking to (the sysfs/class stuff), so why do you keep
> >saying that "it is not clear".
> 
> I know his opinion. I don't debate his opinion. It is his code. I
> choose not to use his code because of the license issue.
> 
Then choose not to use it and move on, rather than lamenting the fact that
your life is more difficult because of his decision

> >Do you think that, somehow, Linus' opinion trumps Greg KH's opinion on
> >his own code?
> 
> No, just that the trend is disturbing. If enough Kernel Developers
> choose to write their Software in a way that prevents others from
> using it freely, then that is troubling. Especially when these Kernel
> Developers are substituting existing interfaces in the Kernel with
> ones that are NEW and require specific licenses.
> 
Its disturbing to you, and you alone.  If you stopped using Linux today because
of this, no one would miss you.  If enough like-minded people did this, you
would all be using your business model, and th F/OSS community would continue on
its way.  You appear to think that the community relies on people who make
drivers in you're model, and thats simply not the case.

Neil

> vj.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Jesper Juhl]

On 16/02/07, v j <vj.linux@gmail.com> wrote:
> > It's written in black and white, in the license.
>
> Please point me to where it says I cannot load proprietary modules in
> the Kernel.
>
http://www.gnu.org/licenses/gpl.txt
Section 2.b. :
"
    b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.
"

Linking with kernel exported symbols in a kernel module is by many
people considered creating a work derived from the kernel.


> >  Apart from that,
> > Greg KH has made his opinion clear, and you have said you understand
> > and don't debate that he holds this opinion, and his code is what you
> > said you were linking to (the sysfs/class stuff), so why do you keep
> > saying that "it is not clear".
>
> I know his opinion. I don't debate his opinion. It is his code. I
> choose not to use his code because of the license issue.
>
> > Do you think that, somehow, Linus' opinion trumps Greg KH's opinion on
> > his own code?
>
> No, just that the trend is disturbing. If enough Kernel Developers
> choose to write their Software in a way that prevents others from
> using it freely, then that is troubling.

They are not preventing people from using it freely **under the terms
of the GPL**.
If you want 'Free' as in 'I want to take this code and be able to do
whatever I want and never open up my source' then what you want is BSD
licensed code.
The freedoms granted you under the terms of the GPL are different -
they grant you the freedoms to run the code, to modify the code etc
but with a restriction that if you modify/derive from the code and
distribute the result you must also distribute your source.

There's actually nothing new here. The kernel has always[1] been under
a GPL license and anyone who wants to use/modify/distribute it have to
do so under the terms of the GPL.

The kernel modules are a little special.
It's quite obvious that a userspace program that simply uses kernel
provided system calls don't have to use the same license as the kernel
- they simply use services provided by the kernel but they don't
derive from it in any way.
The kernel proper is also quite obvious - if you modify internal code
in the kernel you are obviously modifying, and deriving from, the
kernel so if you distribute such changes you obviously have to
distribute your source as well as per the terms of the GPL.
Where all the controversy is at is kernel *modules*. It is not
entirely clear (in a legal sense) if kernel modules can be said to
derive from the kernel, so it's not entirely clear if they are bound
by the terms of the GPL or not. Court cases are needed to determine
that for certain.  One thing is quite clear however; and that is that
a lot of kernel contributors are of the oppinion that closed source
kernel modules are indeed illegal regardless of EXPORT_SYMBOL /
EXPORT_SYMBOL_GPL.  EXPORT_SYMBOL_GPL was simply introduced as a means
for those kernel developers to make their belief explicit - to be able
to tell the world that "I believe using this symbol makes your code a
derived work of the kernel and thus it has to be GPL", but that's all
it is, a message.  If the courts decide that linking with kernel code
in the form of a module makes the module a derived work, then
EXPORT_SYMBOL and EXPORT_SYMBOL_GPL are completely identical and all
kernel modules must be GPL licensed. However, if the courts decide
that a kernel module is not a derived work, then kernel modules may
only need to be GPL if they use EXPORT_SYMBOL_GPL'ed symbols or they
may not need to be GPL whatever they use - there's no way anyone can
know until there have been court rulings on the matter.

The simple fact is that nothing has actually changed with the
introduction of EXPORT_SYMBOL_GPL except that now those kernel
developers who think anything but GPL'ed modules are illegal can now
express that.


> Especially when these Kernel
> Developers are substituting existing interfaces in the Kernel with
> ones that are NEW and require specific licenses.
>
Depending on who you ask, the requirement for a specific license (GPL)
has always been there, it's just that people got a way to make that a
lot more explicit.



[1] Except the first very few versions that used a licence written by
Linus himself.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

RE: GPL vs non-GPL device drivers

[David Schwartz]

> Linking with kernel exported symbols in a kernel module is by many
> people considered creating a work derived from the kernel.

That's simply unreasonable. It is the most clear settled law that only a
creative process can create a work for copyright purposes. Linking is an
automated process, not a creative process. It cannot create a work at all,
much less a derivative work.

If you have two works, A and B, and neither is a derivative work of the
other, linking them together cannot change the status of A or B. Whether a
work is a derivative work of another is dependent on what the work *is*, not
anything you do with it. The result of the linking of A and B is an
aggregate of A and B and not a single work at all.

I think you severely misstate their position (or I'm overestimating their
understanding). The position of many people is that if you create a work
that is capable of being linked with kernel exported modules, that work
would have to contain so much internal knowledge of (and actual code from)
the kernel that it would have to be a derivative work of it. This would be
true whether or not anybody actually did link it.

Linking cannot change the status of the works linked. The process of linking
is not created and cannot produce a new work.

DS

Re: GPL vs non-GPL device drivers

[Alexandre Oliva]

On Feb 17, 2007, "David Schwartz" <davids@webmaster.com> wrote:

>> Linking with kernel exported symbols in a kernel module is by many
>> people considered creating a work derived from the kernel.

> That's simply unreasonable. It is the most clear settled law that only a
> creative process can create a work for copyright purposes. Linking is an
> automated process, not a creative process. It cannot create a work at all,
> much less a derivative work.

Per this principle, it would seem that only source code and
hand-crafted object code would be governed by copyright, since
compilation is also an automated process.

FWIW, http://www.fsfla.org/?q=en/node/128#1 touches a very similar
issue, also covered in the upcoming release of the video of the FSFLA
session in the 5th GPLv3 conference.

> If you have two works, A and B, and neither is a derivative work of the
> other, linking them together cannot change the status of A or B.

IANAL, but I understand this is correct.  However, the output is
probably a derivative work of both.

Also, it's the fact that A needs to be linked with B, or vice-versa,
that's a clue that A is likely to be a derived work from B, or
vice-versa, even before they're linked together.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

RE: GPL vs non-GPL device drivers

[David Schwartz]

(combined responses)

> On Feb 17, 2007, "David Schwartz" <davids@webmaster.com> wrote:
>
> >> Linking with kernel exported symbols in a kernel module is by many
> >> people considered creating a work derived from the kernel.

> > That's simply unreasonable. It is the most clear settled law that only a
> > creative process can create a work for copyright purposes. Linking is an
> > automated process, not a creative process. It cannot create a
> > work at all,
> > much less a derivative work.

> Per this principle, it would seem that only source code and
> hand-crafted object code would be governed by copyright, since
> compilation is also an automated process.

You misunderstand what I'm saying. If you have two works, A and B, and
neither is a derivative work of the other, linking the two of them together
does not create a new work, so it cannot create a derivative work. The
result still could be work A or work B (or both of them).

If you make a copy of a disk, you have not created a new work. However, the
result of that copy is still the original work.

As a more accurate example, suppose I take a DVD of The Phantom Menace and
convert it to AVI format. The result is not a new work for copyright
purposes, it's just The Phantom Menace. If I take The Phantom Menace and The
Big Lebowski and put them in a program that alternates frames, the result is
not a new work (unless you can argue there was some creativity in choosing
to combine those two works) but is simply The Big Lebowski and The Phanton
Menace, just as if I had put the two DVDs in one box.

> > If you have two works, A and B, and neither is a derivative work of the
> > other, linking them together cannot change the status of A or B.

> IANAL, but I understand this is correct.  However, the output is
> probably a derivative work of both.

That cannot be, because the output is not a new work. Only a creative
process can create a new work.

> Also, it's the fact that A needs to be linked with B, or vice-versa,
> that's a clue that A is likely to be a derived work from B, or
> vice-versa, even before they're linked together.

Correct. That is a separate argument that certainly might be reasonable
under some circumstances. We're dealing with two seprate arguments here, one
reasonable and one unreasonable. The reasonable one (though I think it's
incorrect here) that if you use EXPORT_SYMBOL_GPL symbols, your code likely
has so much knowledge of (and code from) the Linux kernel that it must be a
derivative work. The unreasonable one is that linking creates a derivative
work. No automated process can create a new work for copyright purposes.

And on to the other argument:

> So, since there's no other way to do Yesterday, exactly as performed
> by the Beatles in the 1965 album Help!, I'm free to copy it, perform
> it, create derived versions thereof and perform them, without paying
> royalties to the current copyright holders?

I disagree with the premise, but even assuming it were true, the answer is
no. First, you cannot compare functional works to non-functional works in
this context because this exception is specifically about functional works.
But second, the premise is wrong.

You are correct that there is no other way to express this idea this way.
But that is always true of any work. However, there are other ways to
express the same idea. (Not precisely the same. Arguably if you change the
name of Romeo to Robert and leave everything else in Romeo and Juliet the
same, it's a different idea.) I agree that this distinction (between an idea
and an expression) is not always perfectly clear in copyright, but these are
two cases where it *is* clear.

> One could always create a clean-room implementation of kernel headers
> and use them to build a module that presumably wouldn't be a derived
> work, as long as the binary is indeed created using these clean-room
> headers.  But who does that, considering how quickly kernel headers
> change, and that if you build the object code using the actual kernel
> headers, then the binary is likely to be a derived work of the kernel,
> even if the sources still aren't?

The fact that this is impractical and it's the only other way to accomplish
the same function proves that you don't need to do it. Copyright does not
allow you to own every practical way to achieve a function or even express
an idea.

DS

Re: GPL vs non-GPL device drivers

[Scott Preece]

On 2/17/07, Alexandre Oliva <aoliva@redhat.com> wrote:

> Per this principle, it would seem that only source code and
> hand-crafted object code would be governed by copyright, since
> compilation is also an automated process.
---

Well, compilation is probably equivalent to "translation", which is
specifically included in the Act as forming a derivative work.

scott

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/17/07, Scott Preece <sepreece@gmail.com> wrote:
> Well, compilation is probably equivalent to "translation", which is
> specifically included in the Act as forming a derivative work.

Nix.  "Translation" is something that humans do.  What's governed by
copyright is the creative expression contained in a work, and it makes
no difference whether it's source code or object code, RTL or silicon,
PDF or parchment.  There's a requirement of tangible fixation for
registration purposes, so you can't claim copyright on a story that's
in your head which you haven't written down.  But what's copyrightable
about a computer program is neither the "ideas and methods of
operation" nor the blob of bits (compiled or not); it's the
idiosyncrasies, the human touches, the things that would differ
between two equally skilled coders' ways of putting those ideas into
language.

A judge doesn't care whether a C compiler will spin silk purses or
spit chunks when fed this language, except insofar as duplicating
another coder's language (by trial and error or by blatant, arrant,
heartless enslavement of poor little bytes in ROM) is obligatory in
order to build a silk-purse-spinner.  You can't claim copyright on the
only way to accomplish some engineering purpose.  Even if that purpose
is to interoperate with, or even substitute for, someone else's
software or hardware in a way that destroys its marketability or turns
its author's moral imperatives into subjunctives.  Them's the breaks,
folks; if you don't like it, write poetry instead.  (And don't use it
as a passphrase for a printer cartridge.)

(You also can't claim copyright on something that isn't your work of
authorship, so you can't just write down someone else's sermon and go
obtain copyright registration on it.  Or rather, you can, but you will
lose when you try to sue someone else for infringing it, because
you've falsified the registration.  Under the Berne Convention, you
have also not spoiled the actual author's opportunity to write it
down, register her copyright, and sue you and anyone else for
infringing it.  People who thought they licensed it legitimately from
the ostensible copyright holder may have a defense of innocent
infringement, depending on whether the author can demonstrate
negligence according to the usual tort standards in the relevant
jurisdiction.  Copyright infringement is a statutory tort, and the
only limits to contracting away the right to sue for this tort are
those provided in the copyright statute itself.  A contract not to sue
for tort is called a "license".)

Again, I recommend the Lexmark v. Static Control decision to you.  It
references the major appellate decisions in this space from the late
70's forward, mostly from the 9th and 2nd Circuits.  The full text is
available from FindLaw; the few older decisions not available from
FindLaw are easily Googled.  Or you could just mine the debian-legal
archives for the links; sadly, 80% or more of the actual citations to
case law or statute in the debian-legal archives are in my
handwriting, so you can't take that as an independent source of
information.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Alan]

> jurisdiction.  Copyright infringement is a statutory tort, and the
> only limits to contracting away the right to sue for this tort are
> those provided in the copyright statute itself.  A contract not to sue
> for tort is called a "license".)

I'd insert large quantities of "In the USA" in the above and probably
some "not what I've heard from a lawyer" cases.

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/19/07, Alan <alan@lxorguk.ukuu.org.uk> wrote:
> > jurisdiction.  Copyright infringement is a statutory tort, and the
> > only limits to contracting away the right to sue for this tort are
> > those provided in the copyright statute itself.  A contract not to sue
> > for tort is called a "license".)
>
> I'd insert large quantities of "In the USA" in the above and probably
> some "not what I've heard from a lawyer" cases.

Name ANY counterexample in the entire history of copyright, anywhere
in the world.  I've sifted through the past couple of decades of US
appellate history until I'm blue in the face, and reviewed Canadian
and British and German and French and EU statutes and decisions, and
read Nimmer on Copyright and Corbin on Contracts and historical
analyses of copyright law going back to the Statute of Anne.  And yes,
I too have conversed with attorneys and other individuals with legal
educations, in the US and Belgium and Brazil.

You have been lied to.  You have been hoodwinked.  You have neglected
to inform yourself about the simplest truths.  The GPL is not a
"copyright-based license", anywhere in the developed world.  There.
Is.  No.  Such.  Thing.

Re: GPL vs non-GPL device drivers

[linux-os (Dick Johnson)]

On Mon, 19 Feb 2007, Michael K. Edwards wrote:

> On 2/19/07, Alan <alan@lxorguk.ukuu.org.uk> wrote:
>>> jurisdiction.  Copyright infringement is a statutory tort, and the
>>> only limits to contracting away the right to sue for this tort are
>>> those provided in the copyright statute itself.  A contract not to sue
>>> for tort is called a "license".)
>>
>> I'd insert large quantities of "In the USA" in the above and probably
>> some "not what I've heard from a lawyer" cases.
>
> Name ANY counterexample in the entire history of copyright, anywhere
> in the world.  I've sifted through the past couple of decades of US
> appellate history until I'm blue in the face, and reviewed Canadian
> and British and German and French and EU statutes and decisions, and
> read Nimmer on Copyright and Corbin on Contracts and historical
> analyses of copyright law going back to the Statute of Anne.  And yes,
> I too have conversed with attorneys and other individuals with legal
> educations, in the US and Belgium and Brazil.
>
> You have been lied to.  You have been hoodwinked.  You have neglected
> to inform yourself about the simplest truths.  The GPL is not a
> "copyright-based license", anywhere in the developed world.  There.
> Is.  No.  Such.  Thing.

FWIW. A license is NOT a contract in the United States, according to
contract law. A primary requirement of a contract is an agreement. A
contract cannot, therefore, be forced. Licenses, on the other hand,
can be forced upon the user of the licensed material.

A license is a document that states the conditions under which an
item may be used. A prerequisite of the licensor is that he/she/they
have a legal right to control the thing being licensed. When a licensed
item has its license modified by a party, not the original licensor,
it is quite possible that such attempts to control the item are
invalid (moot). Lawyers like this because it gives them work since
the final resolution of such a action can old be determined by a
court!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5594.84 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/19/07, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
> FWIW. A license is NOT a contract in the United States, according to
> contract law. A primary requirement of a contract is an agreement. A
> contract cannot, therefore, be forced. Licenses, on the other hand,
> can be forced upon the user of the licensed material.

Wrong.  Acceptance through conduct has been integral to contract law
in common-law countries since the days of writs in Chancery, and is
part of the codification of the difference between contracts "in
personam" and "in rem".  Allow me to recommend Kevin Teeven's "A
History of the Anglo-American Common Law of Contract".  It is settled
law throughout the Western world that non-exclusive licenses of
copyright need not be formalized, or even put in writing.  Licenses
cannot in any sense be forced on anyone; they are simply a defense
against an action for tort, a conditional waiver of the right to sue,
and cannot even be introduced as evidence by a plaintiff.

> A license is a document that states the conditions under which an
> item may be used. A prerequisite of the licensor is that he/she/they
> have a legal right to control the thing being licensed. When a licensed
> item has its license modified by a party, not the original licensor,
> it is quite possible that such attempts to control the item are
> invalid (moot). Lawyers like this because it gives them work since
> the final resolution of such a action can old be determined by a
> court!

Wrong again.  A copyright license is a term in an otherwise valid
written, oral, or implied offer of contract, with certain limitations
of scope and certain conditions and covenants of return performance,
waiving the right to sue for the statutory tort of copyright
infringement.  Read Nimmer on Copyright, or follow the links in this
paragraph (another self-quotation from two years ago,
http://lists.debian.org/debian-legal/2005/01/msg00621.html):

<old>
Same difference, legally.  Non-exclusive license has a longer history
in patent cases than in copyright, and copyright cases frequently
point to patent cases as precedent.  The commonly cited Supreme Court
precedent that a non-exclusive patent license is "a mere waiver of the
right to sue" is a 1927 case (De Forest Radio Telephone v. United
States, http://laws.findlaw.com/us/273/236.html ), which in turn cites
Robinson on Patents -- so it was evidently already well established by
then, at least with respect to patents.  Everex Systems v Cadtrak (aka
in re CFLC) 1996, for instance, cites De Forest in concluding that
such a license constitutes significant continuing performance
(settling, as far as I am concerned, the question about whether GPL
release is a "one-shot" act with no continuing performance -- it's
not).  For an example that all this applies to copyright, see Jacob
Maxwell v. Veeck 1997 ( http://laws.findlaw.com/11th/962636opa.html ),
which brings in re CFLC over to the copyright arena.
</old>

Please do not bother to trot out Webster's definition or medieval uses
of the word "license", or the theory of unilateral license with regard
to trespass and third-party beneficiaries.  These are concepts
different from "license" as used in the phrase "non-exclusive
copyright license", and just happen to be spelled the same.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Michael Dreher]

Am Montag, 19. Februar 2007 22:50 schrieb Michael K. Edwards:
> On 2/19/07, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
> > FWIW. A license is NOT a contract in the United States, according to
> > contract law. A primary requirement of a contract is an agreement. A
> > contract cannot, therefore, be forced. Licenses, on the other hand,
> > can be forced upon the user of the licensed material.
>
> Wrong.  Acceptance through conduct has been integral to contract law
> in common-law countries since the days of writs in Chancery, and is
> part of the codification of the difference between contracts "in
> personam" and "in rem".  Allow me to recommend Kevin Teeven's "A
> History of the Anglo-American Common Law of Contract".  It is settled
> law throughout the Western world that non-exclusive licenses of
> copyright need not be formalized, or even put in writing.  

Well, what you write is certainly not correct in Germany.
At least here in Germany, a licence is NOT a contract.
If you go into a shop and buy a cardboard box with a software CD in it, 
the only contract you have made is that contract with the shop
owner about purchasing this very box. The german law is very
explicit in stating that there is absolute NO contract with the producer
i.e., the software company which has the rights on the software.
And as a consequence, that funny microsoft eula is totally void,
even if you have clicked at "I agree". Never ever (at least in Germany)
constitutes the act of clicking this button a contract with the software
company. Because the law says that a contract is not valid without an 
agreement, and the law gives some requirements on the form of an agreement in
order to be valid, and "clicking somewhere" is not enough.

Of course, the user has to honor the general law which forbids copying and
distributing the software (except with permission from the creator).


Michael

RE: GPL vs non-GPL device drivers

[David Schwartz]

> On 2/17/07, Alexandre Oliva <aoliva@redhat.com> wrote:

> > Per this principle, it would seem that only source code and
> > hand-crafted object code would be governed by copyright, since
> > compilation is also an automated process.

> Well, compilation is probably equivalent to "translation", which is
> specifically included in the Act as forming a derivative work.

I would hope that courts will hold that "translation" still means what it
originally meant -- the creative process of converting a work from one
language to another where one has to choose how to map the concepts behind a
work to the most appropriate concept in a different language. Clearly
translating Jabberwocky into German is creative in a way that compiling the
Linux kernel from C to x86 binary is not.

Interestingly, if you are right, then what online translation services like
babelfish (that allow you to see a web site in another language) do is
probably illegal as they create derivative works without permission of the
copyright holder. It's easy to argue that putting up a web site grants
people implicit permission to copy and render it so that they can see it,
but much harder to argue that it gives them the right to create a derivative
work. (Of course, you could argue fair use.)

As far as I know, no court has addressed this issue. But I think the
sensible thing is to hold that "translation", in copyright law, is meant as
an example of one type of creative process that could create a derivative
work, not that any process that can be argued to be translation (whether
creative or not) automatically makes the result a work for copyright
purposes.

But you never know.

DS

Re: GPL vs non-GPL device drivers

[Alexandre Oliva]

On Feb 17, 2007, "David Schwartz" <davids@webmaster.com> wrote:

> Interestingly, if you are right, then what online translation services like
> babelfish [...]
> but much harder to argue that it gives them the right to create a derivative
> work. (Of course, you could argue fair use.)

One could try to argue it's an accessibility issue, if local fair use
has provisions for it.  Even for manual translations.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL vs non-GPL device drivers

[Lennart Sorensen]

On Thu, Feb 15, 2007 at 10:25:12PM -0800, v j wrote:
> Please point me to where it says I cannot load proprietary modules in
> the Kernel.

Some people consider modules derivative works, since they link with
pieces of the kernel.  Distributing derivative works are considered
distributing the original work, which means the GPL applies to the
result.

> I know his opinion. I don't debate his opinion. It is his code. I
> choose not to use his code because of the license issue.
> 
> No, just that the trend is disturbing. If enough Kernel Developers
> choose to write their Software in a way that prevents others from
> using it freely, then that is troubling. Especially when these Kernel
> Developers are substituting existing interfaces in the Kernel with
> ones that are NEW and require specific licenses.

devfs had issues.  Someone (Greg) provided something better.  devfs went
away when nothing in the kernel needed it anymore.  That something
outside the kernel was using devfs, well who cares.  That is the outside
code's problem if they don't keep up.  If they happen to have any issues
with the replacement system, then that too is their problem and only
their problem.

--
Len Sorensen

Re: GPL vs non-GPL device drivers

[Xavier Bestel]

On Thu, 2007-02-15 at 21:48 -0800, v j wrote:
> We only get crap because no one here yet knows how to interpret
> proprietary modules loaded into the kernel.

The proprietary modules where only a tiny wrapper is linux-specific and
the rest is cross-platform are in a grey area, yes.
But your modules, written specifically for linux but distributed as
binary-only, are specifically what the people choosing the GPL want to
avoid. They are a derivative work, and are, as such, illegal under the
GPL.

As stated by multiple other people, please consult a lawyer if you want
to be nasty. Or just play by the rules.

	Xav

Re: GPL vs non-GPL device drivers

[Jon K Hellan]

Xavier Bestel wrote:
> On Thu, 2007-02-15 at 21:48 -0800, v j wrote:
>> We only get crap because no one here yet knows how to interpret
>> proprietary modules loaded into the kernel.
> 
> The proprietary modules where only a tiny wrapper is linux-specific and
> the rest is cross-platform are in a grey area, yes.
> But your modules, written specifically for linux but distributed as
> binary-only, are specifically what the people choosing the GPL want to
> avoid. They are a derivative work, and are, as such, illegal under the
> GPL.

If they are a derivative work, they are illegal under the GPL. However, 
it is not clear that their being written specifically *for* Linux is 
sufficient to make them derivative works *of* Linux.

Jon Kåre

Re: GPL vs non-GPL device drivers

[Jan Engelhardt]

On Feb 16 2007 10:44, Jon K Hellan wrote:
> Xavier Bestel wrote:
>> On Thu, 2007-02-15 at 21:48 -0800, v j wrote:
>> > We only get crap because no one here yet knows how to interpret
>> > proprietary modules loaded into the kernel.
>> 
>> The proprietary modules where only a tiny wrapper is linux-specific and
>> the rest is cross-platform are in a grey area, yes.
>> But your modules, written specifically for linux but distributed as
>> binary-only, are specifically what the people choosing the GPL want to
>> avoid. They are a derivative work, and are, as such, illegal under the
>> GPL.
>
> If they are a derivative work, they are illegal under the GPL. However, it is
> not clear that their being written specifically *for* Linux is sufficient to
> make them derivative works *of* Linux.

	Who knows, perhaps there's a public domain interface that wraps linux
kernel function calls into bsd functions, so you can always "successfully"
argue the source code is not only for Linux. However, I think that precompiled
.ko files are _much more_ tied to Linux (in short, supporting your point) plus
a specific architecture.


Jan
-- 

Re: GPL vs non-GPL device drivers

[Miguel Ojeda]

On 2/16/07, Scott Preece <sepreece@gmail.com> wrote:
> On 2/15/07, Miguel Ojeda <maxextreme@gmail.com> wrote:
>
> > Stupid, maybe. But some people just don't want closed-source
> > projects/companies like yours using their free work, without any kind
> > of feedback. Some others don't care, but they could in the future, as
> > it is their code, and that is your risk.
> >
> ---
>
> So, how are such companies any different from the myriad individuals
> and companies that use Linux on the desktop or in their server rooms
> without ever modifying it and who also contribute nothing back to the
> community? They are also, in many (most?) cases taking advantage of
> the free (as in beer) nature of Linux - saving money by using the work
> of others without returning anything, but the product builders seem to
> get a lot more abuse...
>
> scott
>

Well, as I pointed out in other message, I think there is a difference
between using the GPL'd code (as user), and modify it, link closed
modules, create derivated closed code, and then redistribute
everything.

I'm not saying that we should prevent companies using Linux for money,
I'm just saying that if someone modify some GPL'd code or link or
something like that, he/she should release such code as GPL'd; and
that is the feedback for the original authors: The improvement of the
code.

I don't care if this this or other company makes money, it is free to
do it, but it would be better to receive feedback as opening such
closed modules. Anyway, it is not clear if opening the source would
break his business or help it.

-- 
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm

Re: GPL vs non-GPL device drivers

[Geert Uytterhoeven]

On Thu, 15 Feb 2007, v j wrote:
> So far I have heard nothing but, "if you don't contribute, screw you."
> All this is fine. Just say so. Make it black and white. Make it
> perfectly clear what is and isn't legal. If we can't load proprietary

What's legal depends on the law. What's moral depends on...

> modules, then so be it. It will help everybody if this is out in the
> clear, instead of resorting to stupid half measures like
> EXPORT_SYMBOL_GPL.

Personally, I see no real difference between EXPORT_SYMBOL and
EXPORT_SYMBOL_GPL.
If you derive from GPL'ed code, your code is a derived work.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: GPL vs non-GPL device drivers

[Scott Preece]

On 2/15/07, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, 15 Feb 2007, v j wrote:

> Personally, I see no real difference between EXPORT_SYMBOL and
> EXPORT_SYMBOL_GPL.
> If you derive from GPL'ed code, your code is a derived work.
---

I agree with you that there's no difference in law, though I think the
difference is that neither creates a derived work. "Derived work" is a
very vague notion in law, and the case law on this has varied over
time. I think it would be a real crap shoot for both sides to bring
this to court, at least in the US.

Note, though, that I DO support the OSS equation and believe that
companies *should not* use closed-source modules, whether it's legal
or not, except in the very specific case of code that also works with
other systems. I think this ethical imperative goes with the nature of
the author's gift to the community.

scott

Re: GPL vs non-GPL device drivers

[Jeff Garzik]

v j wrote:
> So far I have heard nothing but, "if you don't contribute, screw you."
> All this is fine. Just say so. Make it black and white. Make it

It is black and white in copyright law and the GPL.

The /whole point/ of the GPL is to funnel contributions back.

We happen to think there are solid engineering reasons for this. 
Customers think there are solid reasons for this. Libre activists think 
there are freedom aspects to this.

But ignoring all the justifications, it /is/ the letter of the law.  And 
you are expected to follow it, just like everybody else.

	Jeff

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/15/07, Jeff Garzik <jeff@garzik.org> wrote:
> v j wrote:
> > So far I have heard nothing but, "if you don't contribute, screw you."
> > All this is fine. Just say so. Make it black and white. Make it
>
> It is black and white in copyright law and the GPL.
>
> The /whole point/ of the GPL is to funnel contributions back.

Bzzzt.  The whole point of the GPL is to "guarantee your freedom to
share and change free software--to make sure the software is free for
all its users."  Undo the EXPORT_SYMBOL_GPL brain damage if you like;
it's not part of the offer of contract, which ties itself in knots to
avoid any measure of derivative-ness other than that enshrined in the
appropriate jurisdiction's copyright law (conformant to the Berne
Convention anywhere that matters).  Fork to your heart's content; if
it breaks, you get to keep both pieces.  Just remember that there is
also no severability clause in the offer of contract (very much the
contrary; see Section 7), so if the contract breaks, you do not
necessarily get to keep both pieces, and weird things happen when you
wander off into the vagaries of your jurisdiction's tort law and
commercial code.

> We happen to think there are solid engineering reasons for this.
> Customers think there are solid reasons for this. Libre activists think
> there are freedom aspects to this.

There are no solid engineering reasons for demanding code that is
probably crap, tied to hardware you will never see, from people with
regard to whom you indulge in mutual hostility and distrust.  There
are, however, solid economies of scale in warranting the unwarrantable
and hand-holding at each stage of the skill hierarchy, and they depend
on keeping the interchangeable parts interchangeable.  The "IP asset"
delusion interferes with these economies of scale and annoys the
Morlocks who keep the gears turning.

99% of customers could care less; show them good, fast, and cheap,
offer them two out of three, they'll leave "good" on the table every
time.  Libre activists don't understand the meaning of the word
"freedom", at least not in the same way I do; freedom is spelled
R-U-L-E O-F L-A-W and they seem to have contempt for this concept.

> But ignoring all the justifications, it /is/ the letter of the law.  And
> you are expected to follow it, just like everybody else.

Fiddlesticks.  The letter of the law is very different from what you
have been led to believe.  Most law is created in the marketplace,
discovered in a courtroom, codified by a legislature, reconciled by
treaty and gunship, and enforced by insurers and other financial
institutions.  This kind of law considers the "free software"
philosophy to be a curiosity at best, and renders the GPL down to:

     You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work ...

     You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third parties
under the terms of this License.

     ... you must cause it ... to print or display an announcement
including an appropriate copyright notice and a notice that there is
no warranty (or else, saying that you provide a warranty) ...

     ... Accompany it with the complete corresponding machine-readable
source code ...

     *** BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, *** THERE IS
NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
LAW.

That's a straightforward license of modification and distribution
rights in return for attribution and warranty disclaimer, just like
any other "open source" license; except that it creates SEVERE
obstacles to commercial exploitation without cutting the originator
in, just like most "free as in beer" licenses.  The rest of the GPL is
composed of no-ops in any legal system that matters.  Don't take my
word for it; read the actual court decisions in which the GPL has come
up, and Nimmer on Copyright for the backstory.

IANAL, YMMV, HTH, HAND, Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Jeff Garzik]

Michael K. Edwards wrote:
> On 2/15/07, Jeff Garzik <jeff@garzik.org> wrote:
>> v j wrote:
>> > So far I have heard nothing but, "if you don't contribute, screw you."
>> > All this is fine. Just say so. Make it black and white. Make it
>>
>> It is black and white in copyright law and the GPL.
>>
>> The /whole point/ of the GPL is to funnel contributions back.
> 
> Bzzzt.  The whole point of the GPL is to "guarantee your freedom to
> share and change free software--to make sure the software is free for
> all its users."

No, that's the FSF marketing fluff you've been taught to recite.

In the context of the Linux kernel, I'm referring to the original reason 
why Linus chose the GPL for the Linux kernel.

	Jeff

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/15/07, Jeff Garzik <jeff@garzik.org> wrote:
> Michael K. Edwards wrote:
> > Bzzzt.  The whole point of the GPL is to "guarantee your freedom to
> > share and change free software--to make sure the software is free for
> > all its users."
>
> No, that's the FSF marketing fluff you've been taught to recite.

<chuckle> Didn't read far into that e-mail, did you?  That's a quote
from the GPL preamble, which isn't part of the offer of contract but
is arguably legally relevant context.  It's largely consistent with
the license as I read it.  It's also consistent with the origins of
the GPL, as you can read anywhere that folk history is sold.

> In the context of the Linux kernel, I'm referring to the original reason
> why Linus chose the GPL for the Linux kernel.

Can't say; wasn't there.  But I doubt that anyone truly "funnels
contributions back" to the kernel because of the letter of the GPL.
They do so because they think it will lower their costs, raise their
revenues, hedge their risks, earn goodwill from peers, enhance their
employability, stroke their egos, save the world, please their Author
and/or Linus, and so on and so forth.

The GPL tells us what is likely to happen in the event of a conflict
that gets as far as a courtroom.  I think the smart money's on
conflict avoidance (that's kind of ironic, isn't it), and failing
that, on ignoring the FSF and other armchair lawyers and reading the
law (spelled A-P-P-E-L-L-A-T-E D-E-C-I-S-I-O-N-S) for yourself.  That
is, after all, what judges have done and will continue to do, at least
until the Revolution comes.

Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/16/07, Jeff Garzik <jeff@garzik.org> wrote:
> No, that's the FSF marketing fluff you've been taught to recite.
>
> In the context of the Linux kernel, I'm referring to the original reason
> why Linus chose the GPL for the Linux kernel.

Great.. The reason why Greg KH, the guy who wrote the bit of code that
vj claims he wants to link to but can't, chose the GPL for *his* code
is clearly not the same as the reason why Linux chose the GPL.
Exactly what that reason is, will be best left to Greg to say, but I'm
pretty sure it has to do with what you call "marketing fluff" and the
rest of us call the moral imperative.

Trent

Re: GPL vs non-GPL device drivers

[Alexandre Oliva]

On Feb 15, 2007, Jeff Garzik <jeff@garzik.org> wrote:

> Michael K. Edwards wrote:
>> On 2/15/07, Jeff Garzik <jeff@garzik.org> wrote:

>>> The /whole point/ of the GPL is to funnel contributions back.

>> Bzzzt.  The whole point of the GPL is to "guarantee your freedom to
>> share and change free software--to make sure the software is free for
>> all its users."

> No, that's the FSF marketing fluff you've been taught to recite.

The same FSF that wrote the GPL, no less ;-)

> In the context of the Linux kernel, I'm referring to the original
> reason why Linus chose the GPL for the Linux kernel.

If he chose it for this reason, he chose the wrong license.  The GPL
does not funnel contributions back.  It doesn't even require anyone to
make contributions: you're free to keep your improvements only to
yourself.  And even if you distribute them, you can choose whom to
distribute it to, and that might very well leave the 'back' out.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL vs non-GPL device drivers

[Jeff Garzik]

Alexandre Oliva wrote:
> On Feb 15, 2007, Jeff Garzik <jeff@garzik.org> wrote:
> 
>> Michael K. Edwards wrote:
>>> On 2/15/07, Jeff Garzik <jeff@garzik.org> wrote:
> 
>>>> The /whole point/ of the GPL is to funnel contributions back.
> 
>>> Bzzzt.  The whole point of the GPL is to "guarantee your freedom to
>>> share and change free software--to make sure the software is free for
>>> all its users."
> 
>> No, that's the FSF marketing fluff you've been taught to recite.
> 
> The same FSF that wrote the GPL, no less ;-)
> 
>> In the context of the Linux kernel, I'm referring to the original
>> reason why Linus chose the GPL for the Linux kernel.
> 
> If he chose it for this reason, he chose the wrong license.  The GPL

Strange, then, how its been so successful in funelling back contributions.

	Jeff

Re: GPL vs non-GPL device drivers

[Alexandre Oliva]

On Feb 16, 2007, Jeff Garzik <jeff@garzik.org> wrote:

> Alexandre Oliva wrote:
>> On Feb 15, 2007, Jeff Garzik <jeff@garzik.org> wrote:
>> 
>>> Michael K. Edwards wrote:
>>>> On 2/15/07, Jeff Garzik <jeff@garzik.org> wrote:
>> 
>>>>> The /whole point/ of the GPL is to funnel contributions back.
>> 
>>>> Bzzzt.  The whole point of the GPL is to "guarantee your freedom to
>>>> share and change free software--to make sure the software is free for
>>>> all its users."
>> 
>>> No, that's the FSF marketing fluff you've been taught to recite.
>> 
>> The same FSF that wrote the GPL, no less ;-)
>> 
>>> I'm referring to the original reason why Linus chose the GPL

>> If he chose it for this reason, he chose the wrong license.

> Strange, then, how its been so successful in funelling back contributions.

There's nothing strange about it.  Promoting (as opposed to mandating)
contributions is a great possible, even probable consequence of the
GPL, but it is far from being the whole point of the GPL.

If Linus' whole point had been to funnel back contributions, assuming
he fully understood the GPL back when he chose it, he'd probably have
chosen a different license that *required* contributions to be
funneled back.  And then Linux would have remained non-Free Software.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL vs non-GPL device drivers

[Gene Heskett]

On Thursday 15 February 2007, v j wrote:
>So far I have heard nothing but, "if you don't contribute, screw you."
>All this is fine. Just say so. Make it black and white. Make it
>perfectly clear what is and isn't legal. If we can't load proprietary
>modules, then so be it. It will help everybody if this is out in the
>clear, instead of resorting to stupid half measures like
>EXPORT_SYMBOL_GPL.
>
>From this observers view, a long one over most of a decade, and a believer 
in the GPLv2 since its was v1, it seems to me that you are missing the 
point entirely with your use of the term 'legal'.

This definition seems to be a bit like nailing jelly to a tree in that so 
far only one companies legal dept has pursued this to the point of 
actually getting a court verdict rendered.  That was the German ruling a 
link was given to earlier in this thread(s).

Everyone else, and there have been many who tried, rattling all sorts of 
legal swords at first, changed their mind once their legal people had a 
chance to sit down and explain to them what their chances of winning in 
court against the GPL were given the limited precedence of legal opinion, 
have eventually taken the cheaper way out and complied with the terms of 
this license.  No one here in the states has been willing to spend the 
legal money to establish once and for all by the rendering of a court 
decision, which then becomes quotable case law, while knowing up front 
that their chances of prevailing, while not impossible, are indeed quite 
slim.

Now, if you would like to make a precedent setting "legal definition" of 
what is or is not legal to do with GPL'd code, then hire the lawyers and 
go to court with your case.

There is no one to my knowledge here, who would not cheer loudly once a 
verdict was rendered because that courts decision would give the FOSS 
community a quotable case law as to exactly what is, and is not legal for 
you to do with GPL'd code.  We would after 16+ years of the GPL, finally 
have a firm, well defined line drawn in the sand, a precedence in US case 
law that at present, only exists in Germany.

I'm a bit like Clint Eastwood here, do you feel lucky?  If not, then 
please comply with the terms of the software you have chosen to base your 
product on.  As you have been told here repeatedly, a distribution to 
your customers of code that is based on the GPL'd kernel headers does 
bring you into non-compliance with the terms of the GPL.  You can do 
anything you want in house, but the minute that code ships, that is 
a "distribution" and the GPL applies in full force in that its all made 
GPL, or you cannot legally ship it.  I don't know how it can be said any 
plainer than that.  But of course IANAL, so talk to yours, please.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.

Re: GPL vs non-GPL device drivers

[Scott Preece]

On 2/15/07, Gene Heskett <gene.heskett@verizon.net> wrote:

> This definition seems to be a bit like nailing jelly to a tree in that so
> far only one companies legal dept has pursued this to the point of
> actually getting a court verdict rendered.  That was the German ruling a
> link was given to earlier in this thread(s).
---

The German decision did not go anywhere near the question of kernel
modules. It was a nice victory that the court decided the license was
enforceable, but the details of the license are still largely
untested.

---
> ...

> I'm a bit like Clint Eastwood here, do you feel lucky?  If not, then
> please comply with the terms of the software you have chosen to base your
> product on.
---

Note that it's not just "lucy", but "rich". Both sides would spend a
LOT of money if this went to court in the US. And, of course, "the
terms of the software [license]" are exactly what the case would be
deciding. There wouldn't be a case unless the two parties had
different views of the terms of the license.

---
> As you have been told here repeatedly, a distribution to
> your customers of code that is based on the GPL'd kernel headers does
> bring you into non-compliance with the terms of the GPL.  You can do
> anything you want in house, but the minute that code ships, that is
> a "distribution" and the GPL applies in full force in that its all made
> GPL, or you cannot legally ship it.  I don't know how it can be said any
> plainer than that.  But of course IANAL, so talk to yours, please.
---

I also ANAL, but even so I can point out that your assertion and Greg
KH's assertions do not have the force of law.  Questions like "what is
a derived work" and "what does 'unrelated' mean" in the license are
just not black-and-white.

I don't like niggling about interpretation, either, especially with
material that someone has contributed to the community; I think it's
rude and possibly unethical and that not testing the limits avoids any
danger of impropriety. But claiming it's clear what the license
requires is simply misleading.

scott

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/15/07, Gene Heskett <gene.heskett@verizon.net> wrote:
[ignorant silliness]
> There is no one to my knowledge here, who would not cheer loudly once a
> verdict was rendered because that courts decision would give the FOSS
> community a quotable case law as to exactly what is, and is not legal for
> you to do with GPL'd code.  We would after 16+ years of the GPL, finally
> have a firm, well defined line drawn in the sand, a precedence in US case
> law that at present, only exists in Germany.

Oferchrissake.  We do have a US precedent, insofar as a decision in a
court of fact on issues of fact can ever be a precedent in a common
law system (hint: zero, unless the later judge feels like quoting some
compelling prose).  That would be Progress Software v. MySQL (also
known as MySQL v. NuSphere in some commentators' writings).  The FSF
interpretation of the GPL lost.  Completely.  Which is true also of
the Munich and Frankfurt decisions.

The plaintiffs, as authors of GPL works, got a full hearing in each
case -- via routine reasoning about the GPL as an offer of contract,
whose conditions either had (Progress Software) or had not
(Fortinet/Sitecom and D-Link) been performed to the extent necessary
for the defendant to claim license under the GPL.  MySQL did obtain a
preliminary injunction, but on unrelated trademark license grounds;
the GPL claim got them nowhere, for at least four distinct reasons
stated in the opinion.  Harald's recovery was limited to statutory
costs and, in the Munich case, an injunction to _either_ offer the
source code of netfilter/iptables itself _or_ stop shipping product.
Both German courts refused to find contract "in personam" (necessary
to a breach of contract claim, in turn necessary to a demand for
specific performance).

"GPL is a creature of copyright law" lost in court, every time.
"Section 4 is a limitation of scope, not a conditional performance"
lost.  "You can lose your license irrevocably" lost.  "We can compel
disclosure of source code with no alternative" lost.  "We can
circumvent contract law standards of breach and remedy" lost.
Everything RMS and Eben Moglen have ever written about the legal
meaning of the GPL is wrong, and where "derivative works" are
concerned, embarrassingly hypocritical as well.  Take the Big Lie
elsewhere, please!

- Michael

Re: GPL vs non-GPL device drivers

[Gene Heskett]

On Friday 16 February 2007, Michael K. Edwards wrote:
>On 2/15/07, Gene Heskett <gene.heskett@verizon.net> wrote:
>[ignorant silliness]
>
>> There is no one to my knowledge here, who would not cheer loudly once
>> a verdict was rendered because that courts decision would give the
>> FOSS community a quotable case law as to exactly what is, and is not
>> legal for you to do with GPL'd code.  We would after 16+ years of the
>> GPL, finally have a firm, well defined line drawn in the sand, a
>> precedence in US case law that at present, only exists in Germany.
>
>Oferchrissake.  We do have a US precedent, insofar as a decision in a
>court of fact on issues of fact can ever be a precedent in a common
>law system (hint: zero, unless the later judge feels like quoting some
>compelling prose).  That would be Progress Software v. MySQL (also
>known as MySQL v. NuSphere in some commentators' writings).  The FSF
>interpretation of the GPL lost.

Pacer citations please.

>Completely.  Which is true also of 
>the Munich and Frankfurt decisions.
>
>The plaintiffs, as authors of GPL works, got a full hearing in each
>case -- via routine reasoning about the GPL as an offer of contract,
>whose conditions either had (Progress Software) or had not
>(Fortinet/Sitecom and D-Link) been performed to the extent necessary
>for the defendant to claim license under the GPL.  MySQL did obtain a
>preliminary injunction, but on unrelated trademark license grounds;
>the GPL claim got them nowhere, for at least four distinct reasons
>stated in the opinion.  Harald's recovery was limited to statutory
>costs and, in the Munich case, an injunction to _either_ offer the
>source code of netfilter/iptables itself _or_ stop shipping product.
>Both German courts refused to find contract "in personam" (necessary
>to a breach of contract claim, in turn necessary to a demand for
>specific performance).
>
>"GPL is a creature of copyright law" lost in court, every time.
>"Section 4 is a limitation of scope, not a conditional performance"
>lost.  "You can lose your license irrevocably" lost.  "We can compel
>disclosure of source code with no alternative" lost.  "We can
>circumvent contract law standards of breach and remedy" lost.
>Everything RMS and Eben Moglen have ever written about the legal
>meaning of the GPL is wrong, and where "derivative works" are
>concerned, embarrassingly hypocritical as well.  Take the Big Lie
>elsewhere, please!
>
>- Michael



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.

Re: GPL vs non-GPL device drivers

[v j]

On 2/15/07, Scott Preece <sepreece@gmail.com> wrote:
> On 2/15/07, v j <vj.linux@gmail.com> wrote:
> > So far I have heard nothing but, "if you don't contribute, screw you."
> > All this is fine. Just say so. Make it black and white. Make it
> > perfectly clear what is and isn't legal. If we can't load proprietary
> > modules, then so be it. It will help everybody if this is out in the
> > clear, instead of resorting to stupid half measures like
> > EXPORT_SYMBOL_GPL.
> ---
>
> I'm not sure what you're asking for. Greg KH's statement was pretty
> black-and-white, and there are a lot of comments in this stream, from
> name-brand developers, that are in line with them. They're the best
> answer you can hope for on this question. The question you're asking
> is an issue of interpretation, which only a court can answer. Do you
> want them to modify the license to make this particular issue clearer?
> Or do you just want a statement from Linus?

Which statement are you talking about? First of all it is not clear to
me if proprietary modules need to be GPL or not. If they do, I guess I
have nothing to say. If that is the way developers want it, so be it.

Assuming these need not be GPL, I have a problem with
EXPORT_SYMBOL_GPL and the general trend in the direction of making
proprietary drivers harder on companies. Our drivers use basic
interfaces in the kernel like open, read, write, ioctl, semaphores,
interrupts, timers etc. This is functionality we would expect from any
operating system. We used devfs before and had no problems there. Greg
KH has gone and made the basic sysfs interface, which any generic
driver could use as EXPORT_SYMBOL_GPL. I don't really care, I just
don't use sysfs. The point is that old functionality is being ripped
off and new ones introduced, and their interfaces are not open
anymore. Hence there will be a point where non-GPLed drivers simply
cannot be loaded.

So why beat about the bush? Just make it illegal to load proprietary
drivers, or remove EXPORT_SYMBOL_GPL.

vj.

Re: GPL vs non-GPL device drivers

[Chris Friesen]

v j wrote:

> Greg
> KH has gone and made the basic sysfs interface, which any generic
> driver could use as EXPORT_SYMBOL_GPL.
> ...The point is that old functionality is being ripped
> off and new ones introduced, and their interfaces are not open
> anymore.

Hmm...you keep using the word "open".  What definition are you using? 
Because the new implementation is licensed under the GPL, which is an 
"Open Source" license.  By definition, this means that it is "open".

What I see you saying is that the interfaces are more restrictive than 
before.  This is true.

However, if you are confident that you are abiding by the terms of the 
GPL then there is nothing stopping you from patching the kernel to 
convert the EXPORT_SYMBOL_GPL to just EXPORT_SYMBOL.  The _GPL version 
is just a hint as to the intent/opinion of the designer.

The flip side of that is that using only items exported via 
EXPORT_SYMBOL doesn't make you automatically compliant to the GPL.  You 
could still be infringing if the module is legally considered a 
derivative work of the kernel.

Chris

Re: GPL vs non-GPL device drivers

[Martin Mares]

Hello!

> Assuming these need not be GPL, I have a problem with
> EXPORT_SYMBOL_GPL and the general trend in the direction of making
> proprietary drivers harder on companies.

Most kernel developers did always say they don't agree with proprietary
drivers, don't want to support them and that they are convinced such
drivers are illegal. And according to the language of the GPL and the
copyright law, it's quite possible they really are illegal (although
a court _might_ rule that the modules are not a derived work of the
kernel). Even with all that, you still decided to distribute such
modules. What you are complaining about?

> So why beat about the bush? Just make it illegal to load proprietary
> drivers, or remove EXPORT_SYMBOL_GPL.

The point is that it's impossible to make it illegal (although many of
the authors of the kernel would like to) -- the point is that if kernel
modules aren't derivative works of the kernel, the kernel license cannot
control them.

				Have a nice fortnight
-- 
Martin `MJ' Mares                          <mj@ucw.cz>   http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
This mail doesn't contain viruses, because it wasn't sent from MS Windows. Checked by eyes.

Re: GPL vs non-GPL device drivers

[Matthew Frost]

v j wrote:
> On 2/15/07, Scott Preece <sepreece@gmail.com> wrote:
>> On 2/15/07, v j <vj.linux@gmail.com> wrote:
>>> So far I have heard nothing but, "if you don't contribute, screw you."
>>> All this is fine. Just say so. Make it black and white. Make it
>>> perfectly clear what is and isn't legal. If we can't load proprietary
>>> modules, then so be it. It will help everybody if this is out in the
>>> clear, instead of resorting to stupid half measures like
>>> EXPORT_SYMBOL_GPL.
>> ---

You are asking developers to make a statement which is not theirs to make.
"Legal" is a jurisdictional variable.  Its meaning is interpreted by the law
codes of whatever jurisdiction you or your company operate within.  You may be
subject to the interpretations of alternate jurisdictions by the scope of your
actions and their effects, personally or corporately.  A general statement of
"legal" with respect to this issue has been described to you, but is ultimately
a result of several factors, the principal of which are the binding legal
instrument governing permissible behavior with respect to the code in Linux and
the legal environment within which your actions under that instrument can be judged.

I want you to consider that Linux is a licensed software product subject to
copyright constraints.  That provides two legal conditions for use of Linux.
The privilege of using Linux for your particular purpose comes at the cost of
respecting the rights of the copyright holders in the work, based upon the
licensing conditions established for that work.  In this respect, it is no
different than any other software package that your company evaluated.

In your evaluation of the respective benefits and costs to the selection of a
given software package for your embedded environment, you should already have
consulted counsel about the legal ramifications of licensing restrictions for
the available options.  They should have informed you that the GPL, as a legal
instrument, binds your scope of action.

You state in your initial comment that you "chose Linux ... because of its lack
of royalty model, robustness and availability of infinite number of open-source
tools."  From your limited description, it sounds as though you believed that
the benefits for use of Linux as a distributable operating system for your
embedded platform were not balanced by costs beyond in-house development.  Linux
is, indeed, free with respect to any monetary royalty.  This does not mean that
there are not costs associated with its use; it merely means that the monetary
outlay for use is far smaller than that required by many of its competitors.  In
general terms, that monetary outlay can be spent in-house, rather than lost to
an outside company.  However, that limited view of costs fails to take into
account the very real demands placed by the license constraints.

You are required, as with any copyrighted and licensed software product, to
comply with the terms of the license and their ramifications in the legal
environment.  These ramifications do change as the environment in which your
company does business changes.  This is why most companies retain counsel.  If
your legal advisers are of the considered opinion that your actions with respect
to the license constraints governing Linux are legally defensible, you have your
answer.

> Which statement are you talking about? First of all it is not clear to
> me if proprietary modules need to be GPL or not. If they do, I guess I
> have nothing to say. If that is the way developers want it, so be it.
> 
> Assuming these need not be GPL, I have a problem with
> EXPORT_SYMBOL_GPL and the general trend in the direction of making
> proprietary drivers harder on companies. Our drivers use basic
> interfaces in the kernel like open, read, write, ioctl, semaphores,
> interrupts, timers etc. This is functionality we would expect from any
> operating system. We used devfs before and had no problems there. Greg
> KH has gone and made the basic sysfs interface, which any generic
> driver could use as EXPORT_SYMBOL_GPL. I don't really care, I just
> don't use sysfs. The point is that old functionality is being ripped
> off and new ones introduced, and their interfaces are not open
> anymore. Hence there will be a point where non-GPLed drivers simply
> cannot be loaded.
> 
> So why beat about the bush? Just make it illegal to load proprietary
> drivers, or remove EXPORT_SYMBOL_GPL.

The kernel developers, collectively the holders of the copyrights in the work
under consideration, continue to perform actions deemed necessary or useful to
prevent circumvention of those licensing constraints.  In this way, they defend
their work, and their rights in that work, from violation by third parties with
agendas incompatible with the principles represented in the chosen license.

Under most legal definitions, violation of license constraints with respect to a
copyrighted work at the very least compels one to refrain from using said work.
 The continued implication that Linux would be injured because you refrain from
violating its license by ceasing to use and distribute Linux in a manner which
is out of compliance with its license is risible.

By all means, consult a lawyer and use Linux in compliance with the license and
your particular relevant legal framework.  But don't ask kernel developers
what's "legal".  They have already told you that in the license.  Perform your
due diligence.

> 
> vj.
> -

Matt Frost

Re: GPL vs non-GPL device drivers

[Matthew Frost]

v j wrote:
> Assuming these need not be GPL, I have a problem with
> EXPORT_SYMBOL_GPL and the general trend in the direction of making
> proprietary drivers harder on companies. Our drivers use basic
> interfaces in the kernel like open, read, write, ioctl, semaphores,
> interrupts, timers etc. This is functionality we would expect from any
> operating system. We used devfs before and had no problems there. Greg
> KH has gone and made the basic sysfs interface, which any generic
> driver could use as EXPORT_SYMBOL_GPL. I don't really care, I just
> don't use sysfs. The point is that old functionality is being ripped
> off and new ones introduced, and their interfaces are not open
> anymore. Hence there will be a point where non-GPLed drivers simply
> cannot be loaded.

And you really should look at why devfs was removed.  It had nothing to do with
closing interfaces.  It had to do with the code itself, and I really should say
nothing more about devfs without my nomex jockeys on.  In replacement, in 2.5,
sysfs evolved.  You can't just point at Greg and say "He's the one stopping me
from doing what I want!"  This is a standard kernel interface, agreed upon by
the usual "rough consensus and running code" methodology.  It simply happens to
be the case that the new code respects a reality which evolved with sysfs
development.  Tainting the kernel on non-GPL module insertion dates from 2001,
early 2.4-series.  Just for a quick google-grep, you can find a very early
explanation for a similar problem in an article by Jerry Epplin, dated March 4,
2001, here:

http://www.linuxdevices.com/articles/AT9161119242.html

Your "3 years ago" timeline surely comes after this information was available.
The reality has changed somewhat, as can be expected over six years and many
arguments and legal consultations.  However, if you do your research, as much as
we'd love to be able to simply ignore non-GPL (especially binary,
no-source-available) modules, we don't.  They just can't use much that is
Linux-unique, and practically nothing that is new.  If you could compile this as
a driver for any UNIX, using POSIXly available interfaces, you would have far
fewer problems.  Any standard syscall that you could get from any standard
(UNIX) operating system, just like you say that you expect.  Or you can do the
nVidia dance, and have to adjust what you can use that is exported, as that
patently non-standard interface changes.  But for your average fire-and-forget
embedded space, that dance only usually gets done once per release.

Your problem is double, of course, because you *distribute non-GPL drivers in a
running Linux*, which is commonly acknowledged to be a problem.  We can't help
you there.  We don't even want to.  And you have it easy!  You just don't like
the idea of releasing your code.  You can't say "Oh, we incorporate patented and
trade secret information which we licensed but cannot divulge".  You're doing it
to yourself.

Sorry,
Matt

Re: GPL vs non-GPL device drivers

[Helge Hafting]

v j wrote:
>
> Assuming these need not be GPL, I have a problem with
> EXPORT_SYMBOL_GPL and the general trend in the direction of making
> proprietary drivers harder on companies. Our drivers use basic
> interfaces in the kernel like open, read, write, ioctl, semaphores,
> interrupts, timers etc. This is functionality we would expect from any
> operating system. We used devfs before and had no problems there. Greg
> KH has gone and made the basic sysfs interface, which any generic
> driver could use as EXPORT_SYMBOL_GPL. I don't really care, I just
> don't use sysfs. The point is that old functionality is being ripped
> off and new ones introduced, and their interfaces are not open
> anymore. Hence there will be a point where non-GPLed drivers simply
> cannot be loaded.
>
> So why beat about the bush? Just make it illegal to load proprietary
> drivers, or remove EXPORT_SYMBOL_GPL.
Those wo introduce EXPORT_SYMBOL_GPL are not in a position where
they can make it illegal to load proprietary modules. They may want to,
but they can't.  The kernel has very many copyright holders, each
decides for his own part only.

Someone who didn't write the module interface or posix interface can't
stop you there.  Anti-proprietary folks then go and make new
useful subsystems, and make sure those are accessed with
EXPORT_SYMBOL_GPL only.  Then they phase out the old
interfaces as the new ones are clearly better, and the vast majority
with GPL drivers have no problem with this.
As long as there are developers with this attitude, expect
EXPORT_SYMBOL_GPL to crop up in new places over time.

Yes - this makes it harder (although not impossible) to distribute
closed-source drivers.  Which is exactly what these people want.
When they are powerless to forbid such drivers, they settle for making
them harder and harder to use instead.  They want this trend
to continue.

There is an obvious way around it - you (and other people
with an interest in closed-source drivers) can write & contribute your
own "sysfs" and whatever else you might need.  Make it better
than the existing sysfs so it actually gets into the kernel,
replacing the existing stuff. And of
course there will be no EXPORT_SYMBOL_GPL in it - since
that is what you want to avoid. 

The price for this then, is to outcompete the proponents of
GPL-only symbols.  If you offer more and better source (under the GPL)
then you can turn the trend and keep linux the way you want it.
If you don't - those that do contribute will get to shape linux
the way they like. Whoever makes linux gets to decide.

Another way is to stay with linux 2.4.  You won't get any
new stuff that way, but no new GPL surprises either.

Helge Hafting

Re: GPL vs non-GPL device drivers

[Greg Trounson]

Theodore Tso wrote:
> On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:
>> You are right. I have not contributed anything to Linux. Except one
>> small patch to the MTD code. However, I don't think that is the point
>> here. I am perfectly willing to live with the way Linux is today. I am
>> telling you as a user that if Linux continues on the current path it
>> will become less and less attractive to Embedded Users.
> 
> But so what?  How will that hurt *Linux*?  If the Embedded developers
> don't contribute changes back, it doesn't hurt us any if they go away
> and start paying $$$ to VxWorks instead of using Linux for free.  

I disagree.  Linux needs popularity at the moment.

Otherwise, Linux may be in for a hard time once manufacturers standardize on TPM-enabled 
processors that only allow 'authorized' code to run.  And it looks like this is going to 
happen.

Unless there is a sufficient user base (ie a market) for Linux, what incentive are Intel, 
AMD, etc going to have to make their hardware run anything except code signed by Microsoft?

When taken off modern CPUs, Linux will be relegated to hobby cpu fabs, legacy hardware and 
maybe a niche back in the embedded market.  Then watch development all but stagnate. 
Something I'd rather not see happen.

Greg

Re: GPL vs non-GPL device drivers

[Lee Revell]

On 2/15/07, Greg Trounson <gregt@maths.otago.ac.nz> wrote:
> Theodore Tso wrote:
> > On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:
> >> You are right. I have not contributed anything to Linux. Except one
> >> small patch to the MTD code. However, I don't think that is the point
> >> here. I am perfectly willing to live with the way Linux is today. I am
> >> telling you as a user that if Linux continues on the current path it
> >> will become less and less attractive to Embedded Users.
> >
> > But so what?  How will that hurt *Linux*?  If the Embedded developers
> > don't contribute changes back, it doesn't hurt us any if they go away
> > and start paying $$$ to VxWorks instead of using Linux for free.
>
> I disagree.  Linux needs popularity at the moment.

Um... what's your point?  Allowing vendors to legally ship embedded
devices containing proprietary drivers would require relicensing the
kernel which is impossible, for reasons that have been discussed at
length on this list.

Lee

Re: GPL vs non-GPL device drivers

[Greg Trounson]

Lee Revell wrote:
> On 2/15/07, Greg Trounson <gregt@maths.otago.ac.nz> wrote:
>> Theodore Tso wrote:
>> > On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:
>> >> You are right. I have not contributed anything to Linux. Except one
>> >> small patch to the MTD code. However, I don't think that is the point
>> >> here. I am perfectly willing to live with the way Linux is today. I am
>> >> telling you as a user that if Linux continues on the current path it
>> >> will become less and less attractive to Embedded Users.
>> >
>> > But so what?  How will that hurt *Linux*?  If the Embedded developers
>> > don't contribute changes back, it doesn't hurt us any if they go away
>> > and start paying $$$ to VxWorks instead of using Linux for free.
>>
>> I disagree.  Linux needs popularity at the moment.
> 
> Um... what's your point?  Allowing vendors to legally ship embedded
> devices containing proprietary drivers would require relicensing the
> kernel which is impossible, for reasons that have been discussed at
> length on this list.
> 
> Lee

I wasn't disputing legal problems with proprietary drivers nor suggesting people ignore 
the issue.  I was trying to make the point that Linux is adversely affected when lots of 
users, proprietary developers or otherwise, abandon Linux, and the issue might be more 
serious than people here think.

IMO the lack of provision for proprietary drivers in the GPL is a problem.  Not 
necessarily one we can do anything about now the horse has bolted, but a problem nonetheless.

Greg

Re: GPL vs non-GPL device drivers

[Lee Revell]

On 2/15/07, Greg Trounson <gregt@maths.otago.ac.nz> wrote:
> I wasn't disputing legal problems with proprietary drivers nor suggesting people ignore
> the issue.  I was trying to make the point that Linux is adversely affected when lots of
> users, proprietary developers or otherwise, abandon Linux, and the issue might be more
> serious than people here think.
>
> IMO the lack of provision for proprietary drivers in the GPL is a problem.  Not
> necessarily one we can do anything about now the horse has bolted, but a problem nonetheless.

What has changed lately that would cause anyone to "abandon Linux"?
The rules are the same as they have ever been, and Linux is more
popular than ever in the embedded market.

Lee

Re: GPL vs non-GPL device drivers

[Scott Preece]

On 2/15/07, Theodore Tso <tytso@mit.edu> wrote:
>
> But so what?  How will that hurt *Linux*?  If the Embedded developers
> don't contribute changes back, it doesn't hurt us any if they go away
> and start paying $$$ to VxWorks instead of using Linux for free.
---

Well, this is somewhat oversimplified. If the device supports add-on
software, that may be good for the FLOSS community even if the
underlying OS is partly closed. And if they're returning changes and
patches from any work they do in the code kernel (aside from their
drivers), that is also good for the community. And there is some value
to the community in their hiring and/or growing developers who may
later contribute directly to the kernel. And there is even some value
in just the publicity and hype for Linux, which helps bring new people
in. I'm not saying those things are worth "enough", just that they're
worth
something.

---
> Contrawise, if Embedded developers do contribute their device driver
> changes back to the kernel, they will be fine.  ...
---

In fairness, though, some of the developers WILL bitch about your not
using a recent kernel and not providing patches until products ship,
despite that meeting the letter of the license. Some of the notes in
this thread do exactly that. And I HAVE seen real developers say
something very close to "Your code is based on a kernel too old to
have any value to us" even though they would also claim abuse if the
code hadn't been made available at all. And I've seen lots of cases
where laptop-centric developers rejected or simply ignored code
submitted by embedded developers.

I'm completely in line with participating fully in the community, but
it's important that the mainstream developers recognize that the
community is bigger than the laptop/server-room crowd.

scott

Re: GPL vs non-GPL device drivers

[Pavel Machek]

Hi!

> >Contrawise, if Embedded developers do contribute their 
> >device driver
> >changes back to the kernel, they will be fine.  ...
> ---
> 
> In fairness, though, some of the developers WILL bitch 
> about your not
> using a recent kernel and not providing patches until 
> products ship,
> despite that meeting the letter of the license. Some of 
> the notes in

Well, of course developers will complain, they _always_ complain. But
it is very different kind of complain... first is

'I think you are violating the law, you are evil'

and second is

'Thank you for playing by the rules, but you know, your code is not
mergeable right now'.

> this thread do exactly that. And I HAVE seen real 
> developers say
> something very close to "Your code is based on a kernel 
> too old to
> have any value to us" even though they would also claim 
> abuse if the
> code hadn't been made available at all. And I've seen 

Yep, and guess what, thats okay. Someone with more time than they do
may decide to forward port the code and/or rewrite it for new kernel.

I was doing exactly that with 2.4 sharp sl-5500 code.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: GPL vs non-GPL device drivers

[Neil Brown]

On Wednesday February 14, vj.linux@gmail.com wrote:
> 
> However we have a worrying trend here. If at some point it becomes
> illegal to load our modules into the linux kernel, then it is
> unacceptable to us. We would have been better off choosing VxWorks or
> OSE 3 years ago when we made an OS choice. The fact that Linux is
> becoming more and more closed is very very alarming.

Might I suggest that you give very serious consideration to
open-sourcing your drivers?  There are benefits and well as costs, and
many have found that the benefits substantially out weigh the costs.

NeilBrown

Re: GPL vs non-GPL device drivers

[Gene Heskett]

On Thursday 15 February 2007, Neil Brown wrote:
>On Wednesday February 14, vj.linux@gmail.com wrote:
>> However we have a worrying trend here. If at some point it becomes
>> illegal to load our modules into the linux kernel, then it is
>> unacceptable to us. We would have been better off choosing VxWorks or
>> OSE 3 years ago when we made an OS choice. The fact that Linux is
>> becoming more and more closed is very very alarming.
>
>Might I suggest that you give very serious consideration to
>open-sourcing your drivers?  There are benefits and well as costs, and
>many have found that the benefits substantially out weigh the costs.
>
>NeilBrown

Speaking as one who has not contributed back to the kernel other than an 
occasional bug report as I'm getting too old to code alongside these 
wizards, please let me say:

That's an admirable bit of advice Neil, but I have serious doubts it will 
fall on a fertile mind.  From vj's tone here, its obvious that he thinks 
its fine to leech his income stream from code that is free.  And giving 
one teeny little patch for some utility back seems to make him think he 
has paid the bill.  Methinks he has not paid the bill in kind because its 
an ongoing rental.

Now, if he _were_ to contribute his top secret drivers into the kernel 
tree, how are we to convince vj that it is in his best interest in the 
long run to do so?  After all, the many eyeballs theory will guarantee 
that his codebase will not go untouched because bugs he doesn't even know 
exist will be noticed and fixed, and routine speedups of 2x are entirely 
possible too.  He will in the long run get back faster, more stable code 
which can't do anything but enhance the value of his hardware, both in 
how well it runs, but in the public's perception too, simply because it 
IS in the kernel tree and therefore very well reviewed.  And that vj, is 
an advertising point of no little value. 

But, I suspect by now he has pulled the batteries out of his hearing aid 
so he doesn't have to listen to any more of this blasphemous talk.  
Sad...

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.

Re: GPL vs non-GPL device drivers

[Ben Nizette]

v j wrote:
> This is in reference to the following thread:
> 
> http://lkml.org/lkml/2006/12/14/63
> 
> I am not sure if this is ever addressed in LKML, but linux is _very_
> popular in the embedded space. We (an embedded vendor) chose Linux 3
> years back because of its lack of royalty model, robustness and
> availability of infinite number of open-source tools.
[...]
> However we have a worrying trend here. If at some point it becomes
> illegal to load our modules into the linux kernel, then it is
> unacceptable to us. We would have been better off choosing VxWorks or
> OSE 3 years ago when we made an OS choice. The fact that Linux is
> becoming more and more closed is very very alarming.
> 
Question to the world here:  Distros make, as a matter of course, a 
series of modifications to the Linux Kernel so that their modules or 
features work.  What stops VJ making a patchset which effectively 
s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g 's the kernel source then 
distributing that under the GPL?  He then supplies his un-GPL'd modules 
to the world which just happen to only run on the modified kernel.  I've 
read the GPL of course (IANAL though) and I can't see what this violates 
except the /spirit/ of the license.  Don't get me wrong, I'm strongly 
against anyone doing what I just mentioned, I believe it to be immoral 
taking someone's GPL'd code and mangling it in such a way.  I speak as 
an embedded developer myself whose company decided that running our code 
under Linux and distributing our code under the GPL was far preferable 
to running closed-source software on a closed-source platform.

I'll finish off to VJ:  If you want to be alarmed, go ahead and switch 
to VxWorks, the Linux community will live on.  It might have a smaller 
user-base in embedded-land but that's the nature of the beast.  A large 
user-base doesn't mean much to something like linux unless it comes with 
a large, open-source-minded developer-base.

--Ben.

Re: GPL vs non-GPL device drivers

[Nick Piggin]

Ben Nizette wrote:
> v j wrote:
> 
>> This is in reference to the following thread:
>>
>> http://lkml.org/lkml/2006/12/14/63
>>
>> I am not sure if this is ever addressed in LKML, but linux is _very_
>> popular in the embedded space. We (an embedded vendor) chose Linux 3
>> years back because of its lack of royalty model, robustness and
>> availability of infinite number of open-source tools.
> 
> [...]
> 
>> However we have a worrying trend here. If at some point it becomes
>> illegal to load our modules into the linux kernel, then it is
>> unacceptable to us. We would have been better off choosing VxWorks or
>> OSE 3 years ago when we made an OS choice. The fact that Linux is
>> becoming more and more closed is very very alarming.
>>
> Question to the world here:  Distros make, as a matter of course, a 
> series of modifications to the Linux Kernel so that their modules or 
> features work.  What stops VJ making a patchset which effectively 
> s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g 's the kernel source then 
> distributing that under the GPL?  He then supplies his un-GPL'd modules 
> to the world which just happen to only run on the modified kernel.  I've 
> read the GPL of course (IANAL though) and I can't see what this violates 
> except the /spirit/ of the license.  Don't get me wrong, I'm strongly 
> against anyone doing what I just mentioned, I believe it to be immoral 
> taking someone's GPL'd code and mangling it in such a way.  I speak as 
> an embedded developer myself whose company decided that running our code 
> under Linux and distributing our code under the GPL was far preferable 
> to running closed-source software on a closed-source platform.

The best bet would be to read up on lots of past discussions related to
exactly these kinds of questions, then ask your Lawyer.

Rhetorical question: what stops me from taking somebody's copyrighted
work, stripping the copyrights or falsely claiming to have a license
to redistribute it, then selling it?

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

RE: GPL vs non-GPL device drivers

[David Schwartz]

> > Question to the world here:  Distros make, as a matter of course, a
> > series of modifications to the Linux Kernel so that their modules or
> > features work.  What stops VJ making a patchset which effectively
> > s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g 's the kernel source then
> > distributing that under the GPL?  He then supplies his un-GPL'd modules
> > to the world which just happen to only run on the modified
> > kernel.

> The best bet would be to read up on lots of past discussions related to
> exactly these kinds of questions, then ask your Lawyer.

> Rhetorical question: what stops me from taking somebody's copyrighted
> work, stripping the copyrights or falsely claiming to have a license
> to redistribute it, then selling it?

Totally unrelated for so many reasons:

1) EXPORT_SYMBOL_GPL is not a copyright. Removing functional code is not
even remotely analogous to "stripping copyrights".

2) Falsely claiming to have a license is not the same thing as actually
having a license. The GPL is a license.

> > I've
> > read the GPL of course (IANAL though) and I can't see what this
> > violates
> > except the /spirit/ of the license.

On the contrary, being allowed to change the code if you don't like what it
does *is* the spirit of the GPL. Being able to share those changes *is* the
spirit of the GPL. It's those who try to contaminate GPL'd code with
*functional* *aspects* they wish to use the law to stop people from
circumventing who are violating the spirit of the GPL.

> > Don't get me wrong, I'm strongly
> > against anyone doing what I just mentioned, I believe it to be immoral
> > taking someone's GPL'd code and mangling it in such a way.

The whole point of the GPL is to ensure the freedom to mangle code to make
it do what you want and not do what you don't want. The whole point is to
people from adding things that others cannot remove.

> > I speak as
> > an embedded developer myself whose company decided that running
> > your code
> > under Linux and distributing our code under the GPL was far preferable
> > to running closed-source software on a closed-source platform.

I agree. I think a lot of people choose not to open source their commercial
software for reasons that really don't make sense and they don't appreciate
the advantages. To the person who said that "open sourcing our code only
helps our competitors", I would respond:

1) It may also help you. People will look at the code. If they notice bugs,
they may tell you. They may add new capabilities. People may support
themselves -- I know if I encounter a problem with a piece of software and I
have the source, I'll try to track it down myself. It's easier for me.

2) It may help your customers. If they have a problem, they may be able to
fix it themselves. (Yes, many people are capable of making a new build and
burning it onto an embedded device.) If they need additional features, they
may add them. They may be more willing to buy your products if they know
they can support it themselves should you go away and if they can see the
quality of your code.

3) It may help the community at large. You never know when someone will have
a problem similar to one you have already solved.

4) It may not help your competitors. If they're committed to closed source,
they probably  won't do much with your software. Especially when we're
talking about drivers, this argument seems particularly weak.

DS

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Thu, 2007-02-15 at 18:40 +1100, Nick Piggin wrote:
> Ben Nizette wrote:
[...]
> > Question to the world here:  Distros make, as a matter of course, a 
> > series of modifications to the Linux Kernel so that their modules or 
> > features work.  What stops VJ making a patchset which effectively 
> > s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g 's the kernel source then 
> > distributing that under the GPL?  He then supplies his un-GPL'd modules 

Nothing. But it is pointless since that doesn't un-GPL source code.

[...]
> Rhetorical question: what stops me from taking somebody's copyrighted
> work, stripping the copyrights or falsely claiming to have a license
> to redistribute it, then selling it?

No one.
But that doesn't make the action legal or change the copyright/authors
rights in anyway (at least in the more civilized parts of the world).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Jeff Garzik]

Bernd Petrovitsch wrote:
> On Thu, 2007-02-15 at 18:40 +1100, Nick Piggin wrote:
>> Rhetorical question: what stops me from taking somebody's copyrighted
>> work, stripping the copyrights or falsely claiming to have a license
>> to redistribute it, then selling it?
> 
> No one.

Well, that's not quite true, is it?  This little microcosm of life has 
its checks and balances, and certainly strives for an equilibrium.

You make a choice, as in Nick's example, to balance the risk of being 
caught, being sued, being shamed, and/or being avoided by customers 
against the perceived rewards.

Negative incentives are present, is the overall answer, even if they are 
not immediately obvious and spelled out in excruciating detail.

	Jeff

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Thu, 2007-02-15 at 17:41 -0500, Jeff Garzik wrote:
> Bernd Petrovitsch wrote:
> > On Thu, 2007-02-15 at 18:40 +1100, Nick Piggin wrote:
> >> Rhetorical question: what stops me from taking somebody's copyrighted
> >> work, stripping the copyrights or falsely claiming to have a license
> >> to redistribute it, then selling it?
> > 
> > No one.
> 
> Well, that's not quite true, is it?  This little microcosm of life has 
> its checks and balances, and certainly strives for an equilibrium.
> 
> You make a choice, as in Nick's example, to balance the risk of being 

ACK.

> caught, being sued, being shamed, and/or being avoided by customers 
> against the perceived rewards.

ACK, *iff* you get caught.

But I cannot stop you if you just do it. Perhaps I can stop you later on
if I find it out, can proove it sufficient to go to court (or at least
threaten enough) and have the economical power to do it.

> Negative incentives are present, is the overall answer, even if they are 
> not immediately obvious and spelled out in excruciating detail.

Of course. And given the cases on gpl-violations.org I fear I'm right.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Arjan van de Ven]

On Wed, 2007-02-14 at 21:16 -0800, v j wrote:
> This is in reference to the following thread:
> 
> http://lkml.org/lkml/2006/12/14/63
> 
> I am not sure if this is ever addressed in LKML, but linux is _very_
> popular in the embedded space. We (an embedded vendor) chose Linux 3
> years back because of its lack of royalty model, robustness and
> availability of infinite number of open-source tools.


I think you have a bit of a misunderstanding... Linux is not royalty
free. Just the royalty is not in the form of cash, but in the form of
having to give your improvements back to the open source world.

(this is paraphrasing the intent of the GPL basically, you can argue for
hours if drivers are separate or improvements, and I'm not interested in
that debate, it has been debated to death before and only lawyers will
in the end be able to settle that on a case by case basis).

If your mindset is "how much can I take take take without giving back
back back" then personally I think you're sort of acting like a parasite
in this context.... 

Re: GPL vs non-GPL device drivers

[v j]

On 2/14/07, Arjan van de Ven <arjan@infradead.org> wrote:
> On Wed, 2007-02-14 at 21:16 -0800, v j wrote:
> > This is in reference to the following thread:
> >
> > http://lkml.org/lkml/2006/12/14/63
> >
> > I am not sure if this is ever addressed in LKML, but linux is _very_
> > popular in the embedded space. We (an embedded vendor) chose Linux 3
> > years back because of its lack of royalty model, robustness and
> > availability of infinite number of open-source tools.
>
>
> I think you have a bit of a misunderstanding... Linux is not royalty
> free. Just the royalty is not in the form of cash, but in the form of
> having to give your improvements back to the open source world.

Sure. But this is not legally binding.

> (this is paraphrasing the intent of the GPL basically, you can argue for
> hours if drivers are separate or improvements, and I'm not interested in
> that debate, it has been debated to death before and only lawyers will
> in the end be able to settle that on a case by case basis).
>
> If your mindset is "how much can I take take take without giving back
> back back" then personally I think you're sort of acting like a parasite
> in this context....

Ok so are thousands of others who are using Linux as their OS of
choice in embedded systems. They are not doing this because they are
eager to give back back. They are doing it because Linux provides
compelling reasons for them to choose it. They could have very well
chosen VxWorks or OSE too. They chose not to, but not because they
were unwilling to be a parasite.

Re: GPL vs non-GPL device drivers

[Arjan van de Ven]

On Thu, 2007-02-15 at 00:04 -0800, v j wrote:
> On 2/14/07, Arjan van de Ven <arjan@infradead.org> wrote:
> > On Wed, 2007-02-14 at 21:16 -0800, v j wrote:
> > > This is in reference to the following thread:
> > >
> > > http://lkml.org/lkml/2006/12/14/63
> > >
> > > I am not sure if this is ever addressed in LKML, but linux is _very_
> > > popular in the embedded space. We (an embedded vendor) chose Linux 3
> > > years back because of its lack of royalty model, robustness and
> > > availability of infinite number of open-source tools.
> >
> >
> > I think you have a bit of a misunderstanding... Linux is not royalty
> > free. Just the royalty is not in the form of cash, but in the form of
> > having to give your improvements back to the open source world.
> 
> Sure. But this is not legally binding.

that's a legal conclusion that is ... iffy at least. I'm not a lawyer,
but I suggest you talk to a real one before making that conclusion, and
you'll see it's not as simple as that.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: GPL vs non-GPL device drivers

[Richard Knutsson]

v j wrote:
> On 2/14/07, Arjan van de Ven <arjan@infradead.org> wrote:
>> On Wed, 2007-02-14 at 21:16 -0800, v j wrote:
>> > This is in reference to the following thread:
>> >
>> > http://lkml.org/lkml/2006/12/14/63
>> >
>> > I am not sure if this is ever addressed in LKML, but linux is _very_
>> > popular in the embedded space. We (an embedded vendor) chose Linux 3
>> > years back because of its lack of royalty model, robustness and
>> > availability of infinite number of open-source tools.
>>
>>
>> I think you have a bit of a misunderstanding... Linux is not royalty
>> free. Just the royalty is not in the form of cash, but in the form of
>> having to give your improvements back to the open source world.
>
> Sure. But this is not legally binding.
Please clarify!
http://yro.slashdot.org/yro/04/07/23/1558219.shtml?tid=117&tid=123

Richard Knutsson

Re: GPL vs non-GPL device drivers

[v j]

Oh, I am sorry. Seems like the German courts have spoken. I am not
sure about what, but they have spoken. Sorry for the confusion.

On 2/15/07, Richard Knutsson <ricknu-0@student.ltu.se> wrote:
> v j wrote:
> > On 2/14/07, Arjan van de Ven <arjan@infradead.org> wrote:
> >> On Wed, 2007-02-14 at 21:16 -0800, v j wrote:
> >> > This is in reference to the following thread:
> >> >
> >> > http://lkml.org/lkml/2006/12/14/63
> >> >
> >> > I am not sure if this is ever addressed in LKML, but linux is _very_
> >> > popular in the embedded space. We (an embedded vendor) chose Linux 3
> >> > years back because of its lack of royalty model, robustness and
> >> > availability of infinite number of open-source tools.
> >>
> >>
> >> I think you have a bit of a misunderstanding... Linux is not royalty
> >> free. Just the royalty is not in the form of cash, but in the form of
> >> having to give your improvements back to the open source world.
> >
> > Sure. But this is not legally binding.
> Please clarify!
> http://yro.slashdot.org/yro/04/07/23/1558219.shtml?tid=117&tid=123
>
> Richard Knutsson
>
>

Re: GPL vs non-GPL device drivers

[Jörn Engel]

On Thu, 15 February 2007 00:40:31 -0800, v j wrote:
> 
> Oh, I am sorry. Seems like the German courts have spoken. I am not
> sure about what, but they have spoken. Sorry for the confusion.

In short, there seem to be two classes of closed-source drivers:

1. ATI and nVidia.  Both are well-known, in both cases they seem to
avoid the legally important aspect of shipping their driver along with a
kernel and they seem to be legally in relatively safe water.  At least I
haven't heard about them getting sued yet.

2. The embedded companies.  By the very nature of selling an embedded
device they are shipping their drivers along with a kernel and seem to
be in very shallow water.  Dozens of them have received letters from
lawyers and didn't even dare go to court - they just complied.

While this list is not exhaustive and your company's case may be
different from all others, it does give you a hint of what your chances
might be in court.  Go to http://gpl-violations.org/ and do your
research.

The question whether a specific closed-source driver is legal or not can
only be answered in court and only on a case-by-case basis.  You should
have a good idea of what many developers personal opinion is and with
the research you can also estimate your legal position.  Then make your
decision, as noone here is going to make it for you - even if some would
like to.

Jörn

-- 
Eighty percent of success is showing up.
-- Woody Allen

Re: GPL vs non-GPL device drivers

[Nick Piggin]

v j wrote:
> On 2/14/07, Arjan van de Ven <arjan@infradead.org> wrote:

>> If your mindset is "how much can I take take take without giving back
>> back back" then personally I think you're sort of acting like a parasite
>> in this context....
> 
> 
> Ok so are thousands of others who are using Linux as their OS of
> choice in embedded systems. They are not doing this because they are
> eager to give back back. They are doing it because Linux provides
> compelling reasons for them to choose it. They could have very well
> chosen VxWorks or OSE too. They chose not to, but not because they
> were unwilling to be a parasite.

I can't control how people think or the reasons behind their actions. Nor
do I care. All I care about is that I don't have parasites hanging off me.

-- 
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: GPL vs non-GPL device drivers

[Martin Mares]

Hello!

> >I think you have a bit of a misunderstanding... Linux is not royalty
> >free. Just the royalty is not in the form of cash, but in the form of
> >having to give your improvements back to the open source world.
> 
> Sure. But this is not legally binding.

Maybe it's not, but it certainly doesn't mean that the kernel developers
should try to make your life easier, especially if they believe that what
you do is unethical.

				Have a nice fortnight
-- 
Martin `MJ' Mares                          <mj@ucw.cz>   http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
This message is transmitted on 100% recycled electrons.

Re: GPL vs non-GPL device drivers

[Alexandre Oliva]

On Feb 15, 2007, "v j" <vj.linux@gmail.com> wrote:

> On 2/14/07, Arjan van de Ven <arjan@infradead.org> wrote:

>> I think you have a bit of a misunderstanding... Linux is not royalty
>> free. Just the royalty is not in the form of cash, but in the form of
>> having to give your improvements back to the open source world.

It's not giving back, it's giving forward.  Improvements don't have to
go back, but whoever receives them must receive them under the same
license.

> Sure. But this is not legally binding.

Indeed, you don't have to give it back or give it forward.  It's just
that, if you don't comply with the license, you don't have permission
to distribute the software at all.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: GPL vs non-GPL device drivers

[Lennart Sorensen]

On Thu, Feb 15, 2007 at 12:04:26AM -0800, v j wrote:
> Ok so are thousands of others who are using Linux as their OS of
> choice in embedded systems. They are not doing this because they are
> eager to give back back. They are doing it because Linux provides
> compelling reasons for them to choose it. They could have very well
> chosen VxWorks or OSE too. They chose not to, but not because they
> were unwilling to be a parasite.

Some people in the embedded world actually think having access to
cooporating with thousands of other developers is a good thing.  I like
being able to ask questions and get feedback.  I have contributed back
some of my improvements, and the things I haven't are things I think
would make the kernel's drivers worse for general case use (due to
having a few bits of weirdness in our hardware), but anyone that wants
the source with those changes can have it.  Our older products which are
running a closed source OS (well as far as the customers are concerned
at least, since we have source and they don't) are eventually intended
to move to linux as well.  The support for the proprietary embedded OSs
have in our experience been pathetic.  Even when sent patches to fix
bugs they don't make it in to the next release in many cases.  No
thanks.  What keeps customers buying our products is that when there is
a problem we fix it as quickly as we can using whatever resources it
takes.  It isn't really in having secret source code for some feature.
It would be hard for a smallish company to come up with something so
amazing that a larger company couldn't reimplement the same thing in a
very short time if they thought it was useful.

--
Len Sorensen

Re: GPL vs non-GPL device drivers

[Mws]

hi vj,

On Thursday 15 February 2007, v j wrote:
> This is in reference to the following thread:
> 
> http://lkml.org/lkml/2006/12/14/63
> 
> I am not sure if this is ever addressed in LKML, but linux is _very_
> popular in the embedded space. We (an embedded vendor) chose Linux 3
> years back because of its lack of royalty model, robustness and
> availability of infinite number of open-source tools.
> 
> We recently decided to move to Linux 2.6 for our next product, mainly
> because Linux has worked so well for us in the past, and we would like
> to move up to keep up with the latest and greatest.

you choose to move to linux 2.6 for your next product - fine.
it has worked for you well in the past - fine.
you would like to keep along with the latest and greatest - fine.

_but_

for all those reasons you have to get along with all rules, licenses and
at least all changes that the kernel community decided to perform.

> However in moving to  2.6, we noticed a number of alarming things.
> Porting drivers over from devfs to udev, though easy raised a number
> of alarming issues. Driver's no longer could dynamically allocate
> their MAJOR/MINOR numbers. Doing so would mean they would have to use
> sysfs. However it seems that sysfs (and the class_ interface) is only
> available to GPL modules. This is very concerning. The drivers which
> we have written over the last three years are suddenly under threat.
> We don't mind statically assigning MAJOR/MINOR numbers to our drivers.
> We can do this and modify our user space applications too.
> 
> However we have a worrying trend here. If at some point it becomes
> illegal to load our modules into the linux kernel, then it is
> unacceptable to us. We would have been better off choosing VxWorks or
> OSE 3 years ago when we made an OS choice. The fact that Linux is
> becoming more and more closed is very very alarming.

the trend is not worrying. we are not responsible for your decisions you made 
in the past. 
the only real FACT is that linux is being stated to BE OPEN and what is much more 
important to STAY OPEN for everybody.

you chose it years ago, because of those facts. of course linux is very popular on 
embedded systems. i am working within some open source projects that also run
on embedded hardware designs. 

your main mistake in understanding linux and our way to have it also more open in 
future than by now. 

what actually costs you more in future? 
opening your drivers, as much it must be, to have your hardware supported under 2.6
_or_ 
paying license fees for runtime/development tools for vxworks, ose whatever?

and what will do complain at windriver or other companies, if they decide not to support 
your used cpu architecture anymore?


this were my 0.2$
marcel
 
p.s. you said you like linux for its royalty model - that also includes that you accept all the
      other rules and terms. e.g. gpl license _and_ its fullfillment.

> vj.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: GPL vs non-GPL device drivers

[Manu Abraham]

On 2/15/07, Mws <mws@twisted-brains.org> wrote:
> hi vj,
>
> On Thursday 15 February 2007, v j wrote:
> > This is in reference to the following thread:
> >
> > http://lkml.org/lkml/2006/12/14/63
> >
> > I am not sure if this is ever addressed in LKML, but linux is _very_
> > popular in the embedded space. We (an embedded vendor) chose Linux 3
> > years back because of its lack of royalty model, robustness and
> > availability of infinite number of open-source tools.
> >
> > We recently decided to move to Linux 2.6 for our next product, mainly
> > because Linux has worked so well for us in the past, and we would like
> > to move up to keep up with the latest and greatest.
>
> you choose to move to linux 2.6 for your next product - fine.
> it has worked for you well in the past - fine.
> you would like to keep along with the latest and greatest - fine.
>
> _but_
>
> for all those reasons you have to get along with all rules, licenses and
> at least all changes that the kernel community decided to perform.
>
> > However in moving to  2.6, we noticed a number of alarming things.
> > Porting drivers over from devfs to udev, though easy raised a number
> > of alarming issues. Driver's no longer could dynamically allocate
> > their MAJOR/MINOR numbers. Doing so would mean they would have to use
> > sysfs. However it seems that sysfs (and the class_ interface) is only
> > available to GPL modules. This is very concerning. The drivers which
> > we have written over the last three years are suddenly under threat.
> > We don't mind statically assigning MAJOR/MINOR numbers to our drivers.
> > We can do this and modify our user space applications too.
> >
> > However we have a worrying trend here. If at some point it becomes
> > illegal to load our modules into the linux kernel, then it is
> > unacceptable to us. We would have been better off choosing VxWorks or
> > OSE 3 years ago when we made an OS choice. The fact that Linux is
> > becoming more and more closed is very very alarming.
>
> the trend is not worrying. we are not responsible for your decisions you made
> in the past.
> the only real FACT is that linux is being stated to BE OPEN and what is much more
> important to STAY OPEN for everybody.
>
> you chose it years ago, because of those facts. of course linux is very popular on
> embedded systems. i am working within some open source projects that also run
> on embedded hardware designs.
>
> your main mistake in understanding linux and our way to have it also more open in
> future than by now.
>
> what actually costs you more in future?
> opening your drivers, as much it must be, to have your hardware supported under 2.6
> _or_
> paying license fees for runtime/development tools for vxworks, ose whatever?


marcel,

most of the vendors, who claim IP just cite nonsense. There are really
hardly a few vendors who are really bound to the IP issue. Just that
they do not know how to write proper code, they do not want to open up
their code.

In fact , such vendors do have a think probably like this "if we open
up our driver if people see the pathetic quality, the customers would
probably think how bad is the hardware and probably affect our sales"
. So it would be better if we hide under the shade of the IP umbrella.

Little do that these vendors know that customers wouldn't want to go
alongwith such narrow minded vendors in the long run. But somehow due
to a certain void people do the get along, that's it, not for long
though.

regards,
manu

Re: GPL vs non-GPL device drivers

[linux-os (Dick Johnson)]

On Thu, 15 Feb 2007, Manu Abraham wrote:

> On 2/15/07, Mws <mws@twisted-brains.org> wrote:
>> hi vj,
>>
>> On Thursday 15 February 2007, v j wrote:
>>> This is in reference to the following thread:
>>>
>>> http://lkml.org/lkml/2006/12/14/63
>>>
>>> I am not sure if this is ever addressed in LKML, but linux is _very_
>>> popular in the embedded space. We (an embedded vendor) chose Linux 3
>>> years back because of its lack of royalty model, robustness and
>>> availability of infinite number of open-source tools.
>>>
>>> We recently decided to move to Linux 2.6 for our next product, mainly
>>> because Linux has worked so well for us in the past, and we would like
>>> to move up to keep up with the latest and greatest.
>>
>> you choose to move to linux 2.6 for your next product - fine.
>> it has worked for you well in the past - fine.
>> you would like to keep along with the latest and greatest - fine.
>>
>> _but_
>>
>> for all those reasons you have to get along with all rules, licenses and
>> at least all changes that the kernel community decided to perform.
>>
>>> However in moving to  2.6, we noticed a number of alarming things.
>>> Porting drivers over from devfs to udev, though easy raised a number
>>> of alarming issues. Driver's no longer could dynamically allocate
>>> their MAJOR/MINOR numbers. Doing so would mean they would have to use
>>> sysfs. However it seems that sysfs (and the class_ interface) is only
>>> available to GPL modules. This is very concerning. The drivers which
>>> we have written over the last three years are suddenly under threat.
>>> We don't mind statically assigning MAJOR/MINOR numbers to our drivers.
>>> We can do this and modify our user space applications too.
>>>
>>> However we have a worrying trend here. If at some point it becomes
>>> illegal to load our modules into the linux kernel, then it is
>>> unacceptable to us. We would have been better off choosing VxWorks or
>>> OSE 3 years ago when we made an OS choice. The fact that Linux is
>>> becoming more and more closed is very very alarming.
>>
>> the trend is not worrying. we are not responsible for your decisions you made
>> in the past.
>> the only real FACT is that linux is being stated to BE OPEN and what is much more
>> important to STAY OPEN for everybody.
>>
>> you chose it years ago, because of those facts. of course linux is very popular on
>> embedded systems. i am working within some open source projects that also run
>> on embedded hardware designs.
>>
>> your main mistake in understanding linux and our way to have it also more open in
>> future than by now.
>>
>> what actually costs you more in future?
>> opening your drivers, as much it must be, to have your hardware supported under 2.6
>> _or_
>> paying license fees for runtime/development tools for vxworks, ose whatever?
>
>
> marcel,
>
> most of the vendors, who claim IP just cite nonsense. There are really
> hardly a few vendors who are really bound to the IP issue. Just that
> they do not know how to write proper code, they do not want to open up
> their code.
>
> In fact , such vendors do have a think probably like this "if we open
> up our driver if people see the pathetic quality, the customers would
> probably think how bad is the hardware and probably affect our sales"
> . So it would be better if we hide under the shade of the IP umbrella.
>
> Little do that these vendors know that customers wouldn't want to go
> alongwith such narrow minded vendors in the long run. But somehow due
> to a certain void people do the get along, that's it, not for long
> though.
>
> regards,
> manu
> -

There are a lot of device drivers that will never make it into the
mainline kernel because they are for one-of-a-kind devices or boards
that companies embed into their products. Nobody would even want a
copy of the software to interface with something that they would
never even have. When Version 2.6 started, it became necessary to
use special tools and procedures to compile a module that was not
inside the mainline kernel. However, it was still quite easy. Recently,
somebody, apparently with an advanced degree in obfuscation, has made
that more difficult. This is abuse, pure and simple. That, in my
opinion, is one of the major reasons why people who use Linux in
embedded systems end up using very old versions.

There are, however, still ways to work around this obfuscation.
One can write a simple program or script that parses the .config
variables and creates a header file. One can also use the correct
(changing) search paths for the necessary included header files.
This, of course, is a pain in the butt, but it works and provides 
correctly-working modules. The kernel obfuscator's time would be
better spent making kernel use easier, but what do I know.
I don't think of GPL as a religion, only as an experiment
that has run amok.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.61 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: GPL vs non-GPL device drivers

[Manu Abraham]

On 2/15/07, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:

> I don't think of GPL as a religion, only as an experiment
> that has run amok.
>

The point of GPL, is that even if the vendor stopped supporting, you
could fix the device driver by yourself. This is really happening,
vendors do sell hardware with broken drivers and make the suers cry
out loudly. At the mercy of the vendor. (This has happened and is
still happening)

This is exactly the whole point about GPL. If you think otherwise, you
are just one of the vendors trying to force your hopeless driver to
clueless users.

So, IMO when someone says binary only modules are the way, i wouldn't
bite the line. I don't think this is a religion, but a freedom to use
what you want.

HTH,
manu

Re: GPL vs non-GPL device drivers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

On Thu, 15 Feb 2007 09:32:30 EST, "linux-os (Dick Johnson)" said:
> There are a lot of device drivers that will never make it into the
> mainline kernel because they are for one-of-a-kind devices or boards
> that companies embed into their products. Nobody would even want a
> copy of the software to interface with something that they would
> never even have. When Version 2.6 started, it became necessary to
> use special tools and procedures to compile a module that was not
> inside the mainline kernel. However, it was still quite easy. Recently,
> somebody, apparently with an advanced degree in obfuscation, has made
> that more difficult. This is abuse, pure and simple. That, in my
> opinion, is one of the major reasons why people who use Linux in
> embedded systems end up using very old versions.

Actually, the *real* reason embedded systems end up using old versions is
much simpler.

They start developing their code on release 2.X.Y, and they keep their code
out-of-tree.  Then, when they come up for air, and it's at 2.X.(Y+15), they
discover that we weren't kidding when we shipped stable_api_nonsense.txt,
and since their code isn't in the tree, they have to do all the API cleanup
themselves, because no flock of nit-picking kernel janitor monkeys swarmed
over their code and magically fixed it up for them.

And unless Y+15 has some *very* compelling reasons to move forward, just
sticking at Y suddenly starts looking very good, because watching somebody
else's kernel janitor monkeys fix your code is fairly cheap, but paying your
own kernel janitor monkeys gets expensive really fast....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: GPL vs non-GPL device drivers

[Bernd Petrovitsch]

On Fri, 2007-02-16 at 03:19 -0500, Valdis.Kletnieks@vt.edu wrote:
[...]
> Actually, the *real* reason embedded systems end up using old versions is
> much simpler.

ACK.

> They start developing their code on release 2.X.Y, and they keep their code
> out-of-tree.  Then, when they come up for air, and it's at 2.X.(Y+15), they
> discover that we weren't kidding when we shipped stable_api_nonsense.txt,
> and since their code isn't in the tree, they have to do all the API cleanup
> themselves, because no flock of nit-picking kernel janitor monkeys swarmed
> over their code and magically fixed it up for them.

Actually it is questionable for product development in a commercial
environment (especially in the embedded world where you usually have a
quite defined hardware and software on your device) if one actually
wants that - think of the "if it's not broken, don't fix it" reason.

> And unless Y+15 has some *very* compelling reasons to move forward, just
> sticking at Y suddenly starts looking very good, because watching somebody
> else's kernel janitor monkeys fix your code is fairly cheap, but paying your
> own kernel janitor monkeys gets expensive really fast....

It depends on the *very* compelling reason if it is easier/cheaper to
a) fix the problem in the "old" kernel,
b) backport something or
c) forward port the own drivers/changes.
And that decision depends on lots of factors (and company-internal
bureaucracy with the QA department may not be the least important).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: GPL vs non-GPL device drivers

[Chris Friesen]

Valdis.Kletnieks@vt.edu wrote:

> Actually, the *real* reason embedded systems end up using old versions is
> much simpler.
> 
> They start developing their code on release 2.X.Y, and they keep their code
> out-of-tree.  Then, when they come up for air, and it's at 2.X.(Y+15), they
> discover that we weren't kidding when we shipped stable_api_nonsense.txt,
> and since their code isn't in the tree, they have to do all the API cleanup
> themselves, because no flock of nit-picking kernel janitor monkeys swarmed
> over their code and magically fixed it up for them.

That's one reason.  Another reason is that maybe the embedded system 
code is doing stuff that's so special purpose that it doesn't make 
*sense* for it to go into mainline.  We've done stuff like this.  We've 
also done stuff where we tried to get it into mainline but the 
maintainers didn't want it.

Yet another reason is that we need to pick a release and stay on it, 
because we need to get our four hardware vendors and three software 
vendors to all agree that they will support that particular release.

I would *love* to track the mainline kernel.  However, it simply can't 
be done when you're using hardware that isn't supported yet by mainline 
and you're relying on the vendor to provide a patch to make the kernel 
even boot.

Chris

Re: GPL vs non-GPL device drivers

[Scott Preece]

On 2/16/07, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 15 Feb 2007 09:32:30 EST, "linux-os (Dick Johnson)" said:
>
>
> Actually, the *real* reason embedded systems end up using old versions is
> much simpler.
>
> They start developing their code on release 2.X.Y, and they keep their code
> out-of-tree.  Then, when they come up for air, and it's at 2.X.(Y+15), they
> discover that we weren't kidding when we shipped stable_api_nonsense.txt,
> and since their code isn't in the tree, they have to do all the API cleanup
> themselves, because no flock of nit-picking kernel janitor monkeys swarmed
> over their code and magically fixed it up for them.
>
> And unless Y+15 has some *very* compelling reasons to move forward, just
> sticking at Y suddenly starts looking very good, because watching somebody
> else's kernel janitor monkeys fix your code is fairly cheap, but paying your
> own kernel janitor monkeys gets expensive really fast....
---

No, that misses the core reason why embedded companies ship antigue
kernels: because they [we] have a much stiffer concept of "stable"
than the Linux community does. We typically freeze components (meaning
accepting only critical defect fixes) many months before product ship,
because they need several layers of field testing before shipping. We
then try to maximize ROI for that frozen version by reusing it (and
the things we build on it) in successor products. We do that for
years.

Yes, it's extremely painful when we decide to upmerge to a later
release. So, we wait until the later version is an unavoidable choice,
in the meantime downmerging specific patches that we want.

scott

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

I sympathize with you, VJ, I really do, but you're going to have to do
a lot more homework in order to understand what is happening to Linux
in embedded space.  Allow me to supply some worthless, non-lawyer,
non-measurable-kernel-contributor observations, which are at least
quite different from those of most people who will bother to respond
in this thread.  Let's start with: Don't believe everything you read
on the Internet.  That goes double for press releases and public
mailing lists.

On 2/14/07, v j <vj.linux@gmail.com> wrote:
> This is in reference to the following thread:
>
> http://lkml.org/lkml/2006/12/14/63
>
> I am not sure if this is ever addressed in LKML, but linux is _very_
> popular in the embedded space. We (an embedded vendor) chose Linux 3
> years back because of its lack of royalty model, robustness and
> availability of infinite number of open-source tools.

That's not why you chose Linux.  You chose Linux because it made your
lives easy in the short term and you didn't know or care what the
long-term consequences would be.  You didn't have to interact with any
human beings, cut any deals, make any business case, obtain any
executive approvals, sign any contracts, or forecast any per-seat,
per-unit, or per-incident costs.  You did have to put work into making
it work for you, but you chalked your salaries up to "investment" in
an "IP asset".  Now you're finding out that the difference between a
sunk cost and an asset is that an asset produces a revenue stream, and
that few of the people who actually work on the mainline Linux kernel
care whether or not your investment in building things with Linux
inside will continue to produce revenues.  Live and learn.

> We recently decided to move to Linux 2.6 for our next product, mainly
> because Linux has worked so well for us in the past, and we would like
> to move up to keep up with the latest and greatest.

Don't kid a kidder.  2.6 was the latest and greatest three years ago.
Now it's the only game in town if you want anyone to talk to you
without a cash retainer up front.  Mind you, 2.4 still runs great on
anything it ran great on back then; but nowadays the sort of
application coders who work cheap are dead in the water without the
(relatively) inexpensive threads of NPTL/TLS.  Even the most un-hip
and non-showing-up-at-the-table of chip vendors realize that their
price/performance slides will look better under 2.6 unless they are
really, really memory constrained.  Sticking to 2.4 would require a
business case for carrying your own maintenance weight, and we've
already established that proactive analysis of business cases is not
your enterprise's strong point.

> However in moving to  2.6, we noticed a number of alarming things.
> Porting drivers over from devfs to udev, though easy raised a number
> of alarming issues. Driver's no longer could dynamically allocate
> their MAJOR/MINOR numbers. Doing so would mean they would have to use
> sysfs. However it seems that sysfs (and the class_ interface) is only
> available to GPL modules. This is very concerning. The drivers which
> we have written over the last three years are suddenly under threat.
> We don't mind statically assigning MAJOR/MINOR numbers to our drivers.
> We can do this and modify our user space applications too.

Given all the technical and cultural changes in the Linux ecosystem
since you last checked in, it's kinda funny you picked on device
numbering.  Do you really expect your customers to combine your
drivers with someone else's closed-source special sauce that happens
to pick the same major number?  Or if you're concerned about sharing a
major with other devices in the same conceptual class, do you really
think there's a legal risk in using a standardized, published,
arm's-length interface to interchangeable drivers, no matter what the
symbols are labeled?  Ask your lawyer to interpret Lotus v. Borland
and Lexmark v. Static Control for you, and to show you parallels to
the law in other markets that are relevant to you.  Then ask yourself
whether you really want to be calling EXPORT_SYMBOL_MOVING_TARGET
entrypoints from your out-of-tree drivers anyway.

> However we have a worrying trend here. If at some point it becomes
> illegal to load our modules into the linux kernel, then it is
> unacceptable to us. We would have been better off choosing VxWorks or
> OSE 3 years ago when we made an OS choice. The fact that Linux is
> becoming more and more closed is very very alarming.

Illegal, shmillegal.  What's it's becoming is pointless, because all
the kernel "features" that matter in a modern embedded system (bounded
preemption latency, effective power management, reliable I/O
peristalsis with predictable system impact) can't be localized to
"core code".  I can tell you from experience that they're next to
impossible to achieve when there's a big opaque lump of binary driver
stuck in the platform integrator's craw.  Fans of EXPORT_SYMBOL_GPL
may be perversely motivated, but they're telling you in advance what
any customer worth having will tell you next year: if you're trying to
sell components into the embedded market, closed drivers are more
trouble than they're worth.

Back on the topic of crusaders:  There's a tried-and-true way to get
people to care about your revenue stream: cut them in on it, in a
currency they find valuable.  This isn't a moral issue, except in the
sense that all ethics is economics and vice versa.  There are,
however, some people involved in Linux kernel development who try to
make a moral issue out of it and claim not to be willing to cut deals
in mere dollars.  (Maybe you just couldn't pay them enough to put up
with whinging about erratic system behavior when you've invited a bull
into the ring 0 china shop.)  A few of these are such valued
contributors that Linus lets them get away with silliness like
EXPORT_SYMBOL_GPL, and that chums the water for the bigger sharks at
the SFLC.

So you've put yourselves in harm's way, to the extent that you have
become dependent on the ignorance, indifference, or goodwill of people
you've never met, who derive no value from the continued viability of
your business.  Notwithstanding the vitriol poured out in this thread,
there's actually more goodwill to go around than you might think; but
to make use of it you'll have to put on your asbestos skivvies and
show up to the table.  Whether that's worth doing is a business issue
about which I can't advise you, since I'm no more a psychic than a
lawyer.

Legal niceties are not, however, what's actually going to bite you --
unless you do something really stupid like Fortinet did (dissemble
about the presence of Linux inside the box, which is probably what
induced a Munich judge to overlook Harald Welte's dubious claim to
"authorship" in a copyright sense).  That kind of stunt could easily
lead to criminal charges under 17 USC 506, and more to the point, it
makes you look terminally dim as well as dishonest -- not good viral
marketing.  Also totally unnecessary if you just come clean about any
changes to GPL code you make and distribute -- although "derivative
work" is not really the right term for this, it's clearly something
you don't have the legal authority to do without accepting the offer
of contract in the GPL.  But I'll come back to that.

In all probability, what's going to eat your revenue stream hollow is
not pseudo-legal sniping from the cheap seats but the predictable
converse of the very virtues you cited:
    because those infinitely available free-as-in-speech tools are
also free-as-in-beer, you've taken them for granted and barely learned
how to use them or even tested whether the sharper ones work on your
platform;
    Linux is robust except when it's not, for instance when the
underlying hardware has subtle bugs that trigger in wonderful new ways
as code and toolchains evolve; and
    that enticing royalty-free model means that no one owes you a damn
thing in return, and there's no paymaster around to curb certain
people's congenital hostility to freeloaders and suits generally.

Ever noticed that the only thing worse than a salesman who's on
commission is a salesman who isn't on commission?  That goes double
for kernel hackers.  It's hard to find one who's genuinely competent,
not just at refining his subsystem but at pushing a Linux-dependent
product up the steep part of the quality curve.  It's even harder to
outbid Nokia and Google for him and then get him to work on your
actual priorities beyond the initial, fun phase.  And even then, he
doesn't control the evolution of the Linux mainline, unless his name
is Linus Torvalds.  So you had better hope he's also a master
strategist when it comes to "stabilization" (forking by any other
name) for embedded applications, which is playing with fire but
unavoidable in the Brave New World of 2.6.x.y.

Now, I have already glossed a dozen points here in terms different
from the other flamers', and will doubtless be torn to pieces by those
who don't choose to ignore me entirely.  Yet one gloss of a legal
nature is worth emphasizing anyway (but remember, I don't even play a
lawyer on TV.)  The aside about Linus is not entirely a jest; he does,
in fact, control the evolution of the Linux mainline and is the only
candidate for "authorship" in a copyright sense, to the extent that
"the Linux kernel" is a well-defined work of authorship.  Aalmuhammed
v. Lee is good law and has analogues in other important jurisdictions,
notwithstanding Harald Welte's efforts to establish independent
copyright in netfilter and initrd.  Google "Linus Torvalds estoppel"
(omit quotes) for some of the reasons why this matters, even if Linus
chooses to downplay the legal significance of his unique role.

However, getting a correct judgment in a court of fact is always a
crapshoot, and I suppose it's conceivable that a judge would buy the
"GPL is a dark continent" story long enough to issue a preliminary
injunction.  Judge Saris wasn't fooled (she gave Eben Moglen's
affidavit the brush-off that it deserved and dismissed MySQL's GPL
claim according to routine contract law standards), but the judge
_you_ get might have different sympathies, especially if your
established pattern of behavior makes look like a conniving greedhead
or a freeloading scriptmonkey.  Even so, odds are that it'll get fixed
on appeal if you bother; but in the meantime there's a new batch of
disingenuous chest-pounding press releases from the usual suspects
with your name filled in the blank.  Again, not good viral marketing.

What's the bottom line?  Free the software!  It's not the law, it's
just a good idea.  Assuming, of course, that:
    you are selling your hardware at a positive gross margin, and can
therefore afford for it to become more popular among end users (sadly,
this does not go without saying);
    the information content of your software does not totally reveal
your hardware's internals, or at least does not make them so
blindingly obvious that it is cheaper for cloners in poor countries to
reengineer it than to make a backdoor deal with your own contract
manufacturers;
    there is not an authentic, bona fide Prince of Heck from a
regulatory agency warning you not to make it too easy for hobbyists to
Pump Up The (RF) Volume;
    there have been at least two reorgs since the decision was made to
"invest" in an "IP asset", so the bodies are decently buried and you
can unload your albatross without getting fired by an embarrassed
suit; and
    you, personally, can plausibly claim that the code was even worse
before it entered your hands, just in case it comes back to haunt you
in a future job interview.

HTH, HAND, Cheers,
- Michael

Re: GPL vs non-GPL device drivers

[Ihar `Philips` Filipau]

> Our source code is meaningless to the Open
> Source community at large. It is only useful to our tiny set
> of competitors that have nothing to do with Linux. The Embedded
> space is very specific. We are only _using_ Linux. Just as we
> could have used VxWorks or OSE. Using our source code would
> not benefit anybody but our competitors.

What a load of B.S. I'm working with embedded Linux for five years and
hear that shit more or less every day. Is it mantra for happiness here
or what?

That's TOTALLY wrong. You basically are saying that your main
competitors are your own customers. People do with stuff absolutely
unpredictable things creators often even cannot think about. And then
they become your /competitors/. That what is called "innovation".

Linux precisely thriving, since it gave power back to consumers - and
allowed them to use things they have bought to their fullest. Few
people can clearly state what they need - and Linux allow them (w/o
thinking hard formulating on bug report to you - and sparing your time
on guessing what user really wants) to take it and adopt it to their
own needs. I have customers who did absolutely crazy things with
embedded systems - putting to better use those few resources original
system had left redundant. (Just recall LinkSys' WRT54G - and it is
just but one of the examples. In corporate world it is also happening
all the time - just let customers in.)

Also, to the question of "not benefit anybody". I have seen piles of
rare/obscure hardware which is rare/obscure precisely because there
are no drivers for it. And guess how hardware/OS selection works:
primary question is availability of ready drivers and/or effort it
would take to adopt existing drivers. This is vital part of embedded
system costs: engineering costs. Your vendor had driven itself into
lock-in: you have unique drivers for unique piece hardware and costs
cannot be cut because hardware doesn't become commodity. And it can't
become commodity (nor can be standardized) due to lack of open
drivers.  ".. and I've seen it before, .. and I'll see it again" (c)
Propellerheads.

-- 
Don't walk behind me, I may not lead.
Don't walk in front of me, I may not follow.
Just walk beside me and be my friend.
    -- Albert Camus (attributed to)

Re: GPL vs non-GPL device drivers

[Bodo Eggert]

v j <vj.linux@gmail.com> wrote:
> On 2/14/07, Arjan van de Ven <arjan@infradead.org> wrote:
>> On Wed, 2007-02-14 at 21:16 -0800, v j wrote:

>> > This is in reference to the following thread:
>> >
>> > http://lkml.org/lkml/2006/12/14/63
>> >
>> > I am not sure if this is ever addressed in LKML, but linux is _very_
>> > popular in the embedded space. We (an embedded vendor) chose Linux 3
>> > years back because of its lack of royalty model, robustness and
>> > availability of infinite number of open-source tools.

>> I think you have a bit of a misunderstanding... Linux is not royalty
>> free. Just the royalty is not in the form of cash, but in the form of
>> having to give your improvements back to the open source world.
> 
> Sure. But this is not legally binding.

Gee, you have the choice: Be bound, or be using something different because
you opted not to accept the license that would allow you to use linux.
If you use linux and say "I don't accept the license", it's like stepping
into a train saying "I don't want to make a contract, so I don't have to pay".
-- 
Funny quotes:
14. Eagles may soar, but weasels don't get sucked into jet engines.

Friß, Spammer: Xm@ajON9ja.7eggert.dyndns.org yz@fN.7eggert.dyndns.org

Re: GPL vs non-GPL device drivers

[Bodo Eggert]

v j <vj.linux@gmail.com> wrote:

> So far I have heard nothing but, "if you don't contribute, screw you."

That's exactly what you tell to the linux community: If they don't contribute
to your project *FOR*NOTHING*IN*RETURN*, you'll punish them by - stamping
your feet, crying out loud and *paying* for another OS. Off cause you are
serious about your rambling - after all, you're no longer spoon-fed for free -
but nobody fears one more small embedded company stuffing their money in
proprietary OS for developement licenses, an extra developement kit, a
royality per device etc.

> All this is fine. Just say so. Make it black and white. Make it
> perfectly clear what is and isn't legal. If we can't load proprietary
> modules, then so be it. It will help everybody if this is out in the
> clear, instead of resorting to stupid half measures like
> EXPORT_SYMBOL_GPL.

You don't have to worry, because your product is based on linux. (I asume,
because if it weren't, you could replace linux by $whatever right now and
be happy, but obviously you aren't happy.) Therefore the GPL license requires
you to release everything under GPL, including your driver. And since your
driver is GPL-ed, you can use GPL symbols.
-- 
"If you see a bomb technician running, follow him."
-U.S.A.F. Ammo Tech Sgt

Friß, Spammer: 3gv@iz6mtCN.7eggert.dyndns.org

Re: GPL vs non-GPL device drivers

[Robert Hancock]

linux-os (Dick Johnson) wrote:
> There are a lot of device drivers that will never make it into the
> mainline kernel because they are for one-of-a-kind devices or boards
> that companies embed into their products. Nobody would even want a
> copy of the software to interface with something that they would
> never even have. When Version 2.6 started, it became necessary to
> use special tools and procedures to compile a module that was not
> inside the mainline kernel. However, it was still quite easy. Recently,
> somebody, apparently with an advanced degree in obfuscation, has made
> that more difficult. This is abuse, pure and simple. That, in my
> opinion, is one of the major reasons why people who use Linux in
> embedded systems end up using very old versions.

What are you talking about? There's nothing wrong with external module 
compilation in current kernels. You need about a 5-line makefile that 
calls the kernel build system, and it works fine.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: GPL vs non-GPL device drivers

[linux-os (Dick Johnson)]

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]


On Thu, 15 Feb 2007, Robert Hancock wrote:

> linux-os (Dick Johnson) wrote:
>> There are a lot of device drivers that will never make it into the
>> mainline kernel because they are for one-of-a-kind devices or boards
>> that companies embed into their products. Nobody would even want a
>> copy of the software to interface with something that they would
>> never even have. When Version 2.6 started, it became necessary to
>> use special tools and procedures to compile a module that was not
>> inside the mainline kernel. However, it was still quite easy. Recently,
>> somebody, apparently with an advanced degree in obfuscation, has made
>> that more difficult. This is abuse, pure and simple. That, in my
>> opinion, is one of the major reasons why people who use Linux in
>> embedded systems end up using very old versions.
>
> What are you talking about? There's nothing wrong with external module
> compilation in current kernels. You need about a 5-line makefile that
> calls the kernel build system, and it works fine.
>
> -- 
> Robert Hancock      Saskatoon, SK, Canada
> To email, remove "nospam" from hancockr@nospamshaw.ca
> Home Page: http://www.roberthancock.com/

Have you tried it recently? Attached is a compressed session
showing 2.6.16.24 compiling fine. Then the same thing is attempted
with 2.6.19. It fails with some "improper configuration" errors.
This script shows that I execute the demanded commands
as 'make oldconfig' and 'make prepare'. Then I try to compile
again resulting, again with the exact same errors.
This was reported on the Linux kernel list and somebody stated,
with much authority BTW, "we don't support out of tree
drivers anymore."

I took that as a clue to create an environment where I don't give
a damn what the obfuscators do anymore. I made some tools that
will allow me to compile my modules. Of course that doesn't fix
the fact that the names and calling parameters of many macros keep
getting changed. I've fixed that by making my own replacements.

>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5594.84 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04


****************************************************************
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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

[-- Attachment #2: typescript.gz --]
[-- Type: APPLICATION/x-gzip, Size: 42311 bytes --]

Re: GPL vs non-GPL device drivers

[Robert Hancock]

linux-os (Dick Johnson) wrote:
> Have you tried it recently? Attached is a compressed session

Yes, I have, most recently in 2.6.20. It works fine.

> showing 2.6.16.24 compiling fine. Then the same thing is attempted
> with 2.6.19. It fails with some "improper configuration" errors.
> This script shows that I execute the demanded commands
> as 'make oldconfig' and 'make prepare'. Then I try to compile
> again resulting, again with the exact same errors.
> This was reported on the Linux kernel list and somebody stated,
> with much authority BTW, "we don't support out of tree
> drivers anymore."

Who told you that? There's documentation in the kernel tree in 
Documentation/kbuild/modules.txt that describes how to set this up properly.

Looking at your output, without knowing what the makefile contents are, 
it's impossible to determine what's going wrong. Likely the makefile is 
trying to do things that the kernel build system should be doing. For a 
simple module called mymodule with files file1.c, file2.c, file3.c you 
need only a makefile like this:

ifneq ($(KERNELRELEASE),)

# kbuild part of makefile
obj-m  := mymodule.o
mymodule-y := file1.o file2.o file3.o

else

# Normal Makefile
KERNELDIR := /lib/modules/`uname -r`/build
all::
         $(MAKE) -C $(KERNELDIR) M=`pwd` $@

endif

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: GPL vs non-GPL device drivers

[devzero]

Linux and OpenSource is evolution - go on and create your closed source drivers and do your own closed-source fork - go on and create your own little homo neanderthalensis !
_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192