Using GPL'd Linux drivers with non-GPL, binary-only kernel

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Jamie Lokie » Wed, 07 May 2003 18:50:14



I was mulling over a commercial project proposal, and this question
came up:

What's the position of kernel developers towards using the GPL'd Linux
kernel modules - that is, device drivers, network stack, filesystems
etc. - with a binary-only, closed source kernel that is written
independently of Linux?

I realise that linking the modules directly with the binary kernel is
a big no no, but what if they are dynamically loaded?

There seems to be a broad agreement, and I realise it isn't unanimous,
that dynamically loading binary-only modules into the Linux kernel is
ok.  Furthermore, there are some funny rules about which interfaces a
binary-only module may use and which it may not, before it's
considered a derivative work of the kernel.

So, as dynamic loading is ok between parts of Linux and binary-only
code, that seems to imply we could build a totally different kind of
binary-only kernel which was able to make use of all the Linux kernel
modules.  We could even modularise parts of the kernel which aren't
modular now, so that we could take advantage of even more parts of Linux.

What do you think?

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Alan Co » Wed, 07 May 2003 20:40:17



Quote:> So, as dynamic loading is ok between parts of Linux and binary-only
> code, that seems to imply we could build a totally different kind of
> binary-only kernel which was able to make use of all the Linux kernel
> modules.  We could even modularise parts of the kernel which aren't
> modular now, so that we could take advantage of even more parts of Linux.

You want a legal list - you really do. Its all about derived works and
thats an area where even some lawyers will only hunt in packs 8)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Jamie Lokie » Wed, 07 May 2003 21:00:20




> > So, as dynamic loading is ok between parts of Linux and binary-only
> > code, that seems to imply we could build a totally different kind of
> > binary-only kernel which was able to make use of all the Linux kernel
> > modules.  We could even modularise parts of the kernel which aren't
> > modular now, so that we could take advantage of even more parts of Linux.

> You want a legal list - you really do. Its all about derived works and
> thats an area where even some lawyers will only hunt in packs 8)

Alan, you're right of course - from a legal standpoint.  But I'm not
interested in how it pans out in a strict legal interpretation.

What I'm interested in is how the kernel developers and driver authors
would treat something like that.  Binary modules haven't had the full
lawyer treatment AFAIK, but a sort of community viewpoint regarding
what is and is not acceptable, to the community, is fairly clear on
this list.

So I was wondering what is the community viewpoint when it's the
core kernel that is a non-GPL binary, rather than the modules.

What if this new-fangled other kernel is open source, but BSD license
instead?  Would that also anger the kernel developers?  (As I suspect
a closed-source binary kernel would, even if one could get away with it).

The reason for this question is: These days, if someone wants to
develop a new operating system that is compatible with the full range
of PC hardware, the starting point is to read all the *BSD and Linux
source code that's relevant.  There's no way you can duplicate 12+
years of testing every known PC hardware quirk.  It just isn't feasible.

(And for that reason, I'd regard the drivers as "something that nobody
should be forced to rewrite", to paraphrase what Linus said about klibc).

Then, you can (a) rewrite everything, using the knowledge you gained
from reading the various open source drivers, or (b) just use those
drivers, and save a lot of effort.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Eric W. Biederm » Wed, 07 May 2003 21:30:19



> So, as dynamic loading is ok between parts of Linux and binary-only
> code, that seems to imply we could build a totally different kind of
> binary-only kernel which was able to make use of all the Linux kernel
> modules.

If you build a kernel to run Linux drivers that seems to scream
derivative work to me.

Quote:>  We could even modularise parts of the kernel which aren't
> modular now, so that we could take advantage of even more parts of Linux.

> What do you think?

At the very best support wise you would fall under the same category
as if you loaded a binary only driver.

On a very practical side you would suffer severe bitrot.  As I have
seen no project that has attempted this being able to keep up with
the kernel API.  Netkit, Mach and MILO are good examples of why not to
do this.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Jean-Marc Lienhe » Wed, 07 May 2003 22:30:26


Jamie Lokier a crit :

Quote:> Then, you can (a) rewrite everything, using the knowledge you gained
> from reading the various open source drivers, or (b) just use those
> drivers, and save a lot of effort.

Where is the problem ?
In the (b) option, the GPL drivers must still be distributed under
the GPL.

(If you like legal issues and if you want to laugh, I have a funny
web page about the GPL. http://www.oksid.ch/license/faq.html )

--
http://www.oksid.ch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Alan Co » Wed, 07 May 2003 23:00:27


Quote:> What if this new-fangled other kernel is open source, but BSD license
> instead?  Would that also anger the kernel developers?  (As I suspect
> a closed-source binary kernel would, even if one could get away with it).

Then the combined result would be a GPL'd product. You can do that now.
Add BSD code to GPL and the result comes out GPL.

Quote:> Then, you can (a) rewrite everything, using the knowledge you gained
> from reading the various open source drivers, or (b) just use those
> drivers, and save a lot of effort.

The GPL says "you can use them if your final new result is GPL", the BSD
world says "Hey go do it, just say thanks". Its probably a lot simpler
to use the FreeBSD code if you don't want a GPL result.

For myself I'd be willing to discuss relicensing code in some cases but
there is little that has a single author.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Pavel Mache » Wed, 07 May 2003 23:00:31


Hi!

Quote:> I was mulling over a commercial project proposal, and this question
> came up:

> What's the position of kernel developers towards using the GPL'd Linux
> kernel modules - that is, device drivers, network stack, filesystems
> etc. - with a binary-only, closed source kernel that is written
> independently of Linux?

> I realise that linking the modules directly with the binary kernel is
> a big no no, but what if they are dynamically loaded?

> There seems to be a broad agreement, and I realise it isn't unanimous,
> that dynamically loading binary-only modules into the Linux kernel is
> ok.  Furthermore, there are some funny rules about which interfaces a
> binary-only module may use and which it may not, before it's
> considered a derivative work of the kernel.

> So, as dynamic loading is ok between parts of Linux and binary-only
> code, that seems to imply we could build a totally different kind of
> binary-only kernel which was able to make use of all the Linux kernel
> modules.  We could even modularise parts of the kernel which aren't
> modular now, so that we could take advantage of even more parts of Linux.

> What do you think?

If you can make those drivers in your userspace, its certainly okay...

                                                                Pavel

--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Jamie Lokie » Thu, 08 May 2003 00:00:18



> > So, as dynamic loading is ok between parts of Linux and binary-only
> > code, that seems to imply we could build a totally different kind of
> > binary-only kernel which was able to make use of all the Linux kernel
> > modules.

> If you build a kernel to run Linux drivers that seems to scream
> derivative work to me.

I'd agree if the sole purpose of the kernel were to run those drivers.
But if it were built for other reasons, such as an experiment in a
different kind of operating system, and it happens to have very good
support for the Linux driver API?  I'd say that's not a derivative
work, even though the interface is clearly designed to support Linux
drivers.  But now we _are_ into the lawyer zone.

Quote:> >  We could even modularise parts of the kernel which aren't
> > modular now, so that we could take advantage of even more parts of Linux.

> > What do you think?

> At the very best support wise you would fall under the same category
> as if you loaded a binary only driver.

> On a very practical side you would suffer severe bitrot.  As I have
> seen no project that has attempted this being able to keep up with
> the kernel API.  Netkit, Mach and MILO are good examples of why not to
> do this.

I do not see any practical alternative way to create a new kind of
operating system kernel that is compatible with the wide range of PC
hardware, other than:

  (a) read lots of open source code and then write drivers,
      filesystems etc. from what is learned, or
  (b) just use the available code with appropriate wrapping.

Both are lots of work.  But isn't (b) going to be less work?  I'm not
sure.

Your mention of Mach leads me to imagine someone saying "don't waste
your energies writing a new kernel, spend them improving Linux!".  But
then I think, how is it conceivable to "improve" Linux into a very
different vision of what an OS kernel can be like?  No, it is
necessary to experiment with radical new things to try the ideas out,
yet it is quite impractical to develop drivers from scratch without
at least _reading_ existing open source code.  And then, maybe it is
easier to build wrappers than to learn and rewrite.

This whole question comes from that, and the question of whether any
radical experiment in kernel design would have to be GPL'd to take
advantage of the Linux driver code, or whether said code would have to
be rewritten.  (The advantage of the latter is that ideas from many
operating systems could be more effectively integrated, though, such
as combining hard drive blacklists from BSD and Linux, etc.)

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Jamie Lokie » Thu, 08 May 2003 00:30:08



> If you can make those drivers in your userspace, its certainly okay...

Agreed.  Now, what is userspace?

If I load a Java class into a Java VM, that class is executing in the
VM's "userspace", even though both the class and VM execute together
in the underlying kernel's userspace.  If I load an Emacs Lisp library
into Emacs, that's ok too in the same way.

I don't want to go over this old argument of where the interface
boundaries are.  That's a very old argument and thoroughly off topic
for this list.

What I want to know is the reasonableness of using Linux drivers,
filesystems and network stack, extracted from the Linux kernel, in
something that is not Linux and not necessarily GPL'd, using a very
clear _virtual_ boundary between the Linux parts and the not GPL'd part.

Running User Mode Linux on HP-UX would be an example which I think is
clearly acceptable.  (Note that User Mode Linux doesn't access devices
directly, but perhaps it could with some changes).

I have in mind a virtual machine which is capable of executing device
drivers written in an appropriate subset of the C language, in which
wrappers for Linux (and BSD) drivers can be written, so the Java and
Emacs VM examples above are quite appropriate.

This seems reasonable to me, although it also seems like quite a
perversion of Linux to fragment it into GPL'd parts atop a non-GPL'd
kernel, which is why I had to (being a * :) mention the idea on
this list.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by David Schwart » Thu, 08 May 2003 00:30:18


Quote:> If you build a kernel to run Linux drivers that seems to scream
> derivative work to me.

        Then WINE is a derivative work of Windows. Then any product designed to use
AA batteries is a derivative work of the AA battery design.

        If you want to say that if you design X to be compatible with Y, then X is
a derivative work of Y, you can do it. But that's not the kind of world I
want to live in.

        It's not the world the GPL talks about:

The "Program", below, refers to any such program or work, and a "work based
on the Program"
means either the Program or any derivative work under copyright law: that is
to say, a work containing the Program or a portion of it, either verbatim or
with modifications and/or translated into another language.

        You would pretty much have to argue that these were derivative works not of
the kernel or of Windows itself, but of the APIs. In other words, Windows is
a derivative work of the Windows API, as is WINE. Linux is a derivative work
of the Linux kernel API, as is any module that uses this API.

        The only problem with this argument is that it results in the type of world
you don't want to live in. You are not suppose to be able to use copyright
to prohibit compatability.

        DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Alan Co » Thu, 08 May 2003 00:40:05



Quote:> If I load a Java class into a Java VM, that class is executing in the
> VM's "userspace", even though both the class and VM execute together
> in the underlying kernel's userspace.  If I load an Emacs Lisp library
> into Emacs, that's ok too in the same way.

Thats not actually clear either. The kernel contains the clear syscall
message for good reasons. The GPL itself talks about stuff that comes
normally with the OS very carefully for similar reasons.

You see there isn't any difference between an interpreter hitting
        Java bytecode 145
and a function call of
        perform_java_bytecode(145);

Indeed the JVM may turn one into the other.

If you think that is bad remember that the DMCA and other rulings have
held shrink wrap licenses can sometimes overrule US style "fair use", so
your JVM in JITting code may be making you liable for a license
violation for some applications.

Corner cases are fun in more than just the computing profession 8)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Jamie Lokie » Thu, 08 May 2003 00:40:08



> > What if this new-fangled other kernel is open source, but BSD license
> > instead?  Would that also anger the kernel developers?  (As I suspect
> > a closed-source binary kernel would, even if one could get away with it).

> Then the combined result would be a GPL'd product. You can do that now.
> Add BSD code to GPL and the result comes out GPL.

I disagree - as Pavel said, "if it's running in your kernel's
userspace", the GPL applies only to the thing running in that
"userspace", not to the whole combined machine.

Quote:> > Then, you can (a) rewrite everything, using the knowledge you gained
> > from reading the various open source drivers, or (b) just use those
> > drivers, and save a lot of effort.

> The GPL says "you can use them if your final new result is GPL", the BSD
> world says "Hey go do it, just say thanks". Its probably a lot simpler
> to use the FreeBSD code if you don't want a GPL result.

I understand the licensing in unambiguous causes, and I'm not trying
to find loopholes in awkward corners.  I'm just observing that, as
closed-source binary modules are de facto accepted (with some funky
rules about which interfaces they can use), the same in reverse
_ought_ to be accepted to the same degree: Linux (and other) GPL'd
modules as satellites around a non-GPL kernel.

Quote:> For myself I'd be willing to discuss relicensing code in some cases but
> there is little that has a single author.

Thanks.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Alan Co » Thu, 08 May 2003 00:40:11



Quote:> I understand the licensing in unambiguous causes, and I'm not trying
> to find loopholes in awkward corners.  I'm just observing that, as
> closed-source binary modules are de facto accepted (with some funky
> rules about which interfaces they can use), the same in reverse
> _ought_ to be accepted to the same degree: Linux (and other) GPL'd
> modules as satellites around a non-GPL kernel.

Actually at least two contributors of note disagree in the general case
about binary modules - except when the legal test holds that they are
not a derivative work. You'll find Linus comments boil down to much that
as well - the EXPORT_SYMBOL stuff is merely guidance.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Jamie Lokie » Thu, 08 May 2003 00:50:11




> > If I load a Java class into a Java VM, that class is executing in the
> > VM's "userspace", even though both the class and VM execute together
> > in the underlying kernel's userspace.  If I load an Emacs Lisp library
> > into Emacs, that's ok too in the same way.

> Thats not actually clear either. The kernel contains the clear syscall
> message for good reasons. The GPL itself talks about stuff that comes
> normally with the OS very carefully for similar reasons.

I'd get to define "the OS" so that is not a problem :) You could
expect an equivalent "clear syscall message", although that is more
problematic to define in an environment where there is no static code
being executed.

Quote:> You see there isn't any difference between an interpreter hitting
>    Java bytecode 145
> and a function call of
>    perform_java_bytecode(145);

> Indeed the JVM may turn one into the other.

There are a few GPL'd Java programs around (I've written a couple
myself), and no complaints about the above transformation so far.

Quote:> If you think that is bad remember that the DMCA and other rulings have
> held shrink wrap licenses can sometimes overrule US style "fair use", so
> your JVM in JITting code may be making you liable for a license
> violation for some applications.

I was going to write:

   I think you've made a big jump in logic there.  I sympathise, as I too
   might have to quit computing if European law follows the US, but I
   don't agree with the big leap you just made.

But then (<shudder>) I realised you are right.  The kind of kernel
which I'm envisioning would be capable of cracking open some kinds of
protected application automatically, as a mere side effect.  (It has
powerful DWIM semantics :) And that would make _something_ illegal to
write - I'm not sure what, though.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using GPL'd Linux drivers with non-GPL, binary-only kernel

Post by Tony 'Nicoya' Mantle » Thu, 08 May 2003 03:20:09




: I do not see any practical alternative way to create a new kind of
: operating system kernel that is compatible with the wide range of PC
: hardware, other than:
:
:   (a) read lots of open source code and then write drivers,
:       filesystems etc. from what is learned, or
:   (b) just use the available code with appropriate wrapping.
:
: Both are lots of work.  But isn't (b) going to be less work?  I'm not
: sure.

If your interest is in creating a new and unique OS, you'll likely find that it
becomes a great deal of work to try to glue the linux drivers into it.

I would imagine in the majority of cases you'd either have to change the driver
code considerably to fit the subtleties of <newos>, or change the <newos> code
considerably to fit the subtleties of linux.

When creating a new system, the last thing you want to have to do is carry
around a bunch of extra baggage that you really don't need.

Anyways, this is 2003, aren't operating systems supposed to be boring by now?
And where's my flying car damnit. ;)

To answer your question more directly, I think most developers would agree that
the spirit of the GPL is "give as you take". If just releasing back the source
to the modified drivers - completely useless without your new closed kernel -
doesn't feel a whole lot like "giving", then you're probably not doing enough to
keep people happy.

Cheers - Tony 'Nicoya' Mantler :)

--

Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Using GPL'd Linux drivers with non-GPL, binary-only kernel

First much kudos goes to Jamies V. modem work which sped up my V.34 devel
quite a lot.

companies who use complex kernel functions are supposed to GPL, it doesn't mean they
do, and lets not tread down that path,lest Andre see me, proprietary modules suck
everybody knows it, they just keep quiet,
dare it desturb them making money.

Linus says in the credits file his position, although such a position is supposed to be taken
from the majority of users and not a few kernel hackers.

Anyway, as im selling a no license version of my software for 13,000 I can hardly complain.

The best opinion on their legality comes from RMS, and although im not a zealot, he did
write the license, Trawl MARC for lawyers, GNU, and RMS and see if you can find it.

Thanks for your help by working on V.

Cheers, Deano.

--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. NFS & Time Synchronization.

3. offtpic: GPL driver vs. non GPL driver

4. keyboard & cde & openwindows

5. kernel hooks interface available to non-GPL modules?

6. RH8 questions

7. Free bar-code scanner for Linux and non-GPL modules are now "tainted" !

8. Problem with RH5 GLIBC and Metrolink Motif 2.01

9. GPL GPL?

10. Funding GPL projects or funding the GPL?

11. Gtk+ is *L*GPL (Was: Qt goes GPL)

12. GPL question: including a GPL program in a software package

13. Gnu GPL problem: License copyrighted things under GPL???