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
On Maw, 2003-05-06 at 17:42, Jamie Lokier wrote:
> 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 Cox wrote:
> On Maw, 2003-05-06 at 17:42, Jamie Lokier wrote:
> > 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
Jamie Lokier <[email protected]> writes:
> 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.
> 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
Jamie Lokier a ?crit :
> 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
> 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.
> 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
Hi!
> 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?]
Eric W. Biederman wrote:
> > 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.
> > 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
Pavel Machek wrote:
> 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 pervert :) mention the idea on
this list.
-- Jamie
> 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
On Maw, 2003-05-06 at 23:18, Jamie Lokier wrote:
> 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)
Alan Cox wrote:
> > 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.
> > 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.
> For myself I'd be willing to discuss relicensing code in some cases but
> there is little that has a single author.
Thanks.
-- Jamie
On Maw, 2003-05-06 at 23:31, Jamie Lokier wrote:
> 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.
Alan Cox wrote:
> On Maw, 2003-05-06 at 23:18, Jamie Lokier wrote:
> > 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.
> 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.
> 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
In article <[email protected]>,
Jamie Lokier <[email protected]> wrote:
: 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 :)
--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - [email protected]
Winnipeg, Manitoba, Canada -- http://nicoya.feline.pp.se/
Jamie Lokier <[email protected]> writes:
> Eric W. Biederman wrote:
> > > 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.
(c) Modify the drivers to fit into your kernel. (See below).
As far as I know this is the only long term stable approach.
> 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.)
There is no stable Linux kernel API for drivers. There is a software
interface but it is continually morphing, changing becoming different
and hopefully better.
The only practical solution I know of (short of porting Linux to run
on top of your kernel), is to use the Linux code as a base as a starting
point and derive your own drivers. Everyone who attempts to just
reuse the Linux drivers gets stuck with a snapshot of the kernel
at the time they did the work. Later kernels always wind up unsupported.
The successful example I know of is etherboot. Where many of it's drivers
are derived from Linux but it is an entirely different source base. So
etherboot and Linux evolve at different rates.
Beyond that the whole closed thing is a turn-off. Which is likely to
reduce interest in your research OS and get you no free feedback on
the weird situations.
Eric
On Maw, 2003-05-06 at 23:48, Jamie Lokier wrote:
> I'd get to define "the OS" so that is not a problem :) You could
The GPL is smarter than that
"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."
On Wed, 07 May 2003 02:21:25 MDT, Eric W. Biederman said:
> Beyond that the whole closed thing is a turn-off. Which is likely to
> reduce interest in your research OS and get you no free feedback on
> the weird situations.
The target kernel doesn't actually *have* to be closed. What if the
kernel running the Linux driver was some open-but-incompatible licence?
I'll just pause to point out that the single most successful TCP stack
has to be the BSD one - which started off as DARPA-funded research, and got
lots of feedback in spite of its license.
Alan Cox wrote:
> On Maw, 2003-05-06 at 23:48, Jamie Lokier wrote:
> > I'd get to define "the OS" so that is not a problem :) You could
>
> The GPL is smarter than that
> "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."
I am talking about replacing the kernel (and compiler as it
happens)... those _are_ the major components of the operating system
which fall under that exception. So, if we were splitting hairs over
the wording, it would come down to whether the other major components
"accompany the executable", where the executable is the GPL module.
This is further complicated because those GPL modules need not be
distributed in binary form anyway, they could be compiled at run time
from source, so there is no executable to speak of. More corner case
fun :)
Morally, as someone pointed it it comes down to how much giving back
is done, and how the authors of the code in question feel. Of course
one person's belief that something constitutes giving is not the same
as another's.
-- Jamie
[email protected] wrote:
> On Wed, 07 May 2003 02:21:25 MDT, Eric W. Biederman said:
>
> > Beyond that the whole closed thing is a turn-off. Which is likely to
> > reduce interest in your research OS and get you no free feedback on
> > the weird situations.
>
> The target kernel doesn't actually *have* to be closed. What if the
> kernel running the Linux driver was some open-but-incompatible licence?
Regarding Eric's point, I think it comes down to what captures the
imagination of potential users. Even a GPL'd project is not likely to
get much interest if it doesn't offer anything worth using.
Conversely, see BeOS for something which was not ultimately a
commercial success, but which captured the imagination of a lot of
people despite being closed source.
> I'll just pause to point out that the single most successful TCP stack
> has to be the BSD one - which started off as DARPA-funded research, and got
> lots of feedback in spite of its license.
I disagree. Many of the most successful TCP stacks _forked_ from the
BSD one at some time or other (e.g. SunOS, Microsoft), but then they
evolved in their own directions, with their unique quirks.
-- Jamie
Hi!
> > > I'd get to define "the OS" so that is not a problem :) You could
> >
> > The GPL is smarter than that
> > "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."
>
> I am talking about replacing the kernel (and compiler as it
> happens)... those _are_ the major components of the operating system
> which fall under that exception. So, if we were splitting hairs over
> the wording, it would come down to whether the other major components
> "accompany the executable", where the executable is the GPL module.
>
> This is further complicated because those GPL modules need not be
> distributed in binary form anyway, they could be compiled at run time
> from source, so there is no executable to speak of. More corner case
> fun :)
If you are compiling them from source, and interface between the
module and the kernel is well defined (== "userspace") I guess you are
okay.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Jamie Lokier <[email protected]> writes:
> [email protected] wrote:
> > I'll just pause to point out that the single most successful TCP stack
> > has to be the BSD one - which started off as DARPA-funded research, and got
> > lots of feedback in spite of its license.
>
> I disagree. Many of the most successful TCP stacks _forked_ from the
> BSD one at some time or other (e.g. SunOS, Microsoft), but then they
> evolved in their own directions, with their unique quirks.
And that ultimate fate and people shutting up has created a number of
advocates for the GPL. And at the very least people will now insist
on getting the source and the writes to modify and share their modifications
of the source. To some extent this is behind the large national labs
wanting Linux on their supercomputers.
Eric
"Riley Williams" <[email protected]> writes:
> Hi Eric.
>
> >> I disagree. Many of the most successful TCP stacks _forked_ from the
> >> BSD one at some time or other (e.g. SunOS, Microsoft), but then they
> >> evolved in their own directions, with their unique quirks.
>
> > And that ultimate fate and people shutting up has created a number of
> > advocates for the GPL. And at the very least people will now insist
> > on getting the source and the writes to modify and share their
> > modifications of the source. To some extent this is behind the large
> > national labs wanting Linux on their supercomputers.
>
> Do you have any web pointers relating to this issue or those advocates?
That enumerates these issues no. From a practical standpoint
on systems built or proposed, I can here are a couple.
>From Lawrence Livermore National Labs see MCR:
http://www.llnl.gov/linux/mcr
Position #5 on the top500 list
http://top500.org/list/2002/11/
see the ASCI Purple RFP:
http://www.llnl.gov/asci/purple/
>From Los Alamos National Labs see Pink:
http://www.lanl.gov/projects/pink/
Eric
Jamie Lokier <[email protected]> writes:
> 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?
IANAL, but Linux drivers are usually licensed under the GPL and not LGPL.
>
> I realise that linking the modules directly with the binary kernel is
> a big no no, but what if they are dynamically loaded?
You mean one big file versus many small fragments? I don't think there
is a difference. LGPL would permit that (in fact, it seems to be the
difference between GPL and LGPL).
> 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.
That's different, the modules are not (generally) derivatives of the
kernel. The (running) kernel is a derivative of both the GPL code and
binary drivers (all parts are linked at run time) - and while you can't
distribute such a beast at all, you usually don't want to.
(which makes me wonder if "distributing" a running machine with binary
drivers linked to the kernel is legal :-) )
> 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.
IMHO it's independent problem, not related to the license, but rather
to source code symbol names (a technical and not legal issue - something
like copy-protection mechanisms).
> 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.
Build - sure. However, distributing such a system (with GPLed parts)
would be illegal, unless the GPLed code is not a part of the system,
and rather an "independent and separate work" (i.e. the system does not
"depend" on GPL part).
--
Krzysztof Halasa
Network Administrator
Hi!
> > > 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
If you took vicam driver and made it ran under Windows XP, it would be
okay. (It uses defined interface after all). I do not see why vicam
driver under "your own os" would be different.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Jamie Lokier wrote :
>
> 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?
This is the position of Donald Becker :
http://www.scyld.com/expert/modules.html#legal
I would personally ask you to respect the wishes of Don with
respect to all drivers containing his code, just to respect the vast
contribution he made to the Linux community.
My position is similar. If the author wants to make a driver
available to non-GPL kernel, he can always dual license it. In fact,
you will find that many external Linux drivers are available under
dual licences (GPL/MPL, GPL/BSD or GPL/proprietary). For example most
drivers from David Hinds (Pcmcia) are GPL/MPL.
Have fun...
Jean
>Jamie Lokier wrote :
>>
>> 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?
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