* [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-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 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
* 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-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
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).