[Qemu-devel] why is kqemu closed?

[Qemu-devel] why is kqemu closed?

[Rakotomandimby Mihamina]

Hi,
I would like to know why is kqemu not GPL?
Would you know?
-- 
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.

Re: [Qemu-devel] why is kqemu closed?

[Hetz Ben Hamo]

Fabrice is the owner of the KQEMU code, and he decides for his own
reasons to put the code under closed source license.

Thanks,
Hetz

On 4/10/06, Rakotomandimby Mihamina
<mihamina.rakotomandimby@etu.univ-orleans.fr> wrote:
> Hi,
> I would like to know why is kqemu not GPL?
> Would you know?
> --
> A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
> Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
> http://www.cps-project.org for downloads & documentation.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


--
Visit my blog (hebrew) for things that (sometimes) matter:
 http://wp.dad-answers.com

Re: [Qemu-devel] why is kqemu closed?

[Auke Kok]

On Mon, 10 Apr 2006 17:20:54 +0200, "Hetz Ben Hamo" <hetzbh@gmail.com> wrote:
> Fabrice is the owner of the KQEMU code, and he decides for his own
> reasons to put the code under closed source license.

I'm sure that Fabrice knows and that I'm beating a dead horse, but this is (strictly speaking, discussions pending ;^)) violating the linux kernel license agreement.

Auke

Re: [Qemu-devel] why is kqemu closed?

[Hetz Ben Hamo]

> I'm sure that Fabrice knows and that I'm beating a dead horse, but this is (strictly speaking, discussions pending ;^)) violating the linux kernel license agreement.

Actually it doesn't, as kqemu is not part of any kernel. it's just
another closed source module as nvidia's module as well as some
others. It his choice to choose whatever he wants to releae it under a
closed source license or any other license.

--
Visit my blog (hebrew) for things that (sometimes) matter:
 http://wp.dad-answers.com

Re: [Qemu-devel] why is kqemu closed?

[Leonardo E. Reiter]

No it's not!  In fact, in the latest version, he explicitly gives it a 
commercial ("Proprietary") license.  He also does not import any 
exported GPL symbols from the kernel.  In fact, if your claim is true, 
then the following very popular products violate the kernel license 
agreement:

VMware Workstation, GSX Server, ESX Server, Server Beta (free)
Parallels Workstation
NVIDIA drivers
Win4Lin 9x (shameless self-promotion, I admit)
Win4Lin Pro (which distributes KQEMU under license from Fabrice)

In fact, KQEMU uses almost no kernel functionality at all.  Allocating, 
freeing, and locking memory into place is not that interesting and is 
not something that Linux does alone - every OS in existence provides 
these services.  On Linux, you are not forced to be a GPL module to use 
them, because, they are simply not that interesting and are mandatory to 
run just about any type of application or driver.  The real meat of 
KQEMU is kernel-independent (the same binary runs on just about any OS, 
unmodified), and deals with the CPU directly.  It would be a crying 
shame if drivers like these would not be allowed in future kernels - 
they use the kernel as simply a loader, not to do anything really 
interesting.

I admit since I am a vendor, I have certain biases against forcing all 
software to be GPL.  However I respect these licenses fully, and also 
respect the author's choice to use whatever license he or she pleases, 
and also to allow exceptions to these licenses.  You might recall Linus 
Torvalds years ago explicitly giving an exception to "binding" when it 
came to loading kernel modules.  It would be hard to convince any vendor 
in the world to develop software for Linux if you were not allowed to 
run non-GPL applications on Linux.  Let's hope that never happens, 
although I understand that the latest sentiments seem to unfortunately 
be leaning that way.  This is not how Linux will beat Windows on the 
desktop, nor on the server!

Regards,

Leo Reiter

Auke Kok wrote:
> 
> On Mon, 10 Apr 2006 17:20:54 +0200, "Hetz Ben Hamo" <hetzbh@gmail.com> wrote:
> 
>>Fabrice is the owner of the KQEMU code, and he decides for his own
>>reasons to put the code under closed source license.
> 
> 
> I'm sure that Fabrice knows and that I'm beating a dead horse, but this is (strictly speaking, discussions pending ;^)) violating the linux kernel license agreement.
> 
> Auke
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Leonardo E. Reiter
Vice President of Product Development, CTO

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

Re: [Qemu-devel] why is kqemu closed?

[Auke Kok]

Leonardo E. Reiter wrote:
> No it's not!  In fact, in the latest version, he explicitly gives it a 
> commercial ("Proprietary") license. 

I actually submitted this as a patch to him through this list ;^)

> I admit since I am a vendor, I have certain biases against forcing all 
> software to be GPL.  However I respect these licenses fully, and also 
> respect the author's choice to use whatever license he or she pleases, 
> and also to allow exceptions to these licenses.  You might recall Linus 
> Torvalds years ago explicitly giving an exception to "binding" when it 
> came to loading kernel modules.  It would be hard to convince any vendor 
> in the world to develop software for Linux if you were not allowed to 
> run non-GPL applications on Linux.  Let's hope that never happens, 
> although I understand that the latest sentiments seem to unfortunately 
> be leaning that way.  This is not how Linux will beat Windows on the 
> desktop, nor on the server!

applications != kernel space code. It would be rather *good* for linux if all 
kernel-space processes were open sourced, even for trivial things like VM 
emulators ;^)

no matter how you turn Linus' arguments, he doesn't like anything else than 
ports from windows driver objects linked, and I can really agree with that. 
Whatever the laywers say about it is moot - only judges listen to them and 
Open Source doesn't listen to laywers (in generally). Plenty of vendors are 
already backing up Open Source too, and not just with t-shirts and penguins.

I do not think that kqemu benefits from being closed source, and probably more 
people with me. People will pick an open implementation before any closed one, 
even industry, they're picking up faster than you think ;^)

I did not agree with kqemu being released without the proprietary flag, which 
is why I submitted the issue, and,if I can help it, it'll be open source or 
surpassed by something that is - no offense.

Cheers,

Auke

Re: [Qemu-devel] why is kqemu closed?

[Brad Campbell]

Auke Kok wrote:

> no matter how you turn Linus' arguments, he doesn't like anything else 
> than ports from windows driver objects linked, and I can really agree 

I think you best re-read anything from Linus on that subject.
What he has said is something derivative of the kernel.

Now we have kqemu for linux, freebsd and windows and its all relatively the same code. If it were a 
derivative of the kernel it would be using  functions within the kernel that were special and/or 
unique. Given it was easily ported to other OS, it's pretty clear it does not use some of the funky 
features of the kernel (VFS comes to mind) and therefore not likely to be a derivative.

Now don't get me wrong, I'd love for the code to be open, but Fabrice has his reasons. It's his code 
and he can choose to license it as he pleases.


> I do not think that kqemu benefits from being closed source, and 
> probably more people with me. People will pick an open implementation 
> before any closed one, even industry, they're picking up faster than you 
> think ;^)

Really? so where are the open implementations of VM technology that work as fast, or are as 
relatively unintrusive as qemu/kqemu?

> I did not agree with kqemu being released without the proprietary flag, 
> which is why I submitted the issue, and,if I can help it, it'll be open 
> source or surpassed by something that is - no offense.

Cool.. as soon as you come up with some open code that does what kqemu does and does it well, I'll 
look at switching. Hell I'll even spend time testing and reporting bugs to you as long as it does 
not take down my kernel. (which kqemu has *never* done)

Take with a grain of salt as usual. And this will be my last post on the subject.
His code, his license.

I'm just grateful I've got it and it works :)

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] why is kqemu closed?

[Jim C. Brown]

On Tue, Apr 11, 2006 at 11:58:07AM +0400, Brad Campbell wrote:
> Auke Kok wrote:
> 
> I think you best re-read anything from Linus on that subject.
> What he has said is something derivative of the kernel.
> 
> Now we have kqemu for linux, freebsd and windows and its all relatively the 
> same code. If it were a derivative of the kernel it would be using  
> functions within the kernel that were special and/or unique. Given it was 
> easily ported to other OS, it's pretty clear it does not use some of the 
> funky features of the kernel (VFS comes to mind) and therefore not likely 
> to be a derivative.

Agreed.

A case can be made that the code for the linux kernel wrapper is a derivataive
of the linux kernel (since that part is linux specific) but IIRC that is under
the BSD license, and it is legal to combine GPL and BSD code and distribute
that, and equally legal to combine BSD and closed source code and distribute
that. Finally it is legal to combine GPL + BSD + closed source code in a
running kernel image, provided that you don't distribute said image to anyone
else. (How many people actually try to do dd if=/dev/kmem of=... anyways?)

So there is no legal problem here.

> 
> Now don't get me wrong, I'd love for the code to be open, but Fabrice has 
> his reasons. It's his code and he can choose to license it as he pleases.
> 

Agreed in full.

If people really wanted a GPL version of kqemu, we'd have more ppl working on
qvm86.

> 
> >I do not think that kqemu benefits from being closed source, and 
> >probably more people with me. People will pick an open implementation 
> >before any closed one, even industry, they're picking up faster than you 
> >think ;^)
> 
> Really? so where are the open implementations of VM technology that work as 
> fast, or are as relatively unintrusive as qemu/kqemu?

I disagree here as well - industry will take the more stable and mature
technology, not necessarily the more open one.

However, unless Fabrice is benefiting by keeping secret some IP of his,
I do agree in that I don't see how keeping kqemu closed source is necessarily
benefiting him. But that is not my business.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] why is kqemu closed?

[Ricardo Almeida]

> I do not think that kqemu benefits from being closed source, and probably more
> people with me.

Probably. But people got make for a living and I think that Fabrice
has every right to decide how to make it available. We all must be
thankfull that he give it away for free...

> People will pick an open implementation before any closed one,
> even industry, they're picking up faster than you think ;^)

Take a look at http://savannah.nongnu.org/projects/qvm86/ and make it
better if you want...

Re: [Qemu-devel] why is kqemu closed?

[Johannes Schindelin]

Hi,

On Mon, 10 Apr 2006, Auke Kok wrote:

> I do not think that kqemu benefits from being closed source, and probably more
> people with me. People will pick an open implementation before any closed one,
> even industry, they're picking up faster than you think ;^)
> 
> I did not agree with kqemu being released without the proprietary flag, which
> is why I submitted the issue, and,if I can help it, it'll be open source or
> surpassed by something that is - no offense.

This is BS. You are basically going into a restaurant and say: "I don't 
think that lovely steak benefits from having a price tag. I do not agree 
with having to pay for this steak, and if I can help it, it'll be for 
free."

Think about it. Fabrice does a wonderful job. Guess who's paying him.

Hth,
Dscho

Re: [Qemu-devel] why is kqemu closed?

[Jamie Lokier]

Johannes Schindelin wrote:
> > I do not think that kqemu benefits from being closed source, and probably more
> > people with me. People will pick an open implementation before any closed one,
> > even industry, they're picking up faster than you think ;^)
> > 
> > I did not agree with kqemu being released without the proprietary flag, which
> > is why I submitted the issue, and,if I can help it, it'll be open source or
> > surpassed by something that is - no offense.
> 
> This is BS. You are basically going into a restaurant and say: "I don't 
> think that lovely steak benefits from having a price tag. I do not agree 
> with having to pay for this steak, and if I can help it, it'll be for 
> free."
> 
> Think about it. Fabrice does a wonderful job. Guess who's paying him.

Besides, there is already an open source equivalent to kqemu, called
kvm86, isn't there?  I'm surprised it doesn't get more attention.

Perhaps that indicates that people _don't_ pick the open
implementation before the closed one, when the author is respected as
much as Fabrice?

-- Jamie

Re: [Qemu-devel] why is kqemu closed?

[Leonardo E. Reiter]

Hi Auke,

First, let me apologize for not giving you proper credit for suggesting 
the MODULE_LICENSE fix to Fabrice.  But, without starting a flame war 
here, I want to respectfully disagree with a couple of points you make:

1. virtual machine software _is not_ trivial.  Not by any means.  It 
took my company about 20 years to fully develop what became Win4Lin 9x, 
if you trace its history back to before Linux existed (product called 
'Merge').  This was paravirtualization mind you - basically what Xen is 
trying to do now, except that we didn't have the luxury of making 
source-level patches to the guest OS, like Xen does.  The fact that 
Fabrice has been able to engineer KQEMU as quickly as he has, is a 
tribute to his design, and he has every right to keep that secret.  He 
has done what has taken VMware far longer and cost them millions to 
develop, and in my opinion, the KQEMU implementation is better

2. I understand of course that applications are not kernel space... 
however, there are instances where useful applications must provide 
components in kernel space.  To reiterate my point, it is very difficult 
to convince any vendor to write or port good software to Linux if they 
will be forced to accept a license as restrictive as the GPL in _any_ 
capacity.  A *BSD type license is much better for everybody (consumer, 
business, hobbyist, academic, etc.) IMHO, but I respect your opinion to 
thinking the GPL is superior.  You have the right to your opinion.

3. Yes of course the industry gravitates toward open standards. 
However, open standards are not necessarily "open source", and 
definitely not necessarily GPL even if they are open source.  Having an 
open document format or an open communication protocol is something 
industry loves, but that doesn't force vendors to code everything in 
GPL.  It still allows vendors to provide whatever value and protect 
whatever IP they choose, yet prevents vendor lock-in when it comes to 
data.  All important vendors that I can think of except of course 
Microsoft are on board with this.  As for fully open source 
implementations of VM software, can you name a single one that runs 
Windows (desktop or server) guests, at near-native speeds?  I've been in 
this sector of the software industry for 5+ years (and many more years 
outside this sector), and I can't name one.  Xen is awesome, but it 
won't provide this functionality until Vaderpool and Pacifica are 
deployed.  And even then, there is a huge installed base out there of 
chips that do not have VT or Pacifica extensions, so there will be a 
market for other solutions rather than Xen for years to come.  Trust me, 
it is my job to analyze such trends.  And guess what?  Windows servers 
surpassed all Unix server sales combined (including Linux) recently (see 
published studies by respected industry watch groups, not paid by 
Microsoft), so yes, virtualizing Windows operating systems is key to the 
widescale adoption of any VM software today.  This may change in a few 
years, but you can't make the claim that industry is moving to open 
source when Microsoft is selling more servers than ever.

4. There is a slippery slope here - if Linux kernel policies can change 
to force all kernel-space binding to be GPL (even though Linus decreed 
that this is not the case years ago), what's next?  Libraries that make 
kernel interface calls should be GPL rather than LGPL?  Next of course 
any application using one of these libraries (read: any app on Linux) 
must be GPL?  Forget that hypothesis for a second... what if I am a 
hardware vendor in a desperately competitive market, such as say, video 
cards.  Releasing my source code to the driver would mean giving up some 
IP that allows me to surpass the capabilities of my competitor for a few 
weeks.  What motivation do I have to show competitors my competitive 
advantage, just so I can say I released a driver for Linux?  Do you 
think it's mere coincidence that most hardware vendors stick to Windows 
as their main driver platform?  There are 2 things at play here: 1) not 
enough market share for their products on Linux, and when you combine 
that with 2) restrictive policies when it comes to making drivers 
available, then no self-respecting software engineering manager in any 
hardware company can make a good business case to release drivers for 
Linux.  If we keep making it more and more difficult for closed source 
drivers to exist on Linux, more and more hardware vendors will just give 
up altogether.  This means less adoption for Linux from end users (if 
you can't use your hardware, then why bother) - and of course means less 
quality closed source apps (like Photoshop, which is still the gold 
standard despite the excellent capabilities of GIMP) ported to Linux 
because there is less and less market share.  If our goal here is "total 
world domination", then we cannot exclude vendors of any type.  Of 
course "free software" developers spend night and day implementing open 
source drivers from the ground up, but this doesn't increase the 
end-user (pragmatist, non-hacker) adoption of Linux right away.  Not 
when they can use their devices on Windows _right now_.

Anyway, I know that my points have little or no credibility with you 
because I am a vendor.  Just wanted to clarify a few things (and this is 
my last note on the subject, so feel free to have "the last word"),

Leo Reiter

Auke Kok wrote:
> <snip>
> I actually submitted this as a patch to him through this list ;^)
> <snip> 
> applications != kernel space code. It would be rather *good* for linux 
> if all kernel-space processes were open sourced, even for trivial things 
> like VM emulators ;^)
> 
> no matter how you turn Linus' arguments, he doesn't like anything else 
> than ports from windows driver objects linked, and I can really agree 
> with that. Whatever the laywers say about it is moot - only judges 
> listen to them and Open Source doesn't listen to laywers (in generally). 
> Plenty of vendors are already backing up Open Source too, and not just 
> with t-shirts and penguins.
> 
> I do not think that kqemu benefits from being closed source, and 
> probably more people with me. People will pick an open implementation 
> before any closed one, even industry, they're picking up faster than you 
> think ;^)
> 
> I did not agree with kqemu being released without the proprietary flag, 
> which is why I submitted the issue, and,if I can help it, it'll be open 
> source or surpassed by something that is - no offense.
> 
> Cheers,
> 
> Auke

-- 
Leonardo E. Reiter
Vice President of Product Development, CTO

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

Re: [Qemu-devel] why is kqemu closed?

[Jonas Maebe]

On 11 apr 2006, at 17:05, Leonardo E. Reiter wrote:

> what if I am a hardware vendor in a desperately competitive market,  
> such as say, video cards.  Releasing my source code to the driver  
> would mean giving up some IP that allows me to surpass the  
> capabilities of my competitor for a few weeks.

Actually, the reason ATi and NVidia don't open source their graphics  
drivers is because they are both afraid that as soon as as they do  
that, the other one will sue them into oblivion based on software  
patents.

See http://wiki.ffii.org/Smirl041025En for the full story.


Jonas

Re: [Qemu-devel] why is kqemu closed?

[Jim C. Brown]

On Tue, Apr 11, 2006 at 05:14:59PM +0200, Jonas Maebe wrote:
> 
> On 11 apr 2006, at 17:05, Leonardo E. Reiter wrote:
> 
> >what if I am a hardware vendor in a desperately competitive market,  
> >such as say, video cards.  Releasing my source code to the driver  
> >would mean giving up some IP that allows me to surpass the  
> >capabilities of my competitor for a few weeks.
> 
> Actually, the reason ATi and NVidia don't open source their graphics  
> drivers is because they are both afraid that as soon as as they do  
> that, the other one will sue them into oblivion based on software  
> patents.
> 
> See http://wiki.ffii.org/Smirl041025En for the full story.
> 
> 
> Jonas
> 
> 

I wonder, could it be possible that Fabrice is worried about the same
thing? Who holds the patents for x86 virtualization technologies?

Then again, Fabrice is in France iiuc... 

> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] why is kqemu closed?

[Jonas Maebe]

On 11 apr 2006, at 17:25, Jim C. Brown wrote:

>> Actually, the reason ATi and NVidia don't open source their graphics
>> drivers is because they are both afraid that as soon as as they do
>> that, the other one will sue them into oblivion based on software
>> patents.
>>
>> See http://wiki.ffii.org/Smirl041025En for the full story.
>
> I wonder, could it be possible that Fabrice is worried about the same
> thing? Who holds the patents for x86 virtualization technologies?
>
> Then again, Fabrice is in France iiuc...

Even defending against a baseless patent claim costs a lot of money  
(50,000 to 500,000 euro in Europe, which is even fairly "cheap"  
compared to the US' $500,000 to $4,000,000). Which is why in most  
cases where a very small party is threatened, an out-of-court  
settlement will happen, like paying 5,000 euro and no longer  
publishing the program or so, removing an infringing feature, or even  
simply abandoning further publication.

See e.g.:
* http://wiki.ffii.org/Videolan0411En (Videolan removing support for  
some audio format after threats)
* http://www.postgresql.org/about/news.303 (PostgreSQL switching to a  
new patent-free caching scheme)
* http://bladeenc.mp3.no/skeleton/news.html (BladeEnc, halted a.o.  
because of patent issues)


Jonas

Re: [Qemu-devel] why is kqemu closed?

[Paul Brook]

> 4. There is a slippery slope here - 

There's a slippery slope both ways. If you assume vital parts of your system 
are going to be closed source then why bother with open source at all. Just 
use Windows or HPUX.

> if Linux kernel policies can change 
> to force all kernel-space binding to be GPL (even though Linus decreed
> that this is not the case years ago), what's next?  Libraries that make
> kernel interface calls should be GPL rather than LGPL?  

Now you're talking total nonsense.

The GPL explicitly says that OS is exempt from the requirements placed on an 
application:

"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."

Paul

Re: [Qemu-devel] why is kqemu closed?

[M. Warner Losh]

In message: <200604111636.25101.paul@codesourcery.com>
            Paul Brook <paul@codesourcery.com> writes:
: > 4. There is a slippery slope here - 
: 
: There's a slippery slope both ways. If you assume vital parts of your system 
: are going to be closed source then why bother with open source at all. Just 
: use Windows or HPUX.
: 
: > if Linux kernel policies can change 
: > to force all kernel-space binding to be GPL (even though Linus decreed
: > that this is not the case years ago), what's next?  Libraries that make
: > kernel interface calls should be GPL rather than LGPL?  
: 
: Now you're talking total nonsense.
: 
: The GPL explicitly says that OS is exempt from the requirements placed on an 
: application:
: 
: "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 think that you are missing the point.  He's not saying that you have
to distribute the source (which is what that exemption is about).
He's saying that the license on a mere library cannot and should not
force applications linked with that library to become a derived work.
And he's right about that being a dangerous precident.  If I call
write(2) in my application, the mere fact that the kernel is GPL'd
shouldn't matter for the license of my application.  It is not a
derived work.

The circumlocutions that some people go through to try to show that
somehow using internal kernel interfaces make something a derived work
do border on the absurd and are a very agressive interpretation of
what makes a work a derived work.  That interpretation needs to be
curbed, otherwise we'd have a slipperly slope where libc becomes GPL'd
and merely linking against it once and providing that binary infects
the application with the GPL (a position that no court has endorced).

Warner

Re: [Qemu-devel] why is kqemu closed?

[Paul Brook]

> I think that you are missing the point.  He's not saying that you have
> to distribute the source (which is what that exemption is about).
> He's saying that the license on a mere library cannot and should not
> force applications linked with that library to become a derived work.
> And he's right about that being a dangerous precident.  If I call
> write(2) in my application, the mere fact that the kernel is GPL'd
> shouldn't matter for the license of my application.  It is not a
> derived work.

Well, the whole point of the GPL is that you have to provide sufficient 
sources for the user to be able to regenerate your binary. If your 
application includes closed-source code then by definition you've broken that 
requirement.

> The circumlocutions that some people go through to try to show that
> somehow using internal kernel interfaces make something a derived work
> do border on the absurd and are a very agressive interpretation of
> what makes a work a derived work.  That interpretation needs to be
> curbed, otherwise we'd have a slipperly slope where libc becomes GPL'd
> and merely linking against it once and providing that binary infects
> the application with the GPL (a position that no court has endorced).

You can't legally distribute a GPL application linked against a closed-source 
library. In the same way you can't distribute a GPL library as part of a 
closed source application.
Libraries (eg. glibc) that want to allow linking with proprietary code have 
LGPL or additional licence exceptions to permit this.
I'd guess linking against the system libc is reasonably covered by the 
exception I quoted. Linking against 3rd party libc probably isn't, which IMHO 
is prefectly reasonably. Otherwise a proprietary product could just take GPL 
code, modify it and put all the interesting proprietary bits in a library 
called libc.so.

If the GPL doesn't cover linking against libraries then it's effectively 
useless for its stated purpose.

Paul

Re: [Qemu-devel] why is kqemu closed?

[M. Warner Losh]

In message: <200604111700.38801.paul@codesourcery.com>
            Paul Brook <paul@codesourcery.com> writes:
: > I think that you are missing the point.  He's not saying that you have
: > to distribute the source (which is what that exemption is about).
: > He's saying that the license on a mere library cannot and should not
: > force applications linked with that library to become a derived work.
: > And he's right about that being a dangerous precident.  If I call
: > write(2) in my application, the mere fact that the kernel is GPL'd
: > shouldn't matter for the license of my application.  It is not a
: > derived work.
:
: Well, the whole point of the GPL is that you have to provide
: sufficient sources for the user to be able to regenerate your
: binary. If your application includes closed-source code then by
: definition you've broken that requirement.

The problem with that belief is that it might not be what the law
requires.  The GPL cannot be used to force users that do not create
derived works to do anything.  The entire power of the GPL is based in
copyright law.  Copyright law is about verbatim copies and creating
derived works.  Anything outside of these activities, the GPL cannot
regulate.  One of the reasons for the "OS Exception" is because no
other license tries to dictate which license to use when you link with
OS compoents.  It merely recongizes common practice in the industry
that says linking against libc doesn't create a derived work.

: > The circumlocutions that some people go through to try to show that
: > somehow using internal kernel interfaces make something a derived work
: > do border on the absurd and are a very agressive interpretation of
: > what makes a work a derived work.  That interpretation needs to be
: > curbed, otherwise we'd have a slipperly slope where libc becomes GPL'd
: > and merely linking against it once and providing that binary infects
: > the application with the GPL (a position that no court has endorced).
: 
: You can't legally distribute a GPL application linked against a
: closed-source library.

Acutally, closed-source vs open-source isn't the issue.  The issue is
GPL compatible or not GPL compatible.  There are many libraries that
the source is available for which do not meet this definition.  Were
it not for the OS exception, you couldn't use GPL'd products on
systems whose libc wasn't released under the GPL, or a compatible
license.  You couldn't have gcc on Solaris, becuase libc on solaris is
closed-source.  You couldn't have gcc on FreeBSD because FreeBSD's
libc has files in it which contain the advertising clause.

: In the same way you can't distribute a GPL
: library as part of a closed source application.

This is true, with the same caveat.  It isn't just closed-source
applications, but rather everything has to be compatible with the
GPL.  GPL'd libraries are difficult to use.  There's also some
ambiguity in this statement, because one could have a shared library
based on non-GPL'd technology with the same ABI as the GPL'd one.  In
those cases, it is hard to argue that linking dynamically against one
or the other creates a derived work.  The whole issue hinges on what
is a derive work, and as I've stated before, that's an area of the law
that's not well defined when it comes to thinks like the GPL.

: Libraries
: (eg. glibc) that want to allow linking with proprietary code have
: LGPL or additional licence exceptions to permit this.

Alternatively, their license can be written not to need a special
exception.

: I'd guess
: linking against the system libc is reasonably covered by the
: exception I quoted.

The exception that you quoted says I don't have to provide source for
libc and other system libraries that a user may be reasonably expected
to have in binary format.  The purpose of the GPL is so that people
can make changes to the application, and have all the parts needed to
rebuild the application.

: Linking against 3rd party libc probably isn't,
: which IMHO is prefectly reasonably. Otherwise a proprietary product
: could just take GPL code, modify it and put all the interesting
: proprietary bits in a library called libc.so.

Linking against a 3rd party libc is perfectly acceptible, depending on
how it is done.  Static linking likely isn't OK unless that 3rd party
libc is available to others.  Dynamic linking almost certainly is.  If
one has a drop-in replacement for libc.so, say, then one can certainly
use that drop-in replacement.  The trickier legal issues arise when
one tries to define what exactly is an OS, and how are OS vendors.

Merely calling something libc.so doesn't make it part of the OS, so
you are right about that.

: If the GPL doesn't cover linking against libraries then it's effectively 
: useless for its stated purpose.

The coverage isn't as absolute as you might think.  It all hinges on
what is a derived work.  Does calling a kernel that's GPL'd make
something a drived work.  Why is the kernel different than a userland
library that's GPL'd from a copyright perspective?  That's what we're
talking about with kqemu: it is part of the kernel because it is
linked in at run-time.  Yet does that create a derived work?  Some say
yes, and some say now.  Which brings us back to my original statement
earlier in this thread "lots of people have opinions, there's very
little court precident to help us decide who is right."

Anyway, enough about abstract legal theory.  The bottom line is that
distributing a binary kqemu is OK.

Warner

Re: [Qemu-devel] why is kqemu closed?

[Jim C. Brown]

On Tue, Apr 11, 2006 at 11:05:56AM -0400, Leonardo E. Reiter wrote:
> 1. virtual machine software _is not_ trivial.  Not by any means.  It 
> took my company about 20 years to fully develop what became Win4Lin 9x, 
> if you trace its history back to before Linux existed (product called 
> 'Merge').  This was paravirtualization mind you - basically what Xen is 
> trying to do now, except that we didn't have the luxury of making 
> source-level patches to the guest OS, like Xen does.  The fact that 
> Fabrice has been able to engineer KQEMU as quickly as he has, is a 
> tribute to his design, and he has every right to keep that secret.  He 
> has done what has taken VMware far longer and cost them millions to 
> develop, and in my opinion, the KQEMU implementation is better

Agreed, in full.

The only 2 open source virtualization efforts I know of are the old plex86 which
failed and vmbear, which is brand new (and has the easier goal of virtualizing
only linux for the time being).

If we are allowed to step outside of the x86 platform, I can think of one more
open source virtualizer:  Mac-On-Linux. This one is fully open source and does
real virtualization so it is probably as fast as VMware (though the speeds can
not be directly compared obviously) - but it doesn't have to do the hard job of
virtualizing the braindead x86 instruction set.

> 
> 2. I understand of course that applications are not kernel space... 
> however, there are instances where useful applications must provide 
> components in kernel space.  To reiterate my point, it is very difficult 
> to convince any vendor to write or port good software to Linux if they 
> will be forced to accept a license as restrictive as the GPL in _any_ 
> capacity. 

This currently is not the case anyways. Vendors can release non GPL modules.
This of course translates into more work for them (as the official kernel
maintainers can not help to provide support, fix bugs, help with new ports, etc)
but that is the cost of giving up an open source license.

> A *BSD type license is much better for everybody (consumer, 
> business, hobbyist, academic, etc.) IMHO, but I respect your opinion to 
> thinking the GPL is superior.  You have the right to your opinion.

My own personal opinion: the GPL is superior because it ensures that all the
software under it remains open source. And open source (GPL, BSD, etc) is
superior to closed source because I can hack on the code myself to make
desired customizations or do my own bug fixing.

I will grant that it is possible to hack on and do these same changes to the
machine code of software released in closed binary form. But most closed source
licenses/EULAs prevent disassembly or modification to the binary form, so even
if I wanted to try it would be illegal for me to do so.

For non programmers however, there is no difference between BSD and GPL.
For these kinds of users, it is arguably important to keep the vendors happy.

> 
> 3. Yes of course the industry gravitates toward open standards. 
> However, open standards are not necessarily "open source", and 
> definitely not necessarily GPL even if they are open source.  Having an 
> open document format or an open communication protocol is something 
> industry loves, but that doesn't force vendors to code everything in 
> GPL.  It still allows vendors to provide whatever value and protect 
> whatever IP they choose, yet prevents vendor lock-in when it comes to 
> data.  All important vendors that I can think of except of course 
> Microsoft are on board with this. 

Agreed.

> As for fully open source 
> implementations of VM software, can you name a single one that runs 
> Windows (desktop or server) guests, at near-native speeds?  I've been in 
> this sector of the software industry for 5+ years (and many more years 
> outside this sector), and I can't name one.  Xen is awesome, but it 
> won't provide this functionality until Vaderpool and Pacifica are 
> deployed.  And even then, there is a huge installed base out there of 
> chips that do not have VT or Pacifica extensions, so there will be a 
> market for other solutions rather than Xen for years to come.  Trust me, 
> it is my job to analyze such trends.  And guess what?  Windows servers 
> surpassed all Unix server sales combined (including Linux) recently (see 
> published studies by respected industry watch groups, not paid by 
> Microsoft), so yes, virtualizing Windows operating systems is key to the 
> widescale adoption of any VM software today.  This may change in a few 
> years, but you can't make the claim that industry is moving to open 
> source when Microsoft is selling more servers than ever.

I don't keep up to date on the number of servers bought/sold, so no comment
there.

I agree with you on the comment about there not being an open source virtualizer
that can run windows yet (qemu w/o kqemu can, but that is not virtualization,
and qvm86 is far behind kqemu) - but I honestly do not see the market rushing
to choose kqemu here.

> 
> 4. There is a slippery slope here - if Linux kernel policies can change 
> to force all kernel-space binding to be GPL (even though Linus decreed 
> that this is not the case years ago), what's next?  Libraries that make 
> kernel interface calls should be GPL rather than LGPL?  Next of course 
> any application using one of these libraries (read: any app on Linux) 
> must be GPL? 

To be absurdly pendantic, GPL-compatible. :)

If this situation ever actually occured, it would be possible to fork a version
of the Linux kernel (and the GNU parts like glibc, etc) and keep those under
the original license (with the original exceptions).

But if it ever came to that, we'd probably have a large migration to FreeBSD,
so no one would actually bother to make the effort. ;)

> Forget that hypothesis for a second... what if I am a 
> hardware vendor in a desperately competitive market, such as say, video 
> cards.  Releasing my source code to the driver would mean giving up some 
> IP that allows me to surpass the capabilities of my competitor for a few 
> weeks.  What motivation do I have to show competitors my competitive 
> advantage, just so I can say I released a driver for Linux? 

Ironically, this is what software patents are for.

I think the GPL3 has a good compromise here - put ur IP in a patent and then
release the driver as open source. Either the competitor stays closed and thus
can't take advantage of the code, or it opens up and thus gives you the chance
to take advantage of their code.

Another acceptable compromise - keep the product closed source as long as it is
competitive so you can make money - but when it is no longer a cash crop, give
up the source code.

> Do you 
> think it's mere coincidence that most hardware vendors stick to Windows 
> as their main driver platform?  There are 2 things at play here: 1) not 
> enough market share for their products on Linux, and when you combine 
> that with 2) restrictive policies when it comes to making drivers 
> available, then no self-respecting software engineering manager in any 
> hardware company can make a good business case to release drivers for 
> Linux. 

I doubt the "restrictive" policies play any part in this. We have plenty
of binary drivers for linux.

> If we keep making it more and more difficult for closed source 
> drivers to exist on Linux, more and more hardware vendors will just give 
> up altogether.  This means less adoption for Linux from end users (if 
> you can't use your hardware, then why bother) - and of course means less 
> quality closed source apps (like Photoshop, which is still the gold 
> standard despite the excellent capabilities of GIMP) ported to Linux 
> because there is less and less market share.  If our goal here is "total 
> world domination", then we cannot exclude vendors of any type.  Of 
> course "free software" developers spend night and day implementing open 
> source drivers from the ground up, but this doesn't increase the 
> end-user (pragmatist, non-hacker) adoption of Linux right away.  Not 
> when they can use their devices on Windows _right now_.

I agree with you here, on the part of hardware vendors leading to less linux
adoption.

I disagree that closed source is superior for hardware vendors - but this is
getting very off topic.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: Enough already! [Qemu-devel] why is kqemu closed?

[Bakul Shah]

My personal opinion:

Discussions of the GPL are like the bird 'flu -- any time
anyone offers any program for free and there is a
list/newsgroup about it, we know some "bird" will get the GPL
discussion 'flu.  This is inevitable but we can't seem to
avoid it.  And everyone who gets it, starts throwing up.

You will waste everyone's time going over the same old tired
arguments gone over literally hundreds of time in other
forums.  In the end nothing gets resolved.

So enough already!

Instead can someone please figure out why plan9 doesn't work
with kqemu?  Or how about profiling qemu and working on one
of the top 10 time hogs.  Or work on qvm86.  Or work on
adding new capabilities to qemu.  Any of these is likely to
be more challenging, satisfying and fun than being down with
the GPL discussion 'flu blues.  Thanks!

Re: [Qemu-devel] why is kqemu closed?

[Sebastian Kaliszewski]

Auke Kok wrote:
> no matter how you turn Linus' arguments, he doesn't like anything else 
> than ports from windows driver objects linked, and I can really agree 
> with that. Whatever the laywers say about it is moot - only judges 
> listen to them and Open Source doesn't listen to laywers (in generally). 
> Plenty of vendors are already backing up Open Source too, and not just 
> with t-shirts and penguins.

The only thing important is what GPL says. And GPL is clear here. KQemu must 
be a derived work (i.e. include some source (even C headres) from kernel 
and/or be bound just to a Linux kernel) to be forced to go under GPL. But 
neither it includes any kernel headres nor it's Linux only -- the very same 
binary (object file) can be used with *BSD as well as Windows. So KQemu can 
be legally licenced under any licence Fabrice chooses.

rgds
-- 
Sebastian Kaliszewski

Re: [Qemu-devel] why is kqemu closed?

[M. Warner Losh]

In message: <443BC896.5000306@softax.com.pl>
            Sebastian Kaliszewski <Sebastian.Kaliszewski@softax.com.pl> writes:
: Auke Kok wrote:
: > no matter how you turn Linus' arguments, he doesn't like anything else 
: > than ports from windows driver objects linked, and I can really agree 
: > with that. Whatever the laywers say about it is moot - only judges 
: > listen to them and Open Source doesn't listen to laywers (in generally). 
: > Plenty of vendors are already backing up Open Source too, and not just 
: > with t-shirts and penguins.
: 
: The only thing important is what GPL says. And GPL is clear here. KQemu must 
: be a derived work (i.e. include some source (even C headres) from kernel 
: and/or be bound just to a Linux kernel) to be forced to go under GPL. But 
: neither it includes any kernel headres nor it's Linux only -- the very same 
: binary (object file) can be used with *BSD as well as Windows. So KQemu can 
: be legally licenced under any licence Fabrice chooses.

The GPL talks about creating a derived work.  Including headers
doesn't necessarily create a derived work.  The header files have to
have creative content that can be protected by copyright before their
inclusion creates a derived work.  Otherwise, when I include errno.h,
I'd be creating a derived work[*].  What makes a header rise to this
level is an interesting legal issue.  Also, what makes a derived work
in an interesting legal issue that's not been robustly defined by the
courts wrt open source products (it has been defined for copy and hack
of closed source, however).  While there's no shortage of opinions on
what the legal line is, they are just that: opinions.

Having said all that, kqemu is perfectly legal, and anybody that makes
an absolute statement to the contrary is wrong.

Warner

[*] This is the example that SCO likes to trot out for Linux's
infringement.  The errno values are the same and must have been
copied.

Re: [Qemu-devel] why is kqemu closed?

[andrzej zaborowski]

On 10/04/06, Leonardo E. Reiter <lreiter@win4lin.com> wrote:
> No it's not!  In fact, in the latest version, he explicitly gives it a
> commercial ("Proprietary") license.  He also does not import any
> exported GPL symbols from the kernel.  In fact, if your claim is true,
Legally, even without the "Propriotary" tag, or even importing some
GPL symbols from the kernel, kqemu is still absolutely valid. Anything
released to the public by anyone is legal as long as it doesn't
include (in it's content) parts of other people's copyrighted work. In
this sense, kqemu can import whatever symbols it wants and have
whatever license tag because when you download kqemu you're not
downloading any piece of kernel's code as a part of kqemu.
Now, whether using kqemu together with a linux kernel will still be
legal is a different issue, but here the question is whether the user
is breaking the law, not the author.

> then the following very popular products violate the kernel license
> agreement:
>
> VMware Workstation, GSX Server, ESX Server, Server Beta (free)
> Parallels Workstation
> NVIDIA drivers
> Win4Lin 9x (shameless self-promotion, I admit)
> Win4Lin Pro (which distributes KQEMU under license from Fabrice)
>
> In fact, KQEMU uses almost no kernel functionality at all.  Allocating,
> freeing, and locking memory into place is not that interesting and is
> not something that Linux does alone - every OS in existence provides
> these services.  On Linux, you are not forced to be a GPL module to use
> them, because, they are simply not that interesting and are mandatory to
> run just about any type of application or driver.  The real meat of
> KQEMU is kernel-independent (the same binary runs on just about any OS,
> unmodified), and deals with the CPU directly.  It would be a crying
> shame if drivers like these would not be allowed in future kernels -
> they use the kernel as simply a loader, not to do anything really
> interesting.
>
> I admit since I am a vendor, I have certain biases against forcing all
> software to be GPL.  However I respect these licenses fully, and also
> respect the author's choice to use whatever license he or she pleases,
> and also to allow exceptions to these licenses.  You might recall Linus
> Torvalds years ago explicitly giving an exception to "binding" when it
> came to loading kernel modules.  It would be hard to convince any vendor
> in the world to develop software for Linux if you were not allowed to
> run non-GPL applications on Linux.  Let's hope that never happens,
> although I understand that the latest sentiments seem to unfortunately
> be leaning that way.  This is not how Linux will beat Windows on the
> desktop, nor on the server!
>
> Regards,
>
> Leo Reiter
>
> Auke Kok wrote:
> >
> > On Mon, 10 Apr 2006 17:20:54 +0200, "Hetz Ben Hamo" <hetzbh@gmail.com> wrote:
> >
> >>Fabrice is the owner of the KQEMU code, and he decides for his own
> >>reasons to put the code under closed source license.
> >
> >
> > I'm sure that Fabrice knows and that I'm beating a dead horse, but this is (strictly speaking, discussions pending ;^)) violating the linux kernel license agreement.
> >
> > Auke
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
> --
> Leonardo E. Reiter
> Vice President of Product Development, CTO
>
> Win4Lin, Inc.
> Virtual Computing from Desktop to Data Center
> Main: +1 512 339 7979
> Fax: +1 512 532 6501
> http://www.win4lin.com
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Regards,
Andrew
--
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

Re: [Qemu-devel] why is kqemu closed?

[Jamie Lokier]

andrzej zaborowski wrote:
> Anything released to the public by anyone is legal as long as it
> doesn't include (in it's content) parts of other people's
> copyrighted work. In this sense, kqemu can import whatever symbols
> it wants and have whatever license tag because when you download
> kqemu you're not downloading any piece of kernel's code as a part of
> kqemu.

That point is not correct.

Look up the legal terms "indirect infringement" and "contributory
infringement".

If an author distributes something whose principal use will be to
facilitate copyright infringement (i.e. by the users), then the author
may be found guilty of indirect infringement.

Both indirect infringement of GPL'd code, by distributing module
source code which depends on overly-intimate details of the kernel to
be useful, and direct infringement, by virtue of distributing compiled
binaries which use long inline definitions from kernel header files,
are among the theories about what may or may not be infringing.  The
specially-marked symbols in Linux kernel source are guidelines and
indications of intention, which may prove relevant in a court of law
if judgement is required on a borderline case.

Note that I'm not saying anything about kqemu.  Only pointing out that
it's false to say that distributing code you wrote yourself is never
copyright infringement.

> Now, whether using kqemu together with a linux kernel will still be
> legal is a different issue, but here the question is whether the user
> is breaking the law, not the author.

The GPL doesn't restrict linking and using whatever combination you
like.  It only restricts distribution, which the user in your example
isn't doing.  So end users are unlikely to be deemed guilty of anything.

-- Jamie

Re: [Qemu-devel] why is kqemu closed?

[Sebastian Kaliszewski]

andrzej zaborowski wrote:
> Now, whether using kqemu together with a linux kernel will still be
> legal is a different issue, but here the question is whether the user
> is breaking the law, not the author.
> 

And then GPL explicitly allows user to do anything (s)he wishes, including 
(but not limited to) linking with closed source software, incorporating into 
closed source software, etc. until resultant binary is used "internally" 
(i.e. is not spread further).

rgds
-- 
Sebastian Kaliszewski

Re: [Qemu-devel] why is kqemu closed?

[M. Warner Losh]

In message: <443BC6FE.7090607@softax.com.pl>
            Sebastian Kaliszewski <Sebastian.Kaliszewski@softax.com.pl> writes:
: andrzej zaborowski wrote:
: > Now, whether using kqemu together with a linux kernel will still be
: > legal is a different issue, but here the question is whether the user
: > is breaking the law, not the author.
: > 
: 
: And then GPL explicitly allows user to do anything (s)he wishes, including 
: (but not limited to) linking with closed source software, incorporating into 
: closed source software, etc. until resultant binary is used "internally" 
: (i.e. is not spread further).

I think that you ment to say "so long as the" rather than "until"
here.

Warner

Re: [Qemu-devel] why is kqemu closed?

[Brett (Mare) Henley]

  This is all very disturbing, Fabrice wrote an enhancement to qemu
that runs perfectly fine without KQEMU. Why should anyone have a problem
with what license he uses or terms he decides?
  He wants a very reasonable price for the source if you want it, pay 
for it, if you don't. Don't. He makes the module available to be used. 
If you are worried about 'VIOLATING' the GPL don't use KQEMU.
  There is no need for GPL consideration here. It's you're choice to use 
it. He doesn't make you use it.

And for the record. Fabrice, you are amazing. My computing experience
has been greatly enhanced by your contributions. Thank you.

Mare


Auke Kok wrote:
> 
> On Mon, 10 Apr 2006 17:20:54 +0200, "Hetz Ben Hamo" <hetzbh@gmail.com> wrote:
>> Fabrice is the owner of the KQEMU code, and he decides for his own
>> reasons to put the code under closed source license.
> 
> I'm sure that Fabrice knows and that I'm beating a dead horse, but this is (strictly speaking, discussions pending ;^)) violating the linux kernel license agreement.
> 
> Auke
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> !DSPAM:443a7e2e947657584822839!
> 

Re: [Qemu-devel] why is kqemu closed?

[Leonardo E. Reiter]

I second that, very emphatically!

- Leo Reiter

Brett (Mare) Henley wrote:
>  This is all very disturbing, Fabrice wrote an enhancement to qemu
> that runs perfectly fine without KQEMU. Why should anyone have a problem
> with what license he uses or terms he decides?
>  He wants a very reasonable price for the source if you want it, pay for 
> it, if you don't. Don't. He makes the module available to be used. If 
> you are worried about 'VIOLATING' the GPL don't use KQEMU.
>  There is no need for GPL consideration here. It's you're choice to use 
> it. He doesn't make you use it.
> 
> And for the record. Fabrice, you are amazing. My computing experience
> has been greatly enhanced by your contributions. Thank you.
> 
> Mare
-- 
Leonardo E. Reiter
Vice President of Product Development, CTO

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

Re: [Qemu-devel] why is kqemu closed?

[M. Warner Losh]

In message: <3ef9fbda81a71790b3cc0575ebf95538@localhost>
            Auke Kok <sofar@foo-projects.org> writes:
: 
: 
: On Mon, 10 Apr 2006 17:20:54 +0200, "Hetz Ben Hamo" <hetzbh@gmail.com> wrote:
: > Fabrice is the owner of the KQEMU code, and he decides for his own
: > reasons to put the code under closed source license.
: 
: I'm sure that Fabrice knows and that I'm beating a dead horse, but this is (strictly speaking, discussions pending ;^)) violating the linux kernel license agreement.

While that topic is unclear[*], at best, at the moment, I'll point out
that it isn't a violation of the FreeBSD license.  so everyone should
use FreeBSD :-)

Warner

[*] Different people who own large parts of the copyrights to Linux
have said different things on the topic.  Authoritative statements on
the topic therefore cannot be authoritative...