freed_symbols [Re: People, not GPL [was: Re: Driver Model]]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
On Mon, 06 Oct 2003 03:40:05 +0200, you wrote in linux.kernel:
Quoted 4 lines
A much more obvious example than the SCM one is a device driver or a module. That's so cut and dried it isn't even open to debate in the eyes of the law. It's a hard and fast boundary, the GPL can't cross it no matter what people think or want (on either side).
Huh? How is a driver an independent work under the definition you gave? I can't take the Linux kernel out and insert the driver into another kernel and have it still work. Only the opposite is true - the kernel would run without the driver, and therefore the kernel is not a derived work of the driver and can't be subject to license terms of the driver.
The kernel doesn't have a defined interface for drivers. It changes a lot at least during a development series. A driver is not independent from the kernel running under it because it has to be changed quite often to adapt to the changing internal kernel interfaces.
You can't even change the Linux kernel version you're using and have the same driver still work for you. So by your definition, a driver is at least in part a derived work of the kernel.
Now, if the driver has an internal abstraction layer that seperates the kernel side of things from the real work the driver does, I would agree that only the abstraction layer is a derived work and has to be GPL'd, not the rest of the driver.
Most drivers don't work that way because of the additional overhead.
Signature · 2 lines
Ciao, Pascal
Quoted 7 lines · Pascal Schmidt
On Mon, 06 Oct 2003 03:40:05 +0200, you wrote in linux.kernel:
Quoted 4 lines
A much more obvious example than the SCM one is a device driver or a module. That's so cut and dried it isn't even open to debate in the eyes of the law. It's a hard and fast boundary, the GPL can't cross it no matter what people think or want (on either side).
Quoted 5 lines
Huh? How is a driver an independent work under the definition you gave? I can't take the Linux kernel out and insert the driver into another kernel and have it still work. Only the opposite is true - the kernel would run without the driver, and therefore the kernel is not a derived work of the driver and can't be subject to license terms of the driver.
The thing that is trying to cross the boundary is the kernel license so what matters is if the thing which you believe should be GPLed is separable or not.
Quoted 4 lines
The kernel doesn't have a defined interface for drivers. It changes a lot at least during a development series. A driver is not independent from the kernel running under it because it has to be changed quite often to adapt to the changing internal kernel interfaces.
That has no bearing on the legalities. A version of the kernel can't force the GPL on a driver that works with that version of the kernel because you can pull that driver out and drop in another. A great example is the eepro driver, there is Becker's version and the Intel version. Any judge who wasn't fooled by Microsoft priced lawyers would clearly see the boundary and make a ruling that the GPL can't cross over it.
By the way, many people here want to argue against this point of view because they are pro GPL. OK, fine, maybe you can change the laws and make that stick. I very much doubt it but let's suppose you do. By doing that you will be supporting SCO's legal case. If the GPL can cross over those boundaries than so can SCO's license. You can't have one set of rules for you and another set of rules for them, you have to apply them to everyone.
When you understand that you will understand more clearly why I bother to comment on this at all.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 6 lines · Larry McVoy
That has no bearing on the legalities. A version of the kernel can't force the GPL on a driver that works with that version of the kernel because you can pull that driver out and drop in another. A great example is the eepro driver, there is Becker's version and the Intel version. Any judge who wasn't fooled by Microsoft priced lawyers would clearly see the boundary and make a ruling that the GPL can't cross over it.
So you're saying the LGPL and the GPL mean the same thing for libraries? That, for instance, you can handle Qt as if it was LGPL?
OG.
Quoted 10 lines · Olivier Galibert
Quoted 6 lines · Larry McVoy
That has no bearing on the legalities. A version of the kernel can't force the GPL on a driver that works with that version of the kernel because you can pull that driver out and drop in another. A great example is the eepro driver, there is Becker's version and the Intel version. Any judge who wasn't fooled by Microsoft priced lawyers would clearly see the boundary and make a ruling that the GPL can't cross over it.
So you're saying the LGPL and the GPL mean the same thing for libraries? That, for instance, you can handle Qt as if it was LGPL?
I think so, I'm afraid. I know that this view of the law isn't what people think is true and the end result may well be a court case which tests it.
You can sort of see how the logic works. There has to be some sort of boundary, right? Does anyone really think that if Linus hadn't said that the GPL doesn't cross over to the user apps that the GPL really would have crossed over? So if there is a boundary concept, how do you define what a boundary is? Is that left to each license or is that part of the law? As far as I can tell, that's part of the law, it has a concept of a boundary already. The lawyers got a little squirmy around this part and I got the sense that what is a boundary is not universally established. But everyone seemed to think that allowing licenses which bleed over into "unrelated" stuff is about as legal as contracts imposing human slavery, i.e., both are not legal.
It's certainly not a done a deal, I think that sooner or later there will be some court case that establishes the case law on which all future cases will be based. The people I know who care about the GPL dread this case because the GPL has sort of had it both ways for a long time and that can't continue. If you want the law to be that SCO can't claim all the IP that was built on top of the original Unix then that same law also says that the GPL can't claim dominion over separable works either.
I can also image that the Qt people are less than thrilled with what I'm saying because it basically invalidates the GPL-ed library or pay for a non-GPLed version business model.
All of what I say should be taken with a grain of salt. Yeah, I've spent money trying to understand this and I perhaps understand more than some people here (maybe a lot of people in this instance). That doesn't mean what I say is right. If you really care, if your business depends on it, you need to get a lawyer to work through the issues. Right now, I think the side with the deeper pockets would win, so even though I'm pointing at what I think will be the long term outcome, I'm not sure I'd bet the farm on that. How's that for weasel words?
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 3 lines · Larry McVoy
The thing that is trying to cross the boundary is the kernel license so what matters is if the thing which you believe should be GPLed is separable or not.
Forget boundaries, Larry. Consider the case of the Creosote Public Licence to which I referred before. That one required you to bathe daily in creosote and release _all_ your future work under the same licence; separate works or not.
If you don't comply with the licence, you may not use the original work. It's that simple -- whatever the requirements of the licence are, you obey them or you don't have a licence.
In the case of the CPL, it isn't a crime for you to publish your own non-derived work under another licence, or one day to decide not to bathe in creosote -- but it does place you in violation of the Creosote Public Licence and hence mean that continued use of the _original_ work is a violation of its copyright; and therefore a criminal offence.
This is not about whether a licence _can_ demand this. We know it can -- it can demand the ritual sacrifice of your first-born, and all that means is that if you don't agree, you don't get to use the software in question¹.
This is about whether the GPL _does_ demand this. I believe that it does, and that the user-space exception and the existence of the LGPL make that fact entirely clear.
Signature · 5 lines
dwmw2 ¹ Admittedly, incitement to murder is an offence in most countries but you get the point, and you still wouldn't be permitted to use the software if you didn't do it :)
This discussion is more and more about licenses plus law and less and less about the kernel in particular.
Please folks, take it somewhere else.
Thanks.
We can make up the Monica Public License too, but because it is GPL, your added restrictions of whatever are NULL and VOID. So Creosote Public License, is an effective restriction that is not allowed in GPL.
All your copyright under GPL grants you copyright, all other terms are in the license and adding anything to it is not allowed.
Adding your views in how it should be view is your opinion nothing more. It has no legal bases and is only random noise to promote a wider grey line and more confusion.
There is no standing legal decision in a court of law you can point to to use as a referrence for case law or brief/opinion from the position, officer of the court.
So lets add the Rent License, you pay rent to use the GPL code I have published. Anybody who has ever stored any data on an IDE/ATA/SATA device or ATAPI attached to HOST connected to SFF cable headers of 40 pin or SFF cable PHY headers, must pay me 0.001 cents per byte transfered regardless of direction of success.
This on top of GPL is a usage restriction.
Have a cold shower dude, Creosote reminds me of Slick Willy.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Quoted 42 lines · David Woodhouse
Quoted 3 lines · Larry McVoy
The thing that is trying to cross the boundary is the kernel license so what matters is if the thing which you believe should be GPLed is separable or not.
Forget boundaries, Larry. Consider the case of the Creosote Public Licence to which I referred before. That one required you to bathe daily in creosote and release _all_ your future work under the same licence; separate works or not.
If you don't comply with the licence, you may not use the original work. It's that simple -- whatever the requirements of the licence are, you obey them or you don't have a licence.
In the case of the CPL, it isn't a crime for you to publish your own non-derived work under another licence, or one day to decide not to bathe in creosote -- but it does place you in violation of the Creosote Public Licence and hence mean that continued use of the _original_ work is a violation of its copyright; and therefore a criminal offence.
This is not about whether a licence _can_ demand this. We know it can -- it can demand the ritual sacrifice of your first-born, and all that means is that if you don't agree, you don't get to use the software in question¹.
This is about whether the GPL _does_ demand this. I believe that it does, and that the user-space exception and the existence of the LGPL make that fact entirely clear.
Signature · 11 lines
dwmw2 ¹ Admittedly, incitement to murder is an offence in most countries but you get the point, and you still wouldn't be permitted to use the software if you didn't do it :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hi,
Quoted 2 lines · Andre Hedrick
We can make up the Monica Public License too, but because it is GPL, your added restrictions of whatever are NULL and VOID.
Could you please explain about what "added restrictions" you're talking about? Let's actually look at the GPL, which states "You may not impose any further restrictions on the recipients' exercise of the rights granted herein.", a bit earlier we find "Activities other than copying, distribution and modification are not covered by this License". So how exactly does EXPORT_SYMBOL_GPL restrict you in these activities?
bye, Roman
Roman,
You got my point exactly, keep the issue of license to GPL and not muddy the waters with a license other than GPL as an example.
David's "Creosote Public License" is an example how an author using such a license could require the enduser to conform to his/her wishes, regardless.
His "Creosote Public License" adds restrictions not permitted or covered by the scope of GPL. So generating examples of how that license empowers the author to impose extra restrictions and then saying it is equal to GPL by association is not helping to clear the mudd.
Sorry if I was not clear about the direction of the message.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Quoted 22 lines · Roman Zippel
Hi,
Quoted 2 lines · Andre Hedrick
We can make up the Monica Public License too, but because it is GPL, your added restrictions of whatever are NULL and VOID.
Could you please explain about what "added restrictions" you're talking about? Let's actually look at the GPL, which states "You may not impose any further restrictions on the recipients' exercise of the rights granted herein.", a bit earlier we find "Activities other than copying, distribution and modification are not covered by this License". So how exactly does
EXPORT_SYMBOL_GPLrestrict you in these activities?bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi,
Quoted 2 lines · Andre Hedrick
You got my point exactly, keep the issue of license to GPL and not muddy the waters with a license other than GPL as an example.
Fine, but you didn't answer my questions at all and you're the one complaining about EXPORT_SYMBOL_GPL in first place, so here are the questions again, in case you deleted the original mail already:
Could you please explain about what "added restrictions" you're talking about? Let's actually look at the GPL, which states "You may not impose any further restrictions on the recipients' exercise of the rights granted herein.", a bit earlier we find "Activities other than copying, distribution and modification are not covered by this License". So how exactly does EXPORT_SYMBOL_GPL restrict you in these activities?
bye, Roman
"EXPORT_SYMBOL_GPL" is a license enforcement tool, period.
Any driver using a caller wrappered by "EXPORT_SYMBOL_GPL" will have the function fail quietly and restrict functionality. Restricting functionality is a means to disable drivers period. These very same functions in question are required for any other driver to operate.
That makes them part of the API for operational compatibility. The API is described exclusively by the snapshot version of a given kernel.
So under copyright case law, where GPL has never been, there are rulings and history describing what an API is, how it can not be protected, and determinations of fair use based on legal rulings.
Now if one is forced to disable EXPORT_SYMBOL_GPL and redistribute the modified kernel source as a single object, there is nothing anybody can do to stop that process.
A simple solution is to publish an EXPORT_SYMBOL shim so one would not be subject to the issues of distribution clauses. The SHIM is GPL-compatable and it provides clear exports of the API snapshot.
Separtion of the logical .c shim module driver and the decoupled .h is making the boundary clear.
However this is a was of time because neither you (best guess) and the majority here have ever paid to have the license explained and how it is subject to actual copyright laws. In the past I was one of the folks shouting opinions not facts. The facts are rude eye openers.
Well David Miller is going to stomp the thread so lets do it for him?
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Quoted 20 lines · Roman Zippel
Hi,
Quoted 2 lines · Andre Hedrick
You got my point exactly, keep the issue of license to GPL and not muddy the waters with a license other than GPL as an example.
Fine, but you didn't answer my questions at all and you're the one complaining about
EXPORT_SYMBOL_GPLin first place, so here are the questions again, in case you deleted the original mail already:Could you please explain about what "added restrictions" you're talking about? Let's actually look at the GPL, which states "You may not impose any further restrictions on the recipients' exercise of the rights granted herein.", a bit earlier we find "Activities other than copying, distribution and modification are not covered by this License". So how exactly does
EXPORT_SYMBOL_GPLrestrict you in these activities?bye, Roman
Hi,
Quoted 4 lines · Andre Hedrick
"
EXPORT_SYMBOL_GPL" is a license enforcement tool, period.Any driver using a caller wrappered by "
EXPORT_SYMBOL_GPL" will have the function fail quietly and restrict functionality.
If I understand you correctly, you cannot tell me how EXPORT_SYMBOL_GPL is an additional restriction according to the GPL.
OTOH what's wrong with enforcing a license?
Quoted 7 lines
Restricting
functionality is a means to disable drivers period. These very same functions in question are required for any other driver to operate.That makes them part of the API for operational compatibility. The API is described exclusively by the snapshot version of a given kernel.
What gave you the right to use the API or the implementation of this API in first place?
Quoted 1 line
So under copyright case law, where GPL has never been,
Could you please explain, what you're trying to say here?
Quoted 7 lines
there are rulings
and history describing what an API is, how it can not be protected, and determinations of fair use based on legal rulings.Now if one is forced to disable
EXPORT_SYMBOL_GPLand redistribute the modified kernel source as a single object, there is nothing anybody can do to stop that process.
Why would you be forced to disable EXPORT_SYMBOL_GPL? You can do that of course as long as you respect the conditions in the GPL, but that wouldn't require modifying EXPORT_SYMBOL_GPL.
Quoted 6 lines
A simple solution is to publish an
EXPORT_SYMBOLshim so one would not be subject to the issues of distribution clauses. The SHIM is GPL-compatable and it provides clear exports of the API snapshot.Separtion of the logical .c shim module driver and the decoupled .h is making the boundary clear.
Could you please explain how your binary module can be "reasonably considered independent", so that you don't have to distribute it under the GPL? How are boundaries of any importance, if you not allowed to use the GPL part in first place? Alternatively what gives you the right to ignore the will of the copyright owner and distribute the GPL part under your own conditions?
Quoted 4 lines
However this is a was of time because neither you (best guess) and the majority here have ever paid to have the license explained and how it is subject to actual copyright laws. In the past I was one of the folks shouting opinions not facts. The facts are rude eye openers.
Well, what I have seen so far is that your logic stinks mightily and you are twisting reality to your own needs and on this way showing absolutely no respect for the work of others.
bye, Roman
Please guys, stop this thread as I kindly asked earlier this evening.
I hate being truant officer, I in fact hate it. So please just be reasonable.
Quoted 4 lines · David Woodhouse
This is not about whether a licence _can_ demand this. We know it can -- it can demand the ritual sacrifice of your first-born, and all that means is that if you don't agree, you don't get to use the software in question??.
No, that's the point you have been missing all along. Any unenforceable clause is null and void. Read section 7 of the GPL and a little law. You can't enforce unenforceable clauses by revoking the license.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 3 lines · Larry McVoy
No, that's the point you have been missing all along. Any unenforceable clause is null and void. Read section 7 of the GPL and a little law. You can't enforce unenforceable clauses by revoking the license.
Actually, most fairly complicated contracts (more than just 2-3 clauses) have a separability clause because if you don't, then the whole contract DOES go poof if you have an unenforceable clause - so without one, the license goes away, revoking itself.
And sure enough, section 7 has:
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances
Quoted 7 lines · Pascal Schmidt
Now, if the driver has an internal abstraction layer that seperates the kernel side of things from the real work the driver does, I would agree that only the abstraction layer is a derived work and has to be GPL'd, not the rest of the driver.
Most drivers don't work that way because of the additional overhead.
And because making such distinction is pointless, since the GPL'd wrapper and the core driver would not be distributed 'as separate works' but rather 'as part of a whole which is a work based on the Program', where the Program in this case is the GPL'd wrapper part.
Hence under the terms of the final paragraph of section 2 of the GPL, the code of the driver would also have to be released under the same terms.
Signature · 1 line
dwmw2