* [Qemu-devel] QEMU License and proprietary hardware
@ 2007-06-21 11:28 Armbrost Failsafe
2007-06-21 22:24 ` Luke -Jr
2007-06-24 20:10 ` Paul Brook
0 siblings, 2 replies; 16+ messages in thread
From: Armbrost Failsafe @ 2007-06-21 11:28 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
We are looking into using QEMU as the base for a model of a custom system
featuring some custom ASICs. But licensing issues are halting the process
right now. Does anyone know what happens license-wise if we create a model
of proprietary hardware using QEMU? Is that model automatically covered by
the GPL and thus we have to give to anyone who asks about it? It is clear
that if we keep it internal, it is OK. But anyone outside of our
organization is to use it, shouldn't they automatically be entitled to
receive the entire source of QEMU, including our models of proprietary
devices? Even if these are developed from scratch without using any existing
source code for devices?
/armbrost
[-- Attachment #2: Type: text/html, Size: 711 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-21 11:28 [Qemu-devel] QEMU License and proprietary hardware Armbrost Failsafe
@ 2007-06-21 22:24 ` Luke -Jr
2007-06-21 22:33 ` M. Warner Losh
2007-06-24 20:10 ` Paul Brook
1 sibling, 1 reply; 16+ messages in thread
From: Luke -Jr @ 2007-06-21 22:24 UTC (permalink / raw)
To: qemu-devel
On Thursday 21 June 2007 06:28, Armbrost Failsafe wrote:
> We are looking into using QEMU as the base for a model of a custom system
> featuring some custom ASICs. But licensing issues are halting the process
> right now. Does anyone know what happens license-wise if we create a model
> of proprietary hardware using QEMU? Is that model automatically covered by
> the GPL and thus we have to give to anyone who asks about it? It is clear
> that if we keep it internal, it is OK. But anyone outside of our
> organization is to use it, shouldn't they automatically be entitled to
> receive the entire source of QEMU, including our models of proprietary
> devices? Even if these are developed from scratch without using any
> existing source code for devices?
Yep, that's the purpose of the GPL. It'll probably get a lot of people
promoting it if you do a public release, too...
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-21 22:24 ` Luke -Jr
@ 2007-06-21 22:33 ` M. Warner Losh
2007-06-22 15:18 ` Luke -Jr
0 siblings, 1 reply; 16+ messages in thread
From: M. Warner Losh @ 2007-06-21 22:33 UTC (permalink / raw)
To: qemu-devel, luke
In message: <200706211724.25832.luke@dashjr.org>
Luke -Jr <luke@dashjr.org> writes:
: On Thursday 21 June 2007 06:28, Armbrost Failsafe wrote:
: > We are looking into using QEMU as the base for a model of a custom system
: > featuring some custom ASICs. But licensing issues are halting the process
: > right now. Does anyone know what happens license-wise if we create a model
: > of proprietary hardware using QEMU? Is that model automatically covered by
: > the GPL and thus we have to give to anyone who asks about it? It is clear
: > that if we keep it internal, it is OK. But anyone outside of our
: > organization is to use it, shouldn't they automatically be entitled to
: > receive the entire source of QEMU, including our models of proprietary
: > devices? Even if these are developed from scratch without using any
: > existing source code for devices?
:
: Yep, that's the purpose of the GPL. It'll probably get a lot of people
: promoting it if you do a public release, too...
Well, that all depends on if the models constitute a derivative work
or not. The GPL only has as much force of law as copyright law gives
it, and in order to be applicable, the work in question must somehow
rely on the GPL'd work. The "somehow" here is an interesting legal
question that hasn't been well settled.
In this case, however, chances are excellent that it is a derivative
work and would be covered by the GPL. IANAL.
Warner
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
@ 2007-06-22 5:34 Balazs Attila-Mihaly (Cd-MaN)
2007-06-22 15:21 ` Luke -Jr
0 siblings, 1 reply; 16+ messages in thread
From: Balazs Attila-Mihaly (Cd-MaN) @ 2007-06-22 5:34 UTC (permalink / raw)
To: qemu-devel
I must prefix this with the fact that IANAL, but as I understand it, you must release the source code only if you distribute that modified system (with GPL v2). That is, if you use this system internally in you company, you don't have to provide your modifications. But if you, for example, provide your clients with the modified version, you have the obligation to provide them (your clients, not the Qemu community in general) also with the complete source code, after which they have the liberty to redistribute the source code under the GPL. One solution would be (again, IANAL, so please check with a real lawyer :D), is to create an interface to the code you wish to include and put the proprietary code in a dynamically linked library which exposes this interface. In this case IMHO you have to provide only the code which implements the interface in Qemu and loads the shared library, and you would have no obligation regarding the code in the shared library.
----- Original Message ----
From: Armbrost Failsafe <armbrost@gmail.com>
To: qemu-devel@nongnu.org
Sent: Thursday, 21 June, 2007 2:28:53 PM
Subject: [Qemu-devel] QEMU License and proprietary hardware
We are looking into using QEMU as the base for a model of a custom system featuring some custom ASICs. But licensing issues are halting the process right now. Does anyone know what happens license-wise if we create a model of proprietary hardware using QEMU? Is that model automatically covered by the GPL and thus we have to give to anyone who asks about it? It is clear that if we keep it internal, it is OK. But anyone outside of our organization is to use it, shouldn't they automatically be entitled to receive the entire source of QEMU, including our models of proprietary devices? Even if these are developed from scratch without using any existing source code for devices?
/armbrost
___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-21 22:33 ` M. Warner Losh
@ 2007-06-22 15:18 ` Luke -Jr
2007-06-22 16:07 ` Warner Losh
0 siblings, 1 reply; 16+ messages in thread
From: Luke -Jr @ 2007-06-22 15:18 UTC (permalink / raw)
To: qemu-devel
On Thursday 21 June 2007 17:33, M. Warner Losh wrote:
> The GPL only has as much force of law as copyright law gives it, and in
> order to be applicable, the work in question must somehow rely on the GPL'd
> work. The "somehow" here is an interesting legal question that hasn't been
> well settled.
And copyright law by default grants you no rights to modify or copy Qemu at
all. The ONLY way you can get permission to copy or modify Qemu is to agree
to the GPL in its entirety-- which does not restrict itself to merely
derivative works, but covers all linking. (note: obvious the copyright
holder(s) can make exceptions to this rule)
IANAL either, but as much as I have to debate this I might as well be
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-22 5:34 Balazs Attila-Mihaly (Cd-MaN)
@ 2007-06-22 15:21 ` Luke -Jr
0 siblings, 0 replies; 16+ messages in thread
From: Luke -Jr @ 2007-06-22 15:21 UTC (permalink / raw)
To: qemu-devel
On Friday 22 June 2007 00:34, Balazs Attila-Mihaly (Cd-MaN) wrote:
> I must prefix this with the fact that IANAL, but as I understand it, you
> must release the source code only if you distribute that modified system
> (with GPL v2). That is, if you use this system internally in you company,
> you don't have to provide your modifications. But if you, for example,
> provide your clients with the modified version, you have the obligation to
> provide them (your clients, not the Qemu community in general) also with
> the complete source code, after which they have the liberty to redistribute
> the source code under the GPL.
Correct.
> One solution would be (again, IANAL, so please check with a real lawyer :D),
The solution would be to comply with the GPL and release the code. :)
> is to create an interface to the code you wish to include and put the
> proprietary code in a dynamically linked library which exposes this
> interface. In this case IMHO you have to provide only the code which
> implements the interface in Qemu and loads the shared library, and you would
> have no obligation regarding the code in the shared library.
The GPL is viral. A derivative-work wrapper would be under the full GPL terms
and could not link out to a proprietary library either. While there are legal
loopholes in the GPL, this is not one of them. (and no, I will not provide
any more info on the loopholes I am aware of)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-22 15:18 ` Luke -Jr
@ 2007-06-22 16:07 ` Warner Losh
2007-06-22 16:23 ` Luke -Jr
0 siblings, 1 reply; 16+ messages in thread
From: Warner Losh @ 2007-06-22 16:07 UTC (permalink / raw)
To: qemu-devel, luke
From: Luke -Jr <luke@dashjr.org>
Subject: Re: [Qemu-devel] QEMU License and proprietary hardware
Date: Fri, 22 Jun 2007 10:18:01 -0500
> On Thursday 21 June 2007 17:33, M. Warner Losh wrote:
> > The GPL only has as much force of law as copyright law gives it, and in
> > order to be applicable, the work in question must somehow rely on the GPL'd
> > work. The "somehow" here is an interesting legal question that hasn't been
> > well settled.
>
> And copyright law by default grants you no rights to modify or copy Qemu at
> all. The ONLY way you can get permission to copy or modify Qemu is to agree
> to the GPL in its entirety-- which does not restrict itself to merely
> derivative works, but covers all linking. (note: obvious the copyright
> holder(s) can make exceptions to this rule)
Actually, the GPL does only apply to derived works, and it plainly
says so:
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
Linking typically is what makes a derived work, but not necessary. It
is just the shade of grey that most people use as a rule of thumb.
If you do not have a derived work, then you can use and distribute
your work as you see fit, without the GPL restrictions. While the GPL
is viral, it is only viral to the extent that the new work is
derivative of the GPL'd work. This is why, for example, running my
proprietary program on a Linux box doesn't mean my proprietary program
is covered under the GPL. Although it uses the kernel, and in a very
real sense the kernel links into the program due to address space
mapping for system calls and the like, this isn't enough to make my
program a derivative work. So it isn't 'black' vs 'white' but more of
a 'this shade of grey is more white than black' or vice versa.
I can make "fair use" use of GPL'd software with no restrictions
what-so-ever so long as that use falls within 'fair use' as defined by
copyright law. I can also use GPL'd code that doesn't quaify for
copyright protection (as is the case if it lacks a creative element,
is the only possible way to do something, etc).
However, those exceptions tend to be rather specialized and limited.
This isn't just GPL, btw, but any creative work. It is at the heart
of the SCO case because SCO is claiming ~500 lines of Linux infringe
on its copyright rights (to grossly oversimplify). Much of IBM's
defence rests on exceptions to copyright law.
> IANAL either, but as much as I have to debate this I might as well be
It is amaizing how many people get this wrong. It is subtle, and
there's much misinformation circulating. I've had to do a lot of
research in this area because of my involvement in FreeBSD's core team
and the licensing issues that come up there...
Warner
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-22 16:07 ` Warner Losh
@ 2007-06-22 16:23 ` Luke -Jr
2007-06-22 16:46 ` M. Warner Losh
0 siblings, 1 reply; 16+ messages in thread
From: Luke -Jr @ 2007-06-22 16:23 UTC (permalink / raw)
To: qemu-devel
On Friday 22 June 2007 11:07, you wrote:
> > On Thursday 21 June 2007 17:33, M. Warner Losh wrote:
> > > The GPL only has as much force of law as copyright law gives it, and in
> > > order to be applicable, the work in question must somehow rely on the
> > > GPL'd work. The "somehow" here is an interesting legal question that
> > > hasn't been well settled.
> >
> > And copyright law by default grants you no rights to modify or copy Qemu
> > at all. The ONLY way you can get permission to copy or modify Qemu is to
> > agree to the GPL in its entirety-- which does not restrict itself to
> > merely derivative works, but covers all linking. (note: obvious the
> > copyright holder(s) can make exceptions to this rule)
>
> Actually, the GPL does only apply to derived works, and it plainly
> says so:
> 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
> Linking typically is what makes a derived work, but not necessary. It
> is just the shade of grey that most people use as a rule of thumb.
That's merely the definition of "Program" as used in the license. Read all the
requirements, not just definitions...
> If you do not have a derived work, then you can use and distribute
> your work as you see fit, without the GPL restrictions. While the GPL
> is viral, it is only viral to the extent that the new work is
> derivative of the GPL'd work. This is why, for example, running my
> proprietary program on a Linux box doesn't mean my proprietary program
> is covered under the GPL. Although it uses the kernel, and in a very
> real sense the kernel links into the program due to address space
> mapping for system calls and the like, this isn't enough to make my
> program a derivative work. So it isn't 'black' vs 'white' but more of
> a 'this shade of grey is more white than black' or vice versa.
The kernel contains exceptions for userland code. If it didn't, you would be
unable to distribute your program alongside Linux.
> I can make "fair use" use of GPL'd software with no restrictions
> what-so-ever so long as that use falls within 'fair use' as defined by
> copyright law. I can also use GPL'd code that doesn't quaify for
> copyright protection (as is the case if it lacks a creative element,
> is the only possible way to do something, etc).
How does linking fit under "fair use"?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-22 16:23 ` Luke -Jr
@ 2007-06-22 16:46 ` M. Warner Losh
2007-06-22 17:11 ` Luke -Jr
0 siblings, 1 reply; 16+ messages in thread
From: M. Warner Losh @ 2007-06-22 16:46 UTC (permalink / raw)
To: qemu-devel, luke
In message: <200706221123.45997.luke@dashjr.org>
Luke -Jr <luke@dashjr.org> writes:
: On Friday 22 June 2007 11:07, you wrote:
: > > On Thursday 21 June 2007 17:33, M. Warner Losh wrote:
: > > > The GPL only has as much force of law as copyright law gives it, and in
: > > > order to be applicable, the work in question must somehow rely on the
: > > > GPL'd work. The "somehow" here is an interesting legal question that
: > > > hasn't been well settled.
: > >
: > > And copyright law by default grants you no rights to modify or copy Qemu
: > > at all. The ONLY way you can get permission to copy or modify Qemu is to
: > > agree to the GPL in its entirety-- which does not restrict itself to
: > > merely derivative works, but covers all linking. (note: obvious the
: > > copyright holder(s) can make exceptions to this rule)
: >
: > Actually, the GPL does only apply to derived works, and it plainly
: > says so:
: > 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
: > Linking typically is what makes a derived work, but not necessary. It
: > is just the shade of grey that most people use as a rule of thumb.
:
: That's merely the definition of "Program" as used in the
: license. Read all the requirements, not just definitions...
The definition is what is controlling here. IF it is a derived work
THEN you must do X. If it is not a derived work, then you may do as
you see fit. If what you did somehow wasn't a derivative work, then
the there's no legal basis for forcing compliance with a license.
This is exactly what SCO is trying to do right now with its IBM case.
: > If you do not have a derived work, then you can use and distribute
: > your work as you see fit, without the GPL restrictions. While the GPL
: > is viral, it is only viral to the extent that the new work is
: > derivative of the GPL'd work. This is why, for example, running my
: > proprietary program on a Linux box doesn't mean my proprietary program
: > is covered under the GPL. Although it uses the kernel, and in a very
: > real sense the kernel links into the program due to address space
: > mapping for system calls and the like, this isn't enough to make my
: > program a derivative work. So it isn't 'black' vs 'white' but more of
: > a 'this shade of grey is more white than black' or vice versa.
:
: The kernel contains exceptions for userland code. If it didn't, you would be
: unable to distribute your program alongside Linux.
Even if it didn't, you would be able to. Running a program on a
kernel does not create a derivative work. I believe there is even
case law on this. IIRC, there were cases with IBM and third parties
providing software for mainframes that settled this, but I don't have
the time to do an Internet search here.
It is unclear for the Linux kernel if the 'end run' people do with
loadable modules is a legal way to avoid source distribution. The FSF
doesn't think so. Linus has said he's cool with it, but absent a
statement from all the copyright holders of code in the Linux kernel,
the issue is at best murky. It is unclear if the original poster
tried to do a binary-only module with QEMU if he'd be in compliance or
not (since the end user does the actual linking).
: > I can make "fair use" use of GPL'd software with no restrictions
: > what-so-ever so long as that use falls within 'fair use' as defined by
: > copyright law. I can also use GPL'd code that doesn't quaify for
: > copyright protection (as is the case if it lacks a creative element,
: > is the only possible way to do something, etc).
:
: How does linking fit under "fair use"?
Again, this is another example of how the GPL isn't absolute. There
is case law in reverse engineering cases for game consoles where it
was held to be fair use to copy the ROMs into memory for the purpose
of reverse engineering them. There may be other examples where
linking, or linking-like activities are fair use. The biggest one
being when the original post links in his proprietary module to QEMU.
That's definitely fair use. Distributing the results may or may not
be legal, depending on how the linking is done and a bunch of other
factors.
Warner
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-22 16:46 ` M. Warner Losh
@ 2007-06-22 17:11 ` Luke -Jr
2007-06-22 17:30 ` M. Warner Losh
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Luke -Jr @ 2007-06-22 17:11 UTC (permalink / raw)
To: M. Warner Losh; +Cc: qemu-devel
On Friday 22 June 2007 11:46, M. Warner Losh wrote:
> In message: <200706221123.45997.luke@dashjr.org>
> Luke -Jr <luke@dashjr.org> writes:
> : On Friday 22 June 2007 11:07, you wrote:
> : > > On Thursday 21 June 2007 17:33, M. Warner Losh wrote:
> : > > > The GPL only has as much force of law as copyright law gives it,
> : > > > and in order to be applicable, the work in question must somehow
> : > > > rely on the GPL'd work. The "somehow" here is an interesting legal
> : > > > question that hasn't been well settled.
> : > >
> : > > And copyright law by default grants you no rights to modify or copy
> : > > Qemu at all. The ONLY way you can get permission to copy or modify
> : > > Qemu is to agree to the GPL in its entirety-- which does not restrict
> : > > itself to merely derivative works, but covers all linking. (note:
> : > > obvious the copyright holder(s) can make exceptions to this rule)
> : >
> : > Actually, the GPL does only apply to derived works, and it plainly
> : > says so:
> : > 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
> : > Linking typically is what makes a derived work, but not necessary. It
> : > is just the shade of grey that most people use as a rule of thumb.
> :
> : That's merely the definition of "Program" as used in the
> : license. Read all the requirements, not just definitions...
>
> The definition is what is controlling here. IF it is a derived work
> THEN you must do X. If it is not a derived work, then you may do as
> you see fit. If what you did somehow wasn't a derivative work, then
> the there's no legal basis for forcing compliance with a license.
> This is exactly what SCO is trying to do right now with its IBM case.
Unless you modify or distribute the work. These acts are illegal without
compliance with the license.
> : > If you do not have a derived work, then you can use and distribute
> : > your work as you see fit, without the GPL restrictions. While the GPL
> : > is viral, it is only viral to the extent that the new work is
> : > derivative of the GPL'd work. This is why, for example, running my
> : > proprietary program on a Linux box doesn't mean my proprietary program
> : > is covered under the GPL. Although it uses the kernel, and in a very
> : > real sense the kernel links into the program due to address space
> : > mapping for system calls and the like, this isn't enough to make my
> : > program a derivative work. So it isn't 'black' vs 'white' but more of
> : > a 'this shade of grey is more white than black' or vice versa.
> :
> : The kernel contains exceptions for userland code. If it didn't, you would
> : be unable to distribute your program alongside Linux.
>
> Even if it didn't, you would be able to. Running a program on a
> kernel does not create a derivative work. I believe there is even
> case law on this. IIRC, there were cases with IBM and third parties
> providing software for mainframes that settled this, but I don't have
> the time to do an Internet search here.
I bet those cases weren't distributing the kernel along with their software,
were they?
> It is unclear for the Linux kernel if the 'end run' people do with
> loadable modules is a legal way to avoid source distribution. The FSF
> doesn't think so. Linus has said he's cool with it, but absent a
> statement from all the copyright holders of code in the Linux kernel,
> the issue is at best murky. It is unclear if the original poster
> tried to do a binary-only module with QEMU if he'd be in compliance or
> not (since the end user does the actual linking).
It is undisputed that it would be in violation if the kernel was distributed
with the modules. The GPL is clear that mere use (end user) is always
allowed. It is also fairly clear (the opinions of many kernel developers and
IP lawyers) that proprietary modules for Linux are illegal to distribute. As
with all copyright violations, however, the liability is on the distributor's
end, so the end user is again not liable for the download either.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-22 17:11 ` Luke -Jr
@ 2007-06-22 17:30 ` M. Warner Losh
2007-06-22 17:31 ` Ronnie Misra
2007-06-22 17:37 ` Johannes Schindelin
2 siblings, 0 replies; 16+ messages in thread
From: M. Warner Losh @ 2007-06-22 17:30 UTC (permalink / raw)
To: luke; +Cc: qemu-devel
[[ This is my last post on this topic, as we're starting to get quite
far afield from QEMU and I'm starting to repeat myself. "Luke -Jr"
wants the last word, he can have it ]]
In message: <200706221211.58845.luke@dashjr.org>
Luke -Jr <luke@dashjr.org> writes:
: On Friday 22 June 2007 11:46, M. Warner Losh wrote:
: > In message: <200706221123.45997.luke@dashjr.org>
: > Luke -Jr <luke@dashjr.org> writes:
: > : On Friday 22 June 2007 11:07, you wrote:
: > : > > On Thursday 21 June 2007 17:33, M. Warner Losh wrote:
: > : > > > The GPL only has as much force of law as copyright law gives it,
: > : > > > and in order to be applicable, the work in question must somehow
: > : > > > rely on the GPL'd work. The "somehow" here is an interesting legal
: > : > > > question that hasn't been well settled.
: > : > >
: > : > > And copyright law by default grants you no rights to modify or copy
: > : > > Qemu at all. The ONLY way you can get permission to copy or modify
: > : > > Qemu is to agree to the GPL in its entirety-- which does not restrict
: > : > > itself to merely derivative works, but covers all linking. (note:
: > : > > obvious the copyright holder(s) can make exceptions to this rule)
: > : >
: > : > Actually, the GPL does only apply to derived works, and it plainly
: > : > says so:
: > : > 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
: > : > Linking typically is what makes a derived work, but not necessary. It
: > : > is just the shade of grey that most people use as a rule of thumb.
: > :
: > : That's merely the definition of "Program" as used in the
: > : license. Read all the requirements, not just definitions...
: >
: > The definition is what is controlling here. IF it is a derived work
: > THEN you must do X. If it is not a derived work, then you may do as
: > you see fit. If what you did somehow wasn't a derivative work, then
: > the there's no legal basis for forcing compliance with a license.
: > This is exactly what SCO is trying to do right now with its IBM case.
:
: Unless you modify or distribute the work. These acts are illegal without
: compliance with the license.
Modifying the work may create a derivative work. If it does (and it
usually does), then you are correct. If it does not for some reason,
then the terms do not apply.
: > : > If you do not have a derived work, then you can use and distribute
: > : > your work as you see fit, without the GPL restrictions. While the GPL
: > : > is viral, it is only viral to the extent that the new work is
: > : > derivative of the GPL'd work. This is why, for example, running my
: > : > proprietary program on a Linux box doesn't mean my proprietary program
: > : > is covered under the GPL. Although it uses the kernel, and in a very
: > : > real sense the kernel links into the program due to address space
: > : > mapping for system calls and the like, this isn't enough to make my
: > : > program a derivative work. So it isn't 'black' vs 'white' but more of
: > : > a 'this shade of grey is more white than black' or vice versa.
: > :
: > : The kernel contains exceptions for userland code. If it didn't, you would
: > : be unable to distribute your program alongside Linux.
: >
: > Even if it didn't, you would be able to. Running a program on a
: > kernel does not create a derivative work. I believe there is even
: > case law on this. IIRC, there were cases with IBM and third parties
: > providing software for mainframes that settled this, but I don't have
: > the time to do an Internet search here.
:
: I bet those cases weren't distributing the kernel along with their software,
: were they?
They were, actually. The cases I'm thinking of had to do with VARs
integrating their software and shipping the systems to end users.
Similar, but not identical.
: > It is unclear for the Linux kernel if the 'end run' people do with
: > loadable modules is a legal way to avoid source distribution. The FSF
: > doesn't think so. Linus has said he's cool with it, but absent a
: > statement from all the copyright holders of code in the Linux kernel,
: > the issue is at best murky. It is unclear if the original poster
: > tried to do a binary-only module with QEMU if he'd be in compliance or
: > not (since the end user does the actual linking).
:
: It is undisputed that it would be in violation if the kernel was distributed
: with the modules.
It is not undisputed. Linus Torvalds doesn't hold that view, for
example. All the wireless device makers today that are based on linux
use binary-only modules for their wireless devices. Similar issues
happen with NTFS write support in many of network attached storage
devices. These devices are distributed with both the kernel and
devices in the same flash.
I've included some examples of divergent opinion within the Linux
kernel community below.
: The GPL is clear that mere use (end user) is always allowed. It is
: also fairly clear (the opinions of many kernel developers and IP
: lawyers) that proprietary modules for Linux are illegal to
: distribute. As with all copyright violations, however, the liability
: is on the distributor's end, so the end user is again not liable for
: the download either.
This does not square with Linus' prior statements that loadable
modules are OK. He's written extensively about this, and his position
is a little more nuanced than 'good' vs 'bad.' in that he considers
how the module was written, and whether or not the methods make that
driver a derivative work or not. See for example:
http://www.linuxdevices.com/news/NS3501846795.html
which spells out this position quite clearly. And a much earlier post
on the topic from Linus, which reads almost the same as the above one
from 2007:
http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
For examples of vendors that do not hold your view, see:
http://aplawrence.com/Blog/B1045.html
Like I said, this is an area of dispute. Some people think that it is
contrary to the license, while others believe this is a legitimate
loophole. For the binary modules are not ok, see:
http://www.oreillynet.com/linux/blog/2006/08/why_binaryonly_linux_kernel_mo.html
Hence my very careful wording about there being a dispute. Both sides
have good arguments on their side, and the matter is far from settled.
Warner
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-22 17:11 ` Luke -Jr
2007-06-22 17:30 ` M. Warner Losh
@ 2007-06-22 17:31 ` Ronnie Misra
2007-06-22 17:37 ` Johannes Schindelin
2 siblings, 0 replies; 16+ messages in thread
From: Ronnie Misra @ 2007-06-22 17:31 UTC (permalink / raw)
To: qemu-devel
On Jun 22, 2007, at 10:11 AM, Luke -Jr wrote:
> On Friday 22 June 2007 11:46, M. Warner Losh wrote:
>> In message: <200706221123.45997.luke@dashjr.org>
>> Luke -Jr <luke@dashjr.org> writes:
>> : On Friday 22 June 2007 11:07, you wrote:
>> : > > On Thursday 21 June 2007 17:33, M. Warner Losh wrote:
>> : > > > The GPL only has as much force of law as copyright law
>> gives it,
>> : > > > and in order to be applicable, the work in question must
>> somehow
>> : > > > rely on the GPL'd work. The "somehow" here is an
>> interesting legal
>> : > > > question that hasn't been well settled.
>> : > >
>> : > > And copyright law by default grants you no rights to modify
>> or copy
>> : > > Qemu at all. The ONLY way you can get permission to copy or
>> modify
>> : > > Qemu is to agree to the GPL in its entirety-- which does not
>> restrict
>> : > > itself to merely derivative works, but covers all linking.
>> (note:
>> : > > obvious the copyright holder(s) can make exceptions to this
>> rule)
>> : >
>> : > Actually, the GPL does only apply to derived works, and it
>> plainly
>> : > says so:
>> : > 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
>> : > Linking typically is what makes a derived work, but not
>> necessary. It
>> : > is just the shade of grey that most people use as a rule of
>> thumb.
>> :
>> : That's merely the definition of "Program" as used in the
>> : license. Read all the requirements, not just definitions...
>>
>> The definition is what is controlling here. IF it is a derived work
>> THEN you must do X. If it is not a derived work, then you may do as
>> you see fit. If what you did somehow wasn't a derivative work, then
>> the there's no legal basis for forcing compliance with a license.
>> This is exactly what SCO is trying to do right now with its IBM case.
>
> Unless you modify or distribute the work. These acts are illegal
> without
> compliance with the license.
>
>> : > If you do not have a derived work, then you can use and
>> distribute
>> : > your work as you see fit, without the GPL restrictions. While
>> the GPL
>> : > is viral, it is only viral to the extent that the new work is
>> : > derivative of the GPL'd work. This is why, for example,
>> running my
>> : > proprietary program on a Linux box doesn't mean my proprietary
>> program
>> : > is covered under the GPL. Although it uses the kernel, and in
>> a very
>> : > real sense the kernel links into the program due to address space
>> : > mapping for system calls and the like, this isn't enough to
>> make my
>> : > program a derivative work. So it isn't 'black' vs 'white' but
>> more of
>> : > a 'this shade of grey is more white than black' or vice versa.
>> :
>> : The kernel contains exceptions for userland code. If it didn't,
>> you would
>> : be unable to distribute your program alongside Linux.
>>
>> Even if it didn't, you would be able to. Running a program on a
>> kernel does not create a derivative work. I believe there is even
>> case law on this. IIRC, there were cases with IBM and third parties
>> providing software for mainframes that settled this, but I don't have
>> the time to do an Internet search here.
>
> I bet those cases weren't distributing the kernel along with their
> software,
> were they?
>
>> It is unclear for the Linux kernel if the 'end run' people do with
>> loadable modules is a legal way to avoid source distribution. The
>> FSF
>> doesn't think so. Linus has said he's cool with it, but absent a
>> statement from all the copyright holders of code in the Linux kernel,
>> the issue is at best murky. It is unclear if the original poster
>> tried to do a binary-only module with QEMU if he'd be in
>> compliance or
>> not (since the end user does the actual linking).
>
> It is undisputed that it would be in violation if the kernel was
> distributed
> with the modules. The GPL is clear that mere use (end user) is always
> allowed. It is also fairly clear (the opinions of many kernel
> developers and
> IP lawyers) that proprietary modules for Linux are illegal to
> distribute. As
> with all copyright violations, however, the liability is on the
> distributor's
> end, so the end user is again not liable for the download either.
Definitions/terms of the GPL aside, here's what the QEMU license file
says:
> The following points clarify the QEMU license:
>
> 1) QEMU as a whole is released under the GNU General Public License
>
> 2) Parts of QEMU have specific licenses which are compatible with the
> GNU General Public License. Hence each source file contains its own
> licensing information.
>
> In particular, the QEMU virtual CPU core library (libqemu.a) is
> released under the GNU Lesser General Public License. Many hardware
> device emulation sources are released under the BSD license.
>
> 3) QEMU is a trademark of Fabrice Bellard.
If the original poster is able to do what he wants using only the BSD-
licensed hardware device emulation and the LGPL-licensed libqemu, I
believe that he is free to distribute a *dynamically linked* machine
emulator without placing his new code under the GPL. However, he will
have to be very careful to only use those parts of QEMU that are
explicitly LGPL- or BSD-licensed, and if he modifies any LGPL files,
he will have to release any of his changes.
For example, note that every file in the "target-i386" directory is
licensed under the LGPL, hw/usb.c is BSD-licensed, but hw/pxa2xx.c is
GPL-licensed.
Ronnie
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-22 17:11 ` Luke -Jr
2007-06-22 17:30 ` M. Warner Losh
2007-06-22 17:31 ` Ronnie Misra
@ 2007-06-22 17:37 ` Johannes Schindelin
2007-06-22 18:00 ` Luke -Jr
2 siblings, 1 reply; 16+ messages in thread
From: Johannes Schindelin @ 2007-06-22 17:37 UTC (permalink / raw)
To: Luke -Jr; +Cc: qemu-devel
Hi,
On Fri, 22 Jun 2007, Luke -Jr wrote:
> On Friday 22 June 2007 11:46, M. Warner Losh wrote:
>
> > If what you did somehow wasn't a derivative work, then the there's no
> > legal basis for forcing compliance with a license.
>
> Unless you modify or distribute the work. These acts are illegal without
> compliance with the license.
No. If what you did was not a derivative work, then it was no derivative
work, then it was no derivative work.
So if you changed a GPL program, and distribute that, you have to license
these changes with the same license.
If at the same time you make something original, which is not derived from
the GPLed program, then you are as free as a bird to sh*t on the GPL with
regards to your original work. You can choose whatever license, if any.
What you throw about here, Luke, is FUD.
The GPL is only insofar viral as you cannot take something GPLed and just
relicense it at will. Not even when you modify it.
However, writing a virtual device that just happens to be dynamically
linkable to QEmu, but might just as well be linked to VMWare, is fine.
This virtual device is clearly _not_ derived from QEmu.
You can do something like that easily, by implementing a clean interface
for QEmu, which allows you to runtime link with such a standalone virtual
device. A couple of people would even thank you for that.
Besides, QEmu's core is LGPL. Not GPL.
All this discussion is moot though. If you're not a lawyer, you should
not behave like one, and respect the wishes of the authors for a change.
> It is undisputed that it would be in violation if the kernel was
> distributed with the modules.
Nope. It is not undisputed.
> The GPL is clear that mere use (end user) is always allowed.
That's right.
> It is also fairly clear (the opinions of many kernel developers and IP
> lawyers) that proprietary modules for Linux are illegal to distribute.
Nope. Not at all.
I'd rather have your virtual device open sourced, but if you cannot do
that, I'd rather have it closed-source, than not at all.
And please stop this FUD about the GPL being viral and stuff.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-22 17:37 ` Johannes Schindelin
@ 2007-06-22 18:00 ` Luke -Jr
2007-06-22 18:22 ` Johannes Schindelin
0 siblings, 1 reply; 16+ messages in thread
From: Luke -Jr @ 2007-06-22 18:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: qemu-devel
On Friday 22 June 2007 12:37, Johannes Schindelin wrote:
> If at the same time you make something original, which is not derived from
> the GPLed program, then you are as free as a bird to sh*t on the GPL with
> regards to your original work. You can choose whatever license, if any.
Not if you want to distribute the GPL'd work, or anything derived from it.
> The GPL is only insofar viral as you cannot take something GPLed and just
> relicense it at will. Not even when you modify it.
Then explain the difference between the LGPL and GPL. A license that preserves
itself only is pointless without other terms.
> However, writing a virtual device that just happens to be dynamically
> linkable to QEmu, but might just as well be linked to VMWare, is fine.
> This virtual device is clearly _not_ derived from QEmu.
That allows you to distribute the virtual device by itself, not alongside with
Qemu.
> Besides, QEmu's core is LGPL. Not GPL.
Good point, and makes this entire argument mostly irrelevant.
> > It is undisputed that it would be in violation if the kernel was
> > distributed with the modules.
>
> Nope. It is not undisputed.
It is undisputed by anyone who has ever considered the issue as part of
deciding whether or not to do it.
> > It is also fairly clear (the opinions of many kernel developers and IP
> > lawyers) that proprietary modules for Linux are illegal to distribute.
>
> Nope. Not at all.
http://www.kroah.com/log/linux/ols_2006_keynote.html
> I'd rather have your virtual device open sourced, but if you cannot do
> that, I'd rather have it closed-source, than not at all.
I would never buy software without source. Hopefully someday I can apply this
to hardware as well.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-22 18:00 ` Luke -Jr
@ 2007-06-22 18:22 ` Johannes Schindelin
0 siblings, 0 replies; 16+ messages in thread
From: Johannes Schindelin @ 2007-06-22 18:22 UTC (permalink / raw)
To: Luke -Jr; +Cc: qemu-devel
Hi,
On Fri, 22 Jun 2007, Luke -Jr wrote:
> On Friday 22 June 2007 12:37, Johannes Schindelin wrote:
> > If at the same time you make something original, which is not derived from
> > the GPLed program, then you are as free as a bird to sh*t on the GPL with
> > regards to your original work. You can choose whatever license, if any.
>
> Not if you want to distribute the GPL'd work, or anything derived from it.
You can distribute on the same medium, at the same time, two different
programs, one GPL, the other not. No problem. None at all.
> > The GPL is only insofar viral as you cannot take something GPLed and
> > just relicense it at will. Not even when you modify it.
>
> Then explain the difference between the LGPL and GPL. A license that
> preserves itself only is pointless without other terms.
No, it is not.
> > However, writing a virtual device that just happens to be dynamically
> > linkable to QEmu, but might just as well be linked to VMWare, is fine.
> > This virtual device is clearly _not_ derived from QEmu.
>
> That allows you to distribute the virtual device by itself, not
> alongside with Qemu.
To the contrary. You can distribute them both at the same time, under
different conditions, much like you can distribute QEmu with parts GPL,
parts LGPL, and parts BSD.
> > Besides, QEmu's core is LGPL. Not GPL.
>
> Good point, and makes this entire argument mostly irrelevant.
Not at all. If it was a derivative work of the LGPLed part, it would still
have to be LGPLed.
> > > It is undisputed that it would be in violation if the kernel was
> > > distributed with the modules.
> >
> > Nope. It is not undisputed.
>
> It is undisputed by anyone who has ever considered the issue as part of
> deciding whether or not to do it.
There are distributions which deliver closed source binary-only modules.
Many LiveCDs for example.
> > > It is also fairly clear (the opinions of many kernel developers and
> > > IP lawyers) that proprietary modules for Linux are illegal to
> > > distribute.
> >
> > Nope. Not at all.
>
> http://www.kroah.com/log/linux/ols_2006_keynote.html
That is Greg's opinion. There are others. Notably Linus'.
> > I'd rather have your virtual device open sourced, but if you cannot do
> > that, I'd rather have it closed-source, than not at all.
>
> I would never buy software without source. Hopefully someday I can apply
> this to hardware as well.
That is your freedom.
Frankly, I get really bored by the license discussions these days. Gone
seem the days where you discussed code and algorithms on the mailing
lists. Sigh.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] QEMU License and proprietary hardware
2007-06-21 11:28 [Qemu-devel] QEMU License and proprietary hardware Armbrost Failsafe
2007-06-21 22:24 ` Luke -Jr
@ 2007-06-24 20:10 ` Paul Brook
1 sibling, 0 replies; 16+ messages in thread
From: Paul Brook @ 2007-06-24 20:10 UTC (permalink / raw)
To: qemu-devel; +Cc: Armbrost Failsafe
On Thursday 21 June 2007, Armbrost Failsafe wrote:
> We are looking into using QEMU as the base for a model of a custom system
> featuring some custom ASICs. But licensing issues are halting the process
> right now. Does anyone know what happens license-wise if we create a model
> of proprietary hardware using QEMU? Is that model automatically covered by
> the GPL and thus we have to give to anyone who asks about it? It is clear
> that if we keep it internal, it is OK. But anyone outside of our
> organization is to use it, shouldn't they automatically be entitled to
> receive the entire source of QEMU, including our models of proprietary
> devices?
Please read
As someone who has written significant portions of qemu code, and would be in
a position to enforce the licence requirements, teh short answer is:
- If you never distribute (give away or sell) your model to anyone, you can do
what you like.
- If you distribute binaries containing GPL code you must also provide source
for the whole application, including your model.
- If you remove all the GPL code from qemu (leaving just the LGPL/BSD parts)
and distribute the remainder then you must provide source for all the LGPL
parts you have touched, and some mechanism for relinking modified versions of
qemu against your proprietary components.
If you disagree with my summarry then you need to contact the Free Software
Foundation and/or seek professional legal advice. As others have mentioned
(with varying degrees of accuracy) there are grey areas and different legal
interpretations of the terms of the GPL. This in not the correct place for
such discussions.
See also http://www.gnu.org/licenses/licenses.html#GPL
> Even if these are developed from scratch without using any
> existing source code for devices?
IMHO this question doesn't make any sense. Either you're using (linking with)
GPL code, or you aren't.
Paul
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2007-06-24 20:10 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-21 11:28 [Qemu-devel] QEMU License and proprietary hardware Armbrost Failsafe
2007-06-21 22:24 ` Luke -Jr
2007-06-21 22:33 ` M. Warner Losh
2007-06-22 15:18 ` Luke -Jr
2007-06-22 16:07 ` Warner Losh
2007-06-22 16:23 ` Luke -Jr
2007-06-22 16:46 ` M. Warner Losh
2007-06-22 17:11 ` Luke -Jr
2007-06-22 17:30 ` M. Warner Losh
2007-06-22 17:31 ` Ronnie Misra
2007-06-22 17:37 ` Johannes Schindelin
2007-06-22 18:00 ` Luke -Jr
2007-06-22 18:22 ` Johannes Schindelin
2007-06-24 20:10 ` Paul Brook
-- strict thread matches above, loose matches on Subject: below --
2007-06-22 5:34 Balazs Attila-Mihaly (Cd-MaN)
2007-06-22 15:21 ` Luke -Jr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).