Weekly Edition
Return to the Kernel page
| |||||||||||||
Quote of the week
Oh, and at least one major distro has been served with legal papers
due to them shipping closed source kernel drivers, and more are on
the way. That's the direction some developers are taking. Others,
myself included, [are] taking the technical way and just making it so
damn hard to write and ship a closed kernel module, that they will
just give up eventually. Combine that with the EXPORT_SYMBOL_GPL()
stuff in the kernel, and I give it about 1-2 more years before it's
just technically impossible to write such a module.
(Log in to post comments)
Pressure the problem on multiple fronts Posted Oct 27, 2005 4:43 UTC (Thu) by bignose (subscriber, #40) [Link] [Paraphrased from an earlier reply I gave elsewhere]
We have long seen many efforts to convince hardware vendors to allow free software drivers for their products (either by releasing the complete specs so others can write the driver, or releasing their own driver as free software).
This pressure from customers needs to be chronic (as opposed to acute) so that vendors cannot ignore the fact that they can *increase sales* by releasing or allowing free software drivers.
The flip side of that, though, is to ensure that we make it chronically apparent that they can *reduce costs* by releasing or allowing free software drivers.
The efforts of Greg KH, and many other kernel developers, in making it clear they consider non-free drivers in Linux to be a breach of their copyright (and thus a legally costly exercise), are an essential means of achieving the latter.
It's even better that Greg is one of those who makes it *technically* costly for hardware vendors to put non-free software into Linux, thus getting not just the legal department but the engineers to see the cost benefits of free software.
Thanks Greg, for continuing to drive this simple point home, and actively making it difficult to ignore.
Quote of the week Posted Oct 27, 2005 16:34 UTC (Thu) by yodermk (subscriber, #3803) [Link] Will this effectively lock out the non-Free nVidia and ATI drivers, essentially cutting Linux out of the 3D acceleration game until the open graphics card project gets something out to us?
Or could it possibly have the effect of actually getting ATI or nVidia to Free their drivers? [/wishfull thinking]
Quote of the week Posted Oct 27, 2005 19:42 UTC (Thu) by AJWM (guest, #15888) [Link] I don't think it locks out the non-Free drivers -- a user still has every right to download a closed module from Nvidia or ATI and install it himself. The restriction is on what can be distributed along with GPL software.
Of course, if the technical restrictions are significant, AND if they are deemed to constitute a "technical protection measure" within the meaning of the DMCA, then closed-driver vendors may choose not to produce same.
(If it isn't a DMCA protection measure, there's nothing to prevent a company from working around technical restrictions -- nothing in the GPL prevents a user from combining GPL'd code with non-GPL'd modules, so long as he doesn't distribute the result.)
Quote of the week Posted Oct 27, 2005 19:55 UTC (Thu) by cventers (subscriber, #31465) [Link] EXPORT_SYMBOL_GPL is the bigger issue I think.The good news is that the timing is probably right... there are lots of good 3d titles becoming available on the platform, Wine and Cedega are making the Windows-only titles playable, and so the market share of Linux gamers is growing. I'm personally running a 7800GT PCI-E on my Linux-only desktop, and I'm pleased. I've beaten Half-Life 2, and played a good deal of UT2004, Quake 4 and Doom 3. If either NVIDIA or ATI can be forward thinking enough to GPL a driver, I think the other will shortly be forced to follow suit when within a few generations the entire Linux gamer market segment flocks to the competition.
Quote of the week Posted Nov 4, 2005 11:13 UTC (Fri) by daenzer (✭ supporter ✭, #7050) [Link] > If either NVIDIA or ATI can be forward thinking enough to GPL a driver,> I think the other will shortly be forced to follow suit when within a few > generations the entire Linux gamer market segment flocks to the > competition.
While I wish it wasn't, I'm afraid this is wishful thinking. Not too long ago, ATI provided not only docs and code but even money and engineer time in support of fully free drivers for their then-current cards. That didn't prevent the masses from moving to nVidia's proprietary drivers. Apparently, most of the people who buy graphics cards couldn't care less about free drivers. As long as that's the case, there's little incentive for the vendors to supply them.
Quote of the week Posted Nov 9, 2005 0:01 UTC (Wed) by alex (subscriber, #1355) [Link] Cool. Where are the r300 chipset docs?
Quote of the week Posted May 16, 2006 2:54 UTC (Tue) by Arker (guest, #14205) [Link] These guys might know.
Quote of the week Posted May 16, 2006 2:44 UTC (Tue) by Arker (guest, #14205) [Link] I think, machiavellian as it may sound, this is actually where license enforcement making it a *PITA* to rely on blobware can be a practical advantage.
There are a lot of these people that can't, or won't look beyond the tip of their nose. They're happy to give up their freedom - when it's easy. Make it a PITA, and they'll suddenly have a whole newfound appreciation for the difference between supported hardware and hardware that might work if you use the right blob.
ATI is still benefitting from their past support. People that want 3d hardware accelleration without blobware generally grab Radeons still, as a result of it. There are still plenty on the market using the supported chipsets, and while they aren't as fast as the blobware only models, they're cheap and often faster than the Intel/Via/S3/Matrox options.
I hope ATI realises why the demand for these old cards is still strong...
Quote of the week: Free kernel drivers Posted Oct 27, 2005 20:37 UTC (Thu) by Duncan (guest, #6647) [Link] > Will this effectively lock out the non-Free> nVidia and ATI drivers [?] Good question, because it doesn't have as simple an answer as one might at first assume, and I've yet to see decent coverage of this angle. There might be some in that thread as I haven't read it yet tho I intend to, but I've not seen LWN cover it and I'd like to, as Jon's explanations are always so lucid, even to non-tech folks. Actually, I expect this is one of those not entirely clear-cut areas that the kernel folks haven't entirely pinned down -- and you'll see the how and why in a moment. NVidia's drivers, and I assume ATI's are similar, have two parts, a generally BSD style licenced open code wrapper around a proprietary binary-only core. The BSD licensed wrapper is critical here, as it does all the actual interfacing with the GPL kernel (which is legal to do as the BSD license is more liberal than the GPL -- in fact, it's widely known that some of the kernel code was at least originally from BSD, altho much of it has been rewritten since then). Therefore, it doesn't (directly) break the GPL on that side. Similarly, because it's BSD style licensed, and that license allows it, it can interface/link with the proprietary binary-only core, without issues there. The question that's never been pinned down, is whether that level of indirection is sufficient to keep the GPL from applying to the binary-only core that only interfaces thru the wrapper with the GPL code of the kernel itself. Actually, it would appear there are differing opinions on this within the kernel community itself. In fact, the GPL as it applies to the kernel has for many years carried a "user space" specific disclaimer, put there by Linus himself. This simply states that for the purposes of the GPL as applied specifically to the Linux kernel, the definition of "derived code" shall not extend to any userspace code, thus allowing proprietary userspace applications to be developed and run on Linux without legal threat of the GPL on the kernel applying to them. That's a specific exemption that's nailed down and has been accepted by the Linux community. Many argue that a similar exemption should apply, and that a de facto exemption /has/ applied, to non-free kernel code, /provided/ it is sufficiently separated by wrappers as described above from the GPL code of the main kernel, and /provided/ no functions specifically exported as "GPL-Only" are used by the code in question. Linus himself (I believe, I've certainly seen the point made, and believe I've seen him make it, I /know/ I've seen Evan Moglen of the FSF make it) has pointed out that both logically and (likely) legally, where a binary driver core was created originally for some other platform, and was used unmodified with Linux, with only the code of the undisputed free wrapper changing, it's pretty difficult to argue that said core code was then somehow "derived" from the GPL/Linux code (noting of course that the copyright law preconditions on the "derived" status, if the rights are to be assertable). From there, the argument can be made that it shouldn't matter which platforms the binary code targets -- and in fact we're doing ourselves a disfavor if we allow originally (say) MS Windows targeted drivers but disallow the same code if it originally targeted Linux. The logical conclusion of this line of reasoning therefore holds that as long as the preconditions of the legally interfaced wrapper code and no use of explicitly GPL-only exported functions are in place, the driver should be legally acceptable, regardless of one's individual ethical position on the matter. As I said, the above applies to NVidia's open wrapper over a binary core model, which I /believe/ extends to ATI as well (as I can't imagine ATI's lawyer's OKing an unwrapped direct proprietary module -- there's simply too much at stake). Where I'm NOT clear is just how much of the "proprietary kernel model" landscape uses a similar wrapper module, and is thus arguably legal, tho there's some controversy around it, vs. the degree to which direct linkage of proprietary modules, a rather more serious potential violation, exists. Again, I'd /love/ to see Jon write an article addressing this issue, attempting to quantify the number of modules and the degree to which they are used within the community, which use each connection model. At this point, I'm not even sure that when the kernel hackers write of "proprietary kernel modules", they are including references to the open wrappered ones, or not. That be as it may, there's another aspect to consider as well. In at least US law, the intent of the licensor as generally expressed is taken into consideration as much as the direct wording of the license itself. It could thus be legally argued that the very existence of the "GPL-only" function exports, signify an implicit permission to use the generally exported kernel functions in closed source modules, even when used directly, without a wrapper as described above. That's certainly a valid legal argument to make, altho it's NOT certain which way a court would rule on it. In any case, however, even if the Judge held that the conditions of the GPL still applied, at least in the US, the fact that such a position can be honestly held and has specifically NOT been directly discouraged by the kernel hackers, would tend to cause the Judge to give the defendant more time to comply with any ruling, and make it in general less harsh than it might be otherwise. Where a preliminary injunction to cease and desist from distributing the infringing code might otherwise be granted, now the Judge would tend to wait until after the resolution of the trial. At the resolution, rather than a 30-180 day time to cease distribution and comply, it'd more likely be 90 days to a year. ... Now I'm off to go read the thread and see if there's anything new there to add to to my viewpoint... Duncan
It bears repeating that the GPL is a *copyright* licence. Posted Oct 28, 2005 1:13 UTC (Fri) by xoddam (subscriber, #2322) [Link] Let's point out again that the GPL is a licence to copy.And let's suppose (by the platform-independence argument above) that most device drivers are not derivative works of the kernel. The issue of GPL-incompatible licences on kernel modules applies only to people who wish to copy the kernel. The act of linking a module to the running kernel does not actually copy the kernel. To the extent that *linking* creates a derivative work (the new kernel complete with the module), copyright law prohibits the publication of such a linked kernel if the licences are not compatible. But doing an insmod on your own machine isn't publishing a kernel and ought to come under 'fair use' (DMCA provisions and XBoxes notwithstanding). So the legal question marks aren't hanging over developers of proprietary modules or developers of GPL code, but distribution vendors who wish to distribute the two together in a package. Does distribution of a disc which is a 'mere aggregation' of several pieces of code which, by design, will be linked into one 'derivative work' when loaded into a computer, constitute a distribution of the derivative work?
It bears repeating that the GPL is a *copyright* licence. Posted Oct 29, 2005 0:53 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I'm not a copyright lawyer, but I have heard that one of the exlusive privileges the copyright owner has is to "prepare derivative works," and that that doesn't just mean to copy the derivative work. I've heard it said that even if you want to create a derivative work for your own personal amusement, you need permission from the copyright owner. Seems out of place in copyright law, but I've seen the US statute, and it really does say "prepare."In 1998, a person was editing Titanic video tapes to remove the sex and make it watchable by some very sensitive people. A person would bring him his own copy of the tape and the editor would clip out some of the tape and charge him $5. The copyright owner of Titanic claimed it was a copyright violation. I don't think there was ever an authoritative resolution. (If you're a Titanic fan, I know you want to know where the indecent scenes are in it: there are two: one where Dicaprio sketches Winslet in the nude and you see her breasts, and another where they have sex in a car with steamed up windows).
Quote of the week: Free kernel drivers Posted Oct 28, 2005 9:50 UTC (Fri) by fenrus (guest, #31654) [Link] There is one thing wrong with your reasoning wrt the wrapper:
*IF* the wrapper is a derived work of the linux kernel, it *HAS* to be GPL.
so the question is not just "is the binary portion a derived work" but also "is the wrapper a derived work".
If the wrapper is a derived work (and thus needs to be GPL), and the wapper and the binary portion are distributed together as part of one work, section 2 starts to apply and it still is a big license problem.
Quote of the week: Free kernel drivers Posted Oct 29, 2005 0:11 UTC (Sat) by zlynx (subscriber, #2285) [Link] Nope. It only has to be GPL compatible. The adapter + kernel sort of _becomes_ GPL once linked, and the binary object makes into a sort of unholy stew that cannot be redistributed. But who tries to distribute copies of their kernel's in-memory image, anyway?
If the kernel on its own is okay, and the kernel+adapter is okay, and the adapter+binary object is okay, and the end-user takes the responsibility of sticking them all together, where's the problem?
Quote of the week: Free kernel drivers Posted Oct 29, 2005 7:00 UTC (Sat) by fenrus (guest, #31654) [Link] quoting from the gpl
> b) You must cause any work that you distribute or publish, that in
note the word "THIS". It doesn't say "compatible" it says "THIS". Derived works must be GPL licensed....
Quote of the week: Free kernel drivers Posted Oct 29, 2005 7:45 UTC (Sat) by Duncan (guest, #6647) [Link] While what you say is correct as far as it goes, there's a slight trick ofviewpoint that allows "compatible" licenses as well. In this case, "compatible" means with the same or less restrictions in exactly the same areas, thus, the BSD license is defined as "compatible". Keep in mind that the portion of the content authored by someone remains theirs. They control the copyright and as such, can license it however they please. The /catch/ is that the GPL requires that if the work is derived from something that is itself GPL licensed, it MUST be available under the terms of the GPL -- the portion of the license you quoted. However, that does NOT prevent the new/derived content from being licensed under more LIBERAL terms, such as the BSD license, because the terms of such licenses can always be restricted further to match those of the GPL, meaning it's implicitly licensed under the GPL as well. (Note that a license which attempted to ban restricting of said terms such that the GPL license couldn't apply, would in at least that respect be stricter than the GPL, and thus not compatible with the GPL under the terms you quoted.) Again, the prime case in point is the kernel itself. Specific portions of it have been (and may still be, I'm not sure of current status) directly copied over from BSD -- and are thus under the BSD license. If said license wasn't compatible, that code couldn't be used in the kernel. Further, certain contributors continue to license their code under other than the GPL, either BSD licensing it, or GPL2+ licensing it (where the default kernel license is GPL2 ONLY), or assigning copyright to Linus or Alan Cox or another such party. The idea in many cases is to provide a contact point or some other level of flexibility in the license, such that if they get killed or whatever, and the kernel folks eventually decide to change the kernel license to the GPL3 or whatever, there's some method for doing on the code they contributed, without forcing that code to be rewritten so it can be used under the new license. To those contributors who don't really care about additions to their work remaining free, the BSD license is often considered the way to provide maximum flexibility in regard to license matching with whatever license may at some point be chosen for the kernel. So basically, whether or not copyright gives other than the original author the right to make derivative works, the GPL certainly does so. The GPL *DOES* put some conditions on the DISTRIBUTION of said works, namely that it be possible to redistribute them under the GPL, which the BSD as a more liberal license allows, but it does NOT restrict derivation for private non-distributed use AT ALL, and all it requires of distributed code is that it be available under the GPL as well, regardless of what other license it may be available under (but that ONLY applies to NEW code, code that was itself procured under the GPL remains under the GPL unless one makes arrangements with the original authors or current rights holders to get it under a different license). All that said, the original child reply had me confused for a bit, until others started posting replies to it, grandchildren of my own original reply. Of course, I should also do the usual IANAL disclaimer. If it's something that could put you in legal trouble yourself, definitely get the opinion of a licensed legal practitioner before going ahead with it. I don't have such a license, nor am I particularly familiar with any individual situations, including that of the kernel code except in general. Duncan
Quote of the week: Free kernel drivers Posted Nov 2, 2005 3:57 UTC (Wed) by Ross (subscriber, #4065) [Link] derived from -> must under the same licenselinked to -> must have no additional restrictions
Quote of the week: Free kernel drivers Posted Nov 8, 2005 23:32 UTC (Tue) by James200511 (guest, #33711) [Link] Please answer the following questions:
1. Is public domain code licensed under the GPL or compatible with it?
2. Is an interface layer in the public domain licensed under the GPL or compatible with it?
3. What will happen to the kernel when the copyrights on the kernel code start to expire and that code becomes public domain code? Will the public domain code have to be removed?
4. If it your answer to question 3 is that the public domain code doesn't need to be removed, is your answer compatible with your answer to questions 1 and 2?
5. What do you think prevents the copyright holder of the code from licensing their work under multiple licenses, one of which is the GPL?
6. Are Windows drivers and applications derivative works in which Microsoft has a copyright interest because they use Microsoft public or unpublished or undocumented interface specifications? Is your answer here compatible with your views on whether the same things written to a comparable Linux interface are derivative worksof Linux? If not, how do you explain to a court why you want one approach for one and a different approach for the other when they are doing the same thing?
Quote of the week: Free kernel drivers Posted Nov 9, 2005 3:24 UTC (Wed) by hw2 (guest, #33718) [Link] Answers: (IANAL)
1. It can be both. Public domain code is compatible with the GPL. Therefore, a person can then take the public domain code and create a work that would then be distributed under the GPL, with the person doing the "taking" becoming the copyright holder on the "new" work. Public domain code is a free-for-all. Individuals can take public domain code and created closed-source works from that code.
2. By interface layer, do you mean code? See answer #1.
3. Absolutely nothing. All it means is that portions of the kernel code become public domain and then people can do whatever they want with the public domain code. It does not mean that the same code in the kernel stops being covered by the GPL. In effect, the code in question becomes dual licensed (GPL and public domain).
4. You betcha.
5. Ummm, nothing prevents the copyright holder from licensing their work under multiple licenses, one of which is the GPL. This is not unusual. Have you honestly never heard of dual licensed code before?
Here is a Wiki link for you: http://en.wikipedia.org/wiki/Dual_license
6. Your entire line of questioning and reasoning is deeply flawed and, hence, irrelevant. The Copyright holder, excluding fair-use exceptions, makes all the decisions about how their code can be used when that use falls under Copyright. It does not matter one iota if Microsoft chooses to license their code one way and another copyright holder chooses to license their code under the GPL, BSD, Artistic License, etc.
Once again, look at dual licensing. The copyright holder can have multiple, entirely different licenses for the _exact_ same code. According to you, this copyright holder should be hauled in front of a court for the audacity of legally exercising his rights as copyright holder...
Quote of the week: Free kernel drivers Posted Nov 9, 2005 13:23 UTC (Wed) by Duncan (guest, #6647) [Link] > Please answer the following questions:hw2 has it essentially correct. FWIW, as a poster up the thread, here's my answers: > 1. Is public domain code licensed > under the GPL or compatible with it? Code that is in the public domain either has an expired copyright, or has been specifically placed there. Because such code is no longer subject to the usual restrictions of copyright, and the GPL is enforceable as a grant of license to do what copyright would otherwise forbid, public domain code isn't specifically licensed under the GPL, as such is an oxymoron. That doesn't mean that specific reimplementations of the public domain code as part of a collective work are themselves public domain, as they can be recopyrighted as new works (which BTW is how Walt Disney became so famous -- reimplementing "story code" in the public domain as new copyrighted works). Public domain code is of course compatible with the GPL, as it has less restrictions on it than those imposed by the GPL, so works licensed (as a whole or GPL code together with other licenses, including public domain) under the GPL can incorporate code. > 2. Is an interface layer in the > public domain licensed under the > GPL or compatible with it? As an interface layer to the kernel would of necessity have to come after said kernel, and said kernel remains under current copyright (with the GPL granting additional rights to non-code-owners not otherwise allowed by copyright itself), the reason such a layer could be public domain would of necessity be that it was directly placed in the public domain, rather than due to expired copyright. If it's in the public domain, then it's not "licensed" under the GPL (by itself), or any other license (unless the original code owner has released it under additional licenses). It's public domain -- no restrictions now apply to said code or its use. Note the "(by itself)". Again, new works incorporating said public domain code in whole or in part will be subject to copyright themselves. The new implementation is copyrighted, both as a complete collected work, and the new portions that weren't public domain, by their individual and collective authors. In theory, one could legally still use the public domain code as derived from the new collection just as one could before -- without restriction, but one would have to be /very/ careful if doing so not to infringe on the rights or license of the new code or of the collected work -- that is, to use /only/ the original public domain code. What this means in practice is that it's almost always easier to procure the original public domain code in original form, rather than as part of the restricted new work, because by going to the original public domain source, one doesn't have to worry about accidentally grabbing additional code to which copyright still applies. > 3. What will happen to the kernel > when the copyrights on the kernel > code start to expire and that code > becomes public domain code? Will > the public domain code have to be > removed? Why ever would public domain code have to be removed from an aggregation that is itself now falling into the public domain? No. Of course not, because the entire thing will at that point be public domain. > 4. If it your answer to question 3 > is that the public domain code > doesn't need to be removed, is your > answer compatible with your answer > to questions 1 and 2? I don't see how not. Yes, it's compatible. Note that in any case, if the copyright on the collection is now expiring and it is falling into the public domain, individual components of said collection will by definition have had to be written before the collection of said components could have been made. Therefore, each individual component will have either already fallen into the public domain by that point, or will be falling into it at the exact same time as the collection as a whole. No part of the collection could have been written /after/ the collection as a whole, so no part of it could fail to be in the public domain at the point the copyright on the collection as a whole expires, and it falls into the public domain. > 5. What do you think prevents the > copyright holder of the code from > licensing their work under multiple > licenses, one of which is the GPL? Nothing. If someone authored something (or transfered ownership to someone else thereby surrendering all rights to the non-authoring party to whom they transfered all ownership and rights), the author (or new owner) can license it however they desire. As hw2 mentioned, such dual licenses are in fact quite common, and the basis under which a number of open source products and the companies sponsoring them exist. Qt (Trolltech) and MySQL are two such products, with both GPL and proprietary licenses. Keep in mind, however, two things: One, in ordered to have rights to distribute/publish/whatever a collection, the owner of the copyright on the collection would have had to previously procure a license to include each component work in the collection, negotiating if necessary a license from each component's owner a license to do so. Said individual inclusion licenses may or may not limit the manner of inclusion and the presentation or distribution of the collection. Assuming a component author granted distributions rights to the collection author, said collection author can do the distribution. However, that does *NOT* necessarily give the holder of the collection rights the ability to change the license of the individual component, or permission to grant further redistribution rights beyond the first negotiated instance, UNLESS said additional rights have themselves been granted. IOW, the copyrights on the collection remain entirely separate entities from the copyrights on the components included in said collection, and unless otherwise specifically granted, the holder of the rights on the collection does NOT have additional rights to change the conditions under which the components themselves are licensed. To use a previously mentioned real-world example. MySQL distributes its code dual licensed as GPL and proprietary-commercial. If a user of the GPL code submits a patch, MySQL must get permission from the patch author to incorporate it into both the proprietary and GPL versions. In practice, the effect of such a rule is that MySQL won't incorporate patches into EITHER version unless it has procured permission to incorporate them in BOTH versions, and further unlimited rights to relicense the incorporated patch along with the rest of the product. > 6. Are Windows drivers and applications > derivative works in which Microsoft has > a copyright interest because they use > Microsoft public or unpublished or > undocumented interface specifications? The term "Windows drivers and applications" can have two entirely different meanings. If by that term, you refer to the product MS itself distributes, then not only are the derivative works in which MS has a copyright interest, they are MS owned and copyrighted works directly (with the exception of third party components that MS has licensed from others, Hyperterminal comes to mind, again, the components vs. collection of components idea, as discussed above). Absolutely! If by the term, you refer to products designed by third parties to /run/ on (MS) Windows, that's entirely different. Keep in mind that MS products are proprietary closed source. Independent coders can and do use the released (and unpublished but discovered) APIs of "MSWormOS" (as I call it, for obvious reasons) to write their own applications, which MS does *NOT* have a copyright interest in. These third parties write code to "APIs", that is, "Application Program(ming) Interface(s)", that have been released for the express purpose of allowing third party applications to use them. Use of the interfaces is therefore specifically allowed, because that's the purpose thereof. Note again, that MS is *NOT* releasing MS Windows /code/ for folks to write against, only publishing interfaces, with the express purpose of allowing others to write against them. > Is your answer here compatible with > your views on whether the same things > written to a comparable Linux interface > are derivative works of Linux? Of course. Linux, from a programmer's perspective, refers specifically to the kernel. MS Windows is not just a kernel, but the entire OS including userland portions and interfaces. Note that in my original post I specifically mentioned that the Linux kernel GPL includes a preamble that specifically exempts userland from the requirements of the GPL, so the userland interface isn't an issue at all. In terms of drivers and kernel interfaces, again, fully compatible. Again, keep in mind that MS exports an interface specifically made available to third parties for purposes of allowing them to write MS Windows compatible drivers. Having made the same so available, the courts would rightly side with a driver provider if MS were foolish enough to take them to court for using the interface it provided and licensed for that express purpose. In fact, as I pointed out in my original post, that's one of the current questions under discussion, because the kernel specifically exports a GPL_ONLY interface, implying use of the NON-GPL_ONLY interface is allowed, altho it hasn't been specifically stated as such. While no court has ruled on the question and there's legitimate debate on which way such a ruling might go, the fact of the matter is that at least under US law, anyone implementing a proprietary driver using only the general interface is (IM IANAL O) currently on fairly safe ground, because they couldn't be held to be deliberately infringing, as there's a very real debate on the subject, and the kernel devs themselves have refused to agree on a policy to be applied to the entire kernel. At worst, if such /were/ to be held to be infringing, the terms would tend to be fairly lenient in giving the infringer time to rewrite to (for example) a user-land interface, which due to the specific userland exception mentioned above, wouldn't be an issue. That is of course assuming that even after having lost such a case, the author of said driver continued to insist they could not and would not release source, and didn't simply pull Linux support entirely, but instead chose to go with a Userland driver. In practice, they'd probably either release source, or pull support entirely, picking up their toys and going home. The threat of the latter (in addition to the cost issue of any litigation), is one reason why the question hasn't been resolved one way or another. However, as Linux gains strength, the developers holding the rights are becoming increasingly assertive, and whether in one year or ten, it's likely the issue will eventually be resolved, one way or the other, one way or another. > If not, how do you explain to a court > why you want one approach for one and > a different approach for the other > when they are doing the same thing? Simple. It's /not/ the same thing. Other than the specific ambiguity relating to the GPL_ONLY vs general interface as discussed above, MS specifically releases a binary interface (in addition to the API, source interface) with remains the same over a fairly long period of time (several years), for the specific purpose (and licensed as such) of allowing third party developers to code drivers and the like for their OS. The Linux kernel hackers, by contrast, have been very consistently insistent that they will *NOT* release such an binary interface, for a number of reasons, including that it would encourage binary-only drivers that they do NOT want to encourage (and that many consider illegal), AND that such a fixed binary interface inhibits fixing stuff that's found to be broken or less efficieent than it could be. Even for source-available drivers, which are also forced to recode to the new binary interface when it changes (every kernel), the stated intent is to encourage development to the point where the drivers can be merged into the mainline tree, at which point any interface change is cascaded to all components of the kernel by those doing the changes, so no work to maintain compatibility from the original submitter is required. No specific binary interface to target means anything written to the changing interface is demonstrably derived /from/ said changing interface, which unlike the MS stable interface, hasn't been publicly released and licensed for use by proprietary driver developers. So, indeed, the two OSs, MSWormOS and Linux, ARE different, for those who would write drivers or applications for them, different both in practice and legally. (Again, let me stress I'm NOT a licensed practitioner of the legal arts, and advise anyone actually writing drivers or otherwise having direct legal interest in the ownership and rights of the Linux code and their ability to link to it with proprietary code, to seek qualified legal help, rather than relying on the opinion of some unverified poster on some web site, even one as recognized as LWN!) Duncan
Quote of the week: Free kernel drivers Posted Nov 2, 2005 3:50 UTC (Wed) by Ross (subscriber, #4065) [Link] There's another type of non-GPL binary blob in the kernel and that's firmware. I don't see how it can be argued that the firmware is a derivative of the kernel unless it was specifically designed to interface with it, like through a GPLed driver. I believe that most instances of binary firmwares they are identical to the ones loaded in Windows and even ones on ROMs on older versions of the hardware.
Now I guess it could still be a GPL violation to distribute the merged work, if you can consider it a single work, but it would be one without the binary being a derivative of something else.
Kernel vs Debian Posted Nov 3, 2005 20:57 UTC (Thu) by Luyseyal (guest, #15693) [Link] Which is why it's fine if the kernel has firmware included with it, but Debian can't distribute it as part of main... 'cause that has to do with Debian's social policy, not the GPL.
-l
Quote of the week Posted Oct 28, 2005 9:59 UTC (Fri) by fenrus (guest, #31654) [Link] The r300 project is making progress still, so one-generation-old ATI has a reasonable chance.
Intel's 3D graphics are all open as well, and although it's still not quite good enough for games, each generation is making a big step forward and the latest ones seem to be ALMOST there. Fwiw: intel has about a 50% market share in the graphics market. (if you include the onboard video; of course they don't if you only count the add-on cards)
Quote of the week Posted Nov 1, 2005 23:52 UTC (Tue) by N0NB (guest, #3407) [Link] One of the problem areas is wireless network adapters where the US FCC mandates a tamperproof driver to assure Part 15 compliance. I am most familiar with Madwifi for Atheros chipsets and I know it provides a binary file for the chipset driver.
I understand perfectly well the motivation of the kernel developers, and I understand perfectly well the regulatory requirements of the FCC and why they exist. This is an interesting case where two opposing worlds collide.
Quote of the week Posted Nov 4, 2005 3:16 UTC (Fri) by riel (subscriber, #3142) [Link] There is no such thing as "tamper proof". Just do a web search and you will find software that works around, or changes, the binary only drivers to make the wifi cards transmit on other frequencies and/or with different transmission power. Ironically it is the binary only drivers that are being tampered with...
Strange Posted Nov 2, 2005 3:26 UTC (Wed) by Ross (subscriber, #4065) [Link] I'm no fan of binary drivers but I find it surprising the kernel developers now consider them copyright infringement. Why not just make all the kernel symbols GPL-only or make some new OPEN-only tag? Is this new policy stated clearly in the kernel tarball? What about Linus' exception for binary drivers added before the GPL?
And finally, why sue a Linux distributor rather than the creator of the module?
Copyright law is Strange Posted Nov 3, 2005 3:47 UTC (Thu) by bignose (subscriber, #40) [Link] > I find it surprising the kernel developers now consider them copyright> infringement.
Two things that may help to understand this: it's not *all* the kernel developers who interpret the license this way; and it's not just "now", many kernel developers have felt this way from their first code contribution.
> Why not just make all the kernel symbols GPL-only
This is an ongoing debate. I'd certainly shed no tears if direct connections to the kernel code were assured to be GPL only.
> What about Linus' exception for binary drivers added before the GPL?
Linus is one of those kernel developers who does *not* feel strongly that binary kernel code is copyright infringement. It's not a homogenous pool of policy, it's a dictatorship :-)
> And finally, why sue a Linux distributor rather than the creator of the
The creator of the module did not (presumably) perform an act covered by copyright in the kernel code; writing one's own software cannot be covered by the copyright of someone else's software.
The license terms of the GPL code in the kernel only apply to those who would perform acts covered by the copyright holder's copyright; that includes distributing the code along with something else that links to it. Thus, it is distribution of the binary driver with the GPL code, not writing the driver in the first place, that violates the copyright.
|
|||||||||||||