Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux: the GPL and Binary Modules

michael posted more than 10 years ago | from the how-many-angels-on-the-head-of-a-pin dept.

GNU is Not Unix 657

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."

cancel ×

657 comments

aha! (-1)

Anonymous Coward | more than 10 years ago | (#7658111)

I have will of warrior! Primary! ah!

Re:aha! (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7658151)

lick my sweaty balls asswipe!

Andrew Bartlett? (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7658231)

Andrew, is that you?

I told you to stop shouting obscenities both on Slashdot and in the Senate!

PS. Remember to return those wine bottles.

Firts Dang-diddly post! (-1)

Anonymous Coward | more than 10 years ago | (#7658114)

Yeah!

You Fail It!! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7658125)

Hahah!! I troll you better!!! You have no will of warrior!!

I defeat your troll because I have will of warrior!!!!

Linux linkiing analogy (5, Insightful)

rubypossum (693765) | more than 10 years ago | (#7658117)

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....

Re:Linux linkiing analogy (5, Insightful)

rubypossum (693765) | more than 10 years ago | (#7658136)

On the other hand... if I were to take chepter 5 from the LOTR and change it a little bit, include it in my story and then publish it then it would be a derived work. Just like a company taking net/socket.c, modifying it, then including it in their own module and not distributing the source.

Re:Linux linkiing analogy (-1, Flamebait)

DJ FirBee (611681) | more than 10 years ago | (#7658268)

Mod this post up. I hate these analogy posts that compare sports cars to application and literature to code. They are the bane of slashdot and a piss poor form of argument at the best.

"What if I painted a picture of a women named Mona ? would I be technically stealing from Leonardo Da Vinci or not ?"

If you are doing it and it feels wrong then you are an asshole for doing it in the first place. The world owes you nothing. You are not entitled to steal if it feels like you are stealing and you feel you need an excuse for your actions than most likely you sir, are an asshole.

Re:Linux linkiing analogy (4, Insightful)

arkanes (521690) | more than 10 years ago | (#7658191)

It depends on just how much your story is like LOTR. How much is too much is very subjective and depends alot on your lawyer and how convincing he is. It's the same for software except theres even less case law giving you a clear standard to work from.

Basically, aside from clean rooming, there is no 100% way to ensure that you aren't violating copyright, in ANY field.

Re:Linux linkiing analogy (1)

jlar (584848) | more than 10 years ago | (#7658321)

Well, I don't think that it is a very subjective decision. If it is clear that you are making a rip-off of some copyrighted work you are guilty of copyright violation - period.

Re:Linux linkiing analogy (5, Interesting)

kscd (414074) | more than 10 years ago | (#7658208)

Derivative works in general are a grey area, but in your specific example I would have to say that you are in fact wrong. Not wrong according to the original U.S. copyright law, but definitely wrong according to what we have now. You say, "If I wrote a story that was derived from the LOTR...". That's it. You wrote a story derived, it's a deritave work. That simple. For example, let's say you would like to re-write Gone with the Wind from a slave's perspective. Completely different story (as you can imagine), but characters, plot, etc. derived from the original. If you did this, you would wind up in court, much like the person that did. [freedomforum.org]

It's really simple (2, Informative)

ObviousGuy (578567) | more than 10 years ago | (#7658118)

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.

Re:It's really simple (0)

Anonymous Coward | more than 10 years ago | (#7658161)

If a module is "based upon" GPL code, then it must be released under the GPL as well.

Says who?

sez the GPL (0)

Anonymous Coward | more than 10 years ago | (#7658171)

It's right there in black and white or whatever your default browser color scheme is.

Re:It's really simple (3, Informative)

ajs318 (655362) | more than 10 years ago | (#7658190)

Says this [gnu.org] . Copyright law demands permission to base things on other things.

Re:It's really simple (2, Informative)

mattjb0010 (724744) | more than 10 years ago | (#7658197)

Also see this [gnu.org]

Re:It's really simple (2, Interesting)

ajs318 (655362) | more than 10 years ago | (#7658307)

You put two programmes on the same CD => they are not necessarily anything to do with one another. As long as you have permission from the copyright holders of both, that's fine.

You write a programme that interacts intimately with another other than via the established interfaces for user space => they definitely have something to do with one another. Your programme may well be a derviative work. If it makes use of any information obtained from another programme {e.g. a .h file in an obscure -devel package} then it is quite clearly a derived work.

Wouldn't life be so much simpler if the law just said that you have to disclose your source code, no exceptions?

Re:It's really simple (0)

Anonymous Coward | more than 10 years ago | (#7658221)

If a module is "based upon" GPL code, then it must be released under the GPL as well.

You must release it under the GPL if and only you distribute it. If you keep it for yourself, there are no obligations.

Though true, it's stupid to argue that point (0)

Anonymous Coward | more than 10 years ago | (#7658275)

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.

Re:It's really simple (1, Troll)

mackstann (586043) | more than 10 years ago | (#7658359)

I'm not sure how this is +5 informative, it's obvious you missed the point.

The whole debate is about the *definition* of what is derivation and what is not; it's a big grey line.

RTFA!

Pragmatism (4, Insightful)

nepheles (642829) | more than 10 years ago | (#7658120)

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.

Re:Pragmatism (5, Insightful)

pe1rxq (141710) | more than 10 years ago | (#7658155)

When binary modules are allowed it doesn't help linux in any way....

Just look at the nvidia drivers: The only thing you get are kiddies yelling that nvidia has such great linux support. Meanwhile linux didn't get any better from it, kernel developers get lots of bug reports caused by the nvidia black box (One of the reasons the 'tainted' flag was introduced), I still can't use the nvidia cards on platform not-quite-obscure-nividia-just-didnt-bother-compil ing-their-driver-for-it, and most importantly you don't know what the driver is doing on your system (its a black box afterall)

Jeroen

Re:Pragmatism (5, Interesting)

jusdisgi (617863) | more than 10 years ago | (#7658227)

Whatever man, those modules aren't that bad.

1)I'm interested to see these bug reports due to the "nvidia black box"...you are aware that a good chunk of this thing (and all the kernel interface) is available in source, right?

2)And what's this about not having one compiled for your archetecture? Have you ever installed these? I did it this morning; I typed one command, a menu prompted me to accept a license, then looked for a version on nvidia's ftp site, didn't find one. So it compiled one for me. This was all every bit as easy as running a WISE installer in windows. That is, as long as you can read the instruction on the site where you downloaded the thing from that says "type 'sh nvidia-thingie'"

I have run a lot of video cards in a lot of Linux boxes. Some had open source drivers; most of these were good, a couple were not. Some had no drivers available, and I had to use a generic driver. Sometimes this worked, and sometimes it didn't. If I have my choice, I use an nvidia board...the drivers are easy to install, they're fast, you don't have to worry about getting the right module, and most of all they have a knack for just working immediately.

I wish those drivers were FOSS, but they aren't. I'm not too proud to run them.

Now...if I can just get the 3d on this ATI mobile radeon IGP320M going......

Re:Pragmatism (1, Interesting)

Anonymous Coward | more than 10 years ago | (#7658234)

With the nvidia drivers I get a good refresh rate (maximum for my monitor, yay), decent 2d performance, and great 3d performance (equal with windows).

This enables games to run with as fast or faster performance than windows. Games are the most benchmarked thing on computers, and it enables Linux to get its name in there and some more exposure.

Sure I would prefer open source drivers, but for me; the Nvidia drivers have caused me little grief, and I get to use all of the features of my (formerly) expensive video card.

Re:Pragmatism (5, Interesting)

October_30th (531777) | more than 10 years ago | (#7658249)

Meanwhile linux didn't get any better from it

Yes it did. I get proper OpenGL acceleration on my Linux box now.

not-quite-obscure-nividia-just-didnt-bother-compil ing-their-driver-for-it

You know, if the installer cannot find pre-compiled drivers for your card, it will compile them for you. How's that for service?

most importantly you don't know what the driver is doing on your system

Yeah, right. Have you ever read through the code of your LAN card driver, too? How about the USB controller and SCSI-card? Most important of all, how many driver exploits have you heard of either in Windows or Linux?

Re:Pragmatism (4, Interesting)

MS_is_the_best (126922) | more than 10 years ago | (#7658272)

Yes it did. I get proper OpenGL acceleration on my Linux box now.

That is true and an advantage. Unfortunately the drawbacks are perhaps larger (depends on your opinion). An open driver with the same performance would be better (but perhaps impossible).

You know, if the installer cannot find pre-compiled drivers for your card, it will compile them for you. How's that for service?

Nope, only the interface around the binary core is compiled, not the driver itself.

Yeah, right. Have you ever read through the code of your LAN card driver, too? How about the USB controller and SCSI-card? Most important of all, how many driver exploits have you heard of either in Windows or Linux?

Yes, I have. Lots of others have done this too. Being able to look up the source in case of network troubles is really a great help. The debug mode of the driver is very helpful, the source even better.

Re:Pragmatism (1)

October_30th (531777) | more than 10 years ago | (#7658282)

Nope, only the interface around the binary core is compiled, not the driver itself.

So? It works even though NVidia didn't compile it for you. That was your original gripe.

Re:Pragmatism (1)

ocelotbob (173602) | more than 10 years ago | (#7658311)

So? It works even though NVidia didn't compile it for you. That was your original gripe.
Only if you're running the x86 architecture. If you're running a different architecture, say, PowerPC, then the nVidia binary driver simply won't work.

Re:Pragmatism (0)

Anonymous Coward | more than 10 years ago | (#7658266)

Contrary to your belief, I bet the nvidia modules provide far better opengl support, functionality, and acceleration than any other GPLd, LGPLd, BSDd, ... driver. Not that they couldn't but nvidia would never have released the full documentation to a 3rd party for driver development, or if they did they'd have required the source stay closed. Either way, we would have a fourth-rate driver with minimal support.

Now I can have full support for my nvidia cards, and while I wish they were GPLd I realize that at this point in time that simply isn't going to happen. So I live with it.

Re:Pragmatism (4, Insightful)

zurab (188064) | more than 10 years ago | (#7658289)

When binary modules are allowed it doesn't help linux in any way....


In certain cases, manufacturers can provide open source modules, but many times, there simply is no viable way. Complex hardware or hardware/software combination is usually covered by multiple patents, trade secrets, copyrights, and various agreements between different parties. In such cases asking hardware manufacturers to open up their internals and provide modules open source is like asking Linus to provide Linux under license other than the GPL. In neither of those cases is a single party is in control of all of the "intellectual property" involved; and it is virtually impossible to get all parties involved to agree to such a request.

Re:Pragmatism (4, Insightful)

pe1rxq (141710) | more than 10 years ago | (#7658353)

In most cases hardware/software is believed to be the next best thing since sliced bread by management.....
Most drivers do NOTHING that justifies keeping the code under lock like it is done today.
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.
Its a corporate culture that is the problem, not patents (which already are open for anybody to see anyway), trademarks or trade secrets.

Jeroen

Developer resources and graphic cards drivers (2, Insightful)

HuguesT (84078) | more than 10 years ago | (#7658292)

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.

Re:Developer resources and graphic cards drivers (1)

pe1rxq (141710) | more than 10 years ago | (#7658342)

Meanwhile I'd like to know how are things with the ATI camp, probably not much better.


Actually I just bought an ati card...
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.

Jeroen

Re:Developer resources and graphic cards drivers (0)

Anonymous Coward | more than 10 years ago | (#7658355)

Eh? Why is it nobody ever seems to know about the ATi Linux drivers? Gatos are cool and all, but ATi and nVidia are comparable when it comes to Linux support.

Re:Pragmatism (4, Insightful)

_Spirit (23983) | more than 10 years ago | (#7658305)

So you would rather have nvidia making no drivers at all for Linux? In an ideal world I might agree with you, but in the real world I suspect most Linux users would rather have support for their video card.

Re:Pragmatism (0)

Anonymous Coward | more than 10 years ago | (#7658310)

this is so right on the money...with nvidia jacking with the drivers and all.

they've been caught numerous times, but the stuff we can't see is what would probably astonish us.

Re:Pragmatism (4, Insightful)

LizardKing (5245) | more than 10 years ago | (#7658172)

Binary modules may "lower the entry barrier" for some companies, but it can end up being counter productive. Binary only drivers have tended to be crude ports of Windows drivers, and frequently crash the users kernel. This results in bug reports that the regular kernel hackers can't solve, and a misconception amongst users that Linux is unstable.

Far better would be if companies jumped wholeheartedly into the Linux way of doing things, and published their drivers under the GPL. Their competitors aren't going to get much of a leg up from seeing the source to most drivers, especially those for network adapters and the like, but the vendor can benefit from bug fixes provided by independent kernel hackers.

Chris

Re:Pragmatism (4, Insightful)

jusdisgi (617863) | more than 10 years ago | (#7658247)

Well, the trouble is, the drivers to products that really are trivial (those NICs you mentioned) are already available, because those companies agreed with you and released drivers openly or at least released information, allowing the community to produce them.

But some products aren't that way; nvidia, for instance, at least *says* they have IP tied up in the binary part of their drivers that they can't afford to let competitors (ATI) get ahold of. I don't know whether it's the truth.....I haven't seen the code!

lines have to be drawn (4, Interesting)

ciaran_o_riordan (662132) | more than 10 years ago | (#7658181)

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.

Those parasites are getting rich (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7658192)

Poor Microsoft! All their hard work being exploited and taken advantage of by hardware vendors who don't want to open up the drivers on Windows!

It's so unreasonable that Microsoft would go to all these lengths to build in hooks like the WDM and then get shafted because hardware makers were so greedy as to not open the code. Boohoohoo

Unfair moderation (2, Interesting)

Anonymous Coward | more than 10 years ago | (#7658264)

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.

Re:lines have to be drawn (5, Insightful)

jusdisgi (617863) | more than 10 years ago | (#7658276)

Er, yeah, that's a little warped.

It might make sense to take that position, if such a thing as a "module vendor" existed. As it happens, it doesn't, and no one is out trying to sell binary modules for Linux. The creators of binary modules are *hardware vendors* and they are "contributing" by making their hardware compatible with the free system.

This is not parasitic; if they want, they can just not bother, and you can just not use that hardware in Linux. Let's not forget, it's not like you wrote the driver; why would you want to keep people from making their hardware usable on your system? If a manufacturer says "well, sorry, I want to support linux, but not if it means letting the competition get a sneak peak at this crazy technology in my drivers" you would just say, "ok, parasite, we don't need your stupid hardware."

When the manufacturer in question is a leading producer of video boards, such fanaticism is extremely foolish.

Re:lines have to be drawn (3, Insightful)

_Spirit (23983) | more than 10 years ago | (#7658329)

This is some seriously deranged logic. This is how your post reads to me:

I make a video card which I expect to be used with Windows. Some of my users beg me to support Linux. I make a Linux driver. Now I'm a parasite?

An open sourced driver would be nice but not supplying one is now a crime? What am I missing here?

Re:lines have to be drawn (-1, Offtopic)

leroybrown (136516) | more than 10 years ago | (#7658344)

Since the Linux hackers have written an entire kernel...

Where have you been for the past nine months? Didn't you hear? SCO wrote the Linux kernel!

Re:Pragmatism (4, Interesting)

BESTouff (531293) | more than 10 years ago | (#7658193)

Nope. Having binary modules only stops developers from trying to make their own, so you end up with proprietary, non-debuggable and non-portable (across kernel versions or across architectures) drivers. There are for example winmodem drivers you can only use on a 2.2 kernel, or the famous nvidia drivers which work only on i386. Even if this helps the casual gamer (which would be waaay better running Windows anyway), this is in fact a regression from the free software perpective.

Imagine a future where you install your core Linux kernel, then download a ton of different binary modules from different websites, have to hunt in the forums to mix-and-match the right versions, and end up having bugs nobody won't fix ? Think about it, that's what you want when you allow "pragmatism".

Re:Pragmatism (5, Insightful)

starsong (624646) | more than 10 years ago | (#7658281)

Imagine a future where you install your core Linux kernel, then download a ton of different binary modules from different websites, have to hunt in the forums to mix-and-match the right versions, and end up having bugs nobody won't fix....

We have that under Windows! They're called "drivers."

Re:Pragmatism (1)

Catskul (323619) | more than 10 years ago | (#7658300)

I am inclined to agree with you, however I can think of a similar example that is already possible.
Imagine using the Linux Kernel in an otherwise propriatary setup:
i.e. propriatary shell,
windowing system,
compiler,
browser,
office sofware,
database,
media player,
Instant messenger,
email client.

This is all already possible.
In fact, I believe that there are PDAs out there that do just that.

Re:Pragmatism (1)

Hobbex (41473) | more than 10 years ago | (#7658198)

But it isn't like somebody is sitting around considering whether they should be allowed or not. The kernel is under the GPL, with no expections, and unlike the GNU software where the FSF owns the copyright of the entire thing, everybody who submits to the kernel has kept copyright for their own patches. The linux kernel has thousands of owners, and it would be litterally impossible to change the license now.

So all we can do is try to decipher the meaning of the license that the kernel is already under. Whether that license permits binary modules or not doesn't depend on whether we want it to, but whether they are derived works in the legal sense.

Personally I have always found the argument that linking makes something a derived work very questionable, especially for things like java where linked class files contain little other than the class and method names that they link to. If a java class that calls another is a derived work, then that is yet another dumb copyright law. However, I think that Valdis Kletnieks point about inlining very persuasive. I have a very hard time seeing how a binary module that contains snippets of object code directly compiled from GPLed methods in the kernel (because they were inlined) could possibly be anything but unauthorized distribution.

Re:Pragmatism (1)

GammaTau (636807) | more than 10 years ago | (#7658218)

A certain amount of pragmatism has to prevail here -- were binary modules disallowed, the phrase 'shoot yourself in the foot' jumps to mind.

I don't know if you've fallen for this but one common misunderstanding is that Linus or some other individual kernel developer would be able to decide to what extent binary modules are allowed. In reality, this decision was made when the GPL version 2 was adopted as the license for Linux. Now there is only speculation about what the copyright law says, what the GPL says, and what the courts would say if it ever got to court some day. Each kernel contributor has the option to sue or not to sue but the license and copyright law are what they are and there is very little any kernel contributor can do about them. They can speculate how things are but they really can't make a decision to change anything. Relicensing Linux would require permission from all the contributors which is, for practical purposes, a mission impossible.

SEventh POsT! (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7658128)

Take that fp bastards!
7 > 1!

GPL/Linux Modules? (0, Offtopic)

nil5 (538942) | more than 10 years ago | (#7658129)

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 [sco.com] you will find just the sort of licensing predicament we can expect from now on.

Karma Whoring: Linus's Posts (-1, Redundant)

Trillian_1138 (221423) | more than 10 years ago | (#7658134)

From: Linus Torvalds [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Wed, 3 Dec 2003 16:00:21 -0800 (PST)

On Wed, 3 Dec 2003, Kendall Bennett wrote:
>
> I have heard many people reference the fact that the although the Linux
> Kernel is under the GNU GPL license, that the code is licensed with an
> exception clause that says binary loadable modules do not have to be
> under the GPL.

Nope. No such exception exists.

There's a clarification that user-space programs that use the standard system call interfaces aren't considered derived works, but even that isn't an "exception" - it's just a statement of a border of what is clearly considered a "derived work". User programs are _clearly_ not derived works of the kernel, and as such whatever the kernel license is just doesn't matter.

And in fact, when it comes to modules, the GPL issue is exactly the same. The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result, anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that leads to any gray areas. There are areas that are not gray at all: user space is clearly not a derived work, while kernel patches clearly _are_ derived works.

But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.

Basically:
- 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.
- anything that has knowledge of and plays with fundamental internal
Linux behaviour is clearly a derived work. If you need to muck around
with core code, you're derived, no question about it.

Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area.

Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kenrel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking).

So being a module is not a sign of not being a derived work. It's just one sign that _maybe_ it might have other arguments for why it isn't derived.

Linus

From: Linus Torvalds [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Wed, 3 Dec 2003 16:23:33 -0800 (PST)

On Wed, 3 Dec 2003, Linus Torvalds wrote:
>
> So being a module is not a sign of not being a derived work. It's just
> one sign that _maybe_ it might have other arguments for why it isn't
> derived.

Side note: historically, the Linux kernel module interfaces were really quite weak, and only exported a few tens of entry-points, and really mostly effectively only allowed character and block device drivers with standard interfaces, and loadable filesystems.

So historically, the fact that you could load a module using nothing but these standard interfaces tended to be a much stronger argument for not being very tightly coupled with the kernel.

That has changed, and the kernel module interfaces we have today are MUCH more extensive than they were back in '95 or so. These days modules are used for pretty much everything, including stuff that is very much "internal kernel" stuff and as a result the kind of historic "implied barrier" part of modules really has weakened, and as a result there is not
avery strong argument for being an independent work from just the fact that you're a module.

Similarly, historically there was a much stronger argument for things like AFS and some of the binary drivers (long forgotten now) for having been developed totally independently of Linux: they literally were developed before Linux even existed, by people who had zero knowledge of Linux. That tends to strengthen the argument that they clearly aren't derived.

In contrast, these days it would be hard to argue that a new driver or filesystem was developed without any thought of Linux. I think the NVidia people can probably reasonably honestly say that the code they ported had _no_ Linux origin. But quite frankly, I'd be less inclined to believe that for some other projects out there..

Linus

From: Linus Torvalds [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 07:58:30 -0800 (PST)

On Thu, 4 Dec 2003, Jason Kingsland wrote:
> > - anything that has knowledge of and plays with fundamental internal
> > Linux behaviour is clearly a derived work. If you need to muck around
> > with core code, you're derived, no question about it.
>
>
> If that is the case, why the introduction of EXPORT_SYMBOL_GPL and
> MODULE_LICENSE()?

It is really just documentation.

This is exactly so that it is more clear which cases are black-and-white, and where people shouldn't even have to think about it for a single second. It still doesn't make the gray area go away, but it limits it a bit ("if you need this export, you're clearly doing something that requires the GPL").

Note: since the kernel itself is under the GPL, clearly anybody can modify the EXPORT_SYMBOL_GPL() line, and remove the _GPL part. That wouldn't be against the license per se. But it doesn't make a module that needs that symbol any less needful of the GPL - exactly because the thing is just a big cluehint rather than anything else.

Linus

From: Linus Torvalds [email blocked]
Subject: RE: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 22:58:09 -0800 (PST)

On Thu, 4 Dec 2003, David Schwartz wrote:
>
> The GPL gives you the unrestricted right to *use* the original work.
> This implicitly includes the right to peform any step necessary to use
> the work.

No it doesn't.

Your logic is fundamentally flawed, and/or your reading skills are deficient.

The GPL expressly states that the license does not restrict the act of "running the Program" in any way, and yes, in that sense you may "use" the program in whatever way you want.

But that "use" is clearly limited to running the resultant program. It very much does NOT say that you can "use the header files in any way you want, including building non-GPL'd programs with them".

In fact, it very much says the reverse. If you use the source code to build a new program, the GPL _explicitly_ says that that new program has to be GPL'd too.

> Please tell me how you use a kernel header file, other than by including
> it in a code file, compiling that code file, and executing the result.

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_.

You use the word "use" in a sense that is not compatible with the GPL. You claim that the GPL says that you can "use the program any way you want", but that is simply not accurate or even _close_ to accurate. Go back and read the GPL again. It says:

"The act of running the Program is not restricted"

and it very much does NOT say

"The act of using parts of the source code of the Program is not
restricted"

In short: you do _NOT_ have the right to use a kernel header file (or any other part of the kernel sources), unless that use results in a GPL'd program.

What you _do_ have the right is to _run_ the kernel any way you please (this is the part you would like to redefine as "use the source code", but that definition simply isn't allowed by the license, however much you protest to the contrary).

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).

BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.

Comprende?

Linus

From: Linus Torvalds [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 17:58:18 -0800 (PST)

On Thu, 4 Dec 2003, Larry McVoy wrote:
> >
> > linux/COPYING says: This copyright does *not* cover user programs
> > that use kernel services by normal system calls - this is merely
> > considered normal use of the kernel, and does *not* fall under
> > the heading of "derived work".
>
> Yeah, and the GPL specificly invalidates that statement. We're on thin
> ice here. Linus is making up the rules, which is cool (since I tend to
> like his rules) but the reality is that the GPL doesn't allow you to
> extend the GPL. It's the GPL or nothing.

Larry, you are wrong.

The license _IS_ the GPL. There's no issue about that. The GPL rules apply 100%.

But a license only covers what it _can_ cover - derived works. The fact that Linux is under the GPL simply _cannot_matter_ to a user program, if the author can show that the user program is not a derived work.

And the linux/COPYING addition is not an addition to the license itself (indeed, it cannot be, since the GPL itself is a copyrighted work, and so by copyright law you aren't allowed to just take it and change it).

No, the note at the top of the copying file is something totally different: it's basically a statement to the effect that the copyright holder recognizes that there are limits to a derived work, and spells out one such limit that he would never contest in court.

See? It's neither a license nor a contract, but it actually does have legal meaning: look up the legal meaning of "estoppel" (google "define:" is qutie good). Trust me, it's got _tons_ of legal precedent.

Linus

different perspective (3, Informative)

millette (56354) | more than 10 years ago | (#7658137)

The article is actually an email thread. It does explain boths views. Here's another look at it from Kevin Dankwardt [linuxdevices.com] . A little dated, sept. 2002, but still relevant today.

Free? I don't think so. (1, Insightful)

Anonymous Coward | more than 10 years ago | (#7658146)

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.

Re:Free? I don't think so. (1)

BESTouff (531293) | more than 10 years ago | (#7658166)

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.

Then don't use the word "free", it has a too weak meaning. Either use analogies ("free as in beer"), or other words ("gratis", "libre", "no charge", whatever ..)

Linux driver model doesn't help (5, Insightful)

Vanders (110092) | more than 10 years ago | (#7658148)

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 [sourceforge.net] 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.

Re:Linux driver model doesn't help (3, Interesting)

StenD (34260) | more than 10 years ago | (#7658232)

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
No, because he immediately explains that it isn't an exception, it's a clarification:
There's a clarification that user-space programs that use the standard system call interfaces aren't considered derived works, but even that isn't an "exception" - it's just a statement of a border of what is clearly considered a "derived work". User programs are _clearly_ not derived works of the kernel, and as such whatever the kernel license is just doesn't matter.


And in fact, when it comes to modules, the GPL issue is exactly the same. The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result, anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that leads to any gray areas. There are areas that are not gray at all: user space is clearly not a derived work, while kernel patches clearly _are_ derived works.

But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.
And specifically talking about nVidia:
In contrast, these days it would be hard to argue that a new driver or filesystem was developed without any thought of Linux. I think the NVidia people can probably reasonably honestly say that the code they ported had _no_ Linux origin. But quite frankly, I'd be less inclined to believe that for some other projects out there.
And, to wrap it up:
No, the note at the top of the copying file is something totally different: it's basically a statement to the effect that the copyright holder recognizes that there are limits to a derived work, and spells out one such limit that he would never contest in court.


See? It's neither a license nor a contract, but it actually does have legal meaning: look up the legal meaning of "estoppel" (google "define:" is qutie good). Trust me, it's got _tons_ of legal precedent.

Re:Linux driver model doesn't help (1)

Vanders (110092) | more than 10 years ago | (#7658325)

No, because he immediately explains that it isn't an exception, it's a clarification:

Um, yeah. So in other words: There is no exception. If you read the text you quote you can see that Linus specifically states that "The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result, anything that is a derived work has to be GPL'd." He does not make any exeptions for kernel modules (Which is the point of the entire discussion on the LKML)

While Linus gets tied up arguing about derived works and wether the code was originally written for Linux, he doesn't actually solve the problem of the "grey area". I don't believe Linus has thought it through totally.

Think about it in terms of the nVidia binary modules. The kernel is GPL and the nVidia wrappers are written specifically for Linux. Therefor the wrapper must be under the GPL. If the wrapper is under the GPL and the nVidia driver itself is linked with this wrapper code..what licence is the core part of the driver under? If it isn't the GPL then it can be argued that the "viral" nature of the GPL is fluff, and cannot be enforced or is easily worked around. If it is GPL, then nVidia are going to be concerned because they don't want their driver under the GPL.

here's two well writtens articles: (4, Informative)

ciaran_o_riordan (662132) | more than 10 years ago | (#7658154)

LWN.net do some great coverage of this issue in these articles:
http://lwn.net/Articles/53780/ [lwn.net]
http://lwn.net/Articles/51561/ [lwn.net]
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.

What Linus is missing here... (4, Insightful)

kju (327) | more than 10 years ago | (#7658158)

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.

Re:What Linus is missing here... (2, Informative)

squid_wrangler (596345) | more than 10 years ago | (#7658186)

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.

For device driver (and similar) modules that run within the kernel, the statement that they "don't contain any part of it [the kernel source]" can't be made so easily. To develop and compile the driver, the kernel header files are needed. Even putting aside structure definitions and the like, which are kernel sources, it is very easy to get whole functions subject to GPL be included in binary-only drivers by way of inlining (see the example of "static inline ..." functions mentioned in the original discussion).

Re:What Linus is missing here... (1)

kju (327) | more than 10 years ago | (#7658213)

For development you will need the kernel sources, yes. But the companies are free to use them for inner-house development, and what they are shipping in final is free from kernel sources. See it more like a "patch" against the kernel. This patch is distributed to endusers which happen to use it against the kernel and compile it. And it would work against any other os kernel which happen to have the same module interface.

For the linking (which is done by the enduser!) you will fairly sure end up with having gpl code contained in your binary (e.g. through using the header files which include static inlines). But as the binary is not distributed (at least not by the company), this is no breach of the GPL.

I guess the phrase "binary modules" is misleading. Of course a complete binary-only-module would be very likely against the GPL. But most binary modules are only in part binary only but contain a lot of open sourced stuff for interfacing with the kernel etc. The final linking of the GPL'd stuff against binary-only modules is done by the enduser which is free to do so. No point here.

Re:What Linus is missing here... (1)

MS_is_the_best (126922) | more than 10 years ago | (#7658304)

YANAL, that's obvious.

Re:What Linus is missing here... (2, Interesting)

Anonymous Coward | more than 10 years ago | (#7658199)

We're talking about binary modules. In this case, while the linking may be done by the user, the module is compiled before distribution. Consequently the object file may contain GPLd code by ways of inlining. At that point it clearly becomes derived work and cannot be distributed (except with source and GPL).

Even if it doesn't contain GPLd code there are things to look out for. The GPL defines what is considered derivative and what is not. According to the GPL, kernel modules clearly fall into the former category, even if they don't include GPLd code by inlining. If you are in a position in which you have to accept the Linux kernel license (IOW you distribute the kernel, which you aren't allowed to do without accepting its redistribution license), then you have to provide source to your modules. Only if you don't distribute the kernel you can ignore the GPL's definitions of "derivative" and fall back to standard law definitions which probably allow distribution of a binary module.

Re:What Linus is missing here... (4, Insightful)

kju (327) | more than 10 years ago | (#7658222)

Yes, we are talinkg about some binary modules which are compiled before distribution and WHICH SIMPLY DOES NOT EXIST. All "binary only" modules i've seen so far contains at least a short kernel linkage stub which is distributed in source and compiled by the enduser, because this is the only way to ensure that the module is compatible with your running kernel.

The companies providing "binary only" drivers are only distributing this stub source (which they very often GPL) plus their propitary binary. Compiling and linking is usually done by the enduser. Providing real binary-only-drivers would lead to many problems and therefore just isn't done.

Re:What Linus is missing here... (2, Insightful)

Anonymous Coward | more than 10 years ago | (#7658265)

Stubs don't save you. The intentional viral nature of the GPL transcends stubs. If the stub becomes a derivative work of the kernel, so does the binary module, because according to the definitions of the GPL the stub and the binary module are not independent programs. The real question is if the stub is a derivative work of the kernel. That is exactly the same question as wether a directly linkable binary module is a derivative work of the kernel. According to the GPL it is, according to standard law it is not. It boils down to the question wether you are bound by the kernel's redistribution license, IOW wether you distribute the kernel or not.

Re:What Linus is missing here... (0)

Anonymous Coward | more than 10 years ago | (#7658273)

hhh. Apply where required by spelling laws.

Re:What Linus is missing here... (1)

Hobbex (41473) | more than 10 years ago | (#7658343)

The real question is if the stub is a derivative work of the kernel. That is exactly the same question as wether a directly linkable binary module is a derivative work of the kernel. According to the GPL it is, according to standard law it is not.

The GPL derives it's authority only from copyright law. If copyright law does not recognize the stub as a derivative work, then nothing in the GPL can force it to be, and there are no restrictions under what license it can be distributed.

The problem seems to be that nobody can say for sure whether such a stub is a derivative work under current copyright laws or not.

Re:What Linus is missing here... (2, Insightful)

Anonymous Coward | more than 10 years ago | (#7658242)

On second thought, inlining is probably a non-issue. If you aren't bound by the GPL because you don't distribute the kernel, standard copyright law applies and AFAIK (IANAL), you are allowed to use published interfaces, so standard interfaces which cause kernel code to be inlined into your module probably don't force you to GPL the module. However, entering a contract with kernel developers by redistributing the kernel and therefore accepting the GPL does force you to GPL your module, regardless of inlining or symbol-names.

Re:What Linus is missing here... (1)

BESTouff (531293) | more than 10 years ago | (#7658204)

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.

You just don't seem to know much about IP law, eh ? You will never loose your copyright by releasing some code under the GPL. You still own the code, and you can still make a proprietary package from it, e.g. to sell it packaged for an other OS.

Copyright and license are two different beasts.

Re:What Linus is missing here... (2, Interesting)

geirhe (587392) | more than 10 years ago | (#7658236)

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.

He doesn't. He is claiming copyright for the interfaces you have to use to make a kernel module. You are free to do whatever you wish to the bits you have written yourself - you have the copyright on that.

However, including the *.h files needed to make your code a derived module makes use of something someone else have written. You are not allowed to make copies of that code without the consent of the copyright holder.

The other copyright holder is willing to give you the right to make copies of his code and distribute the result. The terms may, however, be dictated by him. He owns the copyright to the code you need, after all. The terms you are being offered are based on the concept that if you want to link to the linux kernel and distribute the result, you have to let everyone else do what you just did to the code you wrote.

You are, of course, free to try to negotiate a better deal. Be my guest.

Re:What Linus is missing here... (0)

Anonymous Coward | more than 10 years ago | (#7658322)

Copyright law allow you to use published interfaces. That alone doesn't make your module a derivative work of the kernel. The GPL makes a more inclusive definition of derivative works under which kernel modules _must_ be GPLd. The question is whether you're bound by the GPL or not. That only depends on whether you distribute the kernel or not. Just making use of a published interface does not force you to GPL your module, even if that interface causes kernel code to be inlined into your module.

Re:What Linus is missing here... (1)

Tooky (15656) | more than 10 years ago | (#7658327)

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. If someone is distributing source that the user then compiles themselves against the kernel, that would be fine under the terms of the GPL, as you say. But this discussion is about binary ony modules, which do contain part of the linux kernel. The header files. These are linked against and the modules are distributed binary only, against the terms of the GPL.

I love this guy. (5, Funny)

the gnat (153162) | more than 10 years ago | (#7658170)

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.)

How viral IS the GPL? (4, Interesting)

MROD (101561) | more than 10 years ago | (#7658176)

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?

Re:How viral IS the GPL? (-1, Troll)

DJ FirBee (611681) | more than 10 years ago | (#7658241)

"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?"

Listen to me. That should have been at least two sentences. If you want me to help you answer your question, please use punctuation. UmmKay ?

You are a weasel.

Older Thoughts (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7658178)

And here's an old article from about 1992 with an Interterview with Mr. Linux [yahoo.com] which touches on this same issue. Quite an interesting and thought provoking read.

Don't bother... (0)

Anonymous Coward | more than 10 years ago | (#7658252)

Please, don't bother opening that link.

Re:Don't bother... (0)

Anonymous Coward | more than 10 years ago | (#7658258)

Great, another MS Astroturfer (TM) trying to shut Linux users everywhere up. Fuck you buddy! Your OSonopoly is going down bitch!

Re:Older Thoughts (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7658256)

Looks like someone else must have been eating Plumrose Chicken Curry, 59p a tin!

If anyone needs me, I'll be reading up on how to clear Squid's cache.

Re:Older Thoughts (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7658262)

Mod parent down please. Link goes to the quite disgusting tubgirl.jpg

Re:Older Thoughts (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7658277)

Mod Parent Up!!! Very informative. My how far we've came.

MODS!!! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7658284)

Mod parent up informative!

DISGUSTING LINK!!!!!!!!! (0)

Anonymous Coward | more than 10 years ago | (#7658285)

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.

SCO Derivative works theory & Linux modules (4, Interesting)

putaro (235078) | more than 10 years ago | (#7658184)

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.

Re:SCO Derivative works theory & Linux modules (0)

Anonymous Coward | more than 10 years ago | (#7658207)

WRONG.

If this is really SCO's case then it has a fundamental flaw: the linux port of JFS came from the OS/2 codebase. The OS/2 implementation of JFS was done in a clean room fashion based on a specification. There was no sharing of code.

Fair Use (5, Interesting)

Anonymous Coward | more than 10 years ago | (#7658195)

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.

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 .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.

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 that....... (1, Interesting)

Anonymous Coward | more than 10 years ago | (#7658220)

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?

Kernel and module compability (4, Interesting)

Anonymous Coward | more than 10 years ago | (#7658229)

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!?

Re:Kernel and module compability (0)

Anonymous Coward | more than 10 years ago | (#7658317)

That's what would happen if linux would 'destroy' windows. You now have multiple distros trying to make a buck out of something that is free. Like farming in a dry land with only one well (Bad analogy and poorly structered, but hey, Im an AC)

Clearly Gray? (-1, Redundant)

tjackson (50499) | more than 10 years ago | (#7658244)

"Maybe it was, maybe it wasn't, but it clearly is a gray
area." -Linus Torvalds

Why don't they just introduce a proper driver API? (4, Insightful)

MisterFancypants (615129) | more than 10 years ago | (#7658267)

With Windows and other OSes, there is a clearly defined API that drivers code against to work with the system. In the Windows case this is *required* because the driver authors do not have the Window source code (well, most of them don't). If Linux had something similar to the Windows DDK, this would all be a non-issue as that API would become a clear boundary of where the GPL ends and commercial company lawyers wouldn't have a near-heart-attack worrying about this huge (in Linus' words) 'grey area'.

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.

Jon Johansen verdict next week (0)

Anonymous Coward | more than 10 years ago | (#7658291)

From a Norwegian newspaper (free translation): "Experts estimate that Jon Johansen will lose the case..."

Original purpose (4, Insightful)

tjackson (50499) | more than 10 years ago | (#7658298)

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.

Re:Original purpose (1)

Akai (11434) | more than 10 years ago | (#7658348)

So by your argument, every addition/function that IBM, SGI, etc have developed for their unix versions is a dervative and cannot be donated to the linux kernel?

Where JFS/XFS/RCU/NUMA/EIEIO developed using the UNIX .h files? I'm sure they were.

It's my understanding that since the information traditionally included in .h files (excepting perhaps inline'd code) is not considered copyrightable, since all it does is define data types and methods, it does not implemeent them.

this book covers GPL licensing issues quite well (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7658306)

this [amazon.com] book covers GPL licensing issues quite well...

Static Linking with libstdc++ (0)

Anonymous Coward | more than 10 years ago | (#7658316)

What about static linking with libstdc++ and other C++ development libraries in a commercial application?

Is this allowed or not allowed?

Why binary-only modules? (2, Insightful)

file-exists-p (681756) | more than 10 years ago | (#7658333)

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!

kernel-api-headers package? (2, Interesting)

Akai (11434) | more than 10 years ago | (#7658337)

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.

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 .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?

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.

Binary modules & GPL (3, Redundant)

tr0llx0r (730590) | more than 10 years ago | (#7658345)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...