On Thu, Dec 11, 2003 at 11:46:47PM +1100, Benno wrote:
The part that particularly annoys me at the moment is the definition
of derivative work. So if anyone feels like clarifying just jump right
in. Its not a derivative work if you fork/exec something to interface with it, but if you dynamically link against it, it is.
This seems so, well, arbitrary, and not pertaining to any logic that
I can understand. <sigh>. Defining a derivative work in terms of address space/process boundaries just seems wrong to me.
Some of us are paid to write commercial software.
Me too.
One difference here is that MS and other OSes are licensed on a 'use' basis. They don't care how integrated you stuff is, so long as you or your customer pay their OS license.
One of our products, including kernel patches and kernel modules, was first released on Compaq Tru64, and is also sold on Solaris. A related product is even sold on Microsoft. But when we port our Unix code to Linux, some people seem to think it gets to be a derived work of the OS which isn't a derived work of Unix.
The 'payment' required under the GPL license is the contribution of more GPL code, but at the same time all use of GPL works is totally unrestricted. Unlike the proprietary OSes, or middleware, the original developers gain nothing from sales of operating systems or hardware or whatever. I think this is a good reason for GPL contributors to be quite harsh on enforcing the terms under which they actually do receive 'payment'.
As a perhaps silly example, say some guys write a very good media player which links against the OS provided multimedia components, Microsoft says 'Great, another good app for our platform, that means more sales'. If someone writes a very good media player, linked against a GPL'd OS provided mutimedia component, the GPL developers should have a right to say "Great, another good app for our platform, that means more GPL code is available to us, and everyone else".
I have no idea what it is btw.(For those who know the company or the product, this is new code, written from scratch, with no sources derived from earlier products we sold on other brand-name Unixes.)
For a standard library, unless it was LGPL, it wouldn't matter where the inlines ended up, your code must also be GPL. I get the impression that binary kernel modules have been pretty much defined as 'runtime use' of the kernel, as an exception to the rule. Of course, once you start including GPL object code in your module, it's no longer just 'use', hence the inline concerns.The argument I've seen quoted about inlines in kernel headers sprinkling generated GPL code through one's object files seems spurious to me, being a coincidental consequence of choosing a particular compiler. (Some people use other compilers for free OS kernels, you know.) The C standard requires the behaviour of inlines to be equivalent (modulo performance) to putting the generated code elsewhere as if it weren't inline.
Using POSIX or C headers doesn't make your code a derived work of the POSIX or C standards, so I fail to see why this should be different for Linux.
Because Linux developers *want* it to be different, and they have a right to say what is allowed or not.
Consider this scenario (as far as I know, this is entirely fictional): somebody writes some really good documentation for certain kernel interfaces of Linux (unlikely given the general standard of Linux documentation); somebody else writes some headers defining these interfaces, using only the document just generated. Neither the documentation nor these headers would be a derived work of the original kernel headers, and the new headers are not a derived work of the documentation, at least in terms of copyright law. The document and new kernel headers would therefore have whatever license the authors chose to apply. To avoid issues of "contamination", one would probably arrange for the document writer not to participate in the writing of the headers, and vice versa. If the license chosen for the new headers was not the GPL, somebody writing a Linux kernel module against these new headers would have used no GPL code, and therefore the module would not be GPL unless its author chose so.
If I got someone to write a very detailed summary of a novel, and then 'rewrote' it based on the summary, it would still be plagiarism, and a copywrite violation if I sold it.
Headers are irrelevant, not every language uses them. It's the fact that you are linking at all, not the method.
Given the argument that one can get an equivalent result without using GPL headers, I fail to see how the fact that the headers are GPL would in itself contaminate the resulting code. (Yes, I know that linking GPL code into the same kernel module would contaminate the resulting code anyway, but if one can avoid such linking, the issue is not so clear.)
I don't think anything like that is legal. Try this scenario:Before you get upset at me, I would probably agree that while the previous two paragraphs may indicate a legal path, this is probably contrary to Linus's expressed intention. (Not everything legal is moral; not everything moral is legal. I prefer to satisfy both where possible.)
I have a license for MS SQL Server, and a 5 user license for same. I write a custom network server which takes user requests for data, in Swedish, translates these requests into ANSI SQL, retrieves data from MSSQL, retranslates it into Swedish, and sends it off to the user.
Do you think MS will be happy if I connect 250 users to my custom server without buying more licenses? No, I'm only trying to weasel out of my agreement with them.
I reckon that if you think long term, more people have more rights under the GPL. What rights do you have to the BSD code that MS modified for NT?In the BSD world, we have freedom to port our product in without somebody's license attempting to restrict our use of our own original code. In my more exasperated moments (and speaking personally) I find the GPL's restriction of rights to be just as offensive as SCO's attempts to control IBM's distribution of stuff they (IBM) wrote. I do use GPL stuff, and comply with the license, but I wouldn't particularly want to spend any time on fixing it.
Not quite as silly as if everyone rewrote everything every single time, as is often done with closed source.Just as some of the more doctrinaire GPL anti-BSD people rewrite code from scratch rather than contributing to existing BSD code, some of the more doctrinaire BSD anti-GPL people do the same to avoid GPL code, just so they can have their stuff under a freer license. It's all a bit silly, eh?
Are you 100% convinced that this is totally unlike weaselling out of the GPL license?Back to the practical: for our Linux product, we are pushing code from kernel to user space, modifying the gross structure of the whole thing (changing from event driven to polling). Yes, we are GPLing what's left in the Linux kernel, but only after the significant IP is moved to somewhere safe.
It seems a little that way to me.
Has anyone there considered making the Linux version GPL? That would really be complying with the spirit of the license.Just because we're doing this, doesn't mean we think it was always the best way to do it - it could be we're just sick of arguing the point, and have chosen to comply not just with the obvious and direct interpretation of the GPL but with some of the less certain and more arguable parts of the thing.
Horses for courses =)Oh yes, my personal choice is to run *BSD at home. Trying to get Fedora working at home recently (specifically for Planet CCRMA) reminded me why it's only at work I run on Linux.
Thanks for discussing this stuff.
Felix
-- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
