Slashdot Mirror
Linux: the GPL and Binary Modules
An anonymous reader writes "When first made available in September of 1991, the Linux kernel source code was released under a very restrictive non-GPL license requiring that the source code must always be available, and that no money could be made off of it. Several months later Linus changed the copyright to the GPL, or GNU General Public License, under which the kernel source code has remained ever since. Thanks to the GPL, any source code derived from the Linux kernel source code must also be freely released under the GPL. This has led many to question the legality of 'binary only' kernel modules, for which no source code is released. Linux creator Linus Torvalds talks about this issue in a recent thread on the lkml."
Maybe I'm wrong here but perhaps this is a way to look at it. If I wrote a story that was derived from the LOTR then it would not be a derived work in the legal sense it would be copyright by me. Although I'd have to get permission to use the trademarked names etc. Isn't this a bit like the linux kernel issue? The module is not directly derived from the kernel it is an extension that uses the hooks that were created in the previous "story". Maybe I'm on crack here....
I have a theory that the truth is never told during the nine-to-five hours. - Hunter S. Thompson
If a module is "based upon" GPL code, then it must be released under the GPL as well.
If a module is not "based upon" the GPL code, then no such restriction exists in regards to its licensing.
In fact, you could say that the Linux kernel in a particular system was "based upon" these closed modules, but it is difficult to argue in the other direction.
I have been pwned because my
A certain amount of pragmatism has to prevail here -- were binary modules disallowed, the phrase 'shoot yourself in the foot' jumps to mind. Linux is probably better off with them, as it lowers the entry barrier to companys wishing to contribute. And that's rarely a bad thing.
((lambda x ((x))) (lambda x ((x))))
So how does this affect hardware developers? I mean come on, are they subject to the same constraints as typical kernel developers? The main proble, as I believe Linux was trying to outline in the article, is that using any sort of licensing scheme will result in some unexpected difficulties. if you go here you will find just the sort of licensing predicament we can expect from now on.
The article is actually an email thread. It does explain boths views. Here's another look at it from Kevin Dankwardt. A little dated, sept. 2002, but still relevant today.
Thanks to the GPL, any source code derived from the Linux kernel source code must also be freely released under the GPL.
I believe this is wrong. The GPL doesn't say anything about having to release things for free. You could charge a million bucks. You just have to give the source.
This "grey area" exists because there is no clearly defined boundary defining the seperation between the kernel and the drivers. Modules are parts of the kernel which have not been linked yet. When they're required, they are loaded and linked with the kernel.
The fact that Linus states that there is no exception must worry a lot of companies out there who are producing binary drivers for Linux E.g. nVidia, or SciTech (Who started the LKML thread, after all!) Are nVidia's kernel modules under the GPL? If the possibility exists that they are then I would expect them to suddenly get cold feet over Linux.
If the kernel had a proper boundary with E.g. a set of API's that the kernel and drivers can use to communicate with each other then it would help to solve the issue of what is and isn't "the kernel". For example in Syllable drivers are ELF images which are loaded by the kernel ELF loader. The drivers are loaded under the kernels memory space but there is a very well defined API between the two, and a very clear seperation between them. Under this model I can argue that the kernel is actually being linked to the driver, so the driver can be under any licence while the kernel remains under the GPL. There is no "cross pollenation" between the driver and the kernel. Which is a good thing IMHO, if it avoids issues like the ones being raised on the LKML.
Syllable : It's an Operating System
LWN.net do some great coverage of this issue in these articles:
http://lwn.net/Articles/53780/
http://lwn.net/Articles/51561/
These two articles are in relation to Linksys, but they cover the general issue. There have been some other great GPL-related articles on LWN.net if anyone wants to search the site.
Expert in software patents or patent law? Contribute to the ESP wiki!
Linus talks all about linking source with the kernel and stuff like this. But guess what: With most binary modules this part is done by the user, not by the distributor, and this is clearly your right - you just cannot distribute the binary.
See for example stuff like driverloader (the ndis-wrapper around windows wlan drivers for the centrino and other cards): They are shipping a source which you can compile against the kernel headers (which are provided by YOU!) and will form a kernel module which can be loaded (by YOU!) against the kernel.
I really can't see how linus can claim copyright to the distribution of any source which happens to run with the linux kernel - but does not contain any part of it. And the enduser is free to compile and link this sources against the kernel, as the GPL allows modifications for own use without any restriction.
I guess the whole discussion is politics. Linus dislikes binary only drivers (for good reasons: they are unflexible, hard to debug and can cause user confusion and problems) and would like to have them not happen. But i don't think it is helpful to take a extreme shaky legal position (and downright confusing the users by making legal statements which simply do not apply here) to achieve this goal.
Although i dislike binary-only drivers in general, i came to the understanding that sometimes this might be the best you can get. In the business software world copyright is often a diverse field, and even companies who would like to release the source might be barred from that through NDAs and copyrights of third companies. So some companies have no choice but releasing binary drivers and i'm happy that they do at least that. If all would adhere to linus position we would just keep some users alone out in the rain. I'm all for helping users getting their hardware running. They might have made the wrong purchase in the first (getting a hardware with open sourced drivers would have been wiser), but just saying "tough stuff, you have lost, now go away" won't help them.
Linus really calls it the way he sees it, doesn't he?
Your logic is fundamentally flawed, and/or your reading skills are deficient.
You are a weasel, and you are trying to make the world look the way you want it to, rather than the way it _is_.
Wow. I hope someday I'm enough of a badass to be able to flame people like that and get away with it. (That said, it's particularly impressive how Linus can fling these barbs at people and still come off as a reasonable guy, unlike quite a few open-source "leaders". Having a sense of humor seems to help quite a bit.)
It's right there in black and white or whatever your default browser color scheme is.
OK, from the article it seems that merely writing a device driver which uses the kernel module interface automatically makes the code a derived work. Also, building programs which include the kernel header files automatically makes those programs GPL.
Now, what if someone wrote another standard driver interface, separate from the kernel interface, wrote a device driver which implemented that and then wrote a GPL'd interface wrapper which translated the Linux module interface to that of the new standard?
Obviously, the wrapper interface code is now a derived work. However, does it also mean that because the new driver which uses a code interface which the GPL'd wrapper implements now is tainted by the GPL?
Also, does the driver become a derived work if the person who writes it initially does so to get some hardware working on his Linux box, rather than his other box which runs ObsureOS which also implements this standard device driver interface but the person hasn't installed the hardware on that machine yet?
Agrajag: "Oh no, not again!"
it lowers the entry barrier to companys wishing to contribute
I see it as encouraging companies *not* to contribute. Why give people Free code when you don't have to?
A binary file is not a contribution, it's just a marketing tactic exploiting our free platform. Since the Linux hackers have written an entire kernel, I don't think it's unreasonable for them to ask for module source code in return. Otherwise the module vendor is a parasite.
Expert in software patents or patent law? Contribute to the ESP wiki!
The SCO case will have some far reaching effects if a sufficiently bone-headed judge rules in certain ways. One of the cornerstones of SCO's "case" is their theory on derivative works: notably, JFS. JFS is in the same category of kernel module as AFS which Linus references. SCO claims that JFS is a derivative work of Unix and therefore falls under IBM's contract obligations and SCO's copyright. Were SCO's theory to be accepted, it would be theoretically possible to try to force AFS to be GPL'd under the same theory.
An even more interesting stretch of the theorem would depend on how this "derivativeness" would be defined. Why is JFS a derivative work? If it's because it has substantial similarities to other Unix file systems (tree structured directories, permissions) there's an interesting case against MS for NTFS and DOS FAT, as these both have tree-structured directories and MS has been a Unix licensee. Now, wouldn't that be fun. Unfortunately the only entity that could bring that case would be our good friends Darl and SCO at this time.
So, I think there's lots of things to quibble about here, and appended is part of the law that might prove relevent. I'll try to make a case for a driver company attempting to create a non-GPL driver that uses snippets of GPL'd code in a 'fair use' way.
.h files), is what matters, and not all of the compilable code even in the subset of files referenced are used to create the .obj.
The key I think is if you can convince a judge that what they are doing is furthering 'research'. But the rest of the tests obtain:
1) Binary Linux drivers are generally release with a non-commercial nature - people don't charge for the software (although the opposite case, that you have to buy the hardware, could be argued to contradict this) - specifically, note that the word "including" modifies the two called out styles of use (commercial and non-profit eduacation) - thus other things might very well cause this section to obtain.
2) The copyrighted work is humungus and designed to be used in explicitly this manner
3) The portion of the whole is miniscule - it could be characterized as a 'quote' from an original source
4) The effect on the market value of the copyrighted work can be argued (successfully, I think) to be _positive_.
One other thing: I am under the impression that you can't copyright tables of raw data (such as names and their numeric mappings), so with Linus, I'd argue the #defines and such don't count for these calculations. The comments can't be said to contribute to the (binary) final work, even if someone read them once. Linus noted, and I agree, the compilable code (macros, subs defined in
I think I've made a (albeit shakey) case for 'Fair Use' in this way.
(ObSCO: I wouldn't be _at all_ surprised if SCO is going to attempt to argue that the overwhelming weight of the detrimental effect of #4 on SCOnix's value will outweigh the relatively trivial amount of infringement of #1, #2, #3 should IBM attempt to suggest fair-use of a couple of lines here and there)
------
Title 17, Chapter 1, Section 107
Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phonorecords or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright. In determining whether the use made of a work in any particular case is a fair use the factors to be considered shall include --
(1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;
(2) the nature of the copyrighted work;
(3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and
(4) the effect of the use upon the potential market for or value of the copyrighted work.
The fact that a work is unpublished shall not itself bar a finding of fair use if such finding is made upon consideration of all the above factors.
If it happens to be that that some modules ARE indeed being GPL'd, where does that put the company that made them? Case in point, Nvida seems to making a VERY obvious statement that it doesnt want the sourcecode to be given to the GPL? Would Nvida be allowed to refuse to release the source? And if not, what then? How would you go about such a thing?
I hate binary-only kernel modules, and all kernel modules should be available as source.
I recently purchased an IDE Raid controller, and naturally I chose one where the box said "Yes! Works with Linux!".
Sounds great so far, doesn't it? Problem was that the drivers turned out to be precompiled binaries for the kernel shipped with the following distributions: SuSe 7.1-8.0 and RedHat 7.2-9.0.
I returned the controller and demanded my money back.
First of all, I ran Debian with a kernel not supported by the binary drivers.
Second, with these kernel-spesific drivers I would be unable to upgrade my kernel (what if an dangerous kernel exploit is found?)
Third, "Yes, works with Linux!" is a lie. What the label should say is "Yes, works with a couple of Linux kernels!"
Fuck the binary drivers. I don't see the point. It's not like they would loose money by giving away the source to the driver -- they'll sell the hardware anyways, won't they!?
Please, don't bother opening that link.
Yes, I'm replying to my own down-modded post. I feel that the Flamebait moderation is uncalled-for and believe that the moderator has simply missed the point of my post.
It is a morally incorrect stance to demand that 'because I did all this work that you are benefitting from, you must pay me back in kind', as the original poster to whom I was responding to said (in a sort of way). He correctly makes the point that this is a community and that it is in everyone's best interest (cumulatively) for everyone to play by the rules, so to speak, and release source code into the open. However, to demand that someone open their source code is to usurp that person's Freedom and that is where the moral error arises.
When a person derives a work from GPL'd code, there is a legal understanding that the derived code must be placed under the GPL as well. This is designed into the GPL because the derived work benefits from having existing source code to be based off of and as 'payment' for this use the deriving programmer gives up his rights to copyright the derived code. It is a raw deal to some, heaven to others, but all parties come into the deal knowing what is required of them.
OTOH, a person who simply writes a driver that is linked at runtime to the kernel is under no such obligation to do so. This is precisely because the code is not based off the GPL'd kernel code but rather designed to a specification which the kernel implements. The use of kernel headers and libs would arguably be considered Fair Use of the GPL-copyrighted work. It would be nice for the developer to include the source under the GPL, but he is in no way required to do so by law. He does not benefit from the GPL'd code in any way except in the sense that the GPL code exists and he is finding a way to serve a need in users of that code.
But another point that I was making in my original response was that closed source binaries in no way hinder the uptake of an OS. Windows, being the premier closed source whipping boy, does no worse because Windows drivers are closed. It is arguable that it does better because binaries can be standardized at the source rather than having many incompatible user-altered binaries floating around. Support becomes a matter of fixing a problem once and floating a new binary rather than applying a patch to the source code and hoping that everyone who's using the source can merge the changes correctly.
Linux is not hurt by closed source drivers. The Free Software Movement may be set back because drivers for advanced hardware may not be available in any form except binary, but Linux itself will soldier on regardless. In fact, the more drivers that are available for Linux (open or not), the more likely it is that a user will be able to use the operating system without an incompatible hardware problem.
I know some people just hate the idea of binary drivers to begin with, and if that is your stance, fine; I don't agree, but I understand where you're coming from. But if you're going to allow binary modules (as Linux does), why do it in such a half-assed fashion that a company that might provide a Linux driver can't be sure one way or another how you're going to view their code (exempt from GPL or bound by it)? Either do it right and enforce a clear boundary or just stick with source only drivers.
Why argue such borderline cases as that?
If someone creates a work derived from the GPL and never distributes it, it DOESN'T MATTER what the author wishes to license the work with.
HOWEVER, if at some point the guy wants to distribute the work, it is REQUIRED that the work revert to GPL'd code.
So your point is moot. It is true, but useless to argue.
Trust me, you don't want to see what that really links to. And if you did want to see it, I'd suggest a trip to your therapist instead.
From a Norwegian newspaper (free translation): "Experts estimate that Jon Johansen will lose the case..."
The huge problem pertaining to graphic cards is that they probably are, on PCs, the item that is replaced /upgraded most often and are developed at the highest pace immediately after CPUs.
While CPUs are well documented and a critical resource well looked after by developers, GPUs are in contrast shrouded in mystery and buried in patents. Also most kernel developers, I'd wager, don't care one bit about dual screens and accelerated OpenGL.
Before NVidia came on the scene with their drivers the high-quality multi-screen 3D Linux desktop was very very hard to come by. It think it is still true today that you cannot have accelerated 3D and xinerama together under XFree. This causes no problem with the NVidia drivers.
So yeah, it's bad, and the NVidia stuff does cause mountains of weird problems still (I still can have my USB webcam running with the combination of NVidia drivers, dual-head and SMP, not that this is crucial, mind you, but it is annoying). OSS drivers only give you 2D.
Meanwhile I'd like to know how are things with the ATI camp, probably not much better.
Paradoxically, if NVidia had not come forward with binary-only drivers, the situation would probably be a bit better even with their hardware: it would have been reverse-engineered to some extent.
However the pool of available talented OSS developer is finite, and some other project would have suffered almost certainly.
The original purpose of restricting derived works was to make it so that authors (companies or not) could not copy code from the public domain and claim it as private work, No?
Kernel Modules cannot exist without the Linux Kernel. This dependancy means that any part of the Kernel Module that depends on the kernel for *module* interface purposes is not derived work. It is when authors base their code off of other code that is in the GPL that they must in turn release thier code under the GPL.
So in short, if the module could have been written entirely with Manpages and documentation, it is not derived work. If the author views the code of other modules, then it is derived work.
Deriving functions and invoking them are two very different things.
What about static linking with libstdc++ and other C++ development libraries in a commercial application?
Is this allowed or not allowed?
I never understood why companies are so reluctant to provide the source codes. The reason I hear usually is that such source codes would help competitors to design similar hardwares. Is this just urban legend and the real reason is more an habit of secret, or does this argument is real (i.e. seeing APIs implementation helps you design hardware) ?
--
Go Debian!
I'm no C expert, but I imagine there is a to get a list of available functions from the kernel, some query or another. One that is available, at least as root, from userland. Something like how the System.map file is generated from a kernel compile.
.h files (which don't contain any inline'd code, just function defs), would the resulting .h files be considered GPL? After all if I use a GPL word processor, my documents are not GPL'd, right?
If this facility exists, would a dump of the function calls in the kernel, with apropriate calling information (data types, number of parameters, etc) converted info a new set of
In ethical belief, I side with the GPL-only crowd, in the rome-wasn't-built-in-a-day argument, binary drivers wins for me.
If I were NVidia, which seems to be both the most loved and most hate bin only driver, I would see if it was possible to move all protected/proprietary code to the X11/GLX driver. X11 has full (or near full) access to the system a t a low level, and it's BSD licensed so no toes are stepped on.
Please send all UCE to scally@devolution.com so I can f
Several issues need to be more clearly defined before the forest is seen for the trees.
The phrase "Her bosom heaved..." can probably be found in 152,234 fictional books. If I add a few more words, it becomes a sentence and can probably be found in 1,289 books.
Derivation means you take the original work which has some 'body' of substance and add or subtract to it. Using less than that results in an excerpt. We know that excerpts can be used all over the place. There is also a difference in whether the material is 'instructional' in nature. Significantly more leeway is given. The kernel and associates aren't 'instructional'.
Simply including one line of a system or function call will not make a work a derivation. Including a file (or, even if not a 'file') of substantial body will make a work derivative. Two people writing a play may write separate acts which are then combined and published. Their final work is not one derived from another, but a shared work - joint equal ownership. If they individually copyright their own 'act', the joining would be derivative - the former not.
Binary code is a derivative work. It could not have occurred without the source file. But is it a copyright derivative? Colorization of B&W films results in new copyright, but also contains information for the 'source' that is identifiable. Binary code doesn't except for strings which might appear.
If I use a proprietary compiler on a GPL code, I get a binary. In one sense, it's derivative. In another, it's not. If I create my own scrambler, and process the novel Gone with the Wind text, is that new work a copyright derivative? I think not. This may even imply that using a GPL compiler on GPL source may result in a work that is -not- GPL because it could only be created via the creators unique use of the tools.
Joining a transmission to a motor will not result in copyright infringment over either the motor or tranmission, without regard that they have complex connectivity, assuming there were only separate copyrights beforehand. Patents aren't an issue either provided there is one for the motor and one for the transmission.
Whoever put the two together can sell it or use it as they wish.
Titles cannot be copyrighted. For more protection over things like system or function calls which may be specific to Linux, it may be necessary to do more legal legwork. For example, it may be necessary to assign a trademark to the function one-liner. Overkill? Not in todays legal world. Perhaps a GPL for trademarks used in Linux will become necessary.
My driver is a parody of their driver. :-)
OK, I've wondered about this since the dawn of PCs, and wonder about it every time I have to install nVidia drivers: Why do this? Onceupponatime, you bought hardware and drivers were just kinda there with it. Then they started putting copyright callouts on 'em. Now they're treating 'em as if they were standalone programs - doesn't an nVidia card kind of function as a dongle for the nVidia drivers, if they're so worried about copying?
If the driver spec is floating around in the open, that's a value-add for me as a comsumer (the company can't force-obsolete the cards by yanking drivers away, easier to switch OSes) and for the company (it makes the devices marketable to more people, and they get free optimizations and ports from the OSS community). On embedded devices it's even sillier, I mean, what good does PalmOS do me if I don't have a Palm? If I were trying to reverse-engineer an nVidia card or a Palm, wouldn't I start with the hardware? And if I did make a 100% Palm-compatible, I could just sponge off Palm's binaries then... ditto nVidia...
So, why be all grabby about drivers anyway? The cavalier something-for-nothing closed-source approach to open-source support seems vaguely dishonest to me somehow - it just makes me uneasy, and affects my purchasing decisions. If they're so happy to rip off the OSS community, won't they also be happy to rip me off, I ask myself.
IMO, binary-only is a trap: All it takes is closed-source drivers for motherboard devices, the manufacturer doesn't make a new version of the drivers to support a new kernel, and you're stuck buying a new computer or using Windows. A trap. Since an open driver spec is a value-add for both the consumer and the hardware company, I am very suspicious of proprietary drivers and the motives behind them. Trap. Linux is better off without binary-only taps. I mean drivers.
WHAT? Now you're just being silly! As long as you are not covered by any confidentuality agreements, then only LOOKING at the other source code is fine, because you are NOT copying anything. It has to be a derivative for it to be a derivative work! For example, if I looked at the Amiga Quake 2 source code in order to learn the basics of writing (OS-friendly) Amiga programs, would that mean EVERY SINGLE Amiga program that I wrote from then on had to be GPL'd? I don't think so!Also, if something is really public domain, then there would be no restrictions placed on derivatives, right?
Linus: "So you can run the kernel and create non-GPL'd programs while running it to your hearts content. You can use it to control a nuclear submarine, and that's totally outside the scope of the license (but if you do, please note that the license does not imply any kind of warranty or similar)."
-- All Gods were immortal.
-- S. Lem
Gee, I just read that entire thread and it was very interesting. Now I think I'll go back to bed.
My second printer was a Citizen 120-D 9-pin mono dot matrix, and it was also very Epson-compatible. It had a beautiful programmer's manual replete with examples of how to access each feature, from simple double width text to high-density image graphics, and even went so far as to provide timing details for the Centronics interface. {Hey, you might be plugging the thing into some device of your own construction}. It was even known for owners of EPROM burners to patch the charsets to match certain manufacturers' non-strict interpretation of ASCII {the BBC model B, for example, had a pound sign at CHR$(96) instead of a backtick, so it could keep the comment mark at CHR$(35) - a comment in BASIC is denoted by REM, but the # was used to specify immediate mode in assembler}.
..... you get a Quick Start guide which says "Plug the printer into your computer. Do exactly what Windows tells you to do" and a huge manual, replete this time not with useful programming information but with dire warnings about attempting to do anything "unauthorised" with the printer, and it probably illegal to examine the printout with a magnifier to see how the fonts are made up.
Compare and contrast that with today
IMHO the lawful owner of an instrument has the right to know everything about that instrument. My property can, by definition, contain no secrets from me {though I might reasonably be bound to keep any secret I discover}. It's time that this was enshrined into law. If you can't handle the concept of people knowing how to write drivers for your hardware then you perhaps shouldn't be selling it. Mandatory Full Disclosure would put an end to this argument once and for all.
Je fume. Tu fumes. Nous fûmes!
By his definition, if X was created primarily to work with the linux kernel, then it is a derived work, and therefore falls under his copyright regimen of choice (GPL). this is like saying that if you make a super efficient oil filter that was clearly designed exclusively for mercedes engines, then mercedes can tell you how to sell it.
while mercedes clearly has the right to protect its trademarks and copyrights, as long as the oil filter maker doesn't pass it off as anything but an aftermarket job, his business is secure. this is true whether the aftermarket add-on fits onto an easily identifiable interface (the little bit that the oil filter screws on to) or not (those places that hack up a whole mercedes and turn it into a stretch limousine or something - though the latter may well run into trademark issues if they are not careful).
yes, software is not like physical items in many instances. but, in this one, it is.
was a crackingly playable Quake 3. That was worth something to me.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
An even better alternative would be for the proprietary part of the driver to be a provider of a public, documented API, so that anyone could write a driver for it for any OS, instead of it being a consumer of some particular OS driver API. This would completely eliminate the need to use any GPL'd code in the proprietary driver binary.
Such an API could (and in many cases should) conceal proprietary aspects of the associated hardware, and in so doing perhaps remain stable for more than one generation of the hardware. Also, such an API could (but in most cases should not) have hidden functionality (e.g. "reserved" arguments to functions) that could be transparently used by proprietary application code (assuming the driver for a particular OS passes the arguments through unchanged).
I thought that was a big shout out to the general Slashdot population.
You are a weasel, and you are trying to make the world look the way you want it to, rather than the way it _is_.
And I thought that was a shout out to the sizable (or maybe just loud) neo-con Slashdot population.
If there was a LAW requiring hardware manufacturers to release hardware specifications and/or source code?
It depends rather the module uses or not other GPLed files, either source or headers.
It's as simple as MS claims to be. GPL infects everything it touches. If you use any header or any source code from Linux kernel (or whatever GPLed code) it MUST be released under GPL.
But this is theory. We must avoid problems with this kind of GPL violation in order to keep major non-free drivers avaiable. (oh no, if Stallman sees me talking like this... :o) At this moment popularity is also very interesting.
Let's not become like SCO.
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
You'd have a point iff the Linux Community actually believed any of SCO's IP was actually in there.
In fact, even if it is there, then most of the Linux community wants to know what and where, so it can be removed and replaced.
Now if we were going "Yeah, SCO's IP is in here, so what!" Then that'd be double-standards.
TiggsHowever, seeing that most of us as saying "Darl's talking out of his ass", then you can be pretty sure that no-one believes that any of SCO's IP is in Linux. At least, not intentionally. So I can't see any double-standard here.
Tiggs
"120 chars should be enough for everyone..."
Binary drivers are a load of braindamage, and should be make as difficult as
possible.
With binary drivers the whole point of Open Source is lost, and you could as
well have a proprietary kernel.
As you very well know, most BSOD in windoze are mainly caused by faulty
drivers, do we want the same "feature" in Linux? what about other OSes like
*BSD, what should they do? and other arches like PPC or Alpha? should they all
give up their OSes and systems and follow the "one true way of Linux proprietary
drivers"?
And don't even tell me about those "cross-platform-driver-interfaces", what a
joke... FYI, that didn't work for M$, and it wont work for anyone else, M$
tried to make a "standard" driver interface to allow win9x drivers to work on NT,
it was a *DISASTER*; there are loads of hardware out there that didn't make the
transition and has *no* drivers for WinNT/2k/xp, because the manufacturers were
bankrupt, because they were clueless, because they wanted you to buy new
hardware; do you want the same to happen with Linux?
What we *need* is for hardware vendors to get a fucking clue and start
releasing documentation about the crap they sell, that is the only way for a
stable and open system. Hardware vendors that refuse to document their hardware
are just too stupid to be dealt with.
If I buy something, I have a *right* to know how it works and how I can use it
in any OS I like.
Best wishes
uriel
"When in doubt, use brute force." Ken Thompson
No software for linux.
No software for linux. Linux = dead without software.
You cannot have it both ways. Free and commercial support.
You clearly missed the point in my signature. It has nothing to do with pessimism. Karl Popper (famous natural philosopher) wrote a book after WW2 called "The Open Society and its enemies" as a defence of democracy and a critique of totalitarian rule (including fascism, communism and various religious ways to rule).
In the book he argues that democracy has an incremental approach to society building whereas e.g. communism (and political islam for that sake) has a "revolutionary" approach. The point is that those who promise us paradise on Earth after we have made the society in whatever way they would like us to - they have always ended up giving us hell on Earth (Soviet Union, Iran, Afghanistan and so on).
This is my take on the whole thing:
Linux, inded, Open Source is like communism. It doesnt work unless everyones involved in it.
I know many of you will disagree with my example, but heres my meaning:
Open Source Kernel Modules submitted by hardware manufacturers WILL NOT work unless EVERY hardware manufacturer opens their code. They keep their binaries, and they keep their trade secrets, but if everyone opens their source, the benifits felt by all would outweigh the losses of information, much in the same way as Linux distributions prefer to work alongside each other, even though they are realistically in competition with each other.
I think the real issue here isnt with Black Box Modules on the desktop, but rather hidden modules in embedded systems, such as consumer devices (dvd players, for instance) where the company who could very well be violating the GPL is doing it under cover, and away from the prying eyes of most Linux Hackers, possibly even compiling their own code into the kernel, and not GPLing it. I think embedded device manufacturers should be taking this step of opening their source, for common gain, especially since they are the ones that most frequently use the kernel without singing its praises.
A binary module to save a desktop customer, who has forked out money for a nonfunctioning product is a good thing, and I hope this technology flourishes, and intergrates properly, but using the expertese of thousands of devolopers who give their time for free, creating a Linux system for end users, but not crediting linux, thus creating a world where most Linux users dont even REALISE that they use it, and only contributing to it by inserting a binary module to save a $lot_of_money$ on R&D, or licencing is WRONG.
Parent comment is lifted from a comment in the article's comment thread. just FYI for anyone reading who might have mod points.
Discussion in article is actually halfway interesting, by the way.
Pragmatism can be a double-edged sword, but let's assume that pragmatism is a good thing in this area.
Binary modules need to be tolerated - fine. But kernel instability cannot be tolerated, ever. Put these two things together and I can think of only one way out of the dilemma: binary modules must be run within a restricted execution environment where the harm that they can do is reduced to a minimum. Existing taint+symbol controls do not provide such protection.
What this means is, we should use the MMU to allow non-GPL modules access only to a small section of kernel space for interfacing purposes, and not to the entire kernel. This is pretty easy to do as far as code access is concerned (they should not be calling kernel code anyway if they claim to be independent), but it would impact markedly on data handling since data would have to be copied first into module-space buffers before a binary module could access it. This would make GPL modules run faster than binary-only modules in most cases. That seems fair.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
You're mistaking the GPL for the LGPL. The API would not be subject to copyrights, but any sources compiled against it would be GPL because the license of the GPL does not allow for abstraction layers like that.
"[We'll be] really getting inside your head and making it an unpleasant place to be" -- Trent Reznor
There are a load of GCC headers and other GPL'd library headers which are compiled into any code you build. The library itself may be LGPL'd but the code, data astructure definitions in the headers are included into the resulting binary, so if this problem is as you state, it is a GPL issue rather than a Linux kernel issue.
If this is the case then *any* binaries produced by GCC or which even look at headers or data structures included with any GPL'd or LGPL'd library must also be [L]GPL'd.
Government of the people, by corporate executives, for corporate profits.
Hard to believe you're not a troll but just in case...
The Linux community wants SCO's "intellectual property" out of Linux. The GPL doesn't permit their IP to stay in there. It must be removed; the license and the law demands it.
But first they have to tell us WTF their IP actually is. We can't remove it because we don't know WTF they're talking about! Even IBM doesn't know and the judge couldn't figure it out either, which is why SCO has been compelled to tell the court WTF they think they own in 30 days time.
Linux developers are very respectful of IP rights, even if sometimes the users (*cough*MP3 thieves*cough*) are not. This is why we wrote our own operating system, from scratch, rather than subject ourselves to binary-only licensing.
its good to see the variety and originality of first posts these days.
You make an excellent point.
It was like this with any hardware product you bought in "the good old days". All personal computers and hardware came with excellent programming manual.
Remember the C64? It was shipped with a big manual explaining everything from how to program to how it was built. All ports were carefully described, and you were even given a brief introduction to assembly programming.
Seems like the manufacturers are taking the focus away from "how it works" and directs our attention to "it works, just use it".
that sometimes there is no other choice.
For example, try to find a combination of GPU and drivers that is good enough to play linux games like Neverwinter and Unreal or emulated games through WINE that is 100% open.
You cant.
I suspect that even if you were able to completly Reverse Engineer (through disassembly or otherwise) the windows or linux Binary-Only drivers and/or the interface and hardware APIs for and from that, make an open source driver, you would probobly be violating several patents or other IP thingos and would have your ass sued by the makers of . Also, the makers of would probobly state that using the code means you get no tech support, no warranty, no nothing. Plus, the makers of would get some kind of court order to state that since the open source driver violates the patents etc that distributing, using or working with it is illegal and have all the copies in existance removed.
Also, 802.11* wireless network cards. I dont know of any 802.11* wireless network cards that have 100% open source drivers for linux except for 1 or 2 that have been Reverse Engineered by someone. For those, you dont get technical support, you may not get warranty service and the manufacturers would probobly shut down the Open Source driver projects if they had a way to do it.
Personally, I love Open Source and Open Specifications (i.e. Open file formats, Open APIs, Open network protocols, Open hardware interfaces etc) and push for such things wherever I can. (I was involved in a push to get Electronic Arts to release stuff connected with the gameplay scripts for Command & Conquer Renegade. They didnt release it. But in the end, I wrote my own DLL that sits between the game exe and the official DLL and allows one to implement ones own scripts but its still nowhere near as good as having the official stuff would have been)
If you are worried about the GPL and its implication, don't use a GNU/Linux fork.
Use FreeBSD (if you want X86), NetBSD (if you want to have portability across platforms) or OpenBSD (tries to make sure all code on the platform is under a BSD compatible license).
Very simple. To date however, no 'you have infringed on the GPL in linux' lawsuits have been filed, even with violations like the Virgin WebPlayer.
Yes, and M$ keeps trying to make a secure version of Windows and so far that's a disaster too. You aren't seriously suggesting that if M$ can't do something then it can't be done? Hardware can be virtualized in software.
I sympathize, but how many device manufacturers provide hardware schematics. Don't you really need those to really know how it works? Providing proprietary software with the proprietary hardware is just drawing the line a little higher. If the proprietary software is buggy, don't buy the product (just as you wouldn't buy buggy hardware). And you'd find out real quick whether the software is buggy if Windows were using the same proprietary binary.
It's dangerous because if Linus's argument actually holds, than Microsoft can legitimately claim that Mono is a "derived work" from
It is also unnecessary because the kernel falls under a license. A license can state under what conditions something can be used. Whether or not the GPL has enough teeth, you could certainly write an open source license under which any module developed using the Linux kernel must itself have an open source license. Or you could write an open source license that explicitly prohibits the linking of closed source modules into the kernel. That makes the question of whether something is a "derived work" or not irrelevant and still enforces the intent.
Now, we only need to figure out what the intent should be. Do we actually want closed source kernel modules?
If you are going to help redesign society, you should be prepared to accept any role given to you at random within the new society. Otherwise, how can anybody be sure that the society that you helped design really was fair?
Je fume. Tu fumes. Nous fûmes!
You don't have to agree with me, but I can only conclude that the restrictive GPL with its vague derived work clause is hurting Linux: a company won't put trade secrets into a binary driver to run the risk of losing these trade secrets because of a lawsuit based on the GPL which states that the binary only driver has to be opened up because it violates the GPL.
OR get a proper system into place like in Windows, for kernel modules so the modules are not 'derived works' (calling kernel modules derived works is pretty stupid IMHO, but that aside) OR live by the fact that not a lot of hardware vendors will offer drivers for their hardware. (which then results in the 'home brewn' drivers which are not always up to par).
Reading all the comments here I simply can't understand why so many people are so hardheaded. Don't you see / understand that to make Linux an OS with great support for a LOT of hardware, you have to convince hardware vendors their drivers will not be part of a GPL-case? Apparently not.
Never underestimate the relief of true separation of Religion and State.
I'm not a coder. (...) I get no benefits from having the code available.
Actually, I think you would get benefits from having the source code.
For example, it doesn't seem like nVidia is in a hurry to release drivers for new kernel versions, and just renaming their current driver doesn't work in Linux 2.6. The day you want to move to 2.6 (and you may have reasons; for example if it brings support for a new device you buy), you'll find that you can't just go to the manufacturer's site and download a binary.
(Note: it is possible to use the current nVidia drivers with 2.6, but with some patching.)
> I'd rather run a 95% Free Software operating
;-)
> system, than a 95% closed operating system
All software should come with permission to study, share, modify, and redistribute. If 95% of the software you use comes with these freedoms, that's a great, but we mustn't lose sight of the final goal. We've come so far, we have soooo many pieces of software that people said we'd never have. If hardware companies would just give us specs, we could write our own drivers, and y'know I bet we'd write better drivers than they do!
Expert in software patents or patent law? Contribute to the ESP wiki!
Well, I prefer a society where roles are not "given". I prefer that people are handed as much freedom as possible to shape their own lives as they see fit.
Your proposition seem to based on the premise that all should be equal in all respects and therefore it should not matter what role you have in society. That is not one of my priorities. I would like a society with equal opportunities - then people have the responsibility to shape their own future (for good or for bad).
no one is making money -- look at your local LUG do most of them even have jobs using linux, let alone making money?
You obviously got no clue what you are talking about.
;)), and they did put a *load* of effort in making drivers compatible, and
First, M$ might not make very secure software, but they sure got a load of
talented people working there, and even if their software is crap they know how
to do some things right, the NT kernel is not all that bad(after all, it's just
VMS
they had the src for all the OSes they wanted to make compatible, and they
still failed miserably, other efforts by a bunch of amateur kids aren't going
to work much better(and if you do some research, you will find that some other
people have tried, and failed too).
And that is for a very simple reasons, drivers and kernel modules, by
definition are *very* tied to the underlying kernel architecture, that you
really want to be able to change, and when you change that, you will need to
change the interface to it, and you will break code that uses that interface,
and if you only got a binary you are in a world of shit.
And yes, I *really* need to know how to interface with my hardware, and no,
adding a layer of proprietary software on top of proprietary hardware is *not*
OK, for *many* reasons, for example security, stability, CPU and OS
portability, etc...
There is *no* excuse for not releasing the necessary specs for hardware, the
interfaces to them are meaningless to other hardware vendors, and the only
reasons hw vendors don't release them are: ignorance; to keep more control over
the (l)users and make them more dependant(eg., force upgrades by removing
support for old hardware...), and to hide embarrassing bugs in their
hardware(or advertise fake features that are implemented in software, eg.,
winmodems, winprinters, etc.)
In all cases specs are withheld to screw the user, and nothing else, which is
*exactly* what Open Source tries to avoid.
You have to remember that in Open Source, we are all the developers, and M$ got
access to the src of all their drivers(their license for hardware vendors force
them to give the src to M$), and we at the very least need the same.
Best wishes
uriel
"When in doubt, use brute force." Ken Thompson
And what is to stop them? If they do NOT distribute any part of the Linux kernel with their hardware, but only provide the binary kernel module (say in the case of a driver provided with a video capture or decoder card) they *MAY* have technically violated the GPL, but this is clearly a case of looking a gift horse in the mouth. If you ban the binary module, they will just stop providing it, and now you can't use their hardware anymore in Linux.....
OTOH if they were to provide a complete hw solution based on Linux, running the Linux kernel, using a binary kernel driver module they wrote (such as a router box) they they would have to stop shipping the router unless they provided the source to the derived work.
Of course you can argue that this is a two-way relation, and that users probably would no longer buy those products if there's no support for linux. And since the linux userbase is growing constantly, that might prove to be a bigger problem for the manufacturer.
If a train station is a place where a train stops, what's a workstation?
Khun kills Popper :-)
"I think this line is mostly filler"
Companies like NVidia provide binary-only modules because they have to. Their code contains stuff that is patented and licensed from other companies, and they *cannot* legally release that code.
For example, NVidia's linux drivers contain S3TC tecxture compression algorithms, which is patented and licenssed. It is not theirs.
They CANNOT open source these drivers, nor could Linux developers create an implementation of them without being sued by the company who owns the rights.
And people just don' t seem to get this and it really really pisses me off. NVidia is just trying to do The Right Thing (tm), releasing Linux drivers at a LOSS nonetheless ( you think they make enough on Linux-owner sales of their cards ot cover these programmers salaries? I doubt it. ), and all the community does is flame them. No wonder hardware companies are so hesitant to support Linux in any shape or form.
I also need to throw this in to close... I don't know what people's problems with these drivers are. I have been using them since version 1043, and I have *NEVER* had a problem that wasnt fixed by reading the FAQ. And their feature and 3D support totally blows away any of the open source drivers (ATIs always lag 1-2 years behind the release of a card, and they still don't have all the features of the windows ones).
E.g. quite a few Linux based security products.
Checkpoint SecurePlatform for example is based of Redhat and the modified sources are not available.
And the firewall itself is inside the kernel, not even sure that it is a module...
The good point is that Checkpoint have very deep pockets, some developpers could make big bucks suing....
Of all the comments on here, no one is advocating a boycott against nvidia products or at least shopping smart. I had a geforce 3 in a RedHat box and it was really just a waste of money and energy. Linux isn't exactly a gamer's platform and I spent almost all of my time in 2D. Now that box has a Matrox card from 1995 or so. Works great.
Support manufacturers who work with the OSS community, give them your money. Sure, Linux is usually just installed on whatever junk Dell or Compaq sold you, but you do have a choice with desktop machines and especially machines you build yourself. Pull that offending card out, replace it with something with decent drivers and write a letter to the manufacturer/coders thanking them for supporting your OS. Eventually this will hopefully escalate to being a big stain on nvidias image.
Until Linux is sold by various OEMs this problem will continue. Ideally OEM competition will help force OSS drivers into existance as they simply would work better freshly compiled and have cross-platform capabilities (porting to solaris, etc).
Its understood that nvidia probably has contracts forbiding them to release an OSS driver. Well, perhaps in the future they can avoid such agreements and provide OSS drivers.
I'm not holding my breath, Linux isn't exactly what comes to mind when talking about 3D apps (with the exception of rendering farms), especially games. Do they even still make OpenGL games?
Even with tons of pressure this issue may never be resolved. Its a compromise the Linux community may have to live with for a long time. Not to mention chastising users who choose the binary path also goes against the free pricinples of "doing whatever I want with my computer."
Companies like NVidia provide binary-only modules because they have to. Their code contains stuff that is patented and licensed from other companies, and they *cannot* legally release that code.
For example, NVidia's linux drivers contain S3TC tecxture compression algorithms, which is patented and licenssed. It is not theirs.
They CANNOT open source these drivers, nor could Linux developers create an implementation of them without being sued by the company who owns the rights.
And people just don' t seem to get this and it really really pisses me off. NVidia is just trying to do The Right Thing (tm), releasing Linux drivers at a LOSS nonetheless ( you think they make enough on Linux-owner sales of their cards ot cover these programmers salaries? I doubt it. ), and all the community does is flame them. No wonder hardware companies are so hesitant to support Linux in any shape or form.
I also need to throw this in to close... I don't know what people's problems with these drivers are. I have been using them since version 1043 (3+ years), and I have *NEVER* had a problem that wasn't fixed by reading the FAQ. And their feature and 3D support totally blows away any of the open source drivers (ATIs always lag 1-2 years behind the release of a card, and they still don't have all the features of the windows ones like FSAA and anisotropic filtering, while NVidia has had them for years).
Authored by: PJP on Friday, December 05 2003 @ 02:20 PM EST
What this doesn't mention is the definition of derived work from the same source:
A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''.
Now isn't that interesting? the definition seems to require a large part, if not all of the original to be included for a work to meet the definition of derivative.
Simply being inspired by a work, or even writing something which can perhaps only have value in the context of the original work does not appear to meet this definition, provided you don't package the original with your work.
Linus seems to be saying that black box drivers are derived works and thus should be GPL'd. However the definition of derived work means the original or part-thereof must be included.
If the black box driver does not include the original when it is distributed then it cannot by definition be a derived work and thus not need to be GPL'd.
In the case of something like handling industrial I/O devices, yes, they ARE simple and there's no excuse for anyone to keep those as closed modules.
In the case of something like 3D drivers, they're not simple, per se, but the details of the writing to the card, etc. IS simple and as such, the overall commanding of the device in question is very similar to another card. (For example, there's a DMA pathway on each and every modern card...) There's nothing in the programming for most, if not all, of 3D cards that merits NVidia's or Imagination's (and to a lesser extent ATI- they've released most of the details of the earlier generation of cards which make up their low-to-middle product line to the DRI team...) apparent need to keep the details proprietary- just because it's a complex task doesn't make it something that nobody else thought of and provided a similar implementation thereof.
It's in the best interests of nearly everyone (whether they see it that way or not...) to provide the driver source and technical info to program for their devices. This way they can provide a couple of developers for the hard stuff and let the rest of the community build and support the bulk of the work producing driver code for the operating system.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
So far, most posts in here have been about binary only drivers provided directly by hardware vendors. My case is somewhat different, yet if I read everything correctly, I could still be affected by all this.
I am the author of the Linux Philips webcam driver, which supports a lot of Philips and Logitecht webcams, and a few others. This driver has been in development for nearly 4 years, has been formally introduced into kernel 2.4.5 and has been in continual support by yours truely ever since the first public release, some 3 years ago. Now here's the catch:
Part of the driver (PWC) is Open Source, even in the kernel under the GPL. With it, you have a functional webcam driver, but there are some limitations; you can't get the full resolution and not as high as framerate as is possible. For that, you need a binary only plugin, called PWCX. It contains decompression routines that allow you to use the cam at its full performance. These decompression routines fall under an NDA and are thus not public. Judging by the number of mails and webvisitors I think this driver has been quite a success. And now this may no longer be possible.
The point is, that by the strict interpretation held by Linus et al. I can no longer make this PWCX driver, thereby depriving a lot of users of a useful bit of hardware. Or at least make it quite a bit less enjoyable. I might as well remove the PWC driver altogether form the kernel then, hmm?
First off, I feel sorry for the thousands of Linux users that use my driver (PWC and/or PWCX) and may no longer be able to do so. Second, I'm getting pissed off beyond measure by this Open Source fundamentalism because it is my driver that may be turned into a worhtless piece of code.
It is my ass here that's on the line; I signed the NDA with Philips and if I goof up and accidently post the decompressor code or fail to protect it properly, I will be the one standing in court, not Linus. Second, I went through all the trouble of getting in contact with Philips, trying to convince them to help the Linux community and indeed they have, and I commend them on that. But they have their reasons to shield some parts from prying eyes (read: competition) and I can't blame them. So that's why there's and NDA and it's even fairly relaxed. Without the NDA there wouldn't even have been a driver.
BTW, Philips spent exactly 2 webcams and a couple of manhours on getting the paperwork done in order to get their product supported in Linux for 3 years across 3 major kernel versions, including online helpdesk. I think that's damn cheap. I cannot count the hours I spent on programming and debugging and tracing intractable bugs, not to mention the time spent in helping users by e-mail. I've also spent many an hour to get this PWCX module crosscompiled to various hardware platforms in order to extend it's Linux usage as much as possible. Now that may appearantly all have been a big waste of time. Thank you very much!
No, it is time to realize for anybody who thinks that the GPL is the Holy Grail of computing that this is not going to work. You cannot force anyone to oblige by a volountary license (because that's what the GPL is: nothing more, nothing less). As I wroting in my piece on tainting the kernel, if you make it any harder for (hardware) vendors to support their product in Linux, they'll drop it like a brick because they don't have to. This way Linux will never gain any real acceptance.
Finally, it's also not very wise to piss off people like me, who are doing their best, and made some small yet clearly apreciated contribution to Linux. I would also rather have a complete Open Source solution, but I'm realistic enough to know that is not possible in this Universe. So I think I've struck quite a good comprise. But if I am being told now: "well, that isn't good enough", I might just throw in the towel in the ring altogether.
- Nemosoft
"Fix it? It has been disintegrated, by definition it cannot be fixed!" - Gru in Despicable Me.
Excuse me, but I was under the impression that *BSD was dying. Why should we worry about supporting it?
Ok, I know of some closed source SCSI controller modules. The issue here is, to interact with the SCSI subsystem, a lot of things have to happen, including a '#include ' statement. That means any binary only SCSI module contains the scsi_module.c file contents compiled into the binary. Whatever the nature of other bits of code and include, clearly the implementaition of scsi_module.c is contained, and that c file is GPL.
With this in mind, is it true that all companies shipping binary-only SCSI modules are in violation of the GPL? One prominent example is Adaptec's 1210SA SATA card, which implements itself as a SCSI driver on the Adaptec website. It annoys me because to use the card, I have to stick to their compiled binaries, which doesn't have anything newer than RH8.0, or SuSE 8.1, and certainly is far removed from Gentoo, my distro of choice, but annoyance aside, is Adaptec violating the GPL? I wanted to use the siimage driver, but it simply wouldn't work for me with that particular card (found out after buying it).
XML is like violence. If it doesn't solve the problem, use more.
I understand that way back at the Dawn of Time, Creative published the soundblaster specs and interface so that game creators could produce games that worked with it. And the result was dozens of "knockoff" cards that were produced far cheaper than the soundblaster, and could boast compatibility, which was important because back in those days there was no such thing as "abstraction layers" and barely anything you could call an "operating system".
However, in these days, why do companies continue to do this? Unlike back then when games only used a soundblaster, applications now use the operating system and library calls to produce output of whatever kind. Arguing that revealing the driver or the interface to the card would allow people to clone their card is rather silly. Sure, someone could spend a lot of money to develop a card that operates exactly like your card, and therefore skip the driver development step, but is there a savings in that? And would the hardware operate sufficiently alike to make it a "drop-in" replacement (especially in these days of complex graphics hardware).
So not releasing your source because "someone will develop a drop-in replacement for our hardware and drive us out of the market" is no longer a valid excuse, because thanks to the wonders of drivers in the first place, all hardware became drop-in replacements for other hardware. Does anyone have another excuse?
If I have been able to see further than others, it is because I bought a pair of binoculars.
It doesn't work like that. Things over which you have no control shape your destiny too. A baby born with one leg is extremely unliklely to win the FA cup, for instance ..... fair enough, it's an extreme example, but not everyone starts out capable of success at everything, and society does assign you a role, whether or not you realise it.
Je fume. Tu fumes. Nous fûmes!
Wouldn't it be great if there was a LAW requiring hardware manufacturers to release hardware specifications and/or source code?
How about just a law requiring people to be NICE?
That would cover your wish, plus a whole lot of others, in one simple stroke.
Under a strict GPL interpretation, modules can be considered "derived works" because they link dynamically into a GPL environment (the kernel). The modules depends on kernel headers to compile and use internal kernel data structures exposed through module interfaces that are technically under the GPL. Thus, if you interpret the GPL as written, then yes, all modules would be required to be released under the GPL.
Clearly such a situation is not acceptable to hardware manufacturers and Linus recognized this. Hence his "binary only is allowed for modules" rule. It is the kernel developers themselves that are changing the module environment to try and enforce the strict constructionist view of the GPL.
RMS recognized this issue and developled the LGPL. The intent behind the LGPL was to allow for the development of GPL'd code that could be incorporated into binary-only products without tainting those products provided the binary product announced was linking to LGPL code and made it available on request (or distributed it with the product). As long as a clear separation exists between the proprietary product and the LGPL'd code (in other words, the proprietary code links to the LGPL'd work. If it copied LGPL'd code into its code base, then it would become tainted), the two models can co-exist.
RMS doesn't like the LGPL. It is a compromise license designed to fit the realities of the world rather than what he wishes it could be.
In my opinion, maybe the simplest solution is to relicense future versions of the Linux kernel under the LGPL. The distribution and modification requirements for the kernel proper would still be in force as with the GPL and make it compatible with binary-only modules explicitly since this very issue of linkage and mixing is exactly what the LGPL was designed to address. For the record, I prefer the LGPL over the GPL for practical, real-world open source development. It provides the best of both worlds when approached correctly.
If the LGPL cannot fit, then clarification is required for the definition of derived works as encompassed by copyright law and how the GPL perceives it. v3 of the license should maybe incorporate a better, clearer definition of dynamic linking when no source is exchanged between two programs.
I agree with Linus. Binary-only modules should be acceptable under the GPL since they do not incorporate GPL'd works directly except through runtime linkage.
Of course, in real life not all are born equal. What I was trying to convey was that, in my opinion, society should work towards giving, e.g. disabled people, equal opportunity (though I do realise that it is a goal that cannot be reached in full).
Equal opportunity does not mean that everybody will be able to become astronauts. But it does mean that most people will have greater opportunity to shape their lives according to their wishes than in other societies.
And sure society is influencing how you live your life. But we also have a choice for ourselves. In my 'dream society' this choice is maximised.
Was anyone else taken aback by Linus calling someone a 'weasel' and 'deficient', and telling someone else that they were 'wrong' in a crudely forward way? This isn't how you make friends. Kind of a jerk, I thought.
sadly, those who want equality focus on outcomes. thus, affirmative action, preferences, etc. arguig logic here at /. willonly have you banging your head against a wall. the best part is when it ends.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
Thanks to the GPL, any source code derived from the Linux kernel source code must also be freely released under the GPL.
That's really nice when you are the owner of a project and you want to use a non-GPL license. How can you switch to a non-GPL license without backing out all of the GPL licensed changes.
http://www.linuxant.com/company/
For some people, these (admittedly low-cost) drivers are the only way to get their modem working in Linux. This is not a hardware company.
WMBC freeform/independent online radio.
ok, let's get really muddy here.
I'll probably get flamed and modded down for this, but I've actually been tossing this around for a few years now...
I've read a lot of these comments, and even Linus' comments on LKML, etc. and it's pretty good coverage.
But I have a question that doesn't seem to be covered, because it'd be considered pretty "Grey" and probably downright underhanded...
Could a company create a commercial proprietary product using GPL code for portions of it (assume even large portions), but have their own proprietary modifications, modules, and additions, AND... could they then keep their modifications/additions private by releasing ONLY the original GPL code source ?
I hope readers can catch the meaning of this. What I mean is, say for example (just example) the "hello world" program was GPL'd (yes, I know it can't be, but that's not the point), and say Fred's company wants to change it to say "Hello Fred" instead, so they modify hello.c, compile it and release it, but only release the original unmodified hello.c with it. Yes, I know this seems to violate the GPL terms, in a sense. but does it?
Let's get really muddy... Take the Linux kernel, make a "ton" of modifications and additions to it, re-release it as a new product, give the original authors, contributors proper notice in copyright files, licenses, and documentation, release the original kernel that was used as source with it, AND, just for kicks, release a document file listing which "lines" in which "files" of the original were modified. Not the modifications themselves, just the "tap" points, as it were. But don't list the actual modifications, and don't list the additions made.
I've always wondered about this scenario. It means the company is perhaps "technically" complying with the GPL, but more than likely breaking it. However, in these grey muddy waters, I have no idea where each of these would stand legally.
the idea is this - a company wants to create a product, they have a great idea, but they're not about to re-invent the wheel, they find that there is GPL code that does a "lot" of what they need, but is missing stuff all over the place, and key critical modules and functions are also missing. They can't afford to hire coders to "white room" rewrite all that GPL code and can't afford the time to do this even if they could, and they can't afford to release their unique creation to GPL.
So what are they supposed to do?
This is all based on my thoughts of commercial uses of "GPL" code (note the QUOTES!). and please don't flame me...
Wow. I hope someday I'm enough of a badass to be able to flame people like that and get away with it.
All it takes is truth, gnat. Depending on what was said, the poster in question may have been a weasel.
In any case, all of this is temporary. Binary only modules suck. Compared to free code, their quality is poor. Even when the quality is good, they are not flexible enough to survive kernel changes and don't work. I've heard of Nvidia binaries that make X take 5 minutes to load and I've dealt with a wi-fi binary only that would only work with specific versions of Red Hat. Free software is taking over and hardware makers are going to release GPL'd drivers if they want to be competitive. It's only a mater of time before binary only distribution is just a bad memory.
Friends don't help friends install M$ junk.
You can't. Release under the GPL or don't use GPL code at all. RMS, Linus, ESR et al did not write their code so some selfish tosser could take it and lock it away in a piece of closed-source proprietary software. It was their intention that the code should remain out in the open, where anyone can study it and make changes. And that's the way it should be: not sharing is theft.
Je fume. Tu fumes. Nous fûmes!
You might not want to tell anyone anything and no one you know may be intersted, but there's no reason you should not be able too. If you accept this, you accept the worst kind of prior restraint on your property. Apply your thinking to your old parallel printer. Are you telling me that you would accept not being able to go to a local meeting to share your hacks as you just did here? That's nuts. The whole reason the kernel works with so much hardware is that people have been able to share their hacks. DMCA type laws interpreted by people willing to be shut up would kill free software off completely and no amount of mandatory disclosure would make up for it. Hardware used by free software routinely does much more than it's makers ever envisioned.
Friends don't help friends install M$ junk.
There's one other thing that the "I'm content with binary" people forget as well, DRM. Nvidia and any other "binary" release could have DRM introduced and no one would be the wiser until the switch was thrown. I also think the "I'm happy with binary" group don't fully understand that FOSS is about control. Control of your hardware that you bought. That must be important judging by all the "wining" that goes on whenever a RIAA/MPAA story comes up. "I bought this CD/DVD and the big, bad corporation is dictating to me what I can do with it", and yet no one see's the problem with hardware companies "dictating" what you should be able to do with your hardware. I also think that most haven't learned their lessons from the Windows side. How much finger pointing have we seen between OS and hardware manufacturers? How many times has a manufacturer "taken their time" with a driver release? Or "It's time to rake in some more money, lets get everyone with older hardware to upgrade".
Everyone with a binary driver, regardless of platform. Can you honestly say that you control your computer, in every sense of the word? Why not?
An argument in more than 300 comments by now is the cause for me to prefer the BSD license which does not tend to have so many grey areas which need about as much interpretation as some religious text which is a couple of thousand years old. Keep it simple, use the BSD license.
If modem companies are forced to release the source of that to support Linux, there will be no Linux modem support for any of these.
So, the community is left a choice of learning to accept supported binaries or no support at all.
Alternatively, you could wait for the GNU Radio project to echo cancel, then equalize, then demodulate QAM, then trellis, then LAPM, then V42bis. Then, you'll be within 8 years of up-to-date.
I am a big believer in open-source. But I don't expect every company to give their products away just to make Linux users happy. Many good companies will take a few extra steps to support Linux drivers, but not if they have to give away their own products to do it.
Are you noit still free to put a PCI SVGA card in your Linux box and use the GPLed driver for standard VGA or for SVGA?
I don't see the binary-only drivers for the top current cards (nVidia and ATI) as giving us fewer choices. I see them giving us more choices, although some of the choices are somewhat tainted by being closed source.
No, I'm not a new Linux user. I've had to compile the Linux kernel on DOS and use loadlin myself in the past. I've used Yggdrasil, SoftLanding, and a few more distributions that haven't been around in years. These were a great step forward in getting Linux in wider use. Better distributions (Slackware, Debian, RedHat, Mandrake) than those have helped more since then.
Using a distribution involves making choices between control and ease. The FSF isn't always thrilled about the Linux kernel, but a hell of a lot more people use GNU utilities with Linux than with the Horde. Embracing Linux as part of the GNU system is about taking what's available and widely popular in place of having the extra control they have over the Horde kernel.
So you have every right to write your own nVidia drivers (although the tech info for the cards not being released does make this much harder), you have the right to use the black box driver instead, you have the right to use another card and driver, and you have the right to use the black box driver and feel uneasy about it until something better comes along. I'd recommend the last of these options if you can't find an acceptably performing card with an open driver, but of course many of us are willing to accept less performance because the driver is open. This is of course especially the case for machines that don't do much with 3d or even fast 2d graphics.
Linux will get is name far faster by being accepted on the corporate desktop. There you don't need gaming performance, you don't need 3d performance.
So you're saying that Linux should never be used for (say) CAD/CAM work (for instance Pro\Engineer), 3d-modelling, 3d GIS visualisation, and many other sceintific uses of OpenGL?
Maybe you haven't noticed that Pro\Engineer + NVidia cards actually make one high-end business case for Linux on the desktop (especially with the deals HP is pushing for their Linux Workstations, which AFAIK come with NVidia Quadro cards).
Am I the only one who sees the irony in the "we don't control all that's in our driver" excuse? An excuse that can neither be proven or disproven due to the black-box nature of the driver.
The reason most of these companies develop binary-only modules is to keep a leg up on their competition. Put simply, companies like nVidia don't want ATI or Matrox getting hold of their improvements. Some drivers include proprietary technology and speed or quality improvements that either can't or (in the interest of profit) shouldn't be open.
Hardware manufacturers have very little that sets them apart from each other. Their biggest concern is that the driver source code would give away how the hardware works and therefore would show their competitors how to implement their technologies.
Let the hardware manufacturers develop their binary only modules. It's better than what we've seen with the wireless market...which is what we would likely see if we started spouting "show us your source code" to all of the hardware manufacturers that choose to make binary only modules...
And of course the other reason for a binary module is to charge for it (like is being done with Linuxant's DriverLoader) but...just like anything else worthwhile, there is already an open sourced equivalent under development.
You can't. Release under the GPL or don't use GPL code at all. RMS, Linus, ESR et al did not write their code so some selfish tosser could take it and lock it away in a piece of closed-source proprietary software. It was their intention that the code should remain out in the open, where anyone can study it and make changes. And that's the way it should be: not sharing is theft.
Would that be "theft" as in "downloading mp3s for music I don't own (and don't have the artist's permission) from Kazaa style theft?" Or are we talking about two different types of theft here?
If music copyright violation isn't theft, how can this be?
From what I understand, the module API used to be much cleaner. However, as additional performance tuning has been done, there have been many additional interfaces added, so that you have a sort of coding equivalent to urban sprawl. The typical example is the interaction between the block device driver and network API's in order to read a block off a disk and directly send it across a network.
You have an interesting problem though-- the GPL was clearly intended to be used with self-contained, modular programs, hence the descriptions of aggrigation, communication using pipes and sockets, etc. We also have the LGPL for libraries where such self-containment is not exactly possible.
The questions of dynamic linking are interesting questions and I have heard different answers as to how sound the GPL's prohibition of dynamic linking with non-GPL programs is (IANAL). You also have the question of what the definition of "use" is in the GPL (which is stated to be beyond the scope of the license). For example are the following actions permitted under the GPL (assuming you are not redistributing what you compile)?
1: Downloading a GPL'd source in C and compiling it against a binary-only LIBC library with supplied source header...
2: Downloading a BSD'd source and compiling it against a GPL'd LIBC library... Better yet-- providing patches to the BSD source so that it better supports the GPL'd library...
3: Distributing a GPL'd "wrapper" you wrote and emulates proprietary NDIS Windows Networking drivers?
4: Distribute a non-GPL'd (non-redistributable) PHP script that plugs into a GPL'd PHP application server? Is this similar to dynamic linking?
Don't get me wrong. I like the GPL and use it for several of my projects, but these are questions that I don't have the answers to, partly because IANAL, but also partly because it is not clear when the GPL comes into effect-- whether it does so at compile time in which case it is the user downloading the software that is violating the license, or whether it does so at redistribution time (in which case-- no redistribution == no foul). I suspect that the way I have seen courts work, that the line is likely to be very gray.
LedgerSMB: Open source Accounting/ERP
Is that you must release source code to the program/module linking to GPL libraries... however, I also understand that just because the program is GPL, that it does NOT prevent you from linking with proprietary, closed source, libraries.
So, what is to stop a module developer from creating his own closed source API, and then using an open source wrapper to interface between the Kernel module API, and the proprietary portions of code???
and' as any profit would technically be derived from the code in the proprietary portions of the code, it would be perfectly legal to charge for the module. As long os the source for the actual Module (wrapper) code was released under the GPL license, and said code linked to the proprietary code (in object form).
As, contrary to popular opinion in the community, the GPL does not prohit linking to proprietary code, nor does it nessecitate that code must not depend upon a non-GPL component. It only requires that, in the case of the kernel -- because of a module being considered a derived work -- the code which actually interfaces to the kernel be released under the GPL.
And, before I get flamed, I would like to state that I am very much for open-sourced modules. Hawever, if a closed source driver is the only option, so be it... and, from dealing with hardware companies (and the stacks of paper/many lawyers)... the engineers themselves would like nothing better than to distribute driver openly..., however, it is usually the managers, stockholders, and corp lawyers who prevent this from happening... Mostly due to a completely illogical fear of losing IP, and the mis-belief that invaluable IP is contained within a device driver.... (and in the case of Machining Equipment.... this makes absolutely no sense, as all the guts are in an embedded system within the equipment, and all the driver handles is the communications protocol) But, the GPL makes them nervous, and if we become overly aggressive about device drivers, and the GPL -- I'm afraid that where we may have once been able to rally support for a driver, we will be turned away as a bunch of fanatics who don't care about IP...
I make my money as a consultant for various companies, and this is the one thing that truly scares me... the communities insistance that everything involving the kernel (or I've even heard Linux) be completely free and open-source... and this makes companies extremely nervous, especially with the SCO disaster looming over us. Edison Gieswein
Heh. So communism etc. gives us hell on earth immediately, while capitalist democracies do it incrementally. Great...
Having binary modules only stops developers from trying to make their own
No. I don't think so. What it might do, is give lazy developers a reason not to make a driver, or time to work on a different driver while the current binary is working. Neither NVidia nor anyone else who released binary-format drivers is "stopping" developers. Do they have a court-order out asking for a cease-and-decist on all non-NVidia endorsed source drivers? No? Didn't think so.
You might also want to consider that there are drivers to interface with NVidia boards that aren't binary. They don't do everything the binaries do, but they get the job done in many cases.
Say if you want that the linux world would be a nicer play with full-source NVidia drivers, I'll agree with you. But if you want to argue that by providing "Y" NVidia is at fault for reducing development on "X," I'd say your blame is misplaced and your arguement flawed.
Conspiracy theorize as you may, but I believe the NVidia driver release is more about getting their hardware sold to linux users than it is about slowing/stopping any attempt at making open-source drivers.
The copyright (gpl) says that it must remain open. If you close it, you are violating copyright. So yes, it is the same "theft" as in "downloading mp3s for music I don't own." (Where "theft"=copyright violation).
"I'm not impatient. I just hate waiting." - My Dad
Sounds like a sugar coated version of communism? Wasn't that the point of communism? Everything was equal so everyone was the same.
ever tried getting a tnt2 to work in an smp box? no? didn't think so. It doesn't work with nvidia's drivers.
However, I can use a crappy card with open drivers to get better performance on that smp box than the nvidia card with it's open drivers.
Binary drivers can really bite the big one.
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
Capitalism is probably the only true way to run a government. At least with in a capitalist democracy, everyone has equal chance to make money, those with money control how things work, but even the average joe can become a millionare and have power. The reson communism failed is 2 key points. 1> Everyone is not equal, generaly the ruling body keeps the power and money while the "common people" are the ones forced to all be "equal". 2> Since everyone is kept at bane to be equal ,there is no motivation to better yourself, it strips people of ambition, bascialy a social system deisgned on the weakest link theory.
I agree. stupid nvidia smp...crap. you can try turning AGP off, that helps. and the usual noapic, etc. Stupid binary drivers.
I submit that the only ones that like Nvidia's binary drivers are ones who use standard kernels (never recompile) on standard systems (no funny configurations, no smp...). For the rest of us, ARGHHT!
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
Most drivers simply push data to the right place and fiddle with registers in the right way. There is nothing the competitor wouldn't have already thought off.
If youre competitor has to learn from your driver they are atleast two generations behind you and you have nothing to fear.
So why don't we have competitors (Linux kernel DRI developers etc) that have written drivers with similar 3d performance?
Why isn't there a competitor providing open-source drivers for cards in the same league?
No, the GPL allows what copyright law allows.
The commercial world does not consider linking against APIs to be a "derived work" under copyright law. Otherwise Microsoft would own intellectual property rights for everything from QuickTime/Windows to Emacs/Windows. Not even evil nasty bad evil M$ claims this. But GNU does.
The GNU people have spread a huge ASSumption that "sources compiled against [our API] would be GPL", but there's absolutlely no legal backing for that, and if there was it would cause the commercial software industry to collapse.
Who defines "fair"?
I apologise for my knee jerk reaction. Upon re-reading your post, I realized that my response was overdrawn.
Sorry
Im not here now... Im out KILLING pepperoni
You don't have to agree with me, but I can only conclude that the restrictive GPL with its vague derived work clause is hurting Linux: a company won't put trade secrets into a binary driver to run the risk of losing these trade secrets because of a lawsuit based on the GPL which states that the binary only driver has to be opened up because it violates the GPL.
There's no judge that will force a company to release their source code - if some kernel code contributor pushes the matter, and it is declared illegal, nVidia will simply stop distributing it (probably replaced by a big nothing).
Then, the GPL author could try to get damages - which are likely to be none, since I don't see any reasonable way he's been hurt by the illegal nVidia/kernel derivate. There's certainly no economic loss, and it has been an accepted way of doing it now for quite some time.
In short, I think even though some might grumble over binary-only kernel modules, it's much the same as why few companies would want to trial the GPL. There's nothing to be gained, and everything to be lost by doing so.
What I do not understand, is why the companies couldn't give out the specs - not all the driver code, but the hardware interface. It's not like AMD or Intel's op-codes are a secret. Then simply say "this is the hardware. we do a lot of magic in software too, but we can't tell you about it".
Maybe noone would bother to write that so completely from scratch. But whenever nVidia gets these complaints, they can point do it and say "If you want it, write it yourself. We're not going to stop you. In the mean time, we will provide drivers, but binary-only."
Kjella
Live today, because you never know what tomorrow brings
This has been more than paid for by the thousands of NVIDIA cards sold on the back of supposed "Linux support".
Well, this is precisely why, I and many others, buy nVidia cards. I use a dual boot Win2K/Mandrake box and I know I'm getting excellent drivers for each operating system.
I personally don't see any problems with closed source binary drivers. The kernel provides (or should provide) interface abstraction to a sensible level where it's possible for safe "black box" drivers to be written.
Then again, I don't understand anything about writing device drivers or how tightly integrated to an os kernel they need to be. As a layman, I would have thought that the kernel provides certain services to a driver module which are accessable through an interface?
Card manufacturers have trade secrets to protect - that's the nature of the world we live in. No matter how much you or I may wish that drivers are all open source, if an opensource driver reveals details about the hardware, manufacturers are not going to want to opensource the software.
Do all of us Linux users a favor, then. Please switch to Windows. Or better yet, Mac OSX. Linux should not change itself to support the needs of the consumer-gamer crowd; if you want your expensive hardware to 'just work' why are you running on a tinkerer's operating system?
=====================
Together, we will drive the rats from the tundra.
Wouldn't it be more productive to concentrate on finding a solution everyone can accept?
Quack, quack.
I thought the GPL was a license that allowed someone, under certain circumstances and provided they do certain things, to legally make copies of something that normally copyright law would prevent.
That could stop someone from distributing Linux,
but how could that possibly prevent them from releasing their own work?
-- this is not a
The thing that worries me in that thread is the following:
Now, IANAP[rogrammer] but it seems to me that you need the kernel headers on the system to compile anything, so any time you compile anything on linux, you are using the kernel headers, right? So therefore, any time you compile anything on Linux, you are using the kernel headers.
Therefore, assuming my logic is correct, any Linux binary must necessarily fall under the GPL.
PLEASE tell me I am missing something here, and that I am wrong. Obviously if I am right it will not mean the end of Linux but it will basically pit Linux against the entire non-GPL world in a very confrontational way. Rather than the long road to glory, it'll be the short road to war.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
My employer has a product that includes an embedded Linux system. Some of the product code runs in user space, some is implemented as loadable modules. I can find no clear guideline anywhere that tells me whether the product can remain proprietary (i.e., closed source).
First problem: Nobody's *opinion* (not even Linux or Stallman) counts - only a legal interpretation of the GPL has any weight in the real world (i.e, with my employer). Such a legal opinion does not yet exist (though it probably will post-SCO).
Second problem: Does the fact that some code is a module mean it has to be GPL'd? (These aren't device drivers, BTW).
Third problem: How much does the use of header files "infect" the code with GPLness?
As much as I love Linux, using it in a litigation-shy big company is more complicated that most people realize.
I think it would be interesting to see the support for these two statements:
and Where's he getting this stuff? I have serious doubts that copyright law contains the words "user space" anywhere. So just what causes that distinction to exist? My guess is that he's making it up (with the best intentions and desire, of course).That one about "anything that was written with Linux in mind" is particularly amazing.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Simple. They want all the benefits of OSS without all the pain of principles. Remember if having principles was easy, the world wouldn't be in the state it's in. But actions do speak louder than words.
Actually be-fan (were is he now? Usually he comments on such stories) usually brings up the fact (debatable) that the OSS community would have to do an entire OpenGL implimentation. Of course his whole premise rests on the implication that OSS couldn't do such a thing, and points out poor OSS drivers as an example of such a failure. I personally would like to attempt such a feat, just so he'll have crow for dinner.
- anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work.
What implications does this have for TiVo's proprietary modules for access to their proprietary MFS partitions for storing video? Do these have to have their source disclosed as well? (TiVo DVRs run Linux.)Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
...that include Linux kernel header files?
Linus commented in the LKML thread that "YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES" (emphasis in original).
I've written a userland program for my company that #includes a single kernel header file (linux/nbd.h, the network block device).
It's mostly of academic interest, since my company has no plans to ship this program, but does #include'ing that GPL'd header file mean that the program must now be GPL licensed?
I didn't think so, since I'm not getting any actual GPL'd code in my own program (just #defines for ioctl() numbers, and a couple of struct definitions), but Linus's comment seems to say otherwise.
More and more these days, I view the GPL as moralistic masturbation. It's pathetic and sad. There are plenty of other things in this world that are worth being moralistic about. I don't see how software development falls under the same heading as "helping the homeless" or "stopping persecution" or any of those things we really ought to give a shit about.
Sorry, but I just don't want to waste my energy on that crap. My primary objective with my code is for people to USE it. Not to sit around smoking cigars with the boys arguing over who has a "right" to it. Grow up and find something worth fighting for, for chrissake.
"What about users like me? I'm not a coder. For me the source might as well be written in Hebrew. I get no benefits from having the code available. "
Here's a thought everytime someone starts a sentence out this way. If you're not getting any benefit out of source code availablity?[1] Then why are you using software based on Open Source? Honestly, why?
[1] For those who missed it, without source code and all the advantages it brings, what would be the difference between open source and closed? One can give software away without a license (public domain).
That's not all they have to prove...
People all too quickly forget that it wasn't pragmatism that made the community what it is. It wasn't paying attention to pragmatism that got us an entirely Free Software operating system. It's only because that system is so remarkably useful that people think they can afford to throw away the idealistic principles of software freedom in favor of the self-contradictory goal of pragmatism.
The Free Software Foundation wrote about this self-contradiction in this essay. In short, when people have proprietary code that works better than the Open Source alternative, the Open Source movement offers users no reason to reject the proprietary program. By contrast, the Free Software movement competes on something proprietary programs can never provide--software freedom--therefore Free Software always comes out ahead in a head-to-head comparison, even if it is less practical (which, sometimes, it is).
I recently wrote about this on the Fedora Core user's mailing list hosted by Red Hat. I think what we need to do is have an easy-to-use website that helps people find hardware that works completely with Free Software (all kinds of hardware). Right now, this means recommending ATI video cards (along with a bunch of other video cards) instead of NVidia's hardware. I think once we get organized and have a site that lets a user easily construct a shopping list (even finding supportive online dealers where users can buy what they need right from the site), some manufacturers will be proud to be on the list and continue to help us. Other manufacturers will want to get on the list and be pressured to help us by shipping specs and/or Free Software drivers. Is there anything like this already? We need to stop helping organizations that hurt us.
Digital Citizen
You know, I was thinking of doing the standard Slashdot list of 50 or so applications (out of tens of thousands) that prove you wrong.
Then I realized. Correct me if I'm wrong, but the big show-stopper closed source software in Linux is the controversial nvidia driver(s). Your entire point is that without 3D games, Linux is dead.
See subject line.
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
"Although not a perfect situation it is better than with nvidia. Ati have released enough specs to allow the gatos project to produce some good drivers which even have 3d support and most important for me tv-out support."
Actually in this thread I pointed out that having closed-source means that the manufacturers can sneak in DRM. Note that under Windows playing certain DVD's through the TV-out is impossible, or crippled (Macrovision). Under creative drivers you can't pipe digital-out on certain sources. Under open-source such tricks would be impossible. I'm afraid that we'll have to go through some of the same nonsense that Windows users have gone through before the hard of head learn.
Yeah, Linus doesn't suffer fools lightly.
In this case, he's totally justified, though I think he might be wasting his time feeding a troll. The guy is suspiciously arrogant about a totally wrong-headed view of the GPL.
He's arguing that part of "use" of a GPL'd program includes making use of the source code, and to successfully make use of a header file, for example, he'd be forced to link it (with his non-GPL code). Therefore this usage couldn't be forbidden by the GPL.
Huh.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
You say that as if this is the user's concern. It isn't the user's problem that a manufacturer chose to saddle themselves with a variety of non-disclosure agreements and licenses that don't allow Free Software drivers. This is just another reason to avoid doing business with these manufacturers and more justification to reward those companies that do the right thing and allow users to enjoy software freedom.
Digital Citizen
My apology for leaving out the link to the essay I referred to.
Digital Citizen
Instead of whining about it, why don't you just don't use it and shut up. I hate these zealots whose only function in this world is to attack everybody and make everything worse for everybody except themselves, cause they satisfy their own ego by attacking others and feeling proud of what they do thinking that they are fighting for a just cause, while they are actually the evil themselves.
Let's say I accepted the fact that binary only drivers are evil. What video card can I possibly use? Matrox, nvidia, and ati all only offer binary drivers right now.
All I need is some solid 2d performance and stability. Possibly dual head support. This is assuming I can resist the urge to play neverwinter.
I can always switch back to the stock XFree drivers, or just turn off X, if I want to do some kernel debugging for some reason.
I am prepared to help free software developers, you see. I like to send in bug reports when I can. But when I'm not doing that, I want to play UT2003. Is that such a big deal?
Comment removed based on user account deletion
Comment removed based on user account deletion
I realize this may be seen as a nieve question, but is it possible to make userland drivers? I.e. you start a program that talks to the AGP port (the AGP interface code would have to be GPL), but can send signals through it from a binary/proprietary program to the hardware.
Is this possible, or do drivers _have_ to be in the kernel some how. If someone could explain this it would be really helpful to those of us who aren't kernel hackers. Thanks.
"When ideology and theology couple, their offspring are not always bad but they are always blind." -- Bill Moyers
See, I've used linux since around version .95
I remember, clearly, reading the kernel license, which was the GPL with an added clause: that binary-only kernel modules were permitted, as long as they use an interface that already exists in linus' kernel tree. So you could write a new binary only network driver, or scsi driver, or video driver, but not some totally new kernel functionality, and wrap it up as a module.
Now, I realize that this clause seems to have never existed, and I must have mentally mixed up some mailing list posts with the actual license... I can't find it anywhere in the kernel archives.. but I swear Linus' older kernel license was not just the stock GPL... it had some exceptions.
Anyone else remember this, or am I off my rocker?
On a side note, there are certian things nVidia CAN'T publish if they have to use GPL! Much of the hardware they build is "patented" from outside sources...they would get into IBM/SCO style lawsuits...but without any cause to defend themselves! That leaves them [and us] with bianary drivers--or NO drivers.
I'm sorry but that is absolute rubbish. If the hardware is patented then all the details of it are published by the patent office and there are no secrets to hide. They may have secret, un-patented, stuff in their hardware that they don't want anyone else to know about, but their competitors can buy their hardware and drivers, the same as anyone else, and no doubt have many people you can read machine code don't need the drivers in C to be able to understand them. If they have any remotely rational reason for not publishing the C code for their drivers it will be that they just don't want to give away something they spent money writing. You see similar behaviour from Intel with their compilier. They are a hardware company and should be doing everything to get people to buy their hardware including giving away software to make it work better, but the people who run these companies just don't get it.
I understand that. :)
I was merely pointing out the inherent hypocrisy of many who insist that downloading music isn't "theft", yet GPL violations somehow are. Legally, neither is theft; they are all just copyright violations.
I was aware of the Uniform Driver Interface (UDI) project, but again, I don't think their goal was exactly what I had in mind. They specify a "UDI environment", which is an API to be provided by any OS that wants to support UDI drivers. What I'm talking about is making the proprietary driver code present an API much more like a device BIOS interface.
Yes, you do need to know how to interface with your hardware, and so does everyone else who wants develop an OS. Issues of security and stability apply to hardware as well as software. Although I am addressing OS portability, CPU portability would remain an issue. It could be addressed by releasing proprietary code in some low-level intermediate code, or by the device manufacturer simply responding to reasonable requests from developers.
Chill. It's not that black and white, as several other posters have pointed out.
M$ no doubt also agreed not to disclose the vendors' source to the whole world. Open Source can't make that same agreement by its very nature. Nevertheless, I won't claim that even that concession was necessary, given M$'s monopoly power. I certainly would encourage you to go back to the hardware vendors and try again as soon as Open Source takes over the world (which would be fine with me).
Unless you had the nerve to publish it openy. Nerve? No, it should not take nerve to share your knowledge and no one will ever know anything if knowledge can't be shared globally.
Friends don't help friends install M$ junk.
I hate these zealots whose only function in this world is to attack everybody and make everything worse for everybody except themselves
If you could explain how open, well supported drivers would be worse for everyone else, you might have a point, but as it is: you don't. STFU.
No, quite the opposite. It's not user's concern what patents and trade secrets your DVD writer or video card contains. At the same time, it's not users' concern whether the OS allows or doesn't allow the binary-only drivers either. It works both ways.
Again, you are right, but that goes both ways, like I explained above. Also, you cannot judge all companies in one pool that way. Companies base their business models on technologies that they believe are superior and/or will generate most profit. GPL compatibility may be one of the factors, but it's not the only factor. If you sell network cards for servers and want to target Linux installed server base (among others), then it's obviously of more importance. If you are selling Winmodems to prospective AOL and MSN dialup users, and want to find the cheapest way to market them, you may buy bulk from another manufacturer and maybe integrate it with your own software. In the latter case, GPL compatibility is not as much of a factor since Linux desktop market share is nowhere as significant as its server side.
Yeah, well, the definition of "the right thing" is different for different people. Most of the times, it's "the money thing" that's more important for most corporations, anyway. Again, it's like saying Linus should free Linux of GPL and provide it under BSD license instead - it's the "right thing" after all - so that people enjoy freedom of doing whatever they wish with the software, including redistributing without having to provide source code. I don't think that is likely to happen; and I don't think all corporations will all of a sudden give up their patents, trade secrets, and other forms of revenue-generating IP either, just because it hit them that they have to do what some people perceive to be "the right thing."
Yeah, sounds almost eerily like the DriverLoader philosophy, only that approach is even worse because you don't even get a Linux binary.
Karma: It's all a bunch of tree-huggin' hippy crap!
Then I guess it's a real shame that 2D performance suffers from the crappy drivers too, huh. Hey everyone, run vesa. I promise you'll get used to the 60Hz refresh rate.
Karma: It's all a bunch of tree-huggin' hippy crap!
Call me crazy, but I was under the impression the point of a 3D accelerator was to move more of the work to the card. Otherwise you might as well be rendering those quadrics yourself, triangle by triangle.
A 'perfect' video card would have one call per OpenGL function, and the driver really would just shunt the data across. I was pretty sure NVIDIA satisfied this case, at least with their later boards (the unimplemented features on the earlier boards are presumably implemented in the drivers at the time the later boards come out, or they just refuse to implement the feature, one or the other.)
Karma: It's all a bunch of tree-huggin' hippy crap!
What is the inherent problem with using closed source software? Yes, I will admit, having a wonderful troubleshooting tool like the source code is ideal. And yes, that might make your/our lives easier. But why do people fly off the handle when a company doesn't release the source code and/or swear off said software until it is made open source? Too often, people get so caught up with "Open source=Superior" or on the other side "Closed source=Superior". to be a little cliche, why can't we just pick the best tool for the job/all get along? I mean if solution X exists for problem Z, why don't you use it, closed or open source? We shouldn't ALWAYS try to reinvent the wheel.
Here's my take on the topic of whether NVidia's release of binary modules is a good thing. It's a little late for the mods to catch it, but what the hell.
A few years ago, I Matrox released the specs for the G200. GLX drivers were quickly written for the current X server, and later XFree86 4 was released and had nice support as well.
Matrox cards are also well-supported by the kernel -- having a native framebuffer driver for your video card is REALLY NICE. Both framebuffer and GLX drivers were quite stable surprisingly quickly after the specs were made available by Matrox.
Then, NVidia came along with some kick-ass hardware and binary-only drivers. Q3A players all bought NVidia hardware, and Matrox was ignored by anyone serious about 3D performance. They still produce cards, but the last thing I'd really heard about them was that they'd decided to focus on making "business hardware", which I loosely interpret as "non-gamer-oriented hardware".
Years later, I still hear of quirks and problems with the NVidia binary-only drivers, including complaints of lockups and general instability.
Would I consider putting a Matrox card into a vital machine? Sure. Would I consider putting an NVidia card into a vital machine? Hell no.
This is why I don't buy NVidia hardware. Unfortunately, too many people out there are in the "stability would be nice, but I want (current-3d-shooter) now!" camp for NVidia to really gain a bad reputation.
Maybe the XBox was a much, much smarter move for Microsoft than I'd thought previously. If you look at NVidia, tons of Slashdotters would be quite unhappy with them as a company, except that they'd trade ideological comfort for a kick-ass gaming rig any day, so instead of bashing NVidia for being slimy they applaud them for the fact that their half-assed drivers work at all.
I'm led to wonder how many former MS-bashers own an XBox today...
Somebody get that guy an ambulance!
In your case, it seems like you have a GPL driver (PWC) which has a binary plugin that you also create (PWCX) and which contains code that you are contractually bound not to release.
Okay, so the question is, is the code in PWCX derived from the code in PWC? Obviously the proprietary stuff isn't, as you got it from someone and had to sign an NDA to get it. There may be some minor "glue" code in PWCX needed to use the PWC plugin structures. So I'd say that it's not derivitive, simply because you took some [b]already existing closed code[/b] and modified it to make it work with some open code. The act of modifying closed code to make it interoperate with GPL code doesn't make the closed code GPL.
The problem is really that "derived work" is poorly defined. What makes a work derived?
- If I write a complete Linux kernel module from absolute scratch, then it's clearly derived. I wrote it from nothing and wrote it specifically for Linux. So the GPL applies.
- If I take existing code from, say, a Windows driver, port it to Linux, and make it work as a kernel module, then is it a derived work? What Linus is saying is that it doesn't have to be.
It's all about intent. In the second case, I clearly ported the code to make it work with Linux, but I didn't originally write it for Linux in the first place. It was a Windows driver. I began by porting it from Windows to Linux. It's clearly not a derived work at this stage.
Later, I might have even optimized and rewrote portions of the code to make it work better in Linux. Is it a derived work now? Eventually, through the process of optimization and rewriting, I may have completely seperated the codebase from the Windows and Linux drivers.. Now is it a derived work? This is the gray area, because there's no clearly defined point at which something becomes a derived work or not. If I were to dump the driver and write it from scratch for Linux, without referring to the Windows driver, then it is clearly a derived work now, because it was written for Linux from essentially nothing but knowledge of the hardware and knowledge of the Linux kernel. But porting it in is a fuzzier question.
Take nVidia's drivers. It's pretty obvious that they started out by porting the Windows driver codebase into a kernel module. A lot of changes were obviously needed to do this, but it makes the most sense to start with code you already have. In the process of optimizing for Linux and rewriting portions of the code, then they may have changed the code so considerably that you can no longer easily recognize its origins from the Windows driver codebase. But is it a derived work of the kernel? Probably not.
But simply "being a module" isn't what makes it not a derived work of the kernel, it's the origins of the code that determines that. A module may be derived or it may not be. But simply including code from the kernel headers in a project isn't enough to make it obviously derived. I could include that code because that code is necessary to port the driver over to the Linux kernel, but the driver itself clearly wasn't created to work in the kernel, I'm porting it from somewhere else, and likely I don't have to GPL it.
This whole mess [b]isn't about code[/b]. This is about legal definitions and intents and such. That's why there's all this confusion. The only thing any developer making closed source modules needs to worry about is their ability to show that the closed code is not a derived work, and the legal aspects of "derived work" doesn't necessarily have anything to do with the code itself.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
It is becoming increasingly more common these days to use wrappers for binary-only modules.
m sg/1247 8
The last time this came up on Slashdot, I thought about it for a while, and posted this here:
http://www.oreillynet.com/cs/user/view/cs_
(I wish I hadn't posted this as "Anonymous", but O'Reilly's registration system was nitpicky at the time....)
Anyway, a quick summary:
Companies these days are including binary-only modules in the kernel by using wrappers. Here's how it works:
1) Kernel already exists, Open Source and covered by GPL.
2) A wrapper module is written, also Open Source, to link into the kernel. It is written by the company writing the binary-only module, but released under the GPL. This module contains an API that is called by the binary-only module.
3) A binary-only module is written. It is closed source, and not covered by the GPL. The only linkage this module has is to the kernel is via the wrapper module.
Normally the GPL wouldn't allow the linkage of the binary-only module (the LGPL does, but that's not relevant here). However, since the GPL allows the original author of the copyrighted material to re-licence it later as needed for different uses (this is another way for authors of GPL software to make money), this can be done! Since the author of the wrapper module is friendly to the binary-only module, the wrapper would be licenced as GPL to the rest of the world, but not to the binary-only module.
Not only does the wrapper module form a legal barrier against the GPL, but it also serves as a technical barrier against evolving kernel API changes. If the kernel functions change, then glue code can be written within the wrapper module to take care of this, without needing to change the binary-only module at all!
This seemed to be effective for me. Does anybody else see a problem with this idea of using wrappers, or would it work well in all circumstances?
Dr. Demento On The 'Net!
Oh, come on, this is not really that hard:
1: Downloading a GPL'd source in C and compiling it against a binary-only LIBC library with supplied source header...
Allowed.
2: Downloading a BSD'd source and compiling it against a GPL'd LIBC library...
Allowed. You can also compile a completely closed-source code against GPL code. Nothing in the GPL stops you from using the code in any way you want. It only affects redistribution of the code.
Better yet-- providing patches to the BSD source so that it better supports the GPL'd library...
Here is the first example where you actually talk about redistribution (if "providing patches" means sending code to others). If the library is GPL than this means your patched source must be GPL. However you can probably get around it by convincing people that your patches make the program "more portable" or "more standard" or otherwise avoid admitting that the changes were for this GPL library. In any case this is entirely contrived, except for "readline" there are no useful libraries that are GPL and not LGPL.
3: Distributing a GPL'd "wrapper" you wrote and emulates proprietary NDIS Windows Networking drivers?
Allowed. You wrote it and it is pretty obvious that it's use is to load closed-source drivers. If you really think you have to, add an "exception" saying that using this to load closed-source drivers does not violate the license. It's your code and you can modify the GPL in any way you want.
4: Distribute a non-GPL'd (non-redistributable) PHP script that plugs into a GPL'd PHP application server? Is this similar to dynamic linking?
Check the license for the PHP appliation server. In most cases this is allowed.
There's no real way to tell if someone is violating the GPL unless you violate the DCMA, right? For example, you'd have to reverse engineer a Windows library in order to prove that they are (hypothetically) putting GPL code into their commercial product but doing that would be a violation of the DMCA.
No, the FSS has made no such assumption. Copyright covers *copying* and they know that.
If QuickTime/Windows or Emacs/Windows actually contained an entire copy of Windows (so you could run it on machines without Windows) you can be pretty damn certain Microsoft will not be happy and will stop it.
Sources compiled against the API are NOT affected by the GPL. It is sources that are *linked* with GPL code that is the problem, since when you send them to somebody else you are also sending a copy of the linked source.
Everybody is kind of ignoring it, but there are enormous loopholes in the GPL that could be "exploited". Sending somebody a whole lot of source code and telling them to compile it and link it and you could then say the source code is copyrighted and cannot be copied. However in the real world there are problems: first everything you could take advantage of this way is already LGPL or otherwise has exceptions so you could do this anyway. Second you have given the end user your source code and they can look at it, even if you have them sign a contract saying it is illegal.
I think the main problem with the GPL (well from my eyes, as I'm not fluent in law), is the use of the term "linking".
Is RPC linking? Am I in violation of the GPL if I don't GPL my code at the other end of the RPC connection?
What if i make a LGPL'd RPC library? is this a potential way to overcome the GPL? What if the RPC uses named pipes?
What if you use shared memory? This is so ambiguous.. What's the point of protecting against linking if we can get around it? linking is just letting two compiled modules talk to each other across a set of standardised/agreed interfaces.
^moo^
Either you're attempting to lump together disparate things here in an attempt to make it appear that I am not giving corporations something due them, or I'm not being sufficiently clear. I'll try to be more clear to avoid misunderstanding. Issues that directly affect the user's ability to do what is natural to do with technical information, and the profit motivation for a corporation are not the same thing and should not be treated as if they are of equal importance to society. It is definately the user's concern that trade secrets and patents step on user's freedoms. Therefore we should not dismiss these issues as irrelevant because in doing so we lose valuable freedoms. The Free Software community was built on paying attention to the freedoms to share and modify software, not ignoring them because some business tells us to.
And sometimes businesses believe the wrong thing; sometimes they don't know their business as well as they would have you believe (I'm reminded of Jack Valenti's claims that the VCR was to Hollywood movie making as the Boston Strangler was to a woman alone, then later seeing the VCR become the centerpiece of a hugely profitable business model). Expanding their userbase is more likely to be profitable. So even according to this lesser value system of how to maximize profits, your view doesn't explain reality. ATI apparently thinks it's okay to develop competitive video cards and distribute specifications for the Free Software community to use to make drivers. This act deserves our support. It is possible to have what corporations call a "win-win" here--we can work with companies that don't step on our valued freedoms while giving them business. We can help good businesses help us. In the post to Fedora's mailing list I linked to earlier, I suggest we do just that by setting up a database listing only hardware that works with Free Software. We should leave out corporations that don't work with us, like NVidia, regardless of their proprietary drivers. Or we should mention why we are telling people to buy other hardware instead.
Within the context of this conversation, the thing that matters for citizens is software freedom. So long as businesses don't interfere with our freedoms and conduct themselves ethically, I am fine with letting businesses do what they think they need to do to make a reasonable profit. I am also fine steering people away from those that don't work with us to make mutually beneficial products.
As for Linus Torvalds relicensing under a non-copyleft Free Software license, you are drawing a poor comparison. I never said he should do that, he doesn't have the power to do that (he's not the only copyright holder to the Linux kernal anymore), and I don't agree with that logic. Preserving software freedom for all users, including those that use derivative works, is important and worthwhile. I'm glad others distribute software under the new BSD and MIT X11 licenses, because they contribute to our community. But we also need licenses that create and preserve a commons like the GNU GPL does. Businesses have far too much power to dictate copyright and patent policy (particularly in the US via the legalized bribery scheme known as campaign finance).
Digital Citizen
about this or that, how it's legal or it isn't, etc., but ignoring the real issue, namely, that we have to have drivers at all.
Wouldn't it be nicer if there was just a standardised interface to send stuff to the 3d accelerator, like OpenGL, but we send raw OpenGL to the card and the cards' onboard drivers handle it from there? Or raw sound API requests? It wouldn't matter what platform architecture we used them, since we'd just be sending standardised data to the cards and letting them handle it from there.
Upgrades to the drivers would probably have to be a bootable floppy or something to flash the ROM on the card, so manufacturers might actually have to get the drivers right the first time.
But best of all, all we'd need to write is a layer to send the standard API to the cards, nopt have to muck around with billions of different drivers for billions of different cards..
After all, we don't need drivers for hard drives, just the controllers. Why should we need drivers for the PCI devices, and not just for the PCI controller itself?
> No, the FSS has made no such assumption.
Read RMS's seminal comments about the readline library. Read the Linux-Kernel thread linked in this story. Read the comments here.
Sorry, while I agree with your gist, that "ASSumption" is made all the time in the open source world.
Well, I'm not talking about issues that are important to "society" - that's a different topic was not relevant to my point at all. Citizens, society's issues, developers are not users; not the way I envisioned. Users are people who simply use the software. Whether it's patents, NDAs, or GPLed kernel, the software either works, or it doesn't work. Those users don't care about anything else. This even wasn't my original point; but a side point you made.
You are advancing your own propaganda here. And that's fine. Just beware that your perception of "freedom" may be different from others'.
"Citizens?" Take a slightly different view on "freedom" - none of the businesses should be forced to use GPL or any other single license for their works. They should be free to use copyrights, and other business arrangements with other companies to find the business models that they believe is most beneficial to them. Not what you believe is most beneficial for them - that would not be true "freedom" then. I think you want the laws changed more than anything else.
Neither is, for example, NVidia.
That's your propaganda, but I was just giving an example. Again, as an example, some people believe GPL is more restrictive than BSD-type license. The BSD license gives you more freedom to do whatever you want to do with the code/software. Can you ask Linus to release Linux under BSD? You are making a similar argument towards, for example, NVidia.
Well, why don't they just strip out parts licensed from other parties? Then those parts would be re-written with GPL'd code?
The problem with this is code containing patents(i.e. S3TC support).
I was actually thinking of the case of NeXT and Objective C where the FSF decided that providing .o files which would like to the GCC was a derivative work. The case was settled by GPL'ing the Objective C .o's and never made it to court.
:)
One of the issues regarding the GPL, IMO (and IANAL), is that we don't have a lot of case law regarding what exactly constitutes a derivative work of software. We know, for example, that copying code is not necessary to make it a derivative work. The courts handle this on a case-by-case basis which makes it difficult to predict where they will side in any given case, especially with so little case law established.
Bear in mind, I license nearly all my software under the GPL, and I personally would avoid suing or taking other enforcement measures unless the work was clearly and obviously a derivative work (NOT merely one which interoperates/plugs in). Copyright protects expressions, not practical devices, and interoperation seems to me to be the latter.
One of the real questions regarding binary kernel modules is the question of whether dynamic linking is enough to call something a derivative work. The most common answer I have seen from IP lawyers is that there is insufficient case law to determine that and to play it safe. OF course if you distribute the the library under these circumstances it is most likely enforcable, but consider:
The MySQL client libraries are licensed under the GPL. Suppose for a moment that I don't distribute these client libraries, but my application can link to them if they are available. Does my application have to be released under the GPL? What if my program REQUIRES those libraries in order to function? Does this change anything?
One of the questions here (and on the LKML) is whether using
#include kernel.h
makes the work a derivative work. I don't know. Seems to me that the output of the C PReprocessor would be more like object code from a copyright perspective than source code. The binary may be copyrighted, but I am not sure that it is exactly the same. Again, IANAL, and if anyone can provide case law otherwise, I would be grateful
LedgerSMB: Open source Accounting/ERP
People thinking of writing binary-only drivers should consider one thing. Linus has given his views, but he is only one of many copyright holders. Any one of those copyright holders could sue, and some of them take the view that all non-GPL kernel modules are a breach of copyright.
I think for me the test is whether there is a defined API. The FSF claim that dynamic linking to readline is sufficient to make a program a derived work. I disagree because readline has a defined API and you are really writing your program against that rather than against readline itself. Remember that there is another library (editline) which implements much of the same API. If it is true that a program using readline thereby becomes a derived work, it makes no sense. The program would become a derived work of readline and editline at the same time!
(This seems rather like Plato's theory of ideals: the "ideal readline" is the thing you are writing against, not the real implementations.)
In the kernel, I think you'd have more problems. If you could point to a generic spec like NDIS that you were writing against, that would be one thing. (I know Linux doesn't support NDIS drivers, it's just an example.) In practice I suspect the kernel is not documented to this extent, so you end up "modifying the kernel" rather than "writing against an API".
Nvidia may well have imported a lot of existing code, but that doesn't help them. It only takes one line of GPL code to "contaminate" the lot. There was bound to be some Linux-specific "glue" and that will be all that is required.
It is always relevant to the issue of software freedom, which is a superior issue to convenience. Your point about calling people users (some say "consumers" in a similar vein) is true--when people are reduced to this status, society is given an inaccurate picture of how they should be treated. The word "citizen" paints a far more accurate picture because people do care about other issues when they are introduced to them. It also helps lead us to more beneficial conclusions about policy.
That's no excuse for purposefully keeping people in the dark about issues that matter. It has typically been the job of the unethical mass media to keep people from information and arguments that would awaken people's sensibilities about what really goes on in the world--how does Wal-Mart keep prices so low? Why should I run exclusively Free Software when some proprietary software offers better features? Why should I want to pay a few extra cents for tomatoes?--questions like these deserve answers and none are supplied when you focus away from behaving ethically.
Ironically, it's not as you think. The real difference is in who is being denied, not what is being denied. NVidia will not deny themselves the freedom to modify software or distribute it in whatever form they wish, even though they may have chosen to operate under various non-disclosure and patent licenses. Yet they will deny us the power to modify (possibly sharing too) by denying us complete corresponding source code and not giving us this freedom in their program's license. They also want to keep us helpless by denying us technical information about their hardware. And they want us to pay them for this privilege.
Nobody is ever forced to use the GNU General Public License (GPL). People and organizations choose to distribute derivative works based on GPL-covered works, so they choose to abide by the GPL's terms. Some choose to license their works under the GPL so others must choose whether they want to behave in accordance with the GPL. But nobody is forced to distribute programs under any particular license. With effort, everyone can either write their own software, hire someone to write software for them, or derive programs from something licensed under more liberal terms (including the MIT X11 and new BSD licenses).
NVidia is treating their customers wrongly because they distribute non-free software and no means to make Free Software replacements. NVidia chose to do business by tying themselves down under licenses that might prohibit Free Software drivers (or so you seem to be saying). A number of other video card manufacturers shows by existence that one can still make competitive hardware without doing this.
Your example wasn't analogous to what I was saying. I recognize the new BSD license as one of many Free Software licenses, one which purposefully does nothing to preserve the freedom of the software for derivative works. I see this as something people should know so they can make an informed choice when they wield the power to license.
I could, but I won't for reasons I've already described. As for NVidia, I am saying that I won't recommend anyone do business with NVidia (or recommend NVidia to others) until NVidia works with the Free Software community.
Digital Citizen
Again, you are using your own definition of "freedom" - even if you create software under the GPL, you are [in your words] "denying freedom" to everyone else to create proprietary software out of it. Creating/offering/selling proprietary software is one of the "freedoms" you'd be taking away.
But this is how proprietary commercial software works. You pay for the use, utility and the services that the software product provides - you don't pay for the "freedom" to modify and redistribute it. That's nothing new at all. If you don't like laws that allow proprietary software, that's a different issue altogether.
If NVidia chose to cooperate with other companies that hold relevant expertise, copyrights, etc. to make their product that's their choice - they are free to do so. They are free to sign NDAs, other agreements, trade secrets, whatever they believe it will take to offer superior products, at whatever calculated cost. It's their choice how they want to set up their model.
You may well believe that their model sucks, or their products suck, because they don't give you more "freedoms," etc.; but they are not obligated to in any way.
Well, exactly what I was saying. NVidia, as everyone else, is free to use GPL, BSD, or any legal commercial license, provided they don't violate 3rd party licenses, agreements, trade secrets, copyrights, etc.
NVidia is free to "[tie] themselves down" any way they want. That's your opinion, and that's fine.
The example is analogous in one way - if the software, or software/hardware combination that NVidia distributes are covered by multiple copyrights, patents, trade secrets, NDAs, etc. and all those belong to multiple companies, it is highly unlikely that they will all of a sudden all agree to license their contributions under GPL's terms. I drew a comparison that it's as unlikely as, for example, Linux being provided under BSD-type license because of similar reasons.
Readline has to be *linked* with the program to be useful. This is totally different from just having seen or worked with Readline before. Plenty of closed source is written by people "tainted" by Readline and FSS/RMS cannot and will not do a thing about it. The GPL is not viral no matter how much you want to pretend it is.
I agree RMS is being an ass in putting useful shareable functionality under the GPL. The end result is that all Linux command-line programs do not use readline and thus lack editing capabilities. It probably has forced *zero* software to be GPL.
I was aware of the Uniform Driver Interface (UDI) project, but again, I don't think their goal was exactly what I had in mind. They specify a "UDI environment", which is an API to be provided by any OS that wants to support UDI drivers. What I'm talking about is making the proprietary driver code present an API much more like a device BIOS interface.
The "UDI environment" is just their way of saying that the OS has to implement UDI's API to run UDI drivers. (Well, duh!) UDI drivers can be proprietary code -- the UDI specification is not under the GPL, and is free for anyone to implement. There is also a reference implementation of a UDI environment (for Linux) which is open source.
I'm not a lawyer, but I can't fathom any argument for claiming an independently-developed UDI driver to be a derivative work of Linux, even if you choose to load it dynamically into a Linux kernel. (Obviously, static linking creates a binary which is a derived work of both, and therefore couldn't be distributed.) UDI effectively neutralizes the GPL at the device-driver boundary...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay