Slashdot Log In
Sun Finds & Exploits Hole in the GPL *Update*
Posted by
CmdrTaco
on Fri Sep 15, 2000 12:45 PM
from the not-playing-fair dept.
from the not-playing-fair dept.
chrisd writes "Sun is shipping binaries (no source code for you!) of some of Donald Beckers work, saying in their defense that "It says that anyone using its kit is responsible for ensuring that how it's used doesn't violate licenses, and that's not Sun's problem."" Update: 09/15 11:30 PM by CT :The article is somewhat confusing here: this is essentially a cross compiler, and Sun isn't distributing anything in violation of the GPL, and if they used their compiler to distribute binary drivers, that wouldn't violate the GPL either, assuming that they distributed the original driver source code as well.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Re:This is what Donald gets... (bullshit) (Score:2)
Yeah. Too bad Be paid him a good chunk of money to license the drivers after he made a stink about it. With enough negative press maybe he can cut an even better deal with Sun.
I still think it's a crock that dynamically loaded GPL'd binaries (for example, gnu ls) don't taint the proprietary libc and kernel they run under, but dynamically loaded drivers do.
-- Brian
contributory negligence? (Score:3)
Seems like Becker was in bad need of PR (Score:3)
2 conclusions:
- those linuxgram folks are clueless and probably dishonest
- Becker is an arrogant asshole who clearly doesn't grasp open source
Sun never asked his permission to convert them to Solaris binaries...
But Becker knows one thing - he wants Sun to stop peddling the kit, which he says includes "explicit instructions on taking a copyrighted work and converting it to unlicensed use with the Solaris operating system."
What a jerk!
If you want anyone who uses your code to suck your dick or give you money (is there any significant difference?), then you release it under a closed source license, not the GPL. The GPL is about writing better code, it's about the pleasure and pride of seeing your code used by many. It's about free software. Nobody needs to thank you for this. It's better if they do but you must be prepared to see people just take it. And expecting users to ask you for permission is blantantly against the spirit of the GPL.
When you release under the GPL, you allow user to do whatever they want with the code, provided:
- that the source comes along with it - the status of which is not clear in the article, so I assume that Sun is ok with that.
- that any derived work becomes GPL - and under no circumstances could Sun's kit (more or less a compiler) be considered as derived from GPL code.
All in all,it appears that Becker is an arrogant, self-conscious kid. I'm afraid that the open source movement is increasingly populated by religious fanatics. Those guys see GPL as a tool for power and totally forgot (or chose to ignore) the real message: freedom.
Donald, if you don't want others to use your code freely, get a job in Redmond.
Just my 2c.
- I will fight for the right to be right - Bowie, 1971
Re:Excellent- WHAT? (Score:2)
I'm sorry, but I did not enjoy working on Sun hardware. Give me a slightly expensive PC any day. At least if something fails, it's relativly cheap to replace.
Bill - aka taniwha
--
No education/non-commercial exception in crnt GPL (Score:2)
Bill - aka taniwha
--
Re:The GPL should be able to handle this... (Score:2)
>copy of the drivers without the source included
And once put in these terms, the objection becomes taht the sun software
*can* be used by someone who is going to commit a violation . . . which,
iirc, has come up around here in a different context
hawk
Re:The GPL should be able to handle this... (Score:2)
> In my opinion, and I'm not an attorney,
But I am, and you're correct (though we have, err, radically different opinions on the GPL
If Sun is only distributing the source of the drivers, they're safe. If they're distributing drivers as binaries, but include the source to those but not to the tools, they're safe.
[note: this doesn't mean it's a good move on Sun's part; there's a basic biting the hand that feeds you problem here . .
What I don't get (Score:2)
Re:Bad journalism (Score:2)
Chris DiBona
VA Linux Systems
--
Grant Chair, Linux Int.
Pres, SVLUG
Re:Contributory Infringment (Score:2)
Chris DiBona
--
Grant Chair, Linux Int.
Pres, SVLUG
Re:Excellent- WHAT? (Score:2)
Their low end boxes aren't cheap either and they aren't worth the money. I have a Sun U10 on my desk and it certainly wasn't worth the money it cost. Only buy Sun if you really need Solaris, otherwise there are much better alternatives.
Not even close to breaking the GPL.. (Score:2)
Re:Agreed. How is this different from compiling? (Score:2)
Re:Both Perens and Becker are wrong (Score:2)
Basically, why are you concerned with what they are doing? They're not stealing the drivers and claiming them for their own. They're simply providing a way for them to run somewhere else. People don;t get in an uproar when someone ports vi to windows, or anything else to an alternate environment.
I guess I don;t get what the concern is all about. The fact that Sun is using Linux kernel things for their own OS, doesn't that merely reenforce the quality of the code?
Re:It's a (cross) compiler! (Score:2)
Re:Both Perens and Becker are wrong (Score:2)
Re:It's a (cross) compiler! (Score:2)
Re:It's a (cross) compiler! (Score:2)
First Semi-Intelligent Reply(TM) (Score:2)
Surely some sort of code within the kernel has to be used in writing the driver. I cannot say with authority since I have never written a kernel driver. But I'm hoping that this post will spur someone to respond to this issue.
Does this mean... (Score:2)
I'm not sure this is a problem that needs to be fixed. I always understood the GPL as meaning that if I integrate GPL'ed code into a program in a way that isn't transparently separable from my new code, then I must GPL my new code along with the GPL'ed older code. But, if my code is transparently separable, like header files or object files, even if they are all compiled into a single binary, then I need only distribute the source for changes I have made to files that were already under GPL. I always thought the idea was that you could use GPL'ed code in your non-open projects, as long as the GPL'ed part is transparently separable and distributed whith the program.
Now, I don't see why a device driver's code would be integrated into Sun's source tree in a non-transparent way. It almost certainly resides in separate files, and is either loaded seperately at compile time or at run time. How, then, would this be a GPL violation, even if Sun changed their kernel to make it compatible with formerly Linux drivers?
If I wrote a program (hypothetically) that turned Linux device drivers into Windows device drivers, I couldn't turn around and sue Microsoft for not GPL'ing their source. I fail to see how this is different.
But (Score:2)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
I would imagine that program modules that are shipped in separate files constitute "identifiable sections." Furthermore, shipping separately doesn't mean on separate CD's, or else Red Hat would have to GPL all the non-GPL'ed programs that ship on their Linux CD's. Yes, if Sun took GPL'ed code (like the TCP/IP stack) and stuffed it into their monolithic kernal binary, that would strike me as a violation, but any part that can be optionally used would seem to me to be a separate work, and rightly so.
Re:The GPL should be able to handle this... (Score:2)
You know... (Score:5)
This isn't a GPL breach, in letter or in spirit. The author of the article is correct: it is the responsibility of driver porters to ensure that their drivers don't violate licenses, not Sun's. In the case of GPL'd drivers, they do this by providing the sources, which they must do for the Linux drivers. Since the Sun toolkit seems to be little more than a recompiler (less than that, actually; more like a relinker) it hasn't actually modified the source any more than a compiler does.
Maybe I'm wrong about the software's nature; I'd appreciate corrections if that is the case. But it looks like a lot of people are blowing this out of proportion. Sun is not violating the GPL. It has created software which could, theoretically, be used as an aid in GPL violation, but isn't intended for that purpose (rather like Napster and DeCSS can be used in violating more restrictive, and some might say unethical, licenses but are not intended for that purpose).
I'll admit, this looks a bit fishy. But I support Napster and DeCSS; because of that I can't cry out against this driver converter without being a hypocrite.
----------
Both Perens and Becker are wrong (Score:4)
Now, if Sun itself is distributing object code derived from GPL software, they have an obligation to follow the GPL with regard to distributing source. It is also unclear whether or not they are doing this. If they are not, then they are in clear violation of the GPL, and I don't see where Bruce sees the gray area. (And, FWIW, they should have asked RMS about this, not Bruce.)
So, in essence, from what we know: 1) the idea of compiling source intended for Linux into a Solaris object code is not objectionable nor a violation of the GPL even if the compiler is not GPL'd; and 2) if Sun uses GPL'd code in their compiler, they must include the source. So on #1, Becker is wrong, and on #2, Perens is wrong. If Sun indeed is using GPL'd code and not including source, then they need to be taken to task. Otherwise, they are not doing anything to violate the GPL.
Re:Agreed. How is this different from compiling? (Score:2)
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Re:Why didn't the author talk to RMS or a lwayer?? (Score:2)
Bruce
Re:Why didn't the author talk to RMS or a lwayer?? (Score:2)
Re:Both Perens and Becker are wrong (Score:2)
Bruce
Re:The GPL should be able to handle this... (Score:2)
Here is the relevant part of the GPL:
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
In my opinion, and I'm not an attorney, this means that you must distribute the driver source, but not the source to Solaris.
Thanks
Bruce
Re:Both Perens and Becker are wrong (Score:2)
At most, Sun would have to GPL the driver porting kit. However, they need not distribute the source to their operating system under the GPL.
Bruce
Re:The GPL should be able to handle this... (Score:2)
The intent of the exception was so that people could run Emacs on SunOS before there was a free OS. Now, we have free OS and the exception applies to OS code too, things that provide services to the proprietary operating system rather than just using the operating system's services. IMO that's not what was intended, and when I contacted Richard he said he'd get it fixed in GPL 3. I took that as agreement that it wasn't what he intended.
Thanks
Bruce
Re:The legality of limiting linking (Score:3)
Another avenue, which the GPL doesn't try to use, is contract law. You can require an exchange of rights in a contract that would cover linking.
Why a double-standard? It's the way it's used. The GPL restrictions work to keep software free. Most people's restrictions work to do the exact opposite.
Thanks
Bruce
Re:Is the assertian valid? (Score:3)
Not well. The only case was Nintendo vs. Goloob games. Goloob made some device that gave you special powers, invulnerability, etc. in Nintendo games. Nintendo asserted that Goloob's device created a derived work. The opinion in this case was not conclusive.
Let me ask this: If I have a program that makes a call to, e.g. execlp("someprogram", {"someprogram", "filename"}); Does that make my program a derivative of someprogram?
No. And that is a problem where the GPL is concerned because with CORBA you can server-ize any program and use that to circumvent the GPL. It is argued that this might not stand because you could show a court that server-izing was a device explicitly used to circumvent the copyright.
Regarding whether or not MS holds a copyright on every program that links agains MS libraries, they do something even worse. They don't license those libraries and their own executables for use on an operating system that is not a Microsoft product.
My goal is to keep free software free. If it turns out that all of the free software I write is used as a subroutine library for any proprietary software that cares to pick it up, what incentive would I have to write free software?
Thanks
Bruce
What the GPL says in this case (Score:4)
Thanks
Bruce
Re:Both Perens and Becker are wrong (Score:5)
Thanks
Bruce
I'm not sure I get it... (Score:4)
What's the problem here?
Is it that the binary might or might not have new code in it introduced by the compiler? If that's the case, the same could be said if, say, Metrowerks distributed the source for these drivers with its compiler. Essentially the GPL under this interpretation forbids shipping binaries of GPL'ed code compiled with a non-GPL compiler. Also, it would mean that any code compiled with a GPL'ed compiler would become GPL'ed if the compiler introduced any foreign code (I don't know if gcc does or not).
I don't think this is a huge concern anyway. The compiler can't pull but so many "dirty tricks" simply because it can't know what the code is supposed to ultimately do. And compilers work at such a low level that the question of what is or isn't "foreign" code with respect to a given set of source is non-trivial, especially with an optimizing compiler.
Is the concern over the fact that Sun isn't shipping the driver source with the driver binaries? Assuming that this is the only concern, does anyone really care? Unless they've changed the source, does it matter to me whether I get the source for tulip.o from Sun or from Donald Becker? More specifically, if I put tulip.o binaries on my FTP site as a convenience for my user-group, am I obligated to distribute tulip.c myself? Is it not enough to say "get the source from the author?" Under a particularly strict reading of the GPL, it would be unacceptable to have tulip.c and tulip.o in the same directory as separate files -- they would have to be zipped together so as to be sure that Section 3 of the GPL could not be breached inadvertently.
Or is Becker just throwing a tantrum because he doesn't like seeing his work used for something outside the scope of his intent (to write a Linux driver)? This is, I hope, a remote possibility, because in itself that attitude defeats the whole point of the GPL, but one that occurs to me to toss out.
Re:Similarly, Napster isn't responsible... (Score:3)
It might be legal, fair, or whatever, but unless it's nice they chances of success in the long run are pretty low.
c.
Fun with hypocracy (Score:3)
Imagine that someone produces a tool that somehow modified VXD and WDM drivers intended for Windows so that they could drive all that hardware on Linux. Do you think people are really going to say:
"Well... since the Microsoft license agreement to driver developers licenses drivers only for use with the Windows kernel we can't use this tool."
Or do you think that they would just say "Fuck the man mirror it with your copy of DeCSS?"
Funny how the "opensource/freedom of information" mob feels no remorse in flagrantly violating choice laws yet comes crying back with this "oh please save us IP law" when they so much as get brushed against by a large company.
Why should anyone care if I can load linux drivers into my Solaris, BSDi, Win32, MacOS kernel? Oooh you're going to lose your precious market share? What happened to producing the best work you could?
~GoRK
Bad journalism (Score:5)
When i first read that, i didn't realize that the quote was from the author of the article -- i was shocked, thinking a Sun spokesperson said that.
CmdrTaco: You really should have edited that submission to make it more clear.
--
The problem is GPL vs LGPL (Score:4)
Now, if Becker's drivers were released under the LGPL, which explicitly allows linking with proprietary code, this would be a non-issue. However, the general intent of the GPL is to not allow such linking, static or dynamic -- although the latter has been argued as insufficiently made clear in the GPL. And there's the problem.
If the drivers are statically linked into a Solaris kernel, then that's pretty clearly a GPL violation. If dynamically loaded, then it may be as Bruce Perens states, violating the spirit of the GPL (vs LGPL). Whether it also violates the letter of the GPL may end up being up to a judge to decide.
No, no, no. It ain't ME babe,
It ain't ME you're looking for.
Nobody is Hiding the Source (Score:3)
Sun isn't changing the source code much less adding any features to the source code. Changes like that would have to be distributed.
I don't think this is a hole in anything.
The only thing Sun must do, in my mind, is include a few URL pointers to driver source.
The GPL should be able to handle this... (Score:5)
OK, here's the deal: The kit itself is just a piece of software - it no more "encourages" licens violations than GCC does. But any product of the kit was originally made from some code. Chances are, that code was under copyright and license. So, distributing the modified binary is distributing a derivative work - this is only allowed under the terms of the license the original code was under (in this case, the GPL). So, Sun must distribute the source to Becker's drivers if it distributes binaries of them (for any system).
-Dave Turner.
Analogy Error (Score:5)
Sure, if SUN was just providing the (what appears to be) compiler then there would be no issue. If they included the source code to the GPL code they ship as example binaries, there would be no issue. In that case it would be simular to Napster distrubuting an MP3 with permission of the artist or Xerox buying dictionaries to include with their photocopier.
It's a (cross) compiler! (Score:5)
To me this sounds like the definition of a compiler. Ok, so maybe it does a bunch of additional magic to convert the API's, but nothing to get our panties in a knot over.
Sure, an unscrupulous party could use this to "compile" an open source Linux driver into a Solaris binary, and "forget" to ship the source with it, but the same is true for any compiler. So what's the problem with this? If we attack Sun for this, we should also surrender to the MPAA, because admittedly DeCSS could be used for infringment.
> To his surprise, the kit used the Linux eepro100 and Tulip network drivers as examples. Becker wrote those drivers. Sun never asked his permission to convert them to Solaris binaries.
Again, what's the problem? That's just as if an application developer complainted that sb compiled his app for an Alpha, whereas he had developped it on an Intel. Nobody does the GPL say (or intend) that applications should only be run on the platform that they were developped for. If that was the case, we would be hypocrites for denying the MPAA the right to restrict their movies to the Windows platform (or to a given regions).
> Now Perens has ruled, or should one say opined, that Sun is perfectly within its legal rights -
Now comes the test (Score:3)
The legality of limiting linking (Score:4)
Second, I would like to say I love the GPL and do not want to see it legally weakened. That is, in fact, the reason I have thought about this. Because if the GPL makes (what a court deems to be) over-broad claims, that would definitely weaken the GPL. So don't flame me ;-)
But, I have been thinking for a long time that the GPL's claim to limit who can and can't link to GPL'd code might be tenuous. It is very easy, when I can point to a program and say "that program's source code contains my source code" to say that that code should therefore be GPL'ed. I can argue though, that a program that links to your library doesn't somehow become one program, it merely uses your code, and remains a separate entity that can be distributed under seperate copyrights. I think that one might find that a court might entertain the idea that linking code doesn't make it a derivative program.
To illustrate, let me argue it this way. Copyright, If I understand it correctly, allows you to specify terms upon which people can obtain a copy of your work, and make copies/derivatives; however, once someone _has_ a copy, I think, you can't really specify how they can use it(there are some exceptions, e.g. public performances, etc; and of course companies try to limit people's usage all the time, so I could be wrong here). So, if I have legally obtained a copy of your source-code, and this source-code is in the form of a library (or module in this case, which is similar), I might (I don't know, IANAL, and as far as I know no court has ever ruled on this) be able to make the case that "my" code (in this case sun's solaris x86 kernel; in the previous sentence, and for a bit following, when I say "my" I am speaking from the hypothetical standpoint of a defendant making a case in a GPL lawsuit) was distributed legally, and that the user got the GPL'ed code legally (assuming the module's/library's source code is included), and that the GPL cannot limit the user from using the two together.
Let's look at this another way: if a commercial software company said that their library X couldn't be linked against program Y, even though I paid for library X and got it legally, and paid for program Y and got it legally, because company Y hadn't paid a fee to the maker of library X, then we on slashdot would all be crying that this library distributor was making a draconian claim to rights that they didn't have: namely the claim that they could control how I used their software after I had gotten it legally. Why do we apply a double-standard to free-software?
Re:I disagree... (Score:3)
This is what I got from the article:
So the complaint, as I read it, seems to be that sun has a released a kit (binary only, it would seem), that is somehow in gross violation of the GPL - but I say, not unless the program itself was written with GPLed code and the source isn't being given a way.What it does to other binary files outside of that is a moot point.
But does it take the source or the binary? That's the real question. It sounds like it takes the binary...which, itself, should be distributed with the source code. However, I believe the problem is that, given the binary, you can modify it, and release it without the source. I agree that's a problem, and would violate the spirit, if not the letter of the GPL.HOWEVER, I didn't see anywhere that SUN itself has actually done that.
There is this:
I still don't see anywhere in the article that said these were distributed without source code, but the complaint seems to be that SUN didn't ask Becker's permission. To which I reply: why should they? Their use of the code doesn't seem to be, in itself, a violation of the GPL or any other moral codes. The code is open source, it's out there ready to be used by anybody, even SUN, or even Microsoft - if you release something under GPL, you need to accept that.The problem actually arises, it seems, from SUN linking the GPLed code to their non-GPLed code (as runtime modules). According to GPL, they would have to release the source to Solaris in order to do this (remember the difference between GPL and LGPL, this is GPL we are talking about).
I guess it's a sticky issue...but I think people are reading this the wrong way, I don't think the issue is even about Becker's source code at all, but that an non-open source operating system is using GPLed (and not LGPLed) drivers.
So the question that needs to be addressed is: are binary files created from GPL code subject to the same restrictions as the source code? So it's not the source code, and it's not even the binary created from the source code - it's the binary created from the binary, and the violation is not releasing the source to the operating system that uses it.
Difficult question.
----------
Re:The GPL should be able to handle this... (Score:3)
Now Perens has ruled, or should one say opined, that Sun is perfectly within its legal rights - not that he particularly likes it. He cites exceptions in the GPL allowing for Sun's ported drivers "as long as the drivers are runtime loading and are not distributed with the kernel."
Becker argues the exceptions were intended for user-level programs, not drivers that send threads into the kernel.
"Yes, that is how it was intended, but that's not what it says," Perens replies. In other words, a hole in the license.
In e-mail exchanges with Becker (provided to us by the participants, not obtained surreptitiously), Perens added that "We both know that the GPL was not intended to allow this use. Unfortunately, the language of the GPL does allow it."
Neither Perens nor Becker has suggested how the GPL could, or should, be changed. But Becker knows one thing - he wants Sun to stop peddling the kit, which he says includes "explicit instructions on taking a copyrighted work and converting it to unlicensed use with the Solaris operating system."
It seems the two closest to the issue disagree with you. I don't really understand the whole thing myself. No offence, but I would take these two's word over yours.
-Jon
Wake up people (Score:4)
This is the napster to kernel drivers, the Xerox machine to books. Remember, it's not Napster's problem that users violate copyright with the service. Nor is it Xerox's probolem that people photocopy copyrighted works on machines. We can have it one way or the other. If it's not Napster's fault, and if it's not Xerox's fault. Then Sun cannot possibly be held accountable for what people do with their software.
Remember, it is the responisibility of the user to ensure that no copyrighted source code is converted to binary drivers.
Re:Both Perens and Becker are wrong (Score:3)
I think that the problem is quite deep. The question is about the status of a work that is the result of run-time linking a GPL driver with a non-GPL kernel. If run-time linking of the two creates a derived work, the the kernel would then either have to be GPLed or not link with the driver. If run-time linking does not produce a derived work, then there's no violation.
Now Sun's role is also a bit unclear. It doesn't sound as though they're actually producing run-time linked drivers themselves, just producing a kit that makes it easy for others to do so. That's why there's a claim of contributory infringement- that Sun is basically aiding and abetting others in GPL violations.
It seems to me that Sun would probably be best of creating a kit that would grab drivers from the free BSDs. They're obviously released under a license that's much friendlier toward this kind of thing, and I'd guess that Solaris's closer kinship to the BSDs might even make it easier.