Re: GPL vs non-GPL device drivers
Linux and OpenSource is evolution - go on and create your closed source drivers and do your own closed-source fork - go on and create your own little homo neanderthalensis ! ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Linux and OpenSource is evolution - go on and create your closed source drivers and do your own closed-source fork - go on and create your own little homo neanderthalensis ! ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
> Macrovision. Just about every vendors hardware can do Macrovision. They just forget to include the Macrovision control in published code, or hide it in a tiny extra driver (Matrox) or in the BIOS switching firmware (SiS) > Just so you know I'm not making this up: I know where the "defeat > Macrovision" bits are on certain devices, and if I told you, Jack They've been published repeatedly, people have even released source code with some of the macrovision functions included. One of the DVD hardware vendors for example released complete Macrovision programming code for their DVD hardware to the public. The Nvidia driver code sets that have been investigated show no sign of either secret macrovision code or delay loops, or stuff crippling the chip. There is a reason for the last twopeople do speed limiting with hardware traces because every kiddie on the planet can do software or jumper based ones. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/25/07, Trent Waddington <[EMAIL PROTECTED]> wrote: On 2/26/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote: > I know it's fun to blame everything on Redmond, but how about a > simpler explanation? Says the master of conspiracy. Yes, I rather chuckled at the irony as I wrote that one. :-) But there is a difference. I've provided you with independent sources for the basic data -- Nimmer and Corbin and dozens of appellate opinions for the universal contract nature of copyright licenses, guidestar.org for Form 990s, links that you can follow a couple of hops to two actual letters of opinion that Moglen has written suggesting "GPL circumvention" techniques, facts that you can verify about the financial dealings surrounding the formation and acquisition of Cygnus Solutions, the campaign to squeeze OpenSSL out of the GNUniverse, and the unreproducibility of commercial cross-compilers built around GCC. You don't have to believe a damn thing I say -- read the law and follow the money trail for yourself. If you care to know more about how the racket works, you can do your own damn homework and see if you reach the same conclusions I did two years ago. Subsequent events -- the forced merger of OSDL into the Linux Foundation, the flowering of the SFLC into the Software Freedom Conservancy, the sunset of Oracle on Sun and rise of Unbreakable Linux, the hocus-pocus around "license compatibility" as first Intel and HP, then Sun, knuckle under, switch to the GPL, and start pressing IBM and Oracle to do the same, the war of the "patent pledges" -- fit into the same pattern. I was disgusted then, and I haven't seen any reason to become less so. I don't actually enjoy this sort of muckraking -- it's dirty work and I have better things to do. Watch for more posturing about Microsoft/Novell -- funny how the distro that regularly pays Eben Moglen to give keynote speeches has been charging by the seat for years, but the distro that does a deal with the _other_ devil is threatened with being written out of GPL v3. Watch for -- but wait, I gave up ranting for Lent. Watch for anything you like, keep scanning the horizon for Moby Ballmer and his secret deals to keep you dual-booting into Windows for your frag-fests. When your pet shark in law professor's clothing decides _your_ arm would be tasty next, don't come crying to me. This really is the absolute last I have to say on this topic in a public forum, in 2007 anyhow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/25/07, Alan <[EMAIL PROTECTED]> wrote: > Busy-wait loops were a rhetorical flourish, I grant you. Thats a complicated fancy way of saying you were talking rubbish ? No, it's a way of saying "yes, there are deliberate performance limits in the driver code, but they're harder to explain than busy-wait loops". Ask anyone who has worked inside a peripheral device company, especially one that sells into the OEM/ODM market. It is _standard_practice_ to fab a single chip design that runs as fast as you know how, and then dumb it down in firmware to meet the spec that the board vendor is willing to pay for. If you don't, those guys will steal you blind, diverting chips intended (and priced) for low-margin commodity mobos into the high-margin gamer market. There is, however, a gross error in my latest explanation of why ATI and NVidia don't provide full driver source code. Really an embarrassing oversight. Wouldn't blame you for ripping me a new one over it. Pity you were busy taking cheap shots at my tortured syntax. Here's what I forgot: Macrovision. Not that any of the stuff about market segmentation, retail margins, and the FCC isn't true, but it's not the scariest thing in a PC graphics vendor's world. The scariest thing in their world is the possibility that it will become widely known how to defeat the "Macrovision in, Macrovision out" mechanism (and the equivalent for DVD playback and HDMI). Just so you know I'm not making this up: I know where the "defeat Macrovision" bits are on certain devices, and if I told you, Jack Valenti would personally come to my house and ream me out with a red-hot poker. (Alan, that's a special kind of "talking rubbish" known as "comic hyperbole". I learned it from your Monty Python. :-) Seriously though, those bits are in there, they're software controlled (or were when I last fiddled with set-tops), and there are large security deposits and large threats of being shut out of the MPEG/DVD and DVI/HDMI patent pools riding on the graphics card makers' promises to keep them hidden. Not that they're that hard to reverse engineer -- but they're not going to help you. You're going to say this cat is already out of the bag; a quarter of the teenagers in developed countries have the MaD sKiLlZ to rip DVDs and pass them around on BitTorrent like so much 1970s kiddie porn. And maybe that's so; but imagine next year's family PC with the HDMI port attached to the 62" HDTV, dual-booting pirated Windows for pirated first-person shooters and Linux for pirated DVDs, both of them conveniently pre-installed by the neighborhood store-front beige-box assembler. That's the MPAA's worst nightmare -- and frankly, I'm not too keen on it either. I like seeing old movies lovingly restored and published on DVD. I'd like to see them come out someday in 16:9 720p, preferably while my eyes are still good enough to tell the difference. Anyway, that's more than enough purple prose. Believe what you want to believe. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/25/07, Alan [EMAIL PROTECTED] wrote: Busy-wait loops were a rhetorical flourish, I grant you. Thats a complicated fancy way of saying you were talking rubbish ? No, it's a way of saying yes, there are deliberate performance limits in the driver code, but they're harder to explain than busy-wait loops. Ask anyone who has worked inside a peripheral device company, especially one that sells into the OEM/ODM market. It is _standard_practice_ to fab a single chip design that runs as fast as you know how, and then dumb it down in firmware to meet the spec that the board vendor is willing to pay for. If you don't, those guys will steal you blind, diverting chips intended (and priced) for low-margin commodity mobos into the high-margin gamer market. There is, however, a gross error in my latest explanation of why ATI and NVidia don't provide full driver source code. Really an embarrassing oversight. Wouldn't blame you for ripping me a new one over it. Pity you were busy taking cheap shots at my tortured syntax. Here's what I forgot: Macrovision. Not that any of the stuff about market segmentation, retail margins, and the FCC isn't true, but it's not the scariest thing in a PC graphics vendor's world. The scariest thing in their world is the possibility that it will become widely known how to defeat the Macrovision in, Macrovision out mechanism (and the equivalent for DVD playback and HDMI). Just so you know I'm not making this up: I know where the defeat Macrovision bits are on certain devices, and if I told you, Jack Valenti would personally come to my house and ream me out with a red-hot poker. (Alan, that's a special kind of talking rubbish known as comic hyperbole. I learned it from your Monty Python. :-) Seriously though, those bits are in there, they're software controlled (or were when I last fiddled with set-tops), and there are large security deposits and large threats of being shut out of the MPEG/DVD and DVI/HDMI patent pools riding on the graphics card makers' promises to keep them hidden. Not that they're that hard to reverse engineer -- but they're not going to help you. You're going to say this cat is already out of the bag; a quarter of the teenagers in developed countries have the MaD sKiLlZ to rip DVDs and pass them around on BitTorrent like so much 1970s kiddie porn. And maybe that's so; but imagine next year's family PC with the HDMI port attached to the 62 HDTV, dual-booting pirated Windows for pirated first-person shooters and Linux for pirated DVDs, both of them conveniently pre-installed by the neighborhood store-front beige-box assembler. That's the MPAA's worst nightmare -- and frankly, I'm not too keen on it either. I like seeing old movies lovingly restored and published on DVD. I'd like to see them come out someday in 16:9 720p, preferably while my eyes are still good enough to tell the difference. Anyway, that's more than enough purple prose. Believe what you want to believe. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/25/07, Trent Waddington [EMAIL PROTECTED] wrote: On 2/26/07, Michael K. Edwards [EMAIL PROTECTED] wrote: I know it's fun to blame everything on Redmond, but how about a simpler explanation? Says the master of conspiracy. Yes, I rather chuckled at the irony as I wrote that one. :-) But there is a difference. I've provided you with independent sources for the basic data -- Nimmer and Corbin and dozens of appellate opinions for the universal contract nature of copyright licenses, guidestar.org for Form 990s, links that you can follow a couple of hops to two actual letters of opinion that Moglen has written suggesting GPL circumvention techniques, facts that you can verify about the financial dealings surrounding the formation and acquisition of Cygnus Solutions, the campaign to squeeze OpenSSL out of the GNUniverse, and the unreproducibility of commercial cross-compilers built around GCC. You don't have to believe a damn thing I say -- read the law and follow the money trail for yourself. If you care to know more about how the racket works, you can do your own damn homework and see if you reach the same conclusions I did two years ago. Subsequent events -- the forced merger of OSDL into the Linux Foundation, the flowering of the SFLC into the Software Freedom Conservancy, the sunset of Oracle on Sun and rise of Unbreakable Linux, the hocus-pocus around license compatibility as first Intel and HP, then Sun, knuckle under, switch to the GPL, and start pressing IBM and Oracle to do the same, the war of the patent pledges -- fit into the same pattern. I was disgusted then, and I haven't seen any reason to become less so. I don't actually enjoy this sort of muckraking -- it's dirty work and I have better things to do. Watch for more posturing about Microsoft/Novell -- funny how the distro that regularly pays Eben Moglen to give keynote speeches has been charging by the seat for years, but the distro that does a deal with the _other_ devil is threatened with being written out of GPL v3. Watch for -- but wait, I gave up ranting for Lent. Watch for anything you like, keep scanning the horizon for Moby Ballmer and his secret deals to keep you dual-booting into Windows for your frag-fests. When your pet shark in law professor's clothing decides _your_ arm would be tasty next, don't come crying to me. This really is the absolute last I have to say on this topic in a public forum, in 2007 anyhow. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Macrovision. Just about every vendors hardware can do Macrovision. They just forget to include the Macrovision control in published code, or hide it in a tiny extra driver (Matrox) or in the BIOS switching firmware (SiS) Just so you know I'm not making this up: I know where the defeat Macrovision bits are on certain devices, and if I told you, Jack They've been published repeatedly, people have even released source code with some of the macrovision functions included. One of the DVD hardware vendors for example released complete Macrovision programming code for their DVD hardware to the public. The Nvidia driver code sets that have been investigated show no sign of either secret macrovision code or delay loops, or stuff crippling the chip. There is a reason for the last twopeople do speed limiting with hardware traces because every kiddie on the planet can do software or jumper based ones. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Sunday 25 February 2007 19:47, David Schwartz wrote: > > > Similary, there are many ways to write inline functions present in > > headers, and no, embedded developer being lazy does not mean they can > > copy those functions into their proprietary module. > > Yes, it does. Have you read Lexmark v. Static Controls? You can take what > you need to interoperate. This is apples and oranges, to use your idiom. In that case Lexmark had the code in the toner cartridges had to have a specific SHA1 hash in order for the printer to recognize them. Because the only way, then, to produce a functional toner cartridge for the printer was to *copy* that code *exactly*. In the case of a system where this is not the case, then you are free to write your own interface functions. If Lexmark had *not* been using a SHA1 hash to validate that the cartridge was produced by them (and that is the real reason - Lexmark wanted to lock users of their printers into buying new toner cartridges from them) the case would have gone against Static Controls. The Lexmark v Static Controls decision applies only to interfaces where there is only, literally, one way to do it. What this means is that, yes, any use of the code in a GPL'd product that could be written in another manner is not covered by the "interoperability standard" that Lexmark v Static Controls describes. (No argument here, people: Lexmark v. Static Controls basically says "Since the only way for this replacement toner cartridge to work was to have the 'Toner Loading Program' exactly copied from one of the cartridges produced by Lexmark doing such is fair use." All application of this precedent to other things must show the exact same thing - namely that the *one* and *only* way for something you have designed/written to fulfill its purpose is to rely on a copy of a copyrighted work. This ruling *only* applies to making computers, peripherals or parts of those peripherals and the copyrighted item that makes it interoperable. Lexmark v. Static Controls does not give people carte blanche to use interfaces to programs that could be re-implemented by them without causing the output to stop functioning. In the given example the work including the GPL'd header file and using its functions is in violation of the GPL if not released under the GPL but is distributed. Why? Because unless there was some form of lock-in making those functions a requirement for interoperability the "Evil Hacker" could have written and used his own versions and his plugin/program would still have been interoperable. DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: GPL vs non-GPL device drivers
> > Right, but *why* is he doing that? The answer: It is the most > > practical way > > to write his driver. > Most practical way to get something Windows compatible is to pirate > Windows; I do not think that gives me permission to do so. This is comparing apples to oranges because Windows has an EULA. EULAs, shrink-wraps, or the like change everything. However, your statement is self-contradictory. By definition, to "pirate" something is not to take what is practically needed to make it interoperate with something else. My point is that taking what you practically need to make something interoperate with something else is *not* pirating. It is *not* taking protected content, it is taking function. How hard is this to understand -- you *cannot* use copyright to make any ideas harder to express. A kernel driver to make a particular piece of hardware work with a particular version of Linux *IS* an idea. You cannot own the most practical ways to express an idea -- you can only own the one way you chose to express that particular idea. > Similary, there are many ways to write inline functions present in > headers, and no, embedded developer being lazy does not mean they can > copy those functions into their proprietary module. Yes, it does. Have you read Lexmark v. Static Controls? You can take what you need to interoperate. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/26/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote: I know it's fun to blame everything on Redmond, but how about a simpler explanation? Says the master of conspiracy. Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Sunday 25 February 2007 06:54, Michael K. Edwards wrote:
> On 2/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> But a 20KLoC 3-D graphics driver that happens to #include
> is not thereby a "derivative work" of the kernel,
> no matter how many entrypoints are labeled EXPORT_SYMBOL_GPL or
> provided as inline functions. And under the Lexmark standard,
> MODULE_LICENSE("GPL") with a disclaimer in the doco is by far the
> sanest way to deal with the EXPORT_SYMBOL_GPL mind games, and likely
> (IANAL, TINLA) to be endorsed by any court in the US and probably lots
> of other places too. Especially when the graphics chip maker explains
> that keeping their driver source code closed isn't really an attempt
> to hide their knowledge under a bushel basket. It's a defensive
> measure against having their retail margins destroyed by nitwits who
> take out all the busy-wait loops and recompile with -O9 to get another
> tenth of a frame per second, and then pretend ignorance when
> attempting to return their slagged GPU at Fry's.
At that point, Mike, you are treading on *very* thin ice. With Intel having
released the complete source to their chipsets and with the number of totally
free 3D drivers that don't slag GPU's...
However - if the hardware is really that fickle then why is it on the market?
Yes, it can run hot enough to slag itself - all modern CPU's run the same
risk. Yet people, mostly the "Power Gamers", will push a CPU beyond their
rated spec's and have it riding the edge of thermal breakdown. Because of the
nature of the 3D accelerator market most manufacturers (of the chips
themselves) have already pushed their chips to that thermal edge, and some of
the makers of the boards will even provide the end user means to push the
chips even further.
However, even *with* some hardware manufacturers providing a way for the
end-user to do it, pushing the componets to the edge of thermal breakdown (or
beyond and keeping them in check through an active cooling system) is
not "normal and expected use". As well, if the that is the argument that
NVidia and ATI use (that they are worried about people recompiling the code
with busy-loops stripped out) then they don't know the Open Source community
well. In general the people that are most likely to recompile the driver with
the busy-loops removed don't run Open Source systems - they run Windows.
Those people are called "competetive gamers" and 99% of the games they play
are only available for Windows.
What I'm trying to say is: Just like the "It gives away too much information
on our IP" claim, the "People will recompile it with code needed to keep it
from destroying itself" claim is bunk. Even moreso if their code is
documented well enough that the purpose of the busy-wait loop is clear.
DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Sun 2007-02-25 03:33:38, David Schwartz wrote: > > > But... how does situation change when Evil Linker does #include > > from his > > binary-only part? > > Right, but *why* is he doing that? The answer: It is the most practical way > to write his driver. Most practical way to get something Windows compatible is to pirate Windows; I do not think that gives me permission to do so. Similary, there are many ways to write inline functions present in headers, and no, embedded developer being lazy does not mean they can copy those functions into their proprietary module. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
> Busy-wait loops were a rhetorical flourish, I grant you. Thats a complicated fancy way of saying you were talking rubbish ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Pavel Machek wrote: Hi! Actually, it's quite clear under US law what a derivative work is and what rights you need to distribute it, and equally clear that compiling code does not make a "translation" in a copyright sense. Read Micro Star v. Formgen -- it's good law and it's funny and readable. I've drafted summaries from a couple of different angles since VJ requested a "translation into English", and I think this is the most coherent (and least foaming-at-the-mouth) I've crafted yet. It was written as an answer to a private query to this effect: "I write a POP server and release it under the GPL. The Evil Linker adds some hooks to my code, calls those hooks (along some of the existing ones) from his newly developed program, and only provides recipients of the binaries with source code for the modified POP server. His code depends on, and only works with, this modified version of my POP server. Doesn't he have to GPL his whole product, because he's combined his work with mine?" This is a fundamental misconception. A <> is not a "work Ok, but this is not realistic. I agree that if Evil Linker only adds two hooks "void pop_server_starting(), void pop_server_stopping()", he can get away with that. But... how does situation change when Evil Linker does #include from his binary-only part? I believe situation in this case changes a lot... And that's what embedded people are doing; I do not think they are creating their own headers or their own inline functions where headers contain them. Pavel The amount copied has to be significant. A few lines against the millions in the kernel would not be enough to be copyright infringement. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/25/07, Alan <[EMAIL PROTECTED]> wrote: > of other places too. Especially when the graphics chip maker explains > that keeping their driver source code closed isn't really an attempt > to hide their knowledge under a bushel basket. It's a defensive > measure against having their retail margins destroyed by nitwits who > take out all the busy-wait loops and recompile with -O9 to get another > tenth of a frame per second, and then pretend ignorance when > attempting to return their slagged GPU at Fry's. Wrong as usual... If this is an error, it's the first one _you've_ caught me in. Or did I miss something conformant to external reality in your earlier critiques? The Nvidia driver and ATI drivers aren't full of magical delay loops and if there was a way to fry those cards easily in hardware the virus folks would already be doing it. The reverse engineering teams know what is in the existing code thank you. Creating new open source drivers from it is however hard because of all the corner cases. Several years ago I worked on a MIPS-based set-top prototype mated to a graphics+HDTV board from a major PC 3-D vendor. We had full documentation and a fair amount of sample code under NDA. We were on the vendor's board spin 52 -- 52! and they'd sometimes spun the chip a couple times internally between released boards -- before it could be persuaded to do the documented thing with regard to video textures. In the meantime, we frotzed a lot of boards and chips before we decided to stick a triple-size fan to the damn thing with thermal grease and to avoid taking any chances with new VRAM timings except in the oversized chassis with the jet-engine fans. Maybe things have gotten better since then, but I doubt it. Busy-wait loops were a rhetorical flourish, I grant you. But software interlocks on data movement that protect you against some "corner case" you're unlikely to think of on your own are the norm, as is software-assisted clock scaling guided by temperature sensors in half a dozen places on chip and package. You can drive enough watts through a laptop GPU to fry an egg on it -- which is not kind to the BGA bonds. Yes, I have killed a laptop this way -- one that's notorious for popping its GPU, but it's no accident that the last thing I did to it was run a game demo that let me push my luck on the texture quality. It's also quite common, or used to be, for the enforcement of limits on monitor sync timings to be done in software, and it's quite possible to kill an underdesigned monitor or grossly exceed regulatory emissions limits by overdriving its resolution and frame rate. (I've never actually blown one up myself, but I've pushed my luck overdriving a laptop dock's DVI and gotten some lovely on-screen sparklies and enough ultrasonics to set the neighbor's dog to whining.) Viruses that kill your monitor may be urban legend, but it's a can of worms that a smart graphics vendor doesn't want to be liable for opening. The FCC also frowns on making it too easy for hobbyists to turn a Class B device into a two-block-radius FM jammer. You will instead find that both vendors stopping providing Linux related source code at about the point they got Xbox related contracts. A matter which has been pointed out to various competition and legal authorities and for now where it seems to lie. I know it's fun to blame everything on Redmond, but how about a simpler explanation? The technology and market for 3-D graphics is now sufficiently mature to allow revenue maximization through market segmentation -- in other words, charging some people more than others for the same thing because they're willing and able to pay extra. The volumes are also high enough to test chips as they come out of fab and bin them by maximum usable clock speed, just like Intel has done with its CPUs for the last decade. Blow a couple of dozen fuses to set a chip ID, laser trim a couple of resistors to set a default clock multiplier, and sell one for ten times what you get for the other. It's the only way to survive in a mature competitive environment. Now, suppose the silicon process for GPUs has stabilized to where chip yields have greatly improved, and maybe 80% of the chips that work at all are good enough to go in any but the top-of-the-line gamer specials. So where do they get the chips for a motherboard that sells for $69 at Fry's? They artificially bin them by target spec, blow those fuses and trim those resistors, and charge what the market will bear, niche by niche. The driver picks up on the chip ID and limits its in-system performance to the advertised spec, and everyone goes home happy. The graphics chip vendors are not utterly stupid. They have seen what has happened to the retail distribution of x86 CPUs, in which overclocker types take six mid-range chips home, see which one they can clock into the stratosphere for 24 hours without actually setting the motherboard on fire (they don't mind a little toxic
Re: GPL vs non-GPL device drivers
> of other places too. Especially when the graphics chip maker explains > that keeping their driver source code closed isn't really an attempt > to hide their knowledge under a bushel basket. It's a defensive > measure against having their retail margins destroyed by nitwits who > take out all the busy-wait loops and recompile with -O9 to get another > tenth of a frame per second, and then pretend ignorance when > attempting to return their slagged GPU at Fry's. Wrong as usual... The Nvidia driver and ATI drivers aren't full of magical delay loops and if there was a way to fry those cards easily in hardware the virus folks would already be doing it. The reverse engineering teams know what is in the existing code thank you. Creating new open source drivers from it is however hard because of all the corner cases. You will instead find that both vendors stopping providing Linux related source code at about the point they got Xbox related contracts. A matter which has been pointed out to various competition and legal authorities and for now where it seems to lie. Fortunately at the moment there is a simple cure - buy Intel hardware. That also has the advantage that you are more likely to get help because some of us only look at AMD processor related problems as part of official work duties nowdays, and plan to do so until AMD (as owner of ATI) behave. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Ok, but this is not realistic. I agree that if Evil Linker only adds
two hooks "void pop_server_starting(), void pop_server_stopping()", he
can get away with that.
But... how does situation change when Evil Linker does #include
from his
binary-only part?
There is no such thing as a "GPL header file". There is an original
work of authorship, that is, your POP server. There is a modified
work of authorship (not exactly a "derivative work", but let's call it
an Annotated Edition in order to bring it into the "derivative works"
category), that is, your POP server as altered by the Evil Linker in a
coherent and readable way. There is an independent work of
authorship, the Evil Linker's program. And there is a claim that the
independent work of authorship infringes on the original author's
copyright in the POP server.
If the sole factual basis for that claim is that the Evil Linker's
program contains #include "what_you_said.h", then it's not going to
fly in court (IANAL, TINLA). The #include directive itself is not
protectable expression, and anything that winds up in the Evil
Linker's binary is either a "method of operation" or "fair use" under
a "minimum practical amount of copying needed to accomplish a
sanctioned purpose" standard. Interoperation, even competitive
interoperation and circumvention of partner licensing programs, is a
sanctioned purpose under US law. You have to go pretty far out of
your way to find a case like Atari v. Nintendo in which the court
ruled that the competitor had been too lazy or venal in its reverse
engineering methodology not to be entitled to copy the bits needed to
interoperate.
I believe situation in this case changes a lot... And that's what
embedded people are doing; I do not think they are creating their own
headers or their own inline functions where headers contain them.
Remember, I am not defending people who hack the kernel and then don't
release the source code to their hacked kernel. (I'm not really
defending people who hack the kernel and write a closed-source
application locked to those hacks, either, although I am saying that
calling such tactics "illegal" or "GPL violation" is irrelevant and
wrong-headed.) And when what they in fact did was to riffle shuffle
together two drivers from Linus's tarball and change the names of the
symbolic constants to match their hardware interface (itself doubtless
a half-assed clone of someone else's), there's no excuse for GPLing
the result.
But a 20KLoC 3-D graphics driver that happens to #include
is not thereby a "derivative work" of the kernel,
no matter how many entrypoints are labeled EXPORT_SYMBOL_GPL or
provided as inline functions. And under the Lexmark standard,
MODULE_LICENSE("GPL") with a disclaimer in the doco is by far the
sanest way to deal with the EXPORT_SYMBOL_GPL mind games, and likely
(IANAL, TINLA) to be endorsed by any court in the US and probably lots
of other places too. Especially when the graphics chip maker explains
that keeping their driver source code closed isn't really an attempt
to hide their knowledge under a bushel basket. It's a defensive
measure against having their retail margins destroyed by nitwits who
take out all the busy-wait loops and recompile with -O9 to get another
tenth of a frame per second, and then pretend ignorance when
attempting to return their slagged GPU at Fry's.
Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: GPL vs non-GPL device drivers
> But... how does situation change when Evil Linker does #include > from his > binary-only part? Right, but *why* is he doing that? The answer: It is the most practical way to write his driver. > I believe situation in this case changes a lot... And that's what > embedded people are doing; I do not think they are creating their own > headers or their own inline functions where headers contain them. They don't have to. You *cannot* use copyright to make ideas harder to express. That's what patents are for. All the people who make this linking argument seem to be completely missing the entire *point* of copyright. A copyright protects the *one* way you chose to express a particular idea. It cannot protect function. It cannot make other ideas harder to express. This is not some loophole or something. This is the most fundamental thing about copyrights that there is. This is the reason they're so easy to get. This is the reason they last so long. They *cannot* impede interoperation. They cannot make other ideas harder to express. They can't even make the very same idea you expressed harder to express. Copyrights are not patents. It is clear, at least in the United States, that something like "a kernel driver to make work with " is an idea. You cannot own all the most practical ways to express that idea. When practical engineering concerns make one way (or one group of ways) the most reasonable, you simply *cannot* own them all with copyright. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Hi! > Actually, it's quite clear under US law what a derivative work is and > what rights you need to distribute it, and equally clear that > compiling code does not make a "translation" in a copyright sense. > Read Micro Star v. Formgen -- it's good law and it's funny and > readable. > > I've drafted summaries from a couple of different angles since VJ > requested a "translation into English", and I think this is the most > coherent (and least foaming-at-the-mouth) I've crafted yet. It was > written as an answer to a private query to this effect: "I write a > POP server and release it under the GPL. The Evil Linker adds some > hooks to my code, calls those hooks (along some of the existing ones) > from his newly developed program, and only provides recipients of the > binaries with source code for the modified POP server. His code > depends on, and only works with, this modified version of my POP > server. Doesn't he have to GPL his whole product, because he's > combined his work with mine?" > > This is a fundamental misconception. A <> is not a "work Ok, but this is not realistic. I agree that if Evil Linker only adds two hooks "void pop_server_starting(), void pop_server_stopping()", he can get away with that. But... how does situation change when Evil Linker does #include from his binary-only part? I believe situation in this case changes a lot... And that's what embedded people are doing; I do not think they are creating their own headers or their own inline functions where headers contain them. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Hi! Actually, it's quite clear under US law what a derivative work is and what rights you need to distribute it, and equally clear that compiling code does not make a translation in a copyright sense. Read Micro Star v. Formgen -- it's good law and it's funny and readable. I've drafted summaries from a couple of different angles since VJ requested a translation into English, and I think this is the most coherent (and least foaming-at-the-mouth) I've crafted yet. It was written as an answer to a private query to this effect: I write a POP server and release it under the GPL. The Evil Linker adds some hooks to my code, calls those hooks (along some of the existing ones) from his newly developed program, and only provides recipients of the binaries with source code for the modified POP server. His code depends on, and only works with, this modified version of my POP server. Doesn't he have to GPL his whole product, because he's combined his work with mine? This is a fundamental misconception. A product is not a work Ok, but this is not realistic. I agree that if Evil Linker only adds two hooks void pop_server_starting(), void pop_server_stopping(), he can get away with that. But... how does situation change when Evil Linker does #include pop3/gpl_header_file_with_some_inline_functions.h from his binary-only part? I believe situation in this case changes a lot... And that's what embedded people are doing; I do not think they are creating their own headers or their own inline functions where headers contain them. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: GPL vs non-GPL device drivers
But... how does situation change when Evil Linker does #include pop3/gpl_header_file_with_some_inline_functions.h from his binary-only part? Right, but *why* is he doing that? The answer: It is the most practical way to write his driver. I believe situation in this case changes a lot... And that's what embedded people are doing; I do not think they are creating their own headers or their own inline functions where headers contain them. They don't have to. You *cannot* use copyright to make ideas harder to express. That's what patents are for. All the people who make this linking argument seem to be completely missing the entire *point* of copyright. A copyright protects the *one* way you chose to express a particular idea. It cannot protect function. It cannot make other ideas harder to express. This is not some loophole or something. This is the most fundamental thing about copyrights that there is. This is the reason they're so easy to get. This is the reason they last so long. They *cannot* impede interoperation. They cannot make other ideas harder to express. They can't even make the very same idea you expressed harder to express. Copyrights are not patents. It is clear, at least in the United States, that something like a kernel driver to make some particular version of Linux work with some particular piece of hardware is an idea. You cannot own all the most practical ways to express that idea. When practical engineering concerns make one way (or one group of ways) the most reasonable, you simply *cannot* own them all with copyright. DS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/25/07, Pavel Machek [EMAIL PROTECTED] wrote: Ok, but this is not realistic. I agree that if Evil Linker only adds two hooks void pop_server_starting(), void pop_server_stopping(), he can get away with that. But... how does situation change when Evil Linker does #include pop3/gpl_header_file_with_some_inline_functions.h from his binary-only part? There is no such thing as a GPL header file. There is an original work of authorship, that is, your POP server. There is a modified work of authorship (not exactly a derivative work, but let's call it an Annotated Edition in order to bring it into the derivative works category), that is, your POP server as altered by the Evil Linker in a coherent and readable way. There is an independent work of authorship, the Evil Linker's program. And there is a claim that the independent work of authorship infringes on the original author's copyright in the POP server. If the sole factual basis for that claim is that the Evil Linker's program contains #include what_you_said.h, then it's not going to fly in court (IANAL, TINLA). The #include directive itself is not protectable expression, and anything that winds up in the Evil Linker's binary is either a method of operation or fair use under a minimum practical amount of copying needed to accomplish a sanctioned purpose standard. Interoperation, even competitive interoperation and circumvention of partner licensing programs, is a sanctioned purpose under US law. You have to go pretty far out of your way to find a case like Atari v. Nintendo in which the court ruled that the competitor had been too lazy or venal in its reverse engineering methodology not to be entitled to copy the bits needed to interoperate. I believe situation in this case changes a lot... And that's what embedded people are doing; I do not think they are creating their own headers or their own inline functions where headers contain them. Remember, I am not defending people who hack the kernel and then don't release the source code to their hacked kernel. (I'm not really defending people who hack the kernel and write a closed-source application locked to those hacks, either, although I am saying that calling such tactics illegal or GPL violation is irrelevant and wrong-headed.) And when what they in fact did was to riffle shuffle together two drivers from Linus's tarball and change the names of the symbolic constants to match their hardware interface (itself doubtless a half-assed clone of someone else's), there's no excuse for GPLing the result. But a 20KLoC 3-D graphics driver that happens to #include linux/whatever.h is not thereby a derivative work of the kernel, no matter how many entrypoints are labeled EXPORT_SYMBOL_GPL or provided as inline functions. And under the Lexmark standard, MODULE_LICENSE(GPL) with a disclaimer in the doco is by far the sanest way to deal with the EXPORT_SYMBOL_GPL mind games, and likely (IANAL, TINLA) to be endorsed by any court in the US and probably lots of other places too. Especially when the graphics chip maker explains that keeping their driver source code closed isn't really an attempt to hide their knowledge under a bushel basket. It's a defensive measure against having their retail margins destroyed by nitwits who take out all the busy-wait loops and recompile with -O9 to get another tenth of a frame per second, and then pretend ignorance when attempting to return their slagged GPU at Fry's. Cheers, - Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
of other places too. Especially when the graphics chip maker explains that keeping their driver source code closed isn't really an attempt to hide their knowledge under a bushel basket. It's a defensive measure against having their retail margins destroyed by nitwits who take out all the busy-wait loops and recompile with -O9 to get another tenth of a frame per second, and then pretend ignorance when attempting to return their slagged GPU at Fry's. Wrong as usual... The Nvidia driver and ATI drivers aren't full of magical delay loops and if there was a way to fry those cards easily in hardware the virus folks would already be doing it. The reverse engineering teams know what is in the existing code thank you. Creating new open source drivers from it is however hard because of all the corner cases. You will instead find that both vendors stopping providing Linux related source code at about the point they got Xbox related contracts. A matter which has been pointed out to various competition and legal authorities and for now where it seems to lie. Fortunately at the moment there is a simple cure - buy Intel hardware. That also has the advantage that you are more likely to get help because some of us only look at AMD processor related problems as part of official work duties nowdays, and plan to do so until AMD (as owner of ATI) behave. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/25/07, Alan [EMAIL PROTECTED] wrote: of other places too. Especially when the graphics chip maker explains that keeping their driver source code closed isn't really an attempt to hide their knowledge under a bushel basket. It's a defensive measure against having their retail margins destroyed by nitwits who take out all the busy-wait loops and recompile with -O9 to get another tenth of a frame per second, and then pretend ignorance when attempting to return their slagged GPU at Fry's. Wrong as usual... If this is an error, it's the first one _you've_ caught me in. Or did I miss something conformant to external reality in your earlier critiques? The Nvidia driver and ATI drivers aren't full of magical delay loops and if there was a way to fry those cards easily in hardware the virus folks would already be doing it. The reverse engineering teams know what is in the existing code thank you. Creating new open source drivers from it is however hard because of all the corner cases. Several years ago I worked on a MIPS-based set-top prototype mated to a graphics+HDTV board from a major PC 3-D vendor. We had full documentation and a fair amount of sample code under NDA. We were on the vendor's board spin 52 -- 52! and they'd sometimes spun the chip a couple times internally between released boards -- before it could be persuaded to do the documented thing with regard to video textures. In the meantime, we frotzed a lot of boards and chips before we decided to stick a triple-size fan to the damn thing with thermal grease and to avoid taking any chances with new VRAM timings except in the oversized chassis with the jet-engine fans. Maybe things have gotten better since then, but I doubt it. Busy-wait loops were a rhetorical flourish, I grant you. But software interlocks on data movement that protect you against some corner case you're unlikely to think of on your own are the norm, as is software-assisted clock scaling guided by temperature sensors in half a dozen places on chip and package. You can drive enough watts through a laptop GPU to fry an egg on it -- which is not kind to the BGA bonds. Yes, I have killed a laptop this way -- one that's notorious for popping its GPU, but it's no accident that the last thing I did to it was run a game demo that let me push my luck on the texture quality. It's also quite common, or used to be, for the enforcement of limits on monitor sync timings to be done in software, and it's quite possible to kill an underdesigned monitor or grossly exceed regulatory emissions limits by overdriving its resolution and frame rate. (I've never actually blown one up myself, but I've pushed my luck overdriving a laptop dock's DVI and gotten some lovely on-screen sparklies and enough ultrasonics to set the neighbor's dog to whining.) Viruses that kill your monitor may be urban legend, but it's a can of worms that a smart graphics vendor doesn't want to be liable for opening. The FCC also frowns on making it too easy for hobbyists to turn a Class B device into a two-block-radius FM jammer. You will instead find that both vendors stopping providing Linux related source code at about the point they got Xbox related contracts. A matter which has been pointed out to various competition and legal authorities and for now where it seems to lie. I know it's fun to blame everything on Redmond, but how about a simpler explanation? The technology and market for 3-D graphics is now sufficiently mature to allow revenue maximization through market segmentation -- in other words, charging some people more than others for the same thing because they're willing and able to pay extra. The volumes are also high enough to test chips as they come out of fab and bin them by maximum usable clock speed, just like Intel has done with its CPUs for the last decade. Blow a couple of dozen fuses to set a chip ID, laser trim a couple of resistors to set a default clock multiplier, and sell one for ten times what you get for the other. It's the only way to survive in a mature competitive environment. Now, suppose the silicon process for GPUs has stabilized to where chip yields have greatly improved, and maybe 80% of the chips that work at all are good enough to go in any but the top-of-the-line gamer specials. So where do they get the chips for a motherboard that sells for $69 at Fry's? They artificially bin them by target spec, blow those fuses and trim those resistors, and charge what the market will bear, niche by niche. The driver picks up on the chip ID and limits its in-system performance to the advertised spec, and everyone goes home happy. The graphics chip vendors are not utterly stupid. They have seen what has happened to the retail distribution of x86 CPUs, in which overclocker types take six mid-range chips home, see which one they can clock into the stratosphere for 24 hours without actually setting the motherboard on fire (they don't mind a little toxic outgassing
Re: GPL vs non-GPL device drivers
Pavel Machek wrote: Hi! Actually, it's quite clear under US law what a derivative work is and what rights you need to distribute it, and equally clear that compiling code does not make a translation in a copyright sense. Read Micro Star v. Formgen -- it's good law and it's funny and readable. I've drafted summaries from a couple of different angles since VJ requested a translation into English, and I think this is the most coherent (and least foaming-at-the-mouth) I've crafted yet. It was written as an answer to a private query to this effect: I write a POP server and release it under the GPL. The Evil Linker adds some hooks to my code, calls those hooks (along some of the existing ones) from his newly developed program, and only provides recipients of the binaries with source code for the modified POP server. His code depends on, and only works with, this modified version of my POP server. Doesn't he have to GPL his whole product, because he's combined his work with mine? This is a fundamental misconception. A product is not a work Ok, but this is not realistic. I agree that if Evil Linker only adds two hooks void pop_server_starting(), void pop_server_stopping(), he can get away with that. But... how does situation change when Evil Linker does #include pop3/gpl_header_file_with_some_inline_functions.h from his binary-only part? I believe situation in this case changes a lot... And that's what embedded people are doing; I do not think they are creating their own headers or their own inline functions where headers contain them. Pavel The amount copied has to be significant. A few lines against the millions in the kernel would not be enough to be copyright infringement. -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Busy-wait loops were a rhetorical flourish, I grant you. Thats a complicated fancy way of saying you were talking rubbish ? Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Sun 2007-02-25 03:33:38, David Schwartz wrote: But... how does situation change when Evil Linker does #include pop3/gpl_header_file_with_some_inline_functions.h from his binary-only part? Right, but *why* is he doing that? The answer: It is the most practical way to write his driver. Most practical way to get something Windows compatible is to pirate Windows; I do not think that gives me permission to do so. Similary, there are many ways to write inline functions present in headers, and no, embedded developer being lazy does not mean they can copy those functions into their proprietary module. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Sunday 25 February 2007 06:54, Michael K. Edwards wrote: On 2/25/07, Pavel Machek [EMAIL PROTECTED] wrote: snip But a 20KLoC 3-D graphics driver that happens to #include linux/whatever.h is not thereby a derivative work of the kernel, no matter how many entrypoints are labeled EXPORT_SYMBOL_GPL or provided as inline functions. And under the Lexmark standard, MODULE_LICENSE(GPL) with a disclaimer in the doco is by far the sanest way to deal with the EXPORT_SYMBOL_GPL mind games, and likely (IANAL, TINLA) to be endorsed by any court in the US and probably lots of other places too. Especially when the graphics chip maker explains that keeping their driver source code closed isn't really an attempt to hide their knowledge under a bushel basket. It's a defensive measure against having their retail margins destroyed by nitwits who take out all the busy-wait loops and recompile with -O9 to get another tenth of a frame per second, and then pretend ignorance when attempting to return their slagged GPU at Fry's. At that point, Mike, you are treading on *very* thin ice. With Intel having released the complete source to their chipsets and with the number of totally free 3D drivers that don't slag GPU's... However - if the hardware is really that fickle then why is it on the market? Yes, it can run hot enough to slag itself - all modern CPU's run the same risk. Yet people, mostly the Power Gamers, will push a CPU beyond their rated spec's and have it riding the edge of thermal breakdown. Because of the nature of the 3D accelerator market most manufacturers (of the chips themselves) have already pushed their chips to that thermal edge, and some of the makers of the boards will even provide the end user means to push the chips even further. However, even *with* some hardware manufacturers providing a way for the end-user to do it, pushing the componets to the edge of thermal breakdown (or beyond and keeping them in check through an active cooling system) is not normal and expected use. As well, if the that is the argument that NVidia and ATI use (that they are worried about people recompiling the code with busy-loops stripped out) then they don't know the Open Source community well. In general the people that are most likely to recompile the driver with the busy-loops removed don't run Open Source systems - they run Windows. Those people are called competetive gamers and 99% of the games they play are only available for Windows. What I'm trying to say is: Just like the It gives away too much information on our IP claim, the People will recompile it with code needed to keep it from destroying itself claim is bunk. Even moreso if their code is documented well enough that the purpose of the busy-wait loop is clear. DRH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/26/07, Michael K. Edwards [EMAIL PROTECTED] wrote: I know it's fun to blame everything on Redmond, but how about a simpler explanation? Says the master of conspiracy. Trent - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: GPL vs non-GPL device drivers
Right, but *why* is he doing that? The answer: It is the most practical way to write his driver. Most practical way to get something Windows compatible is to pirate Windows; I do not think that gives me permission to do so. This is comparing apples to oranges because Windows has an EULA. EULAs, shrink-wraps, or the like change everything. However, your statement is self-contradictory. By definition, to pirate something is not to take what is practically needed to make it interoperate with something else. My point is that taking what you practically need to make something interoperate with something else is *not* pirating. It is *not* taking protected content, it is taking function. How hard is this to understand -- you *cannot* use copyright to make any ideas harder to express. A kernel driver to make a particular piece of hardware work with a particular version of Linux *IS* an idea. You cannot own the most practical ways to express an idea -- you can only own the one way you chose to express that particular idea. Similary, there are many ways to write inline functions present in headers, and no, embedded developer being lazy does not mean they can copy those functions into their proprietary module. Yes, it does. Have you read Lexmark v. Static Controls? You can take what you need to interoperate. DS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Sunday 25 February 2007 19:47, David Schwartz wrote: snip Similary, there are many ways to write inline functions present in headers, and no, embedded developer being lazy does not mean they can copy those functions into their proprietary module. Yes, it does. Have you read Lexmark v. Static Controls? You can take what you need to interoperate. This is apples and oranges, to use your idiom. In that case Lexmark had the code in the toner cartridges had to have a specific SHA1 hash in order for the printer to recognize them. Because the only way, then, to produce a functional toner cartridge for the printer was to *copy* that code *exactly*. In the case of a system where this is not the case, then you are free to write your own interface functions. If Lexmark had *not* been using a SHA1 hash to validate that the cartridge was produced by them (and that is the real reason - Lexmark wanted to lock users of their printers into buying new toner cartridges from them) the case would have gone against Static Controls. The Lexmark v Static Controls decision applies only to interfaces where there is only, literally, one way to do it. What this means is that, yes, any use of the code in a GPL'd product that could be written in another manner is not covered by the interoperability standard that Lexmark v Static Controls describes. (No argument here, people: Lexmark v. Static Controls basically says Since the only way for this replacement toner cartridge to work was to have the 'Toner Loading Program' exactly copied from one of the cartridges produced by Lexmark doing such is fair use. All application of this precedent to other things must show the exact same thing - namely that the *one* and *only* way for something you have designed/written to fulfill its purpose is to rely on a copy of a copyrighted work. This ruling *only* applies to making computers, peripherals or parts of those peripherals and the copyrighted item that makes it interoperable. Lexmark v. Static Controls does not give people carte blanche to use interfaces to programs that could be re-implemented by them without causing the output to stop functioning. In the given example the work including the GPL'd header file and using its functions is in violation of the GPL if not released under the GPL but is distributed. Why? Because unless there was some form of lock-in making those functions a requirement for interoperability the Evil Hacker could have written and used his own versions and his plugin/program would still have been interoperable. DRH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, Feb 22, 2007 at 11:45:22AM -0500, Theodore Tso wrote: >... > The only way GPL'ed code can be become copyrighted by the FSF is if > you explicitly sign a copyright statement >... And even this is only possible if permitted by copyright law. E.g. German copyright law explicitely states that copyright is not transferable except through inheritage. [1] And German copyright law says that if you are granting exclusive usage rights, you must get an appropriate payment. [2] Often much might depend on which copyright law applies in a specific case... > - Ted cu Adrian [1] http://bundesrecht.juris.de/urhg/__29.html [2] http://bundesrecht.juris.de/urhg/__32.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, Feb 22, 2007 at 11:45:22AM -0500, Theodore Tso wrote: ... The only way GPL'ed code can be become copyrighted by the FSF is if you explicitly sign a copyright statement ... And even this is only possible if permitted by copyright law. E.g. German copyright law explicitely states that copyright is not transferable except through inheritage. [1] And German copyright law says that if you are granting exclusive usage rights, you must get an appropriate payment. [2] Often much might depend on which copyright law applies in a specific case... - Ted cu Adrian [1] http://bundesrecht.juris.de/urhg/__29.html [2] http://bundesrecht.juris.de/urhg/__32.html -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/22/07, Alan <[EMAIL PROTECTED]> wrote: > Oh yeah? For IRIX in 1991? Or for that matter, for Linux/ARM EABI > today? Tell me, how many of what sort of users do you support Solaris (NTL - very large ISP/Telco), Dec server 5000 (for fun), Irix (and linux cross for Irix removal), MIPS embedded (including the port to Linux of Algorithmics toolchain) for Sonix then 3COM routers. My list of GNUs maintained is about the same: SunOS 4.x, Solaris 2.x, IRIX, ConvexOS, embedded MIPS and ARM and x86. I've used, but didn't maintain, GCC for embedded PowerPC and m68k, and until I found a distro I could more or less trust to be point fixable, I did my own desktop/server Linux toolchains for x86, PowerPC, and x86_64. The only one for which I resorted to coughing up the university's money to the FSF was IRIX, and that's because it had to reach functional parity with the Sun and Convex boxes pronto. It's not a hard problem. gcc 2.x wasn't too hot on MIPS but it worked although the Irix compiler generated vastly better code (and AFAIK still does). It worked until you tried a 64-bit target or stressed the floating point. I had one of the first R4400s that ever left SGI, in an Indigo with the IndigoVideo board when it was still in alpha. Part of the horse-trade between the university and the start-up I worked for was that they got to run batch jobs on the thing when I wasn't physically at the keyboard. I had built several experimental toolchains for the thing but concluded rapidly that I didn't want to tech-support that shit. Best $5K of someone else's money I ever spent. There are folks who maintain cross devel chains for just about every Linux platform specifically for testing and while it isn't a small job they do seem to be coping quite happily. Er, I'm one of them. :-) When the ARM-based device I'm currently working on first ships as an out-of-form-factor prototype to OEM customers, it will be accompanied by a complete toolchain, kernel, and userland, built from scratch using crosstool and ptxdist and extensive patches I wrote, all of them to be contributed upstream because I convinced my client that it's the right thing to do. This includes the latest upstream editions of each userland component, a gdbserver that has been tested on multi-threaded soft-float NPTL binaries, the first (public) ltrace to work correctly on Linux/ARM in at least three years, the first (public) strace to understand ALSA ioctls, and infrastructure for unit testing and system latency analysis. It will be delivered as a set of git repositories with the complete development history and tracking branches for outside projects, and the only bits that aren't open source will be those encumbered by inescapable trade secret agreements with chip vendors. With the exception of those closed binaries, everything from soup to nuts is exactly reproducible from source on any Linux distro with a moderately current native toolchain and autotools. Before the first unit ships retail, these git repositories will be carefully scrubbed of encumbered material and opened to the public. Pull one git repository and run one script, and a few hours later you have your own JFFS2 image that you can burn to flash using facilities we will leave in U-Boot for end-users' benefit. Absolutely everything in the system can be point-fixed and recompiled by the end user, with results as predictable and reproducible as I know how to make them for myself. Updates from third-party upstreams can be merged using the tools that I believe to be best-in-class for the purpose and use myself, daily. No binary ever ships without passing through an autobuild and unit test framework that I provide as part of the end user source code release. That's my personal standard of release quality. Now tell me, how does that compare to your employer's? > CodeSourcery and MontaVista and Red Hat stay in business? Not with > the quality of their code or their customer service, I'll tell you > that -- although Mark Mitchell is probably the best release manager Lots of people would disagree with you about that (and independant surveys would back the disagreement), like they would disagree with you about most things. I have never particularly feared being in the minority, as long as I'm right. :-) But seriously, if you haven't heard the complaints about unreproducibility of Red Hat toolchains going back to the "GCC 2.96" debacle, you haven't been listening -- and MontaVista became notorious in the industry for deliberately mucking with kernel APIs as a vendor lock-in tactic. (They appear to have reformed substantially since the 2.4.x days.) I don't know Mark personally but he appears to be as open about CodeSourcery's processes and priorities as any toolchain vendor has ever been, and GCC 4.1.2 looks like it's going to be as stable as any upstream GCC release has ever been and perform decently as well, so I don't have much to complain about in that department.
Re: GPL vs non-GPL device drivers
On Fri, 23 Feb 2007 00:18:26 + Alan wrote: > > me off, and in the meantime, you know where to find your keyboard's > > "stick my fingers in my ears and shout la-la-la-I-can't-hear-you" key. > > :-) > > I was hoping you'd take the pseudo-legal noise elsewhere. Yes. I find it interesting, but it should be on [EMAIL PROTECTED] instead of here. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
> Oh yeah? For IRIX in 1991? Or for that matter, for Linux/ARM EABI > today? Tell me, how many of what sort of users do you support Solaris (NTL - very large ISP/Telco), Dec server 5000 (for fun), Irix (and linux cross for Irix removal), MIPS embedded (including the port to Linux of Algorithmics toolchain) for Sonix then 3COM routers. It's not a hard problem. gcc 2.x wasn't too hot on MIPS but it worked although the Irix compiler generated vastly better code (and AFAIK still does). There are folks who maintain cross devel chains for just about every Linux platform specifically for testing and while it isn't a small job they do seem to be coping quite happily. > CodeSourcery and MontaVista and Red Hat stay in business? Not with > the quality of their code or their customer service, I'll tell you > that -- although Mark Mitchell is probably the best release manager Lots of people would disagree with you about that (and independant surveys would back the disagreement), like they would disagree with you about most things. > that any GNU project has ever had. > me off, and in the meantime, you know where to find your keyboard's > "stick my fingers in my ears and shout la-la-la-I-can't-hear-you" key. > :-) I was hoping you'd take the pseudo-legal noise elsewhere. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/22/07, Alan <[EMAIL PROTECTED]> wrote: > compiler people caught on to the economic opportunity. Ever pay $5K > for a CD full of GNU binaries for a commercial UNIX? I did, after No because I just downloaded them. Much easier and since they are GPL I was allowed to do so, then rebuilt them all which took about 30 minutes of brain time and a day of CPU time. Oh yeah? For IRIX in 1991? Or for that matter, for Linux/ARM EABI today? Tell me, how many of what sort of users do you support singlehandedly in an environment where you are a minority architecture and everyone else takes the GNU tools for granted? God knows I've got better things to do with my time than roll the compiler-flag dice again and again trying to get a sketchy GCC port not to ICE or, worse, generate subtly broken code. If it's so bloody easy, how do CodeSourcery and MontaVista and Red Hat stay in business? Not with the quality of their code or their customer service, I'll tell you that -- although Mark Mitchell is probably the best release manager that any GNU project has ever had. Oh, please. Steve Ballmer doesn't waste his time trying to explain to overpaid GNU/Linux Morlocks (among which I number myself) how the legal and economic underpinnings of their industry work and why they shouldn't RAPE THEMSELVES playing stupid EXPORT_SYMBOL_GPL games and cryptographically signing kernel modules. But don't worry -- neither do I beyond a couple of weeks after something really dunderheaded sets me off, and in the meantime, you know where to find your keyboard's "stick my fingers in my ears and shout la-la-la-I-can't-hear-you" key. :-) Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/22/07, D. Hazelton <[EMAIL PROTECTED]> wrote: > If you take the microsoft windows source code and compile it yourself > believe me you will get sued if you ship the resulting binaries and you > will lose in court. "misappropriation of trade secrets" as well as copyright infringement But that's because it is *WINDOWS*, which, unless specifically granted to you, does not include a transfer of the right to distribute in *ANY* form. Every PC manufacturer that wants to distribute Windows on new machines they produce *MUST* sign an agreement with M$. As I have never seen any of those agreements I cannot state what the terms are and whether they are different for each company holding such a license. contract in personam, creating causes of action for breach of contract (for which remedies of specific performance are available) and strengthening the case for misappropriation of trade secrets And unless you've signed a licensing agreement over the source code to Windows, you're more than likely to have another lawsuit on your hands for possessing it. Not for possessing it. For acquiring it unlawfully, and for doing things with it that violate M$ copyright. > I would also note that the FSF makes no claim about dynamic v static > linking, merely about derivative works - which is the boundary the law is > interested in. Indeed the GPLv2 was written in the days where dynamic > linking was quite novel which is one reason the LGPL talks about The FSF makes lots of such claims, all the time, and Eben Moglen uses them to finesse his letter-of-opinion / affidavit racket, along with the fork/exec fetish. Fluendo. Vidomi. XCode. Tornado. NeXT. Progress Software. > "For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link a program with the library, you must provide > complete object files to the recipients so that they can relink them > with the library, after making changes to the library and recompiling > it. And you must show them these terms so they know their rights." Eh? Complete *object* files so that after making changes and recompiling they can relink it? Umm... I don't know about you, but that makes me laugh. What is the purpose of providing "Complete Object Files" to everyone if they are just going to recompile and relink the library? Complete object files for the rest of the non-GPL application. This applies principally to static linking. It also makes it much easier to reverse engineer the application, because unless the person jockeying the linker is really, really good, all of the interfaces between the application components are visible with nm and objdump, and you can use tools like ltrace to watch the calling sequences between modules. Selective symbol stripping and obfuscation on partially linked binaries takes skill. > Flex is more complex because the resulting binary contains both compiled > work of yours and a support library of FSF owned code (-lfl). No, flex is simpler because libfl is obviously a separate work of authorship with a stable external interface, and the application that links against it is not a derivative work of any of the creative expression inside libfl. Copyright *doesn't* extend to compiled code. It cannot, because compiled code is a machine generated translation. A machine generated translation isn't the product of a creative process. And you can also provide all the routines normally provided by the support library. This means that the support library is *NOT* a necessary part of the system. That's rubbish. Copyright in compiled code is very nearly identical to copyright in the source code from which it was generated; see references in Lexmark, especially the seminal Altai case. Copyright in silicon is _not_ identical to copyright in the RTL from which it was synthesized -- the term of protection for a "mask work" is limited to 10 years -- 2 if it's not registered properly. This prima facie bizarre situation reflects the difference in national origin and lobbying power between software and hardware makers, as well as the greater difficulty of extracting the theory of operation of a complex chip using an electron microscope. The chip design oligopoly is bound by a web of contractual covenants not to do this anyway, and they like being able to snap up key people from upstart maverick companies and rip off their designs without pesky legal interference. > The non > computing analogy here is the difference between using a paint program to > create a work, and using a paint program to create a work but also > including other artwork (eg clipart). Not really. Using stock images to illustrate a manuscript requires license to copy and distribute them but rarely, if ever, creates a derivative work. Yes, but in both cases the result is *CLEARLY* the
Re: GPL vs non-GPL device drivers
On Thursday 22 February 2007 09:10, Alan wrote: > > As a side note: The distinct wording of the GPL actually *invalidates* > > the GNU/FSF claim that dynamically linking a work with, say, the readline > > library, means the work is a derivative of said library. The GPL states > > (in > > Not that I can see no, but you could take this to a list with lawyers not > programmers on and improve life for both parties See Section/clause 0 of the GPL. > > clause 0) that the license only covers copying, modification and > > distribution. Unless they are confusing "Linking" with "copying" or > > "creating a derivative work" the claim is invalid - because, as it has > > been shown, a mechanical process such as compilation or linking *cannot* > > create a derivative work. > > If you take the microsoft windows source code and compile it yourself > believe me you will get sued if you ship the resulting binaries and you > will lose in court. But that's because it is *WINDOWS*, which, unless specifically granted to you, does not include a transfer of the right to distribute in *ANY* form. Every PC manufacturer that wants to distribute Windows on new machines they produce *MUST* sign an agreement with M$. As I have never seen any of those agreements I cannot state what the terms are and whether they are different for each company holding such a license. And unless you've signed a licensing agreement over the source code to Windows, you're more than likely to have another lawsuit on your hands for possessing it. > I would also note that the FSF makes no claim about dynamic v static > linking, merely about derivative works - which is the boundary the law is > interested in. Indeed the GPLv2 was written in the days where dynamic > linking was quite novel which is one reason the LGPL talks about Granted. > "For example, if you distribute copies of the library, whether gratis > or for a fee, you must give the recipients all the rights that we gave > you. You must make sure that they, too, receive or can get the source > code. If you link a program with the library, you must provide > complete object files to the recipients so that they can relink them > with the library, after making changes to the library and recompiling > it. And you must show them these terms so they know their rights." Eh? Complete *object* files so that after making changes and recompiling they can relink it? Umm... I don't know about you, but that makes me laugh. What is the purpose of providing "Complete Object Files" to everyone if they are just going to recompile and relink the library? Yes, I know this quite likely refers to any object files (or other binaries) that are part of the library but not part of the source. (and *are* required for the library to be completely functional) > and says nothing about dynamic/static linking. > > > Related to that... Though a parser generated by Bison and a tokenizer > > generated by Flex both contain large chunks of GPL'd code, their > > inclusion in the source file that is to be compiled is mechanical - the > > true unique work is in writing the file that is processed by the tool to > > produce the output. > > Flex is more complex because the resulting binary contains both compiled > work of yours and a support library of FSF owned code (-lfl). Copyright *doesn't* extend to compiled code. It cannot, because compiled code is a machine generated translation. A machine generated translation isn't the product of a creative process. And you can also provide all the routines normally provided by the support library. This means that the support library is *NOT* a necessary part of the system. > The non > computing analogy here is the difference between using a paint program to > create a work, and using a paint program to create a work but also > including other artwork (eg clipart). Yes, but in both cases the result is *CLEARLY* the result of a creative process, and said clipart, unless it is in the form of an entirely machine generated image, is a separate work (and one resulting from a creative process) that you are using under license. (Unless said clipart was released into the public domain) > The same is true of the GCC compiler > as it merges your work with supporting library helper code modules which > are themselves creative works. Again you are confusing a mechanical translation process with a creative process. But it doesn't matter, in this case. The binary form of a program *technically* falls under the copyright on the source code - a mechanical process that translates a copyrighted work into another form *cannot* remove the original copyright. But said modules have clearly defined and limited purposes. > Clearly you could replace those helper > modules with your own work and the result would be different. Yes. And you've noted that yes, they can be replaced. Which means that they are also not a necessary part of the system. Claiming that any
Re: GPL vs non-GPL device drivers
On Thursday 22 February 2007 11:45, Theodore Tso wrote: > But saying that just by licensing your code under the GPL means that > the FSF owns your code? That's just crazy talk. > > - Ted Actually, I've replied with private messages to several mails that arrived in reply to this explaining that the copyright clause I noted does, in fact, refer to the person releasing the code and the FSF. However, because it is located in the preamble and outside the terms of the license it has no legal bearing. As I've noted in those private mails, I pointed it out because I could see the FSF (in the person of Eben Moglen (or another attorney)) using it in a strong-arm tactic to gain copyright to the code. DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, Feb 21, 2007 at 11:17:16PM -0500, D. Hazelton wrote: > Since I tailor the license I apply to code I produce to meet the needs of the > person or entity I am writing it for, I've never run into this. In truth, the > LGPL is, IMHO, a piece of garbage. (as is the GPL - if you release code under > the GPL you no longer have a legal right to it. Note the following text that > appears in the GPL: > > " We protect your rights with two steps: (1) copyright the software, and > (2) offer you this license which gives you legal permission to copy, > distribute and/or modify the software." > --IE: Once you release the code under the GPL, it becomes the *copyrighted* > *property* of the FSF and you are just another person that the GPL is applied > to. That's simply not true. If you release the code under the GPL, you are still the copyright holder. You are simply using the terms of the GPL to allow what *others* can do with your code. So you are always free to make it available under another license, including a propietary one. For example, way back when I was the only author of all of the e2fsprogs code, I once sold a license allowing to allow the PartitionMagic program to use portions of the e2fsprogs codebase in their propietary Windows product; it help pay for the downpayment of my house, too... Now, if other people contribute code to your project, and you accept it without a copyright assignment, then their code is generally presumed to be implicitly licensed under the same license as the original program, and so that would presumably restrict your ability to relicense the project without getting their permission as well, since some of the code or documentation is theirs. The only way GPL'ed code can be become copyrighted by the FSF is if you explicitly sign a copyright statement (and before you do that, take a very close look at the FSF copyright assignment letter, and if you don't know what "indemnify" menas, and have any kind of significant assets, such as a house, or anticipate having significant assets in the future, run, don't walk, to a lawyer and talk to them first), or if you explicitly release the code into the public domain and then they grab it and make some changes which are copyrighted by the FSF. But saying that just by licensing your code under the GPL means that the FSF owns your code? That's just crazy talk. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
> compiler people caught on to the economic opportunity. Ever pay $5K > for a CD full of GNU binaries for a commercial UNIX? I did, after No because I just downloaded them. Much easier and since they are GPL I was allowed to do so, then rebuilt them all which took about 30 minutes of brain time and a day of CPU time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
> As a side note: The distinct wording of the GPL actually *invalidates* the > GNU/FSF claim that dynamically linking a work with, say, the readline > library, means the work is a derivative of said library. The GPL states (in Not that I can see no, but you could take this to a list with lawyers not programmers on and improve life for both parties > clause 0) that the license only covers copying, modification and > distribution. Unless they are confusing "Linking" with "copying" or "creating > a derivative work" the claim is invalid - because, as it has been shown, a > mechanical process such as compilation or linking *cannot* create a > derivative work. If you take the microsoft windows source code and compile it yourself believe me you will get sued if you ship the resulting binaries and you will lose in court. Copyright law deals with the right to copy hence the name. Generally speaking your right to use a work you have a copy of isn't constrained (and isn't constrainable) by pure copyright, only by contract. The author of a book for example has no power to stop you boiling the book if you don't like it, or using it as bog paper. I would also note that the FSF makes no claim about dynamic v static linking, merely about derivative works - which is the boundary the law is interested in. Indeed the GPLv2 was written in the days where dynamic linking was quite novel which is one reason the LGPL talks about "For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights." and says nothing about dynamic/static linking. > Related to that... Though a parser generated by Bison and a tokenizer > generated by Flex both contain large chunks of GPL'd code, their inclusion in > the source file that is to be compiled is mechanical - the true unique work > is in writing the file that is processed by the tool to produce the output. Flex is more complex because the resulting binary contains both compiled work of yours and a support library of FSF owned code (-lfl). The non computing analogy here is the difference between using a paint program to create a work, and using a paint program to create a work but also including other artwork (eg clipart). The same is true of the GCC compiler as it merges your work with supporting library helper code modules which are themselves creative works. Clearly you could replace those helper modules with your own work and the result would be different. A better example for your case might be indent where the program processes your work mechanically and produces an output that doesn't contain any other creative works, or most of intltools which merges translations mechanically. (the merge code is sometimes a little creative but thats in the sense of being a nuisance not in the legal sense of creative work) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
D. Hazelton wrote: (as is the GPL - if you release code under the GPL you no longer have a legal right to it. Note the following text that appears in the GPL: " We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software." --IE: Once you release the code under the GPL, it becomes the *copyrighted* *property* of the FSF and you are just another person that the GPL is applied to. "We" means "whoever is issuing" the license. I.e. you, if it's your work, and you didn't reassign it to somebody else. Jon Kåre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
D. Hazelton wrote: (as is the GPL - if you release code under the GPL you no longer have a legal right to it. Note the following text that appears in the GPL: We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. --IE: Once you release the code under the GPL, it becomes the *copyrighted* *property* of the FSF and you are just another person that the GPL is applied to. We means whoever is issuing the license. I.e. you, if it's your work, and you didn't reassign it to somebody else. Jon Kåre - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
As a side note: The distinct wording of the GPL actually *invalidates* the GNU/FSF claim that dynamically linking a work with, say, the readline library, means the work is a derivative of said library. The GPL states (in Not that I can see no, but you could take this to a list with lawyers not programmers on and improve life for both parties clause 0) that the license only covers copying, modification and distribution. Unless they are confusing Linking with copying or creating a derivative work the claim is invalid - because, as it has been shown, a mechanical process such as compilation or linking *cannot* create a derivative work. If you take the microsoft windows source code and compile it yourself believe me you will get sued if you ship the resulting binaries and you will lose in court. Copyright law deals with the right to copy hence the name. Generally speaking your right to use a work you have a copy of isn't constrained (and isn't constrainable) by pure copyright, only by contract. The author of a book for example has no power to stop you boiling the book if you don't like it, or using it as bog paper. I would also note that the FSF makes no claim about dynamic v static linking, merely about derivative works - which is the boundary the law is interested in. Indeed the GPLv2 was written in the days where dynamic linking was quite novel which is one reason the LGPL talks about For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights. and says nothing about dynamic/static linking. Related to that... Though a parser generated by Bison and a tokenizer generated by Flex both contain large chunks of GPL'd code, their inclusion in the source file that is to be compiled is mechanical - the true unique work is in writing the file that is processed by the tool to produce the output. Flex is more complex because the resulting binary contains both compiled work of yours and a support library of FSF owned code (-lfl). The non computing analogy here is the difference between using a paint program to create a work, and using a paint program to create a work but also including other artwork (eg clipart). The same is true of the GCC compiler as it merges your work with supporting library helper code modules which are themselves creative works. Clearly you could replace those helper modules with your own work and the result would be different. A better example for your case might be indent where the program processes your work mechanically and produces an output that doesn't contain any other creative works, or most of intltools which merges translations mechanically. (the merge code is sometimes a little creative but thats in the sense of being a nuisance not in the legal sense of creative work) Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
compiler people caught on to the economic opportunity. Ever pay $5K for a CD full of GNU binaries for a commercial UNIX? I did, after No because I just downloaded them. Much easier and since they are GPL I was allowed to do so, then rebuilt them all which took about 30 minutes of brain time and a day of CPU time. Balmer impersonation deleted - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, Feb 21, 2007 at 11:17:16PM -0500, D. Hazelton wrote: Since I tailor the license I apply to code I produce to meet the needs of the person or entity I am writing it for, I've never run into this. In truth, the LGPL is, IMHO, a piece of garbage. (as is the GPL - if you release code under the GPL you no longer have a legal right to it. Note the following text that appears in the GPL: We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. --IE: Once you release the code under the GPL, it becomes the *copyrighted* *property* of the FSF and you are just another person that the GPL is applied to. That's simply not true. If you release the code under the GPL, you are still the copyright holder. You are simply using the terms of the GPL to allow what *others* can do with your code. So you are always free to make it available under another license, including a propietary one. For example, way back when I was the only author of all of the e2fsprogs code, I once sold a license allowing to allow the PartitionMagic program to use portions of the e2fsprogs codebase in their propietary Windows product; it help pay for the downpayment of my house, too... Now, if other people contribute code to your project, and you accept it without a copyright assignment, then their code is generally presumed to be implicitly licensed under the same license as the original program, and so that would presumably restrict your ability to relicense the project without getting their permission as well, since some of the code or documentation is theirs. The only way GPL'ed code can be become copyrighted by the FSF is if you explicitly sign a copyright statement (and before you do that, take a very close look at the FSF copyright assignment letter, and if you don't know what indemnify menas, and have any kind of significant assets, such as a house, or anticipate having significant assets in the future, run, don't walk, to a lawyer and talk to them first), or if you explicitly release the code into the public domain and then they grab it and make some changes which are copyrighted by the FSF. But saying that just by licensing your code under the GPL means that the FSF owns your code? That's just crazy talk. - Ted - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thursday 22 February 2007 11:45, Theodore Tso wrote: snip But saying that just by licensing your code under the GPL means that the FSF owns your code? That's just crazy talk. - Ted Actually, I've replied with private messages to several mails that arrived in reply to this explaining that the copyright clause I noted does, in fact, refer to the person releasing the code and the FSF. However, because it is located in the preamble and outside the terms of the license it has no legal bearing. As I've noted in those private mails, I pointed it out because I could see the FSF (in the person of Eben Moglen (or another attorney)) using it in a strong-arm tactic to gain copyright to the code. DRH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thursday 22 February 2007 09:10, Alan wrote: As a side note: The distinct wording of the GPL actually *invalidates* the GNU/FSF claim that dynamically linking a work with, say, the readline library, means the work is a derivative of said library. The GPL states (in Not that I can see no, but you could take this to a list with lawyers not programmers on and improve life for both parties See Section/clause 0 of the GPL. clause 0) that the license only covers copying, modification and distribution. Unless they are confusing Linking with copying or creating a derivative work the claim is invalid - because, as it has been shown, a mechanical process such as compilation or linking *cannot* create a derivative work. If you take the microsoft windows source code and compile it yourself believe me you will get sued if you ship the resulting binaries and you will lose in court. But that's because it is *WINDOWS*, which, unless specifically granted to you, does not include a transfer of the right to distribute in *ANY* form. Every PC manufacturer that wants to distribute Windows on new machines they produce *MUST* sign an agreement with M$. As I have never seen any of those agreements I cannot state what the terms are and whether they are different for each company holding such a license. And unless you've signed a licensing agreement over the source code to Windows, you're more than likely to have another lawsuit on your hands for possessing it. snip I would also note that the FSF makes no claim about dynamic v static linking, merely about derivative works - which is the boundary the law is interested in. Indeed the GPLv2 was written in the days where dynamic linking was quite novel which is one reason the LGPL talks about Granted. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights. Eh? Complete *object* files so that after making changes and recompiling they can relink it? Umm... I don't know about you, but that makes me laugh. What is the purpose of providing Complete Object Files to everyone if they are just going to recompile and relink the library? Yes, I know this quite likely refers to any object files (or other binaries) that are part of the library but not part of the source. (and *are* required for the library to be completely functional) and says nothing about dynamic/static linking. Related to that... Though a parser generated by Bison and a tokenizer generated by Flex both contain large chunks of GPL'd code, their inclusion in the source file that is to be compiled is mechanical - the true unique work is in writing the file that is processed by the tool to produce the output. Flex is more complex because the resulting binary contains both compiled work of yours and a support library of FSF owned code (-lfl). Copyright *doesn't* extend to compiled code. It cannot, because compiled code is a machine generated translation. A machine generated translation isn't the product of a creative process. And you can also provide all the routines normally provided by the support library. This means that the support library is *NOT* a necessary part of the system. The non computing analogy here is the difference between using a paint program to create a work, and using a paint program to create a work but also including other artwork (eg clipart). Yes, but in both cases the result is *CLEARLY* the result of a creative process, and said clipart, unless it is in the form of an entirely machine generated image, is a separate work (and one resulting from a creative process) that you are using under license. (Unless said clipart was released into the public domain) The same is true of the GCC compiler as it merges your work with supporting library helper code modules which are themselves creative works. Again you are confusing a mechanical translation process with a creative process. But it doesn't matter, in this case. The binary form of a program *technically* falls under the copyright on the source code - a mechanical process that translates a copyrighted work into another form *cannot* remove the original copyright. But said modules have clearly defined and limited purposes. Clearly you could replace those helper modules with your own work and the result would be different. Yes. And you've noted that yes, they can be replaced. Which means that they are also not a necessary part of the system. Claiming that any library (that can be replaced), either dynamically or statically
Re: GPL vs non-GPL device drivers
On 2/22/07, D. Hazelton [EMAIL PROTECTED] wrote: If you take the microsoft windows source code and compile it yourself believe me you will get sued if you ship the resulting binaries and you will lose in court. misappropriation of trade secrets as well as copyright infringement But that's because it is *WINDOWS*, which, unless specifically granted to you, does not include a transfer of the right to distribute in *ANY* form. Every PC manufacturer that wants to distribute Windows on new machines they produce *MUST* sign an agreement with M$. As I have never seen any of those agreements I cannot state what the terms are and whether they are different for each company holding such a license. contract in personam, creating causes of action for breach of contract (for which remedies of specific performance are available) and strengthening the case for misappropriation of trade secrets And unless you've signed a licensing agreement over the source code to Windows, you're more than likely to have another lawsuit on your hands for possessing it. Not for possessing it. For acquiring it unlawfully, and for doing things with it that violate M$ copyright. snip I would also note that the FSF makes no claim about dynamic v static linking, merely about derivative works - which is the boundary the law is interested in. Indeed the GPLv2 was written in the days where dynamic linking was quite novel which is one reason the LGPL talks about The FSF makes lots of such claims, all the time, and Eben Moglen uses them to finesse his letter-of-opinion / affidavit racket, along with the fork/exec fetish. Fluendo. Vidomi. XCode. Tornado. NeXT. Progress Software. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights. Eh? Complete *object* files so that after making changes and recompiling they can relink it? Umm... I don't know about you, but that makes me laugh. What is the purpose of providing Complete Object Files to everyone if they are just going to recompile and relink the library? Complete object files for the rest of the non-GPL application. This applies principally to static linking. It also makes it much easier to reverse engineer the application, because unless the person jockeying the linker is really, really good, all of the interfaces between the application components are visible with nm and objdump, and you can use tools like ltrace to watch the calling sequences between modules. Selective symbol stripping and obfuscation on partially linked binaries takes skill. Flex is more complex because the resulting binary contains both compiled work of yours and a support library of FSF owned code (-lfl). No, flex is simpler because libfl is obviously a separate work of authorship with a stable external interface, and the application that links against it is not a derivative work of any of the creative expression inside libfl. Copyright *doesn't* extend to compiled code. It cannot, because compiled code is a machine generated translation. A machine generated translation isn't the product of a creative process. And you can also provide all the routines normally provided by the support library. This means that the support library is *NOT* a necessary part of the system. That's rubbish. Copyright in compiled code is very nearly identical to copyright in the source code from which it was generated; see references in Lexmark, especially the seminal Altai case. Copyright in silicon is _not_ identical to copyright in the RTL from which it was synthesized -- the term of protection for a mask work is limited to 10 years -- 2 if it's not registered properly. This prima facie bizarre situation reflects the difference in national origin and lobbying power between software and hardware makers, as well as the greater difficulty of extracting the theory of operation of a complex chip using an electron microscope. The chip design oligopoly is bound by a web of contractual covenants not to do this anyway, and they like being able to snap up key people from upstart maverick companies and rip off their designs without pesky legal interference. The non computing analogy here is the difference between using a paint program to create a work, and using a paint program to create a work but also including other artwork (eg clipart). Not really. Using stock images to illustrate a manuscript requires license to copy and distribute them but rarely, if ever, creates a derivative work. Yes, but in both cases the result is *CLEARLY* the result of a creative process,
Re: GPL vs non-GPL device drivers
On 2/22/07, Alan [EMAIL PROTECTED] wrote: compiler people caught on to the economic opportunity. Ever pay $5K for a CD full of GNU binaries for a commercial UNIX? I did, after No because I just downloaded them. Much easier and since they are GPL I was allowed to do so, then rebuilt them all which took about 30 minutes of brain time and a day of CPU time. Oh yeah? For IRIX in 1991? Or for that matter, for Linux/ARM EABI today? Tell me, how many of what sort of users do you support singlehandedly in an environment where you are a minority architecture and everyone else takes the GNU tools for granted? God knows I've got better things to do with my time than roll the compiler-flag dice again and again trying to get a sketchy GCC port not to ICE or, worse, generate subtly broken code. If it's so bloody easy, how do CodeSourcery and MontaVista and Red Hat stay in business? Not with the quality of their code or their customer service, I'll tell you that -- although Mark Mitchell is probably the best release manager that any GNU project has ever had. Balmer impersonation deleted Oh, please. Steve Ballmer doesn't waste his time trying to explain to overpaid GNU/Linux Morlocks (among which I number myself) how the legal and economic underpinnings of their industry work and why they shouldn't RAPE THEMSELVES playing stupid EXPORT_SYMBOL_GPL games and cryptographically signing kernel modules. But don't worry -- neither do I beyond a couple of weeks after something really dunderheaded sets me off, and in the meantime, you know where to find your keyboard's stick my fingers in my ears and shout la-la-la-I-can't-hear-you key. :-) Cheers, - Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Oh yeah? For IRIX in 1991? Or for that matter, for Linux/ARM EABI today? Tell me, how many of what sort of users do you support Solaris (NTL - very large ISP/Telco), Dec server 5000 (for fun), Irix (and linux cross for Irix removal), MIPS embedded (including the port to Linux of Algorithmics toolchain) for Sonix then 3COM routers. It's not a hard problem. gcc 2.x wasn't too hot on MIPS but it worked although the Irix compiler generated vastly better code (and AFAIK still does). There are folks who maintain cross devel chains for just about every Linux platform specifically for testing and while it isn't a small job they do seem to be coping quite happily. CodeSourcery and MontaVista and Red Hat stay in business? Not with the quality of their code or their customer service, I'll tell you that -- although Mark Mitchell is probably the best release manager Lots of people would disagree with you about that (and independant surveys would back the disagreement), like they would disagree with you about most things. that any GNU project has ever had. me off, and in the meantime, you know where to find your keyboard's stick my fingers in my ears and shout la-la-la-I-can't-hear-you key. :-) I was hoping you'd take the pseudo-legal noise elsewhere. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Fri, 23 Feb 2007 00:18:26 + Alan wrote: me off, and in the meantime, you know where to find your keyboard's stick my fingers in my ears and shout la-la-la-I-can't-hear-you key. :-) I was hoping you'd take the pseudo-legal noise elsewhere. Yes. I find it interesting, but it should be on [EMAIL PROTECTED] instead of here. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/22/07, Alan [EMAIL PROTECTED] wrote: Oh yeah? For IRIX in 1991? Or for that matter, for Linux/ARM EABI today? Tell me, how many of what sort of users do you support Solaris (NTL - very large ISP/Telco), Dec server 5000 (for fun), Irix (and linux cross for Irix removal), MIPS embedded (including the port to Linux of Algorithmics toolchain) for Sonix then 3COM routers. My list of GNUs maintained is about the same: SunOS 4.x, Solaris 2.x, IRIX, ConvexOS, embedded MIPS and ARM and x86. I've used, but didn't maintain, GCC for embedded PowerPC and m68k, and until I found a distro I could more or less trust to be point fixable, I did my own desktop/server Linux toolchains for x86, PowerPC, and x86_64. The only one for which I resorted to coughing up the university's money to the FSF was IRIX, and that's because it had to reach functional parity with the Sun and Convex boxes pronto. It's not a hard problem. gcc 2.x wasn't too hot on MIPS but it worked although the Irix compiler generated vastly better code (and AFAIK still does). It worked until you tried a 64-bit target or stressed the floating point. I had one of the first R4400s that ever left SGI, in an Indigo with the IndigoVideo board when it was still in alpha. Part of the horse-trade between the university and the start-up I worked for was that they got to run batch jobs on the thing when I wasn't physically at the keyboard. I had built several experimental toolchains for the thing but concluded rapidly that I didn't want to tech-support that shit. Best $5K of someone else's money I ever spent. There are folks who maintain cross devel chains for just about every Linux platform specifically for testing and while it isn't a small job they do seem to be coping quite happily. Er, I'm one of them. :-) When the ARM-based device I'm currently working on first ships as an out-of-form-factor prototype to OEM customers, it will be accompanied by a complete toolchain, kernel, and userland, built from scratch using crosstool and ptxdist and extensive patches I wrote, all of them to be contributed upstream because I convinced my client that it's the right thing to do. This includes the latest upstream editions of each userland component, a gdbserver that has been tested on multi-threaded soft-float NPTL binaries, the first (public) ltrace to work correctly on Linux/ARM in at least three years, the first (public) strace to understand ALSA ioctls, and infrastructure for unit testing and system latency analysis. It will be delivered as a set of git repositories with the complete development history and tracking branches for outside projects, and the only bits that aren't open source will be those encumbered by inescapable trade secret agreements with chip vendors. With the exception of those closed binaries, everything from soup to nuts is exactly reproducible from source on any Linux distro with a moderately current native toolchain and autotools. Before the first unit ships retail, these git repositories will be carefully scrubbed of encumbered material and opened to the public. Pull one git repository and run one script, and a few hours later you have your own JFFS2 image that you can burn to flash using facilities we will leave in U-Boot for end-users' benefit. Absolutely everything in the system can be point-fixed and recompiled by the end user, with results as predictable and reproducible as I know how to make them for myself. Updates from third-party upstreams can be merged using the tools that I believe to be best-in-class for the purpose and use myself, daily. No binary ever ships without passing through an autobuild and unit test framework that I provide as part of the end user source code release. That's my personal standard of release quality. Now tell me, how does that compare to your employer's? CodeSourcery and MontaVista and Red Hat stay in business? Not with the quality of their code or their customer service, I'll tell you that -- although Mark Mitchell is probably the best release manager Lots of people would disagree with you about that (and independant surveys would back the disagreement), like they would disagree with you about most things. I have never particularly feared being in the minority, as long as I'm right. :-) But seriously, if you haven't heard the complaints about unreproducibility of Red Hat toolchains going back to the GCC 2.96 debacle, you haven't been listening -- and MontaVista became notorious in the industry for deliberately mucking with kernel APIs as a vendor lock-in tactic. (They appear to have reformed substantially since the 2.4.x days.) I don't know Mark personally but he appears to be as open about CodeSourcery's processes and priorities as any toolchain vendor has ever been, and GCC 4.1.2 looks like it's going to be as stable as any upstream GCC release has ever been and perform decently as well, so I don't have much to complain about in that department. YMMV. I was
Re: GPL vs non-GPL device drivers
On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote: Actually, on re-reading the GPL, I see exactly why they made that pair of exceptions. Where it's quite evident that a small to mid scale parsers that could have been written *without* the use of Bison is clearly a non-derivative work - Bison was not required, but was used as a mean of expediency. When you reach a large scale parser, such as one that meets all requirements to act as the parser for an ANSI C99 compiler, Bison stops being expedient - it'd likely take just as much time to hand craft the parser as it would to debug the Bison input. However, it makes maintaining the parser easier. I repeat, that is not what "derivative work" means. Do not try to reason about the phrase "derivative work" without reference to its definition in statute and its legal history in appellate decisions. You will get it wrong every time. You have not "recast, transformed, or adapted" the _creative_expression_ in Bison or Flex in the course of using it; so whether or not you have infringed the FSF's copyright, you have NOT created a "derivative work". If Bison and Flex were offered under the "bare" GPL, and you used them to build a parser, and the FSF sued you for offering that parser to other people on terms other than the GPL's, you don't defend by claiming license under the GPL with regard to your parser. You attack the claim of "copying" itself by saying that the _creative_expression_ copied from Bison/Flex into your parser is "de minimis" under the Altai Abstraction-Filtration-Comparison test. You also point out that, even if it weren't "de minimis", it's "fair use"; that's a complex four-factor test, but the main thing is that you're not interfering with the FSF's ability to monetize its copyright in Bison/Flex. If you have any sense, you will strenuously argue that the various "special exceptions" for things like Bison/Flex and GNU Classpath are _not_ part of the offer of contract contained in the GPL, any more than the Preamble is. They're declarations of intent on the part of the copyright holder, and can be used to _estop_ the FSF from making the copyright infringement claim against you in court in the first place. They promised you they wouldn't, not as part of the contract terms, but as part of the inducement to form a contract with them by acceptance through conduct. But the fact is that it's the small to medium scale parsers that have a lower ratio of original to GPL'd code that are at risk of being declared derivative works. All of this because the GPL contains the following text in section 0: "The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does." I'm sorry, but that "ratio test" has nothing to do with whether something is a derivative work or not. It comes up mostly in evaluating a "fair use" defense, and it's the ratio of the amount of creative expression _copied_ to the amount of creative expression in the _original_work_ that matters. Just because you're writing a 49-volume encyclopedia does not give you the right to copy two thirds of my one-page essay. Those weasel-words about "depending on what the Program does" are nonsense. It depends on what _creative_expression_ from the Program winds up in the output. That clause, to me, seems specifically tailored to cover programs such as Bison and Flex. (and is the reason that I try to use Byacc and when I need to, write tokenizers by hand) This frankly stinks of attempts to cover all possible code. (I actually started studying Copyright law in my free time because I was wondering how legal the GPL was and was also puzzled by some major online entities actually complaining about it) I've written tokenizers in at least six different languages to date, including Fortran. It's a pain in the butt. The last thing I want to be worrying about when I write a tokenizer is whether somebody else's peanut butter is winding up in my chocolate. So I will only use a tool which, like bison and flex, is accompanied by a promise not to claim that its output infringes the tool author's copyright or is otherwise encumbered in any way. M$ VC++ is actually more trustworthy in that respect than G++. If you don't believe (as I do) that it is arrant nonsense to claim that the use of interface headers or linking of any kind creates a derivative work, then you must believe that any programs compiled with G++ can only be distributed under the terms of the GPL. libstdc++ is GPL, not LGPL. Since I tailor the license I apply to code I produce to meet the needs of the person or entity I am writing it for, I've never run into this. That's kind of silly. I use the GPL for my own from-scratch programs all the time. It's quite a sensible set of terms for source code created as a side effect of a
Re: GPL vs non-GPL device drivers
On 2/22/07, D. Hazelton <[EMAIL PROTECTED]> wrote: " We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software." --IE: Once you release the code under the GPL, it becomes the *copyrighted* *property* of the FSF and you are just another person that the GPL is applied to. Put *down* the crack pipe. Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wednesday 21 February 2007 21:05, Michael K. Edwards wrote: > On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote: > > Related to that... Though a parser generated by Bison and a tokenizer > > generated by Flex both contain large chunks of GPL'd code, their > > inclusion in the source file that is to be compiled is mechanical - the > > true unique work is in writing the file that is processed by the tool to > > produce the output. Since the aggregation of the GPL'd code into the > > output source is done mechanically - via mechanical translation (which is > > what compilation is as well) - the result is *not* and under US copyright > > law *cannot* be a derivative work. What this means is that the GNU/FSF > > "special" terms applied to parsers generated by Bison and tokenizers > > generated by Flex is unnecessary - they are granting you a right you > > already have. > > Half true. It's not a derivative work exactly, but it could > conceivably be held to infringe against the copyright in Flex/Bison, > if you could prove that the amount of _creative_expression_ copied > into the output exceeds a "de minimis" standard and doesn't constitute > a "fair use". Those nifty photomosaics would probably infringe > against the photographers' copyright in the photos they're made up of, > if they weren't licensed through the graphic industry's "stock photo > archive" mechanism. You could probably defend on "fair use" with > respect to Flex/Bison and the vanilla GPL, since the fact that I can > get some random program with a parser in it from you without needing > my own copy of bison doesn't cost the FSF anything. But it's a > gamble, especially if that random program competes with something the > FSF makes $$$ off of; and I'd want that extra bit of estoppel in my > back pocket. Actually, on re-reading the GPL, I see exactly why they made that pair of exceptions. Where it's quite evident that a small to mid scale parsers that could have been written *without* the use of Bison is clearly a non-derivative work - Bison was not required, but was used as a mean of expediency. When you reach a large scale parser, such as one that meets all requirements to act as the parser for an ANSI C99 compiler, Bison stops being expedient - it'd likely take just as much time to hand craft the parser as it would to debug the Bison input. However, it makes maintaining the parser easier. But the fact is that it's the small to medium scale parsers that have a lower ratio of original to GPL'd code that are at risk of being declared derivative works. All of this because the GPL contains the following text in section 0: "The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does." That clause, to me, seems specifically tailored to cover programs such as Bison and Flex. (and is the reason that I try to use Byacc and when I need to, write tokenizers by hand) This frankly stinks of attempts to cover all possible code. (I actually started studying Copyright law in my free time because I was wondering how legal the GPL was and was also puzzled by some major online entities actually complaining about it) > The LGPL is a very different story. It's not just GPL with extra > estoppel, it's a booby trap. It goes a lot farther to put over its > own perverse definition of "derivative work", and it tries to compel > you to provide all the "data and utility programs needed for > reproducing the executable from it". I don't use the LGPL for my own > work, I wouldn't touch it with a ten-foot pole if it didn't have the > "GPL upgrade" clause in it, and I advise my employers and consulting > clients to go through the "GPL (v2 only!) upgrade" rigmarole with > respect to anything they so much as recompile. They don't all take > that advice, but that's not my problem. Since I tailor the license I apply to code I produce to meet the needs of the person or entity I am writing it for, I've never run into this. In truth, the LGPL is, IMHO, a piece of garbage. (as is the GPL - if you release code under the GPL you no longer have a legal right to it. Note the following text that appears in the GPL: " We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software." --IE: Once you release the code under the GPL, it becomes the *copyrighted* *property* of the FSF and you are just another person that the GPL is applied to. This means that if you later change your mind and decide to revoke the GPL on your code and replace it with say, the Larry Wall's "Artistic License" you are breaking the terms of the GPL and therefore lose all rights to modify and distribute your code. A similar clause appears in the LGPL: "We
Re: GPL vs non-GPL device drivers
On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote: On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote: > I think you just misread. I said that the Evil Linker has cheerfully > shipped the source code of the modified POP server. He may not have > given you the compiler he compiled it with, wihout which the source > code is a nice piece of literature but of no engineering utility; but > that's the situation the GPL is DESIGNED TO PRODUCE. Actually, if memory serves, when you license a work under the GPL, part of the terms is that you have to provide the source and any scripts needed to produce a functioning executable. Absolutely. But not the toolchain, just the "scripts". This is part historical, since after all GNU got started when Sun started to monetize its toolchain independently of its O/S, RMS got annoyed enough to kick off another cloning project, and more competent compiler people caught on to the economic opportunity. Ever pay $5K for a CD full of GNU binaries for a commercial UNIX? I did, after deciding that getting all their shit to compile was more Morlock-work than I was up to. So like I say, it's part historical -- RMS didn't want to owe me a copy of Sun's toolchain along with that CD -- but it's no accident that it's still in there, because THAT'S HOW CYGNUS MADE MEGABUCKS. As a side note: The distinct wording of the GPL actually *invalidates* the GNU/FSF claim that dynamically linking a work with, say, the readline library, means the work is a derivative of said library. The GPL states (in clause 0) that the license only covers copying, modification and distribution. Unless they are confusing "Linking" with "copying" or "creating a derivative work" the claim is invalid - because, as it has been shown, a mechanical process such as compilation or linking *cannot* create a derivative work. Of course. The FSF smokescreen around "derivative work" exists not only to frighten potential commercial users of GPL libraries but to squelch people like Eric A. Young (principal OpenSSL author) who have the presumption to retain their own copyrights. Eric has a quite solid case (IMHO, IANAL) against the FSF and Eben Moglen personally under at least three different U. S. antitrust and racketeering laws, and it would be really entertaining to watch him take it up. Related to that... Though a parser generated by Bison and a tokenizer generated by Flex both contain large chunks of GPL'd code, their inclusion in the source file that is to be compiled is mechanical - the true unique work is in writing the file that is processed by the tool to produce the output. Since the aggregation of the GPL'd code into the output source is done mechanically - via mechanical translation (which is what compilation is as well) - the result is *not* and under US copyright law *cannot* be a derivative work. What this means is that the GNU/FSF "special" terms applied to parsers generated by Bison and tokenizers generated by Flex is unnecessary - they are granting you a right you already have. Half true. It's not a derivative work exactly, but it could conceivably be held to infringe against the copyright in Flex/Bison, if you could prove that the amount of _creative_expression_ copied into the output exceeds a "de minimis" standard and doesn't constitute a "fair use". Those nifty photomosaics would probably infringe against the photographers' copyright in the photos they're made up of, if they weren't licensed through the graphic industry's "stock photo archive" mechanism. You could probably defend on "fair use" with respect to Flex/Bison and the vanilla GPL, since the fact that I can get some random program with a parser in it from you without needing my own copy of bison doesn't cost the FSF anything. But it's a gamble, especially if that random program competes with something the FSF makes $$$ off of; and I'd want that extra bit of estoppel in my back pocket. The LGPL is a very different story. It's not just GPL with extra estoppel, it's a booby trap. It goes a lot farther to put over its own perverse definition of "derivative work", and it tries to compel you to provide all the "data and utility programs needed for reproducing the executable from it". I don't use the LGPL for my own work, I wouldn't touch it with a ten-foot pole if it didn't have the "GPL upgrade" clause in it, and I advise my employers and consulting clients to go through the "GPL (v2 only!) upgrade" rigmarole with respect to anything they so much as recompile. They don't all take that advice, but that's not my problem. Anyway, it's been fun watching this thread. If I've made a mistake somewhere in there, let me know - IANAL and I am just starting to really get into the meat of Copyright and related laws in independant study. Ditto. If you see a mistake in something I write, please please pretty please point it out, in public -- I am not a lawyer, absolutely everything I say could be wrong, and I don't really
Re: GPL vs non-GPL device drivers
On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote: > I think you just misread. I said that the Evil Linker has cheerfully > shipped the source code of the modified POP server. He may not have > given you the compiler he compiled it with, wihout which the source > code is a nice piece of literature but of no engineering utility; but > that's the situation the GPL is DESIGNED TO PRODUCE. Actually, if memory serves, when you license a work under the GPL, part of the terms is that you have to provide the source and any scripts needed to produce a functioning executable. *checks a local copy of GPLv2 for the exact wording* Third clause of the license: "For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." So yes, someone could produce a work that compiles on a specific compiler, but there is then nothing stopping someone from fixing the problems that cause it to not compile using another compiler and releasing that source code - distributing it as a patch, AFAICT, falls outside coverage by the GPLv2. The build tool-chain, libraries and other works that are not a direct part of the program produced by compilation of the source code. (the wording of the GPL is: "However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.") As a side note: The distinct wording of the GPL actually *invalidates* the GNU/FSF claim that dynamically linking a work with, say, the readline library, means the work is a derivative of said library. The GPL states (in clause 0) that the license only covers copying, modification and distribution. Unless they are confusing "Linking" with "copying" or "creating a derivative work" the claim is invalid - because, as it has been shown, a mechanical process such as compilation or linking *cannot* create a derivative work. Related to that... Though a parser generated by Bison and a tokenizer generated by Flex both contain large chunks of GPL'd code, their inclusion in the source file that is to be compiled is mechanical - the true unique work is in writing the file that is processed by the tool to produce the output. Since the aggregation of the GPL'd code into the output source is done mechanically - via mechanical translation (which is what compilation is as well) - the result is *not* and under US copyright law *cannot* be a derivative work. What this means is that the GNU/FSF "special" terms applied to parsers generated by Bison and tokenizers generated by Flex is unnecessary - they are granting you a right you already have. Anyway, it's been fun watching this thread. If I've made a mistake somewhere in there, let me know - IANAL and I am just starting to really get into the meat of Copyright and related laws in independant study. DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
I think you just misread. I said that the Evil Linker has cheerfully shipped the source code of the modified POP server. He may not have given you the compiler he compiled it with, wihout which the source code is a nice piece of literature but of no engineering utility; but that's the situation the GPL is DESIGNED TO PRODUCE. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/21/07, Nuno Silva <[EMAIL PROTECTED]> wrote: I can see that your argument is all about the defenition of a "derivative work". Far from it. Try reading to the end. We all know that #include is mostly non copyrightable, so I mostly agree that some - very very simple - modules may not need to include the source when distributing the resulting module.ko. (need = from a legal standpoint... The intended spirit of the GPL is another story) The "intended spirit of the GPL" is very different from what you think it is, as $674 million of Red Hat stock can testify. It is also utterly irrelevant except when the circumstances surrounding someone's acceptance of the GPL indicate that the two parties negotiated more or less directly before settling on its terms. In this context what do you think about porting Linux to another arch? Does the people porting the OS needs to distribute the source with the [compiled] kernel? Of course. They're distributing a derivative work of the kernel, or perhaps even (for legal purposes) distributing Linus's work of authorship with trivial editorial changes that do not create a new copyrightable work. They need license to do so, and the only license on offer is GPL v2, which conditions the license on distribution of source code. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, 21 Feb 2007, Michael K. Edwards wrote: But wait, you say -- the Evil Linker modified, copied, and distributed my POP server too! That makes him subject to the terms of the GPL. And you're right; but to understand what that means, you're going to need to understand how a lawsuit for copyright infringement works. The very, very, very concise version is: I understand why you say that the Evil Linker's program isn't covered by the GPL, but your argument makes it sound like the modified POP server doesn't need to have it's source released. This I don't understand, it contains the origional source code, so what right does Evil Linker have to distribute it (or a modified version). you are comeing dangerously close to saying that the GPL is meaningless and putting something under it is the same as putting it under public domain. There is case law now that says that this isn't the case (although I agree that it's not nearly as broad as it's proponents would like it to be) David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Michael K. Edwards wrote: > Actually, it's quite clear under US law what a derivative work is and > what rights you need to distribute it, and equally clear that > compiling code does not make a "translation" in a copyright sense. > Read Micro Star v. Formgen -- it's good law and it's funny and > readable. Hello. [Sorry for deleting the rest of the email but it was quite large] I can see that your argument is all about the defenition of a "derivative work". We all know that #include is mostly non copyrightable, so I mostly agree that some - very very simple - modules may not need to include the source when distributing the resulting module.ko. (need = from a legal standpoint... The intended spirit of the GPL is another story) In this context what do you think about porting Linux to another arch? Does the people porting the OS needs to distribute the source with the [compiled] kernel? (Yes, it's a trick question) IANAL too. Regards, Nuno Silva - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Actually, it's quite clear under US law what a derivative work is and what rights you need to distribute it, and equally clear that compiling code does not make a "translation" in a copyright sense. Read Micro Star v. Formgen -- it's good law and it's funny and readable. I've drafted summaries from a couple of different angles since VJ requested a "translation into English", and I think this is the most coherent (and least foaming-at-the-mouth) I've crafted yet. It was written as an answer to a private query to this effect: "I write a POP server and release it under the GPL. The Evil Linker adds some hooks to my code, calls those hooks (along some of the existing ones) from his newly developed program, and only provides recipients of the binaries with source code for the modified POP server. His code depends on, and only works with, this modified version of my POP server. Doesn't he have to GPL his whole product, because he's combined his work with mine?" This is a fundamental misconception. A <> is not a "work of authorship". Copyright is about "works of authorship" and cannot be used to allow or disallow behavior based on whether you have <> two things at an engineering level to make a product. A contract can be used to allow or disallow, and assign penalties to, all sorts of things, and the GPL is an "offer of contract"; but its plain text does _not_ disallow this <> -- largely because the drafter was trying to put one over on you and me by pretending that he could do that without recourse to contract law. The fact that your Evil Linker's program will not do anything interesting without your program is no more relevant than the fact that Borland's spreadsheet program will not do anything interesting without a spreadsheet document loaded. Borland's interest lay in making their macro language compatible with Lotus's so that users didn't have to rewrite their documents from scratch. The Evil Linker's interest lies in making their program compatible with other clients of your POP server so they don't have to rewrite your POP server from scratch. Borland won in court, and so will the Evil Linker. IANAL, TINLA. Now, Borland _almost_ lost at the Supreme Court level. Why? Because while they had a good case that it wasn't practical to copy the 1-2-3 macro language without copying its entire user interface, that gets awfully close to the sort of expression that copyright is supposed to protect. You can take a picture of a skyscraper and sell copies of that picture, not because it isn't in some sense an infringement on the architect's copyright, but because it's "fair use" -- mostly because it doesn't interfere with the architect's ability to make money licensing _architectural_ replicas of her work. When you take a screenshot of a spreadsheet, you're on safe ground; but if you use that screenshot to clone the spreadsheet, you're pushing your luck. Borland won, sort of, when the Supremes split 4-4 (one was out sick or recused or something). If you want to know why, you can get hold of a transcript of the oral argument before the Supreme Court, which is mostly in plain English and about half debate between the Justices about where they ought to draw the line. For an example where screenshots can be over the line, and where even unlicensed distribution of data files can be held to infringe the copyright on the program that reads them, read Micro Star v. Formgen (9th Circuit). That involved a very different theory though, infringement on the "characters and mise en scene" of a fictional work (Duke Nukem 3D), and will not avail you against the Evil Linker. All of this stuff is covered in Lexmark v. Static Control (6th Circuit, cert. denied) -- the law of the land throughout the U. S. of A. But wait, you say -- the Evil Linker modified, copied, and distributed my POP server too! That makes him subject to the terms of the GPL. And you're right; but to understand what that means, you're going to need to understand how a lawsuit for copyright infringement works. The very, very, very concise version is: You claim "copyright infringement". He claims "copyright license" -- "acceptance through conduct" of a "valid offer of contract". You claim conduct outside the "scope of the license". He claims the terms about distributing modified versions together with source code are "covenants of return performance", which he duly performed. You claim the license covers the whole <>, including his application. He points out that <> is explicitly defined in GPL Section 0 to be a "derivative work under copyright law", and that while the paraphrase following this overstates the extent of the "derivative works" category, a raft of case law says that his program is not a "derivative work" of yours. Furthermore, it would be "contrary to the public interest" to allow a "contract of adhesion in rem" to disallow the "universal industry practice" of <>, for engineering purposes, many differently licensed works on
Re: GPL vs non-GPL device drivers
Jan-Benedict Glaw wrote: On Tue, 2007-02-20 15:36:56 +0100, Helge Hafting <[EMAIL PROTECTED]> wrote: If you have a need for "secret" source code, stuff most of it in userspace. Make the drivers truly minimal; perhaps their open/closed status won't matter that much when the bulk of the code and the cleverness is kept safe in userspace. Note that keeping drivers small this way is the recommended way of working anyway. It isn't merely a way to keep your code away from the GPL - you always want a small kernel. Keeping the legal stuff out of sight for a second, this'll solve the "problem" for the embedded developer, but surely not for the Linux community. Would you ever expect that eg. the thin GPL layer used by ATI/NVidia would be merged iff the rest would run in userland? A thin layer - no. To get merged, a driver would have to be of good quality. I didn't think like that - I was thinking of embedded developers that sometimes implement the entire embedded application inside their device driver. Which is crazy from a linux design standpoint, but sometimes reasonable for an embedded developer when the sole purpose of the embedded computer is to control the single "device" and perhaps a little display with a couple of buttons. The "app" part might not be that much bigger than the device driver itself - it is then tempting to cut some corners and put all in one place. Of course this kind of "driver" ends up containing everything, and nobody wants to GPL that. Separating driver and app(s) properly lets them keep a proprietary app, and a driver or two that might be small and simple enough to be released. It's just a workaround for the linking-the-object-file-into-the-kernel-image problem, but after all, it doesn't lead to a working driver being freely available. MfG, JBG Good point. Fortunately, most devices are much simpler than a card with accelerated 3D-graphichs. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Jan-Benedict Glaw wrote: On Tue, 2007-02-20 15:36:56 +0100, Helge Hafting [EMAIL PROTECTED] wrote: If you have a need for secret source code, stuff most of it in userspace. Make the drivers truly minimal; perhaps their open/closed status won't matter that much when the bulk of the code and the cleverness is kept safe in userspace. Note that keeping drivers small this way is the recommended way of working anyway. It isn't merely a way to keep your code away from the GPL - you always want a small kernel. Keeping the legal stuff out of sight for a second, this'll solve the problem for the embedded developer, but surely not for the Linux community. Would you ever expect that eg. the thin GPL layer used by ATI/NVidia would be merged iff the rest would run in userland? A thin layer - no. To get merged, a driver would have to be of good quality. I didn't think like that - I was thinking of embedded developers that sometimes implement the entire embedded application inside their device driver. Which is crazy from a linux design standpoint, but sometimes reasonable for an embedded developer when the sole purpose of the embedded computer is to control the single device and perhaps a little display with a couple of buttons. The app part might not be that much bigger than the device driver itself - it is then tempting to cut some corners and put all in one place. Of course this kind of driver ends up containing everything, and nobody wants to GPL that. Separating driver and app(s) properly lets them keep a proprietary app, and a driver or two that might be small and simple enough to be released. It's just a workaround for the linking-the-object-file-into-the-kernel-image problem, but after all, it doesn't lead to a working driver being freely available. MfG, JBG Good point. Fortunately, most devices are much simpler than a card with accelerated 3D-graphichs. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Actually, it's quite clear under US law what a derivative work is and what rights you need to distribute it, and equally clear that compiling code does not make a translation in a copyright sense. Read Micro Star v. Formgen -- it's good law and it's funny and readable. I've drafted summaries from a couple of different angles since VJ requested a translation into English, and I think this is the most coherent (and least foaming-at-the-mouth) I've crafted yet. It was written as an answer to a private query to this effect: I write a POP server and release it under the GPL. The Evil Linker adds some hooks to my code, calls those hooks (along some of the existing ones) from his newly developed program, and only provides recipients of the binaries with source code for the modified POP server. His code depends on, and only works with, this modified version of my POP server. Doesn't he have to GPL his whole product, because he's combined his work with mine? This is a fundamental misconception. A product is not a work of authorship. Copyright is about works of authorship and cannot be used to allow or disallow behavior based on whether you have combined two things at an engineering level to make a product. A contract can be used to allow or disallow, and assign penalties to, all sorts of things, and the GPL is an offer of contract; but its plain text does _not_ disallow this combination -- largely because the drafter was trying to put one over on you and me by pretending that he could do that without recourse to contract law. The fact that your Evil Linker's program will not do anything interesting without your program is no more relevant than the fact that Borland's spreadsheet program will not do anything interesting without a spreadsheet document loaded. Borland's interest lay in making their macro language compatible with Lotus's so that users didn't have to rewrite their documents from scratch. The Evil Linker's interest lies in making their program compatible with other clients of your POP server so they don't have to rewrite your POP server from scratch. Borland won in court, and so will the Evil Linker. IANAL, TINLA. Now, Borland _almost_ lost at the Supreme Court level. Why? Because while they had a good case that it wasn't practical to copy the 1-2-3 macro language without copying its entire user interface, that gets awfully close to the sort of expression that copyright is supposed to protect. You can take a picture of a skyscraper and sell copies of that picture, not because it isn't in some sense an infringement on the architect's copyright, but because it's fair use -- mostly because it doesn't interfere with the architect's ability to make money licensing _architectural_ replicas of her work. When you take a screenshot of a spreadsheet, you're on safe ground; but if you use that screenshot to clone the spreadsheet, you're pushing your luck. Borland won, sort of, when the Supremes split 4-4 (one was out sick or recused or something). If you want to know why, you can get hold of a transcript of the oral argument before the Supreme Court, which is mostly in plain English and about half debate between the Justices about where they ought to draw the line. For an example where screenshots can be over the line, and where even unlicensed distribution of data files can be held to infringe the copyright on the program that reads them, read Micro Star v. Formgen (9th Circuit). That involved a very different theory though, infringement on the characters and mise en scene of a fictional work (Duke Nukem 3D), and will not avail you against the Evil Linker. All of this stuff is covered in Lexmark v. Static Control (6th Circuit, cert. denied) -- the law of the land throughout the U. S. of A. But wait, you say -- the Evil Linker modified, copied, and distributed my POP server too! That makes him subject to the terms of the GPL. And you're right; but to understand what that means, you're going to need to understand how a lawsuit for copyright infringement works. The very, very, very concise version is: You claim copyright infringement. He claims copyright license -- acceptance through conduct of a valid offer of contract. You claim conduct outside the scope of the license. He claims the terms about distributing modified versions together with source code are covenants of return performance, which he duly performed. You claim the license covers the whole work based on the Program, including his application. He points out that work based on the Program is explicitly defined in GPL Section 0 to be a derivative work under copyright law, and that while the paraphrase following this overstates the extent of the derivative works category, a raft of case law says that his program is not a derivative work of yours. Furthermore, it would be contrary to the public interest to allow a contract of adhesion in rem to disallow the universal industry practice of aggregating, for engineering purposes,
Re: GPL vs non-GPL device drivers
Michael K. Edwards wrote: Actually, it's quite clear under US law what a derivative work is and what rights you need to distribute it, and equally clear that compiling code does not make a translation in a copyright sense. Read Micro Star v. Formgen -- it's good law and it's funny and readable. Hello. [Sorry for deleting the rest of the email but it was quite large] I can see that your argument is all about the defenition of a derivative work. We all know that #include anything.h is mostly non copyrightable, so I mostly agree that some - very very simple - modules may not need to include the source when distributing the resulting module.ko. (need = from a legal standpoint... The intended spirit of the GPL is another story) In this context what do you think about porting Linux to another arch? Does the people porting the OS needs to distribute the source with the [compiled] kernel? (Yes, it's a trick question) IANAL too. Regards, Nuno Silva - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, 21 Feb 2007, Michael K. Edwards wrote: But wait, you say -- the Evil Linker modified, copied, and distributed my POP server too! That makes him subject to the terms of the GPL. And you're right; but to understand what that means, you're going to need to understand how a lawsuit for copyright infringement works. The very, very, very concise version is: argument snipped for brevity I understand why you say that the Evil Linker's program isn't covered by the GPL, but your argument makes it sound like the modified POP server doesn't need to have it's source released. This I don't understand, it contains the origional source code, so what right does Evil Linker have to distribute it (or a modified version). you are comeing dangerously close to saying that the GPL is meaningless and putting something under it is the same as putting it under public domain. There is case law now that says that this isn't the case (although I agree that it's not nearly as broad as it's proponents would like it to be) David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/21/07, Nuno Silva [EMAIL PROTECTED] wrote: I can see that your argument is all about the defenition of a derivative work. Far from it. Try reading to the end. We all know that #include anything.h is mostly non copyrightable, so I mostly agree that some - very very simple - modules may not need to include the source when distributing the resulting module.ko. (need = from a legal standpoint... The intended spirit of the GPL is another story) The intended spirit of the GPL is very different from what you think it is, as $674 million of Red Hat stock can testify. It is also utterly irrelevant except when the circumstances surrounding someone's acceptance of the GPL indicate that the two parties negotiated more or less directly before settling on its terms. In this context what do you think about porting Linux to another arch? Does the people porting the OS needs to distribute the source with the [compiled] kernel? Of course. They're distributing a derivative work of the kernel, or perhaps even (for legal purposes) distributing Linus's work of authorship with trivial editorial changes that do not create a new copyrightable work. They need license to do so, and the only license on offer is GPL v2, which conditions the license on distribution of source code. Cheers, - Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
I think you just misread. I said that the Evil Linker has cheerfully shipped the source code of the modified POP server. He may not have given you the compiler he compiled it with, wihout which the source code is a nice piece of literature but of no engineering utility; but that's the situation the GPL is DESIGNED TO PRODUCE. Cheers, - Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote: I think you just misread. I said that the Evil Linker has cheerfully shipped the source code of the modified POP server. He may not have given you the compiler he compiled it with, wihout which the source code is a nice piece of literature but of no engineering utility; but that's the situation the GPL is DESIGNED TO PRODUCE. Actually, if memory serves, when you license a work under the GPL, part of the terms is that you have to provide the source and any scripts needed to produce a functioning executable. *checks a local copy of GPLv2 for the exact wording* Third clause of the license: For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. So yes, someone could produce a work that compiles on a specific compiler, but there is then nothing stopping someone from fixing the problems that cause it to not compile using another compiler and releasing that source code - distributing it as a patch, AFAICT, falls outside coverage by the GPLv2. The build tool-chain, libraries and other works that are not a direct part of the program produced by compilation of the source code. (the wording of the GPL is: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.) As a side note: The distinct wording of the GPL actually *invalidates* the GNU/FSF claim that dynamically linking a work with, say, the readline library, means the work is a derivative of said library. The GPL states (in clause 0) that the license only covers copying, modification and distribution. Unless they are confusing Linking with copying or creating a derivative work the claim is invalid - because, as it has been shown, a mechanical process such as compilation or linking *cannot* create a derivative work. Related to that... Though a parser generated by Bison and a tokenizer generated by Flex both contain large chunks of GPL'd code, their inclusion in the source file that is to be compiled is mechanical - the true unique work is in writing the file that is processed by the tool to produce the output. Since the aggregation of the GPL'd code into the output source is done mechanically - via mechanical translation (which is what compilation is as well) - the result is *not* and under US copyright law *cannot* be a derivative work. What this means is that the GNU/FSF special terms applied to parsers generated by Bison and tokenizers generated by Flex is unnecessary - they are granting you a right you already have. Anyway, it's been fun watching this thread. If I've made a mistake somewhere in there, let me know - IANAL and I am just starting to really get into the meat of Copyright and related laws in independant study. DRH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/21/07, D. Hazelton [EMAIL PROTECTED] wrote: On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote: I think you just misread. I said that the Evil Linker has cheerfully shipped the source code of the modified POP server. He may not have given you the compiler he compiled it with, wihout which the source code is a nice piece of literature but of no engineering utility; but that's the situation the GPL is DESIGNED TO PRODUCE. Actually, if memory serves, when you license a work under the GPL, part of the terms is that you have to provide the source and any scripts needed to produce a functioning executable. Absolutely. But not the toolchain, just the scripts. This is part historical, since after all GNU got started when Sun started to monetize its toolchain independently of its O/S, RMS got annoyed enough to kick off another cloning project, and more competent compiler people caught on to the economic opportunity. Ever pay $5K for a CD full of GNU binaries for a commercial UNIX? I did, after deciding that getting all their shit to compile was more Morlock-work than I was up to. So like I say, it's part historical -- RMS didn't want to owe me a copy of Sun's toolchain along with that CD -- but it's no accident that it's still in there, because THAT'S HOW CYGNUS MADE MEGABUCKS. As a side note: The distinct wording of the GPL actually *invalidates* the GNU/FSF claim that dynamically linking a work with, say, the readline library, means the work is a derivative of said library. The GPL states (in clause 0) that the license only covers copying, modification and distribution. Unless they are confusing Linking with copying or creating a derivative work the claim is invalid - because, as it has been shown, a mechanical process such as compilation or linking *cannot* create a derivative work. Of course. The FSF smokescreen around derivative work exists not only to frighten potential commercial users of GPL libraries but to squelch people like Eric A. Young (principal OpenSSL author) who have the presumption to retain their own copyrights. Eric has a quite solid case (IMHO, IANAL) against the FSF and Eben Moglen personally under at least three different U. S. antitrust and racketeering laws, and it would be really entertaining to watch him take it up. Related to that... Though a parser generated by Bison and a tokenizer generated by Flex both contain large chunks of GPL'd code, their inclusion in the source file that is to be compiled is mechanical - the true unique work is in writing the file that is processed by the tool to produce the output. Since the aggregation of the GPL'd code into the output source is done mechanically - via mechanical translation (which is what compilation is as well) - the result is *not* and under US copyright law *cannot* be a derivative work. What this means is that the GNU/FSF special terms applied to parsers generated by Bison and tokenizers generated by Flex is unnecessary - they are granting you a right you already have. Half true. It's not a derivative work exactly, but it could conceivably be held to infringe against the copyright in Flex/Bison, if you could prove that the amount of _creative_expression_ copied into the output exceeds a de minimis standard and doesn't constitute a fair use. Those nifty photomosaics would probably infringe against the photographers' copyright in the photos they're made up of, if they weren't licensed through the graphic industry's stock photo archive mechanism. You could probably defend on fair use with respect to Flex/Bison and the vanilla GPL, since the fact that I can get some random program with a parser in it from you without needing my own copy of bison doesn't cost the FSF anything. But it's a gamble, especially if that random program competes with something the FSF makes $$$ off of; and I'd want that extra bit of estoppel in my back pocket. The LGPL is a very different story. It's not just GPL with extra estoppel, it's a booby trap. It goes a lot farther to put over its own perverse definition of derivative work, and it tries to compel you to provide all the data and utility programs needed for reproducing the executable from it. I don't use the LGPL for my own work, I wouldn't touch it with a ten-foot pole if it didn't have the GPL upgrade clause in it, and I advise my employers and consulting clients to go through the GPL (v2 only!) upgrade rigmarole with respect to anything they so much as recompile. They don't all take that advice, but that's not my problem. Anyway, it's been fun watching this thread. If I've made a mistake somewhere in there, let me know - IANAL and I am just starting to really get into the meat of Copyright and related laws in independant study. Ditto. If you see a mistake in something I write, please please pretty please point it out, in public -- I am not a lawyer, absolutely everything I say could be wrong, and I don't really want these messages lying around
Re: GPL vs non-GPL device drivers
On Wednesday 21 February 2007 21:05, Michael K. Edwards wrote: On 2/21/07, D. Hazelton [EMAIL PROTECTED] wrote: snip Related to that... Though a parser generated by Bison and a tokenizer generated by Flex both contain large chunks of GPL'd code, their inclusion in the source file that is to be compiled is mechanical - the true unique work is in writing the file that is processed by the tool to produce the output. Since the aggregation of the GPL'd code into the output source is done mechanically - via mechanical translation (which is what compilation is as well) - the result is *not* and under US copyright law *cannot* be a derivative work. What this means is that the GNU/FSF special terms applied to parsers generated by Bison and tokenizers generated by Flex is unnecessary - they are granting you a right you already have. Half true. It's not a derivative work exactly, but it could conceivably be held to infringe against the copyright in Flex/Bison, if you could prove that the amount of _creative_expression_ copied into the output exceeds a de minimis standard and doesn't constitute a fair use. Those nifty photomosaics would probably infringe against the photographers' copyright in the photos they're made up of, if they weren't licensed through the graphic industry's stock photo archive mechanism. You could probably defend on fair use with respect to Flex/Bison and the vanilla GPL, since the fact that I can get some random program with a parser in it from you without needing my own copy of bison doesn't cost the FSF anything. But it's a gamble, especially if that random program competes with something the FSF makes $$$ off of; and I'd want that extra bit of estoppel in my back pocket. Actually, on re-reading the GPL, I see exactly why they made that pair of exceptions. Where it's quite evident that a small to mid scale parsers that could have been written *without* the use of Bison is clearly a non-derivative work - Bison was not required, but was used as a mean of expediency. When you reach a large scale parser, such as one that meets all requirements to act as the parser for an ANSI C99 compiler, Bison stops being expedient - it'd likely take just as much time to hand craft the parser as it would to debug the Bison input. However, it makes maintaining the parser easier. But the fact is that it's the small to medium scale parsers that have a lower ratio of original to GPL'd code that are at risk of being declared derivative works. All of this because the GPL contains the following text in section 0: The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. That clause, to me, seems specifically tailored to cover programs such as Bison and Flex. (and is the reason that I try to use Byacc and when I need to, write tokenizers by hand) This frankly stinks of attempts to cover all possible code. (I actually started studying Copyright law in my free time because I was wondering how legal the GPL was and was also puzzled by some major online entities actually complaining about it) The LGPL is a very different story. It's not just GPL with extra estoppel, it's a booby trap. It goes a lot farther to put over its own perverse definition of derivative work, and it tries to compel you to provide all the data and utility programs needed for reproducing the executable from it. I don't use the LGPL for my own work, I wouldn't touch it with a ten-foot pole if it didn't have the GPL upgrade clause in it, and I advise my employers and consulting clients to go through the GPL (v2 only!) upgrade rigmarole with respect to anything they so much as recompile. They don't all take that advice, but that's not my problem. Since I tailor the license I apply to code I produce to meet the needs of the person or entity I am writing it for, I've never run into this. In truth, the LGPL is, IMHO, a piece of garbage. (as is the GPL - if you release code under the GPL you no longer have a legal right to it. Note the following text that appears in the GPL: We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. --IE: Once you release the code under the GPL, it becomes the *copyrighted* *property* of the FSF and you are just another person that the GPL is applied to. This means that if you later change your mind and decide to revoke the GPL on your code and replace it with say, the Larry Wall's Artistic License you are breaking the terms of the GPL and therefore lose all rights to modify and distribute your code. A similar clause appears in the LGPL: We protect your rights with a two-step method: (1) we copyright the library,
Re: GPL vs non-GPL device drivers
On 2/22/07, D. Hazelton [EMAIL PROTECTED] wrote: We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. --IE: Once you release the code under the GPL, it becomes the *copyrighted* *property* of the FSF and you are just another person that the GPL is applied to. Put *down* the crack pipe. Trent - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/21/07, D. Hazelton [EMAIL PROTECTED] wrote: Actually, on re-reading the GPL, I see exactly why they made that pair of exceptions. Where it's quite evident that a small to mid scale parsers that could have been written *without* the use of Bison is clearly a non-derivative work - Bison was not required, but was used as a mean of expediency. When you reach a large scale parser, such as one that meets all requirements to act as the parser for an ANSI C99 compiler, Bison stops being expedient - it'd likely take just as much time to hand craft the parser as it would to debug the Bison input. However, it makes maintaining the parser easier. I repeat, that is not what derivative work means. Do not try to reason about the phrase derivative work without reference to its definition in statute and its legal history in appellate decisions. You will get it wrong every time. You have not recast, transformed, or adapted the _creative_expression_ in Bison or Flex in the course of using it; so whether or not you have infringed the FSF's copyright, you have NOT created a derivative work. If Bison and Flex were offered under the bare GPL, and you used them to build a parser, and the FSF sued you for offering that parser to other people on terms other than the GPL's, you don't defend by claiming license under the GPL with regard to your parser. You attack the claim of copying itself by saying that the _creative_expression_ copied from Bison/Flex into your parser is de minimis under the Altai Abstraction-Filtration-Comparison test. You also point out that, even if it weren't de minimis, it's fair use; that's a complex four-factor test, but the main thing is that you're not interfering with the FSF's ability to monetize its copyright in Bison/Flex. If you have any sense, you will strenuously argue that the various special exceptions for things like Bison/Flex and GNU Classpath are _not_ part of the offer of contract contained in the GPL, any more than the Preamble is. They're declarations of intent on the part of the copyright holder, and can be used to _estop_ the FSF from making the copyright infringement claim against you in court in the first place. They promised you they wouldn't, not as part of the contract terms, but as part of the inducement to form a contract with them by acceptance through conduct. But the fact is that it's the small to medium scale parsers that have a lower ratio of original to GPL'd code that are at risk of being declared derivative works. All of this because the GPL contains the following text in section 0: The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. I'm sorry, but that ratio test has nothing to do with whether something is a derivative work or not. It comes up mostly in evaluating a fair use defense, and it's the ratio of the amount of creative expression _copied_ to the amount of creative expression in the _original_work_ that matters. Just because you're writing a 49-volume encyclopedia does not give you the right to copy two thirds of my one-page essay. Those weasel-words about depending on what the Program does are nonsense. It depends on what _creative_expression_ from the Program winds up in the output. That clause, to me, seems specifically tailored to cover programs such as Bison and Flex. (and is the reason that I try to use Byacc and when I need to, write tokenizers by hand) This frankly stinks of attempts to cover all possible code. (I actually started studying Copyright law in my free time because I was wondering how legal the GPL was and was also puzzled by some major online entities actually complaining about it) I've written tokenizers in at least six different languages to date, including Fortran. It's a pain in the butt. The last thing I want to be worrying about when I write a tokenizer is whether somebody else's peanut butter is winding up in my chocolate. So I will only use a tool which, like bison and flex, is accompanied by a promise not to claim that its output infringes the tool author's copyright or is otherwise encumbered in any way. M$ VC++ is actually more trustworthy in that respect than G++. If you don't believe (as I do) that it is arrant nonsense to claim that the use of interface headers or linking of any kind creates a derivative work, then you must believe that any programs compiled with G++ can only be distributed under the terms of the GPL. libstdc++ is GPL, not LGPL. Since I tailor the license I apply to code I produce to meet the needs of the person or entity I am writing it for, I've never run into this. That's kind of silly. I use the GPL for my own from-scratch programs all the time. It's quite a sensible set of terms for source code created as a side effect of a consulting project, when
Re: GPL vs non-GPL device drivers
On Tue, 2007-02-20 15:36:56 +0100, Helge Hafting <[EMAIL PROTECTED]> wrote: > If you have a need for "secret" source code, stuff most of it > in userspace. Make the drivers truly minimal; perhaps their > open/closed status won't matter that much when the bulk > of the code and the cleverness is kept safe in userspace. > > Note that keeping drivers small this way is the recommended > way of working anyway. It isn't merely a way to keep your > code away from the GPL - you always want a small kernel. Keeping the legal stuff out of sight for a second, this'll solve the "problem" for the embedded developer, but surely not for the Linux community. Would you ever expect that eg. the thin GPL layer used by ATI/NVidia would be merged iff the rest would run in userland? It's just a workaround for the linking-the-object-file-into-the-kernel-image problem, but after all, it doesn't lead to a working driver being freely available. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of:If it doesn't work, force it. the second : If it breaks, it needed replacing anyway. signature.asc Description: Digital signature
Re: GPL vs non-GPL device drivers
On Tue, 20 Feb 2007 12:00:51 +0100, Bernd Petrovitsch said: > Flame bait alert: > I heard a talk from an Austrian lawyer an according to his believes (and > I don't know if he is the only one or if there lots of) one must see > from the "users" view if the GPL spreads over or not (and the usual > technical terms like "linking" are basically irrelevant). > E.g.: > - You are distributing an application which links against a GPL-library. > If you provide a link and the user/customer has to get and install that > library, your application can have any license you wish. > - If you distribute an application and it installs automatically a > library (e.g. from the CD where your application is installed), your > applications license must "fit" wit the library license. So tell me - if RedHat distributes a non-GPL program that uses a GPL library that is included as part of the distribution, but *not* one that's usually installed, which rules apply? Even better - does this mean that I can *intentionally* bypass the licensing by including a installer script that removed a problematic library, and then forces the user to re-install it? pgpYyXP1m6V0a.pgp Description: PGP signature
Re: GPL vs non-GPL device drivers
On Tue, 2007-02-20 at 10:14 -0500, [EMAIL PROTECTED] wrote: > On Tue, 20 Feb 2007 12:00:51 +0100, Bernd Petrovitsch said: > > Flame bait alert: > > I heard a talk from an Austrian lawyer an according to his believes (and > > I don't know if he is the only one or if there lots of) one must see > > from the "users" view if the GPL spreads over or not (and the usual > > technical terms like "linking" are basically irrelevant). > > E.g.: > > - You are distributing an application which links against a GPL-library. > > If you provide a link and the user/customer has to get and install that > > library, your application can have any license you wish. > > - If you distribute an application and it installs automatically a > > library (e.g. from the CD where your application is installed), your > > applications license must "fit" wit the library license. > > So tell me - if RedHat distributes a non-GPL program that uses a GPL > library that is included as part of the distribution, but *not* one that's > usually installed, which rules apply? I'm well aware that there are (probably lots of) contradictions with this "idea". IANAL and we must ask that lawyer actually for this. And he will probasbly do not understand the question since he very probably doesn't know all the usual software distribution methods. > Even better - does this mean that I can *intentionally* bypass the licensing > by > including a installer script that removed a problematic library, and then > forces the user to re-install it? A good question which belongs in the same category as above. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: Assuming these need not be GPL, I have a problem with EXPORT_SYMBOL_GPL and the general trend in the direction of making proprietary drivers harder on companies. Our drivers use basic interfaces in the kernel like open, read, write, ioctl, semaphores, interrupts, timers etc. This is functionality we would expect from any operating system. We used devfs before and had no problems there. Greg KH has gone and made the basic sysfs interface, which any generic driver could use as EXPORT_SYMBOL_GPL. I don't really care, I just don't use sysfs. The point is that old functionality is being ripped off and new ones introduced, and their interfaces are not open anymore. Hence there will be a point where non-GPLed drivers simply cannot be loaded. So why beat about the bush? Just make it illegal to load proprietary drivers, or remove EXPORT_SYMBOL_GPL. Those wo introduce EXPORT_SYMBOL_GPL are not in a position where they can make it illegal to load proprietary modules. They may want to, but they can't. The kernel has very many copyright holders, each decides for his own part only. Someone who didn't write the module interface or posix interface can't stop you there. Anti-proprietary folks then go and make new useful subsystems, and make sure those are accessed with EXPORT_SYMBOL_GPL only. Then they phase out the old interfaces as the new ones are clearly better, and the vast majority with GPL drivers have no problem with this. As long as there are developers with this attitude, expect EXPORT_SYMBOL_GPL to crop up in new places over time. Yes - this makes it harder (although not impossible) to distribute closed-source drivers. Which is exactly what these people want. When they are powerless to forbid such drivers, they settle for making them harder and harder to use instead. They want this trend to continue. There is an obvious way around it - you (and other people with an interest in closed-source drivers) can write & contribute your own "sysfs" and whatever else you might need. Make it better than the existing sysfs so it actually gets into the kernel, replacing the existing stuff. And of course there will be no EXPORT_SYMBOL_GPL in it - since that is what you want to avoid. The price for this then, is to outcompete the proponents of GPL-only symbols. If you offer more and better source (under the GPL) then you can turn the trend and keep linux the way you want it. If you don't - those that do contribute will get to shape linux the way they like. Whoever makes linux gets to decide. Another way is to stay with linux 2.4. You won't get any new stuff that way, but no new GPL surprises either. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote:
You are trying to cram this in a simple yes or no box, and it just
doesn't
fit. There are questions nobody knows the answers to (such as what
rights
you need to distribute a derivative work or whether compiling code
makes a
translation).
Thanks, all for the discussion. I certainly learnt a lot. I definitely
expected to be flamed and roasted for posting my original message, and
was not disappointed :)
I do not possess all the knowledge ("legal" and technical) that people
who have contributed to this discussion possess. However I will still
comment from a user's perspective, which was my original point.
Many companies in the embedded field still mistakenly feel (or felt
until a while ago) that Linux was not right for them. That they would
have to open source their code, that they would not get adequate
support, and that Linux was too big and heavy to perform well in an
embedded platform. People like me who were Linux Desktop junkies were
actually trying to convince companies of the opposite.
Now the popularity of Linux is exploding in the embedded space. Nobody
talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be
a worthwhile experiment to study this surge in popularity. I am not an
expert, but perhaps the reason is "it works so goddamn well and has a
wealth of third party FREE software". Sure its a bit of work to make
it work on our platform and we don't have to Enea or Windriver to
write our gripes to. But it definitely is worth it.
Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
does to this popularity. I don't know. I am just giving you my
opinion. The moment companies learn of something like this, alarm
bells start to go off. This is not rational. I personally have nothing
against open-sourcing all software. *But*, this is not how companies
think.
Let's think about why Linux became so popular and strive towards
keeping it that way instead of resorting to innovative ways of just
confusing a lot of people.
Having said this, I am committed to contribute back to the Linux
community in any way I can, not withstanding my present employer. Keep
up the good work guys!
As linux becomes popular, there will always be some people looking
at it that find that it don't fit them perfectly. That don't mean
we have to make sure linux fits them too - they may be better off
with something else, or we may be better off without them.
Linux has a price - you can use it compeltely free but we want
any useful changes you might make. If everybody sat on their stuff,
linux wouldn't be useful to you today.
There are embedded developers who don't have a problem with
writing GPL drivers. And there are embedded developers who
don't need any special hardware driver. No _kernel_ change,
no open-sourcing of company code. It was never a problem, and
will never be a problem, to run proprietary user processes "apps"
on a linux kernel.
If you have a need for "secret" source code, stuff most of it
in userspace. Make the drivers truly minimal; perhaps their
open/closed status won't matter that much when the bulk
of the code and the cleverness is kept safe in userspace.
Note that keeping drivers small this way is the recommended
way of working anyway. It isn't merely a way to keep your
code away from the GPL - you always want a small kernel.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Mon, 2007-02-19 at 21:19 -0800, v j wrote: [...] > Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL > does to this popularity. I don't know. I am just giving you my The big problem with such discussions (as this) are: It is a law decision which license applies in which situation. And preprocessor can solve this (so EXPORT_SYMBOL_GPL may mean that or may only express the wish of one/several/many/a lot of people). Flame bait alert: I heard a talk from an Austrian lawyer an according to his believes (and I don't know if he is the only one or if there lots of) one must see from the "users" view if the GPL spreads over or not (and the usual technical terms like "linking" are basically irrelevant). E.g.: - You are distributing an application which links against a GPL-library. If you provide a link and the user/customer has to get and install that library, your application can have any license you wish. - If you distribute an application and it installs automatically a library (e.g. from the CD where your application is installed), your applications license must "fit" wit the library license. Guess now what this implies for (typical) embedded systems with one piece of GPL code in it where you download complete firmware images - and he explicitly confirmed that. So this whole thing is not really defined yet and one (read: we) must also educate such free-software-illiterate people on how it is intended to work. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: Now the popularity of Linux is exploding in the embedded space. Nobody talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be a worthwhile experiment to study this surge in popularity. I am not an expert, but perhaps the reason is "it works so goddamn well and has a wealth of third party FREE software". Sure its a bit of work to make it work on our platform and we don't have to Enea or Windriver to write our gripes to. But it definitely is worth it. And do you think it works well because of all those companies that don't contribute anything back? For that matter, do they do a single thing to help anyone or anything to do with Linux except themselves? Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL does to this popularity. I don't know. I am just giving you my opinion. The moment companies learn of something like this, alarm bells start to go off. This is not rational. I personally have nothing against open-sourcing all software. *But*, this is not how companies think. Opinions or motivations, or the people working for companies don't really have any relevance at all. What matters is their actions. You would think that those people who think their IP is so priceless that it can't be opened would respect the rights of others. Sadly that doesn't appear to be the case. Let's think about why Linux became so popular and strive towards keeping it that way instead of resorting to innovative ways of just confusing a lot of people. Linux has become popular _in spite_ of parasites, rather than because of them. The main reason for its popularity is its quality. And a big reason for its quality is the GPL. -- Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/20/07, Trent Waddington <[EMAIL PROTECTED]> wrote: I don't think anyone wants to read that. I guess that was a stupid thing to say. Ok, fine people, Michael is ok with me posting this, so enjoy: http://rtfm.insomnia.org/~qg/chat-with-michael-k-edwards.html There ya go. Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote: Just in case anyone cares, after speaking with Michael for a few hours I've found he's not nearly as abrasive as this mailing list banter might suggest. He makes some good arguments once you stop him from spouting conspiracy stuff and, although I don't agree with all of them, I think he has some good points. He suggested posting a transcript of our chat but, frankly, I don't think anyone wants to read that. If you can translate what he had to say in English, I certainly would be willing to hear about it. vj. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/19/07, Trent Waddington [EMAIL PROTECTED] wrote: Just in case anyone cares, after speaking with Michael for a few hours I've found he's not nearly as abrasive as this mailing list banter might suggest. He makes some good arguments once you stop him from spouting conspiracy stuff and, although I don't agree with all of them, I think he has some good points. He suggested posting a transcript of our chat but, frankly, I don't think anyone wants to read that. If you can translate what he had to say in English, I certainly would be willing to hear about it. vj. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/20/07, Trent Waddington [EMAIL PROTECTED] wrote: I don't think anyone wants to read that. I guess that was a stupid thing to say. Ok, fine people, Michael is ok with me posting this, so enjoy: http://rtfm.insomnia.org/~qg/chat-with-michael-k-edwards.html There ya go. Trent - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: Now the popularity of Linux is exploding in the embedded space. Nobody talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be a worthwhile experiment to study this surge in popularity. I am not an expert, but perhaps the reason is it works so goddamn well and has a wealth of third party FREE software. Sure its a bit of work to make it work on our platform and we don't have to Enea or Windriver to write our gripes to. But it definitely is worth it. And do you think it works well because of all those companies that don't contribute anything back? For that matter, do they do a single thing to help anyone or anything to do with Linux except themselves? Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL does to this popularity. I don't know. I am just giving you my opinion. The moment companies learn of something like this, alarm bells start to go off. This is not rational. I personally have nothing against open-sourcing all software. *But*, this is not how companies think. Opinions or motivations, or the people working for companies don't really have any relevance at all. What matters is their actions. You would think that those people who think their IP is so priceless that it can't be opened would respect the rights of others. Sadly that doesn't appear to be the case. Let's think about why Linux became so popular and strive towards keeping it that way instead of resorting to innovative ways of just confusing a lot of people. Linux has become popular _in spite_ of parasites, rather than because of them. The main reason for its popularity is its quality. And a big reason for its quality is the GPL. -- Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Mon, 2007-02-19 at 21:19 -0800, v j wrote: [...] Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL does to this popularity. I don't know. I am just giving you my The big problem with such discussions (as this) are: It is a law decision which license applies in which situation. And preprocessor can solve this (so EXPORT_SYMBOL_GPL may mean that or may only express the wish of one/several/many/a lot of people). Flame bait alert: I heard a talk from an Austrian lawyer an according to his believes (and I don't know if he is the only one or if there lots of) one must see from the users view if the GPL spreads over or not (and the usual technical terms like linking are basically irrelevant). E.g.: - You are distributing an application which links against a GPL-library. If you provide a link and the user/customer has to get and install that library, your application can have any license you wish. - If you distribute an application and it installs automatically a library (e.g. from the CD where your application is installed), your applications license must fit wit the library license. Guess now what this implies for (typical) embedded systems with one piece of GPL code in it where you download complete firmware images - and he explicitly confirmed that. So this whole thing is not really defined yet and one (read: we) must also educate such free-software-illiterate people on how it is intended to work. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: You are trying to cram this in a simple yes or no box, and it just doesn't fit. There are questions nobody knows the answers to (such as what rights you need to distribute a derivative work or whether compiling code makes a translation). Thanks, all for the discussion. I certainly learnt a lot. I definitely expected to be flamed and roasted for posting my original message, and was not disappointed :) I do not possess all the knowledge (legal and technical) that people who have contributed to this discussion possess. However I will still comment from a user's perspective, which was my original point. Many companies in the embedded field still mistakenly feel (or felt until a while ago) that Linux was not right for them. That they would have to open source their code, that they would not get adequate support, and that Linux was too big and heavy to perform well in an embedded platform. People like me who were Linux Desktop junkies were actually trying to convince companies of the opposite. Now the popularity of Linux is exploding in the embedded space. Nobody talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be a worthwhile experiment to study this surge in popularity. I am not an expert, but perhaps the reason is it works so goddamn well and has a wealth of third party FREE software. Sure its a bit of work to make it work on our platform and we don't have to Enea or Windriver to write our gripes to. But it definitely is worth it. Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL does to this popularity. I don't know. I am just giving you my opinion. The moment companies learn of something like this, alarm bells start to go off. This is not rational. I personally have nothing against open-sourcing all software. *But*, this is not how companies think. Let's think about why Linux became so popular and strive towards keeping it that way instead of resorting to innovative ways of just confusing a lot of people. Having said this, I am committed to contribute back to the Linux community in any way I can, not withstanding my present employer. Keep up the good work guys! As linux becomes popular, there will always be some people looking at it that find that it don't fit them perfectly. That don't mean we have to make sure linux fits them too - they may be better off with something else, or we may be better off without them. Linux has a price - you can use it compeltely free but we want any useful changes you might make. If everybody sat on their stuff, linux wouldn't be useful to you today. There are embedded developers who don't have a problem with writing GPL drivers. And there are embedded developers who don't need any special hardware driver. No _kernel_ change, no open-sourcing of company code. It was never a problem, and will never be a problem, to run proprietary user processes apps on a linux kernel. If you have a need for secret source code, stuff most of it in userspace. Make the drivers truly minimal; perhaps their open/closed status won't matter that much when the bulk of the code and the cleverness is kept safe in userspace. Note that keeping drivers small this way is the recommended way of working anyway. It isn't merely a way to keep your code away from the GPL - you always want a small kernel. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: Assuming these need not be GPL, I have a problem with EXPORT_SYMBOL_GPL and the general trend in the direction of making proprietary drivers harder on companies. Our drivers use basic interfaces in the kernel like open, read, write, ioctl, semaphores, interrupts, timers etc. This is functionality we would expect from any operating system. We used devfs before and had no problems there. Greg KH has gone and made the basic sysfs interface, which any generic driver could use as EXPORT_SYMBOL_GPL. I don't really care, I just don't use sysfs. The point is that old functionality is being ripped off and new ones introduced, and their interfaces are not open anymore. Hence there will be a point where non-GPLed drivers simply cannot be loaded. So why beat about the bush? Just make it illegal to load proprietary drivers, or remove EXPORT_SYMBOL_GPL. Those wo introduce EXPORT_SYMBOL_GPL are not in a position where they can make it illegal to load proprietary modules. They may want to, but they can't. The kernel has very many copyright holders, each decides for his own part only. Someone who didn't write the module interface or posix interface can't stop you there. Anti-proprietary folks then go and make new useful subsystems, and make sure those are accessed with EXPORT_SYMBOL_GPL only. Then they phase out the old interfaces as the new ones are clearly better, and the vast majority with GPL drivers have no problem with this. As long as there are developers with this attitude, expect EXPORT_SYMBOL_GPL to crop up in new places over time. Yes - this makes it harder (although not impossible) to distribute closed-source drivers. Which is exactly what these people want. When they are powerless to forbid such drivers, they settle for making them harder and harder to use instead. They want this trend to continue. There is an obvious way around it - you (and other people with an interest in closed-source drivers) can write contribute your own sysfs and whatever else you might need. Make it better than the existing sysfs so it actually gets into the kernel, replacing the existing stuff. And of course there will be no EXPORT_SYMBOL_GPL in it - since that is what you want to avoid. The price for this then, is to outcompete the proponents of GPL-only symbols. If you offer more and better source (under the GPL) then you can turn the trend and keep linux the way you want it. If you don't - those that do contribute will get to shape linux the way they like. Whoever makes linux gets to decide. Another way is to stay with linux 2.4. You won't get any new stuff that way, but no new GPL surprises either. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Tue, 2007-02-20 at 10:14 -0500, [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 12:00:51 +0100, Bernd Petrovitsch said: Flame bait alert: I heard a talk from an Austrian lawyer an according to his believes (and I don't know if he is the only one or if there lots of) one must see from the users view if the GPL spreads over or not (and the usual technical terms like linking are basically irrelevant). E.g.: - You are distributing an application which links against a GPL-library. If you provide a link and the user/customer has to get and install that library, your application can have any license you wish. - If you distribute an application and it installs automatically a library (e.g. from the CD where your application is installed), your applications license must fit wit the library license. So tell me - if RedHat distributes a non-GPL program that uses a GPL library that is included as part of the distribution, but *not* one that's usually installed, which rules apply? I'm well aware that there are (probably lots of) contradictions with this idea. IANAL and we must ask that lawyer actually for this. And he will probasbly do not understand the question since he very probably doesn't know all the usual software distribution methods. Even better - does this mean that I can *intentionally* bypass the licensing by including a installer script that removed a problematic library, and then forces the user to re-install it? A good question which belongs in the same category as above. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Tue, 20 Feb 2007 12:00:51 +0100, Bernd Petrovitsch said: Flame bait alert: I heard a talk from an Austrian lawyer an according to his believes (and I don't know if he is the only one or if there lots of) one must see from the users view if the GPL spreads over or not (and the usual technical terms like linking are basically irrelevant). E.g.: - You are distributing an application which links against a GPL-library. If you provide a link and the user/customer has to get and install that library, your application can have any license you wish. - If you distribute an application and it installs automatically a library (e.g. from the CD where your application is installed), your applications license must fit wit the library license. So tell me - if RedHat distributes a non-GPL program that uses a GPL library that is included as part of the distribution, but *not* one that's usually installed, which rules apply? Even better - does this mean that I can *intentionally* bypass the licensing by including a installer script that removed a problematic library, and then forces the user to re-install it? pgpYyXP1m6V0a.pgp Description: PGP signature
Re: GPL vs non-GPL device drivers
On Tue, 2007-02-20 15:36:56 +0100, Helge Hafting [EMAIL PROTECTED] wrote: If you have a need for secret source code, stuff most of it in userspace. Make the drivers truly minimal; perhaps their open/closed status won't matter that much when the bulk of the code and the cleverness is kept safe in userspace. Note that keeping drivers small this way is the recommended way of working anyway. It isn't merely a way to keep your code away from the GPL - you always want a small kernel. Keeping the legal stuff out of sight for a second, this'll solve the problem for the embedded developer, but surely not for the Linux community. Would you ever expect that eg. the thin GPL layer used by ATI/NVidia would be merged iff the rest would run in userland? It's just a workaround for the linking-the-object-file-into-the-kernel-image problem, but after all, it doesn't lead to a working driver being freely available. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of:If it doesn't work, force it. the second : If it breaks, it needed replacing anyway. signature.asc Description: Digital signature
Re: GPL vs non-GPL device drivers
Just in case anyone cares, after speaking with Michael for a few hours I've found he's not nearly as abrasive as this mailing list banter might suggest. He makes some good arguments once you stop him from spouting conspiracy stuff and, although I don't agree with all of them, I think he has some good points. He suggested posting a transcript of our chat but, frankly, I don't think anyone wants to read that. Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
You are trying to cram this in a simple yes or no box, and it just doesn't
fit. There are questions nobody knows the answers to (such as what rights
you need to distribute a derivative work or whether compiling code makes a
translation).
Thanks, all for the discussion. I certainly learnt a lot. I definitely
expected to be flamed and roasted for posting my original message, and
was not disappointed :)
I do not possess all the knowledge ("legal" and technical) that people
who have contributed to this discussion possess. However I will still
comment from a user's perspective, which was my original point.
Many companies in the embedded field still mistakenly feel (or felt
until a while ago) that Linux was not right for them. That they would
have to open source their code, that they would not get adequate
support, and that Linux was too big and heavy to perform well in an
embedded platform. People like me who were Linux Desktop junkies were
actually trying to convince companies of the opposite.
Now the popularity of Linux is exploding in the embedded space. Nobody
talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be
a worthwhile experiment to study this surge in popularity. I am not an
expert, but perhaps the reason is "it works so goddamn well and has a
wealth of third party FREE software". Sure its a bit of work to make
it work on our platform and we don't have to Enea or Windriver to
write our gripes to. But it definitely is worth it.
Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
does to this popularity. I don't know. I am just giving you my
opinion. The moment companies learn of something like this, alarm
bells start to go off. This is not rational. I personally have nothing
against open-sourcing all software. *But*, this is not how companies
think.
Let's think about why Linux became so popular and strive towards
keeping it that way instead of resorting to innovative ways of just
confusing a lot of people.
Having said this, I am committed to contribute back to the Linux
community in any way I can, not withstanding my present employer. Keep
up the good work guys!
DS
vj.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: GPL vs non-GPL device drivers
Combined responses > On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote: > > There is no legal meaning to "combining" two works of authorship under > > the Berne Convention or any national implementation thereof. If you > > "compile" or "collect" them, you're in one area of law, and if you > > create a work that "adapts" or "recasts" (or more generally "derives > > from") them, you're in another area of law. > As I said, you're having a purely semantic argument. When someone uses a term that can mean more than one possible thing and then uses the fact that it's true for one meaning to argue that it must be true for the other, what else can you do other than point out that the term they are using has multiple meanings? > Regardless of what you *call* it, shoving two works together does not > excuse you from the conditions of the license on one of those works, > *when you make a copy*. Nobody is arguing otherwise. Nobody is saying "you don't have to comply with the GPL". We're saying that the GPL doesn't mean what people think it means. In some cases it's because of the GPL's wording, but in other cases it's because the GPL cannot set its own scope. > And that's the GPL in a nutshell, if you want > to copy the work, you need a license, if you want a license, you must > abide the conditions, and one of the conditions is that you may not > combine it with a work that is under an incompatible license unless it > is mere aggregation. Right. And all the cases we are talking about are mere aggregation (that is, they do not create derivative works). > Of course, now you're going to argue that there's no such thing as an > "incompatible license" or "mere aggregation" and that these are just > words that were made up for the GPL, so they can be ignored.. another > pointless semantic argument because it doesn't change the very simple > fact that you don't have any rights to copy the work unless you have a > license and you don't have a license if you fail to abide the > conditions of the license. The issue is about what the license *means* and what its scope is. For example, if the license said "if you ever use a work that is subject to this license, you must place every work you create after that under the license", that would obviously not be enforceable. The question of the *scope* of the license is critical, and you can't read the license to understand its scope. > Hang on, you're actually debating that you have to abide by conditions > of a license before you can copy a copyright work? Well, there are certainly cases where you can. Necessary step, first sale, and fair use all provide possible situations where you can copy a copyrighted work without complying with the license. But more generally, the argument is over the scope of the license. The GPL doesn't restrict the distribution of mere aggregations not because the authors felt this was a wise decision, but because it *can't*. That is outside the GPL's power. So the question of what's a "mere aggregation" is a legal question about the scope of the GPL, and you have to look at law and case law to understand it, not the text of the GPL. The GPL grants you the permission to modify and distribute the original work if you distribute the source of the original work. The GPL also puts certain requirements on the distribution of derivative works. This is, as far as I can tell, the maximum of the scope it can have. You are trying to cram this in a simple yes or no box, and it just doesn't fit. There are questions nobody knows the answers to (such as what rights you need to distribute a derivative work or whether compiling code makes a translation). DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote: And for those reading along at home, _surely_ you understand the meanings of "ambiguities in an offer of contract must be construed against the offeror", "'derivative work' and 'license' are terms of art in copyright law", and "not a valid limitation of scope". If not, I highly recommend to you that master of exposition who goes by "Op. Cit.". You're really not helping yourself in making a convincing argument here. Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
