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
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 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 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 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 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 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 yo
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 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 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: somebody dropped a (warning) bomb
On Thursday 08 February 2007 19:42, Linus Torvalds wrote: > Most C types don't, and some you can't even tell (do pointers generate > "signed" or "unsigned" comparisons? I'll argue that a compiler that > generates signed comparisons for them is broken, but it tends to be > something you can only see with a standards- conforming proghram if you > can allocate memory across the sign boundary, which may or may not be > true..) And this is, because as Dennis Ritchie says in "The Development of the C Language" (http://cm.bell-labs.com/cm/cs/who/dmr/chist.html) C evolved from a typeless language, B - which, in turn, had originated as a stripped down version of BCPL. B and BCPL used a "cell addressing" scheme, but because of the move off the PDP-7, and the difficulties run into by Ken Thompson in rewriting the code for Unix in B (the original Unix was written in assembler) types were added - 'char' and 'int'. These represented the byte and word addressing modes of the PDP-11, and were needed because Ritchie was in the process of having the compiler generate assembler instead of "threaded code". This "NB" language, after also having data structures added and the rules for defining pointers finalized, was renamed "C" by Ritchie. So almost all the rules around the signs of types are because of a single, historical machine. Hence the rules about "char" being unsigned by default and "int" being signed by default are because of the nature of the PDP-11. The implementation defined nature of bitfields is because Dennis Ritchie had freedom there - the PDP-11 didn't have anything like them in the hardware and they were being stuffed in to make Thompsons life easier. Now: There is no reason for the behavior that came from the nature of the PDP11 to have survived, but because it was in "The White Book" it made it through the ANSI standardization process. Now that this history lesson is over... 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: somebody dropped a (warning) bomb
On Thursday 08 February 2007 19:42, Linus Torvalds wrote: snip Most C types don't, and some you can't even tell (do pointers generate signed or unsigned comparisons? I'll argue that a compiler that generates signed comparisons for them is broken, but it tends to be something you can only see with a standards- conforming proghram if you can allocate memory across the sign boundary, which may or may not be true..) And this is, because as Dennis Ritchie says in The Development of the C Language (http://cm.bell-labs.com/cm/cs/who/dmr/chist.html) C evolved from a typeless language, B - which, in turn, had originated as a stripped down version of BCPL. B and BCPL used a cell addressing scheme, but because of the move off the PDP-7, and the difficulties run into by Ken Thompson in rewriting the code for Unix in B (the original Unix was written in assembler) types were added - 'char' and 'int'. These represented the byte and word addressing modes of the PDP-11, and were needed because Ritchie was in the process of having the compiler generate assembler instead of threaded code. This NB language, after also having data structures added and the rules for defining pointers finalized, was renamed C by Ritchie. So almost all the rules around the signs of types are because of a single, historical machine. Hence the rules about char being unsigned by default and int being signed by default are because of the nature of the PDP-11. The implementation defined nature of bitfields is because Dennis Ritchie had freedom there - the PDP-11 didn't have anything like them in the hardware and they were being stuffed in to make Thompsons life easier. Now: There is no reason for the behavior that came from the nature of the PDP11 to have survived, but because it was in The White Book it made it through the ANSI standardization process. Now that this history lesson is over... 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: [PATCH] KVM: 'asm' operand has impossible constraints
On Saturday 27 January 2007 16:28, S.Çağlar Onur wrote: > 27 Oca 2007 Cts tarihinde, Avi Kivity şunları yazmıştı: > > The patch looks correct, but I don't understand the gcc error message. > > Are we sure this isn't a gcc 4.2 bug? > > > > "g" appears to be equivalent to "rmi", if "i" is impossible, gcc is free > > to use "r" or "m", no? > > Accorgind to GCC devs. its not a bug > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808), on comment #5 the > problem described like; > > "g" means "r"+"i" so the register allocator in the -O0 case is selecting > "r" while in the optimize case is selecting "i" Sounds like a bug to me! After all, shouldn't the different sections of code be selecting the *same* bits ? 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: [PATCH] KVM: 'asm' operand has impossible constraints
On Saturday 27 January 2007 16:28, S.Çağlar Onur wrote: 27 Oca 2007 Cts tarihinde, Avi Kivity şunları yazmıştı: The patch looks correct, but I don't understand the gcc error message. Are we sure this isn't a gcc 4.2 bug? g appears to be equivalent to rmi, if i is impossible, gcc is free to use r or m, no? Accorgind to GCC devs. its not a bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29808), on comment #5 the problem described like; g means r+i so the register allocator in the -O0 case is selecting r while in the optimize case is selecting i Sounds like a bug to me! After all, shouldn't the different sections of code be selecting the *same* bits ? 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: kernel + gcc 4.1 = several problems
On Tuesday 02 January 2007 18:24, you wrote: > On Tue, Jan 02, 2007 at 05:06:14PM -0500, D. Hazelton wrote: > > On Tuesday 02 January 2007 16:56, Alistair John Strachan wrote: > > > On Tuesday 02 January 2007 21:10, Adrian Bunk wrote: > > > [snip] > > > > > > > > > Comparing your report and [1], it seems that if these are the > > > > > > same problem, it's not a hardware bug but a gcc or kernel bug. > > > > > > > > > > This bug specifically indicates some kind of miscompilation in a > > > > > driver, causing boot time hangs. My problem is quite different, and > > > > > more subtle. The crash happens in the same place every time, which > > > > > does suggest determinism (even with various options toggled on and > > > > > off, and a 300K smaller kernel image), but it takes 8-12 hours to > > > > > manifest and only happens with GCC 4.1.1. ... > > > > > > > > Sorry if my point goes a bit away from your problem: > > > > > > > > My point is that we have several reported problems only visible > > > > with gcc 4.1. > > > > > > > > Other bug reports are e.g. [2] and [3], but they are only present > > > > with using gcc 4.1 _and_ using -Os. > > > > > > I find [2] most compelling, and I can confirm that I do have the same > > > problem with or without optimisation for size. I don't use selinux nor > > > has it ever been enabled. > > > > > > At any rate, I have absolute confirmation that it is GCC 4.1.1, because > > > with GCC 3.4.6 the same kernel I reported booting three days ago is > > > still cheerfully working. I regularly get uptimes of 60+ days on that > > > machine, rebooting only for kernel upgrades. 2.6.19 seems to be no > > > worse in this regard. > > > > > > Perhaps fortunately, the configs I've tried have consistently failed to > > > shake the crash, so I have a semi-reproducible test case here on C3-2 > > > hardware if somebody wants to investigate the problem (though it still > > > takes 6-12 hours). > > > > The GCC code generator appears to have been rewritten between 3.4.6 and > > 4.1.1 > > > > I took a look at the dump he posted and there are some minor and some > > massive differences between the code. In one case some of the code is > > swapped, in another there is code in the 3.4.6 version that isn't in the > > 4.1.1... Finally the 4.1.1 version of the function has what appears to be > > function calls and these don't appear in the code generated by 3.4.6 > > Differences are expected since we disable unit-at-a-time for gcc < 4 > and gcc development didn't stall between 3.4 and 4.1. Okay. Thing is that these noted differences, aside from where 4.1.1 doesn't generate an opcode that 3.4.6 does aren't all that fatal, IMHO. The fact that there it does generate call's rather than jumps for local pointer moves (IIRC - been a while since I looked at the dump of pipe_poll that he provided) might be part of the problem > > In other words - the code generation for 4.1.1 appears to be broken when > > it comes to generating system code. > > Bug number for an either already open or created by you bug in the gcc > Bugzilla for what you claim to be a bug in gcc? None. I didn't file a report on this because I didn't find the big, just noted a problem that appears to occur. In this case the call's generated seem to wrap loops - something I've never heard of anyone doing. These *might* be causing the off-by-one that is causing the function to re-enter in the middle of an instruction. Seeing this I'd guess that this follows for all system-level code generated by 4.1.1 and this is exactly what I was reporting. If you'd like I'll go dig up the dumps he posted and post the two related segments side-by-side to give you a better example what I'm referring to. 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: kernel + gcc 4.1 = several problems
On Tuesday 02 January 2007 16:56, Alistair John Strachan wrote: > On Tuesday 02 January 2007 21:10, Adrian Bunk wrote: > [snip] > > > > > Comparing your report and [1], it seems that if these are the same > > > > problem, it's not a hardware bug but a gcc or kernel bug. > > > > > > This bug specifically indicates some kind of miscompilation in a > > > driver, causing boot time hangs. My problem is quite different, and > > > more subtle. The crash happens in the same place every time, which does > > > suggest determinism (even with various options toggled on and off, and > > > a 300K smaller kernel image), but it takes 8-12 hours to manifest and > > > only happens with GCC 4.1.1. ... > > > > Sorry if my point goes a bit away from your problem: > > > > My point is that we have several reported problems only visible > > with gcc 4.1. > > > > Other bug reports are e.g. [2] and [3], but they are only present with > > using gcc 4.1 _and_ using -Os. > > I find [2] most compelling, and I can confirm that I do have the same > problem with or without optimisation for size. I don't use selinux nor has > it ever been enabled. > > At any rate, I have absolute confirmation that it is GCC 4.1.1, because > with GCC 3.4.6 the same kernel I reported booting three days ago is still > cheerfully working. I regularly get uptimes of 60+ days on that machine, > rebooting only for kernel upgrades. 2.6.19 seems to be no worse in this > regard. > > Perhaps fortunately, the configs I've tried have consistently failed to > shake the crash, so I have a semi-reproducible test case here on C3-2 > hardware if somebody wants to investigate the problem (though it still > takes 6-12 hours). The GCC code generator appears to have been rewritten between 3.4.6 and 4.1.1 I took a look at the dump he posted and there are some minor and some massive differences between the code. In one case some of the code is swapped, in another there is code in the 3.4.6 version that isn't in the 4.1.1... Finally the 4.1.1 version of the function has what appears to be function calls and these don't appear in the code generated by 3.4.6 In other words - the code generation for 4.1.1 appears to be broken when it comes to generating system 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: kernel + gcc 4.1 = several problems
On Tuesday 02 January 2007 16:56, Alistair John Strachan wrote: On Tuesday 02 January 2007 21:10, Adrian Bunk wrote: [snip] Comparing your report and [1], it seems that if these are the same problem, it's not a hardware bug but a gcc or kernel bug. This bug specifically indicates some kind of miscompilation in a driver, causing boot time hangs. My problem is quite different, and more subtle. The crash happens in the same place every time, which does suggest determinism (even with various options toggled on and off, and a 300K smaller kernel image), but it takes 8-12 hours to manifest and only happens with GCC 4.1.1. ... Sorry if my point goes a bit away from your problem: My point is that we have several reported problems only visible with gcc 4.1. Other bug reports are e.g. [2] and [3], but they are only present with using gcc 4.1 _and_ using -Os. I find [2] most compelling, and I can confirm that I do have the same problem with or without optimisation for size. I don't use selinux nor has it ever been enabled. At any rate, I have absolute confirmation that it is GCC 4.1.1, because with GCC 3.4.6 the same kernel I reported booting three days ago is still cheerfully working. I regularly get uptimes of 60+ days on that machine, rebooting only for kernel upgrades. 2.6.19 seems to be no worse in this regard. Perhaps fortunately, the configs I've tried have consistently failed to shake the crash, so I have a semi-reproducible test case here on C3-2 hardware if somebody wants to investigate the problem (though it still takes 6-12 hours). The GCC code generator appears to have been rewritten between 3.4.6 and 4.1.1 I took a look at the dump he posted and there are some minor and some massive differences between the code. In one case some of the code is swapped, in another there is code in the 3.4.6 version that isn't in the 4.1.1... Finally the 4.1.1 version of the function has what appears to be function calls and these don't appear in the code generated by 3.4.6 In other words - the code generation for 4.1.1 appears to be broken when it comes to generating system 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: kernel + gcc 4.1 = several problems
On Tuesday 02 January 2007 18:24, you wrote: On Tue, Jan 02, 2007 at 05:06:14PM -0500, D. Hazelton wrote: On Tuesday 02 January 2007 16:56, Alistair John Strachan wrote: On Tuesday 02 January 2007 21:10, Adrian Bunk wrote: [snip] Comparing your report and [1], it seems that if these are the same problem, it's not a hardware bug but a gcc or kernel bug. This bug specifically indicates some kind of miscompilation in a driver, causing boot time hangs. My problem is quite different, and more subtle. The crash happens in the same place every time, which does suggest determinism (even with various options toggled on and off, and a 300K smaller kernel image), but it takes 8-12 hours to manifest and only happens with GCC 4.1.1. ... Sorry if my point goes a bit away from your problem: My point is that we have several reported problems only visible with gcc 4.1. Other bug reports are e.g. [2] and [3], but they are only present with using gcc 4.1 _and_ using -Os. I find [2] most compelling, and I can confirm that I do have the same problem with or without optimisation for size. I don't use selinux nor has it ever been enabled. At any rate, I have absolute confirmation that it is GCC 4.1.1, because with GCC 3.4.6 the same kernel I reported booting three days ago is still cheerfully working. I regularly get uptimes of 60+ days on that machine, rebooting only for kernel upgrades. 2.6.19 seems to be no worse in this regard. Perhaps fortunately, the configs I've tried have consistently failed to shake the crash, so I have a semi-reproducible test case here on C3-2 hardware if somebody wants to investigate the problem (though it still takes 6-12 hours). The GCC code generator appears to have been rewritten between 3.4.6 and 4.1.1 I took a look at the dump he posted and there are some minor and some massive differences between the code. In one case some of the code is swapped, in another there is code in the 3.4.6 version that isn't in the 4.1.1... Finally the 4.1.1 version of the function has what appears to be function calls and these don't appear in the code generated by 3.4.6 Differences are expected since we disable unit-at-a-time for gcc 4 and gcc development didn't stall between 3.4 and 4.1. Okay. Thing is that these noted differences, aside from where 4.1.1 doesn't generate an opcode that 3.4.6 does aren't all that fatal, IMHO. The fact that there it does generate call's rather than jumps for local pointer moves (IIRC - been a while since I looked at the dump of pipe_poll that he provided) might be part of the problem In other words - the code generation for 4.1.1 appears to be broken when it comes to generating system code. Bug number for an either already open or created by you bug in the gcc Bugzilla for what you claim to be a bug in gcc? None. I didn't file a report on this because I didn't find the big, just noted a problem that appears to occur. In this case the call's generated seem to wrap loops - something I've never heard of anyone doing. These *might* be causing the off-by-one that is causing the function to re-enter in the middle of an instruction. Seeing this I'd guess that this follows for all system-level code generated by 4.1.1 and this is exactly what I was reporting. If you'd like I'll go dig up the dumps he posted and post the two related segments side-by-side to give you a better example what I'm referring to. 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: Happy Birthday to Our Fearless Leader
On Wednesday 27 December 2006 18:39, David R. Meyer wrote: > I hope it doesn't get me kicked off the list for unnecessary traffic, > but Happy Birthday Linus. Thanks for making computing fun again > > Dave > Oh, wow, I totally missed the initial post. Happy Birthday, Linus! DRH > Loye Young wrote: > > Be it remembered that on the 28th day of December in the year of our Lord > > 1969, there was born in the town of Helsinki, Finland, Linus Benedict > > Torvalds. > > > > Long live the king. > > > > - > > 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/ - 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: Happy Birthday to Our Fearless Leader
On Wednesday 27 December 2006 18:39, David R. Meyer wrote: I hope it doesn't get me kicked off the list for unnecessary traffic, but Happy Birthday Linus. Thanks for making computing fun again Dave Oh, wow, I totally missed the initial post. Happy Birthday, Linus! DRH Loye Young wrote: Be it remembered that on the 28th day of December in the year of our Lord 1969, there was born in the town of Helsinki, Finland, Linus Benedict Torvalds. Long live the king. - 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/ - 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: [Alsa-devel] HDA Intel sound driver fails on Acer notebook
On Tuesday 19 December 2006 20:48, tony mancill wrote: > FWIW, using pci=noacpi seems to break the USB controller on this laptop. > I get "device not accepting address xx, error -110. Strange. I'm using an Acer Aspire 1640Z and the sound works perfectly. Of course Kubuntu was the only distro I could find that did OOB, but that's besides the point. In a quick look through /etc on my laptop I wasn't able to see how they do this. But after doing a quick check on Google the reports vary from this being a patched bug in ALSA to being easily solved by ensuring that the needed sound modules are loaded in the proper order. An alternate solution to this is to load the snd-hda-intel module with the parameter "model=laptop" > In addition, neither the onboard nor the wireless NIC work anymore with > this option. For the onboard, you see that the link is up, but then > get "NETDEV WATCHDOG: eth0: transmit timed out." > > acpi=off is worse - the boot hangs trying to load acpi/thermal.ko. >From personal experience I can say that ACPI is needed for Acer notebooks with the centrino chipset to function properly. > I've tested with both 1.0.13 and and 1.0.14rc1. I don't get exactly > the same kernel logging (I'm using a Debian 2.6.18 kernel), but kern.log > contains: I had the same problem when I tried Debian on this laptop. I don't recommend it for laptops, since there are several common pieces of hardware found on laptops that need firmware not shipped by Debian. This includes the ipw2200 firmware - which most Acer laptops need, because they ship with that wireless card. > Dec 19 17:39:43 maus kernel: : hda_codec: invalid dep_range_val 0:7fff > Dec 19 17:39:43 maus kernel: ALSA > /home/tony/alsa-driver-1.0.14rc1/pci/hda/hda_codec.c:216: hda_codec: > invalid dep_range_val 0:7fff Dec 19 17:39:43 maus last message repeated 279 > times > Dec 19 17:39:43 maus kernel: hda_codec: num_steps = 0 for NID=0xd > Dec 19 17:39:43 maus kernel: hda_codec: num_steps = 0 for NID=0x9 > Dec 19 17:39:43 maus kernel: hda_codec: num_steps = 0 for NID=0xd > Dec 19 17:39:43 maus last message repeated 20 times > Dec 19 17:39:43 maus kernel: hda_codec: num_steps = 0 for NID=0x9 > > Thanks in advance for any assistance. I hope you enjoyed your > vacation. > > Thanks, > tony > > Takashi Iwai wrote: > > Hi, > > > > sorry for the late reply since I've been on vacation. > > > > At Sun, 3 Dec 2006 02:30:34 -0500, > > > > Chuck Ebbert wrote: > >> The HDA Intel sound driver still fails to load on my Acer Aspire 5102 > >> notebook (Turion64 X2, ATI chipset): > >> > >> Here is the PCI info while running x86_64. I tried i386 and x86_64 and > >> it fails on both: > >> > >> 00:14.2 Audio device: ATI Technologies Inc Unknown device 437b (rev 01) > >> Subsystem: Acer Incorporated [ALI] Unknown device 009f > >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > >> ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- > >> ParErr- DEVSEL=slow >TAbort- SERR- >> 64, Cache Line Size 08 > >> Interrupt: pin ? routed to IRQ 16 > >> Region 0: Memory at c000 (64-bit, non-prefetchable) > >> [size=16K] Capabilities: [50] Power Management version 2 > >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA > >> PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 > >> PME- > >> Capabilities: [60] Message Signalled Interrupts: 64bit+ > >> Queue=0/0 Enable- Address: Data: > >> 00: 02 10 7b 43 06 00 10 04 01 00 03 04 08 40 00 00 > >> 10: 04 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 > >> 20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 9f 00 > >> 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 00 00 00 > >> 40: 00 00 02 40 00 00 00 00 00 00 00 00 00 00 00 00 > >> 50: 01 60 42 c8 00 00 00 00 00 00 00 00 00 00 00 00 > >> 60: 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> > >> On i386 I get this after doing > >> insmod snd-hda-codec.ko ; insmod snd-hda-intel.ko > >> > >> Dec 1 17:38:29 ac kernel: ACPI: PCI Interrupt :00:14.2[A] -> GSI 16 > >> (level, low) -> IRQ 18 Dec 1 17:38:29 ac kernel: codec_mask = 0xb > >> Dec 1 17:38:30 ac kernel: hda_codec: PCI 1025:9f, codec config 5 is > >> selected Dec 1 17:38:31 ac kernel: hda_intel: azx_get_response timeout, > >> switching to polling mode... Dec 1 17:38:32 ac kernel: hda_intel: > >> azx_get_response timeout, switching to single_cmd mode... > > > > These messages are scary. It
Re: [Alsa-devel] HDA Intel sound driver fails on Acer notebook
On Tuesday 19 December 2006 20:48, tony mancill wrote: FWIW, using pci=noacpi seems to break the USB controller on this laptop. I get device not accepting address xx, error -110. Strange. I'm using an Acer Aspire 1640Z and the sound works perfectly. Of course Kubuntu was the only distro I could find that did OOB, but that's besides the point. In a quick look through /etc on my laptop I wasn't able to see how they do this. But after doing a quick check on Google the reports vary from this being a patched bug in ALSA to being easily solved by ensuring that the needed sound modules are loaded in the proper order. An alternate solution to this is to load the snd-hda-intel module with the parameter model=laptop In addition, neither the onboard nor the wireless NIC work anymore with this option. For the onboard, you see that the link is up, but then get NETDEV WATCHDOG: eth0: transmit timed out. acpi=off is worse - the boot hangs trying to load acpi/thermal.ko. From personal experience I can say that ACPI is needed for Acer notebooks with the centrino chipset to function properly. I've tested with both 1.0.13 and and 1.0.14rc1. I don't get exactly the same kernel logging (I'm using a Debian 2.6.18 kernel), but kern.log contains: I had the same problem when I tried Debian on this laptop. I don't recommend it for laptops, since there are several common pieces of hardware found on laptops that need firmware not shipped by Debian. This includes the ipw2200 firmware - which most Acer laptops need, because they ship with that wireless card. Dec 19 17:39:43 maus kernel: : hda_codec: invalid dep_range_val 0:7fff Dec 19 17:39:43 maus kernel: ALSA /home/tony/alsa-driver-1.0.14rc1/pci/hda/hda_codec.c:216: hda_codec: invalid dep_range_val 0:7fff Dec 19 17:39:43 maus last message repeated 279 times Dec 19 17:39:43 maus kernel: hda_codec: num_steps = 0 for NID=0xd Dec 19 17:39:43 maus kernel: hda_codec: num_steps = 0 for NID=0x9 Dec 19 17:39:43 maus kernel: hda_codec: num_steps = 0 for NID=0xd Dec 19 17:39:43 maus last message repeated 20 times Dec 19 17:39:43 maus kernel: hda_codec: num_steps = 0 for NID=0x9 Thanks in advance for any assistance. I hope you enjoyed your vacation. Thanks, tony Takashi Iwai wrote: Hi, sorry for the late reply since I've been on vacation. At Sun, 3 Dec 2006 02:30:34 -0500, Chuck Ebbert wrote: The HDA Intel sound driver still fails to load on my Acer Aspire 5102 notebook (Turion64 X2, ATI chipset): Here is the PCI info while running x86_64. I tried i386 and x86_64 and it fails on both: 00:14.2 Audio device: ATI Technologies Inc Unknown device 437b (rev 01) Subsystem: Acer Incorporated [ALI] Unknown device 009f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort- SERR- PERR- Latency: 64, Cache Line Size 08 Interrupt: pin ? routed to IRQ 16 Region 0: Memory at c000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: Data: 00: 02 10 7b 43 06 00 10 04 01 00 03 04 08 40 00 00 10: 04 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 9f 00 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 00 00 00 40: 00 00 02 40 00 00 00 00 00 00 00 00 00 00 00 00 50: 01 60 42 c8 00 00 00 00 00 00 00 00 00 00 00 00 60: 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 On i386 I get this after doing insmod snd-hda-codec.ko ; insmod snd-hda-intel.ko Dec 1 17:38:29 ac kernel: ACPI: PCI Interrupt :00:14.2[A] - GSI 16 (level, low) - IRQ 18 Dec 1 17:38:29 ac kernel: codec_mask = 0xb Dec 1 17:38:30 ac kernel: hda_codec: PCI 1025:9f, codec config 5 is selected Dec 1 17:38:31 ac kernel: hda_intel: azx_get_response timeout, switching to polling mode... Dec 1 17:38:32 ac kernel: hda_intel: azx_get_response timeout, switching to single_cmd mode... These messages are scary. It means that the communication between the controller chip and the codec chip doesn't work, usually incorrect IRQ handling, and often due to broken BIOS or ACPI
Re: GPL only modules
On Monday 18 December 2006 12:16, David Schwartz wrote: > Combined responses to save bandwidth and reduce the number of times people > have to press "d". > > > Agreed. You missed the point. > > I don't understand how you could lead with "agreed" and then proceed to > completely ignore the entire point I just made. I *initially* thought you had missed the point. After your later post clarifying things I saw that my statement had been in error and that I did agree with you completely. > > Since the Linux Kernel header files > > contain a > > chunk of the source code for the kernel in the form of the macros > > for locking > > et. al. then using the headers - including that code in your > > module - makes > > it a derivative work. > > No, it does not. The header files are purely function and not expressive in > this case. Copyright only protects one choice among many equally-practical > choices for expressing the same idea or performing the same function. In this case, well. We aren't talking Copyright, but the license under which the software is distributed. According to the USPTO placing a statement such as (c) 2006 Pornrat Watanabe on a work you have created automatially places it under a copyright. The kernel source code, copyrighted as it is, is then distributed under the terms of the GNU GPL. Using the code from the header files may not make the module a derivative, but it is including parts of a copyrighted work. By *NOT* complying with the license under which said copyrighted work is distributed, you are giving up your rights under the license. This doesn't negate any problems with people making Blob drivers, because, as you pointed out, under the same laws they aren't a derivative work, which means that that clause of the license doesn't apply. Now if the GPL contained a clause specifically defining what it considered a derivative work things would be different. > > Actually, thinking about it, the way a Linux driver module works actually > > seems to make *ANY* driver a derivative work, because they are > > loaded into > > the kernels memory space and cannot function without having that done. > > If every practical way of expressing an idea contains something, then that > something is *not* protectable when used to express an idea of that kind. Not what I was saying. There are any number of ways to make a driver function - the FUSE system has shown that clearly. But by making that driver one that is loaded directly into the kernels memory space... It's that act that *I* *FEEL* makes it a derivative work. > > *IF* the "Usermode Driver" interface that is being worked on ever proves > > useful then, and only then, could you consider it *NOT* a > > derivative work. > > Because then the only thing it is using *IS* an interface, not complete > > chunks of the source as generated when the pre-processor finishes running > > through the file. > > No, you have it completely backwards. No, you missed my point. I was saying that the Usermode Driver interface would make the current style of kernel modules fully derivative works. This being because they are using an open system interface and *NOT* including code distributed with the kernel. > If a usermode driver interface was equally practical to develop a > particular type of driver, then using the kernel headers would make the > driver a derivative work. Because, in that case, the choice to use the > kernel headers would be a creative choice -- one chosen method among many > equally practical one. And this is what I was saying. Perhaps I didn't state it in clear and concise english. > Copyright only protects creative choices, not purely functional ones. > > "A Linux 2.6 driver for the ATI X800 graphics chipset" is an idea. If the > only reasonably practical way to express that idea is with the Linux kernel > header files, then using the Linux kernel header files is scenes a fair, > not protected content. Okay. I understood this back at the start of your reply. > DS Okay, after a lot of thought and me realizing some mistakes I had made in interpreting the law and legal precedents I see we are on the same page. 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 only modules
On Monday 18 December 2006 20:35, David Schwartz wrote: > > For both static and dynamic linking, you might claim the output is an > > aggregate, but that doesn't matter. What matters is whether or not > > the output is a work based on the program, and whether the "mere > > aggregation" paragraph kicks in. > > > > If the output is not an aggregate, which is quite likely to be > > the case for dynamic linking, and quite possibly also for many static > > linking cases, then the "mere aggregation" paragraph of clause 2 does > > not kick in. > > > > If the output is indeed an aggregate, as it may quite likely be in the > > case of static linking, then the "mere aggregation" considerations of > > clause 2 may kick in and enable the 'anything else' to not be brought > > under the scope of the license. You still need permission to > > distribute the whole. The GPL asserts its non-interference with your > > ability to distribute the separate portion separately, under whatever > > license you can, as long as it's not a derived work from the GPL > > portion. > > No! > > It makes no difference whether the "mere aggregation" paragraph kicks in > because the "mere aggregation" paragraph is *explaining* the *law*. What > matters is what the law actually *says*. > > We are talking about what works are within the GPL's scope. The text of the > GPL does not matter because the GPL does not set its own scope, copyright > law does. > > The GPL could say that if you ever see the source code to a GPL'd work, > every work you ever write must be placed under the GPL. But that wouldn't > make it true, because that would be a requirement outside the GPL's scope. > > We are talking about works are inside the GPL's legal scope, and in that > case, nothing the GPL says can enlarge the scope. > > DS Actually, after rereading the GPLv2 because of this discussion I came to a most surprising conclusion. While there are *IMPLICIT* and *EXPLICIT* copyrights on the code, they have no bearing on the text of the GPL. The GPL is a License that covers how the code may be used, modified and distributed. This is the reason that the FSF people had to make the big exception for Bison, because the parser skeleton is such an integral part of Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the program) that truthfully, any parser built using Bison is a derivative work of code released under the GPL. That said, since there is a distribution, use and modification license on the Linux Kernel - the GPLv2 - there are those extra restrictions on the code *OUTSIDE* the copyright rules. 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 only modules
On Monday 18 December 2006 14:41, Alexandre Oliva wrote: > On Dec 17, 2006, Kyle Moffett <[EMAIL PROTECTED]> wrote: > > On the other hand, certain projects like OpenAFS, while not license- > > compatible, are certainly not derivative works. > > Certainly a big chunk of OpenAFS might not be, just like a big chunk > of other non-GPL drivers for Linux. > > But what about the glue code? Can that be defended as not a derived > work, such that it doesn't have to be GPL? That has never been an issue, really. Its what 99% of the binary drivers believe - hence the reason that there is the user-compiled component to all of them. > If not, can the whole containing both the non-derivative work and the > source code providing the glue without which the whole wouldn't > fulfill its intended purpose be regarded as a mere aggregate, and thus > not be subject to the requirement that the whole be released under the > GPL? The view that binary vendors take is "Linking does not create a derived work" - regardless of the fact that you cannot have a complete compiled program or module *WITHOUT* that linking. However I have a feeling that the lawyers in the employ of the companies that ship BLOB drivers say that all they need to do to comply with the GPL is to ship the glue-code in source form. And I have to admit that this does seem to comply with the GPL - to the letter, if not the spirit. 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 only modules
On Monday 18 December 2006 10:47, Dave Neuer wrote: > On 12/17/06, D. Hazelton <[EMAIL PROTECTED]> wrote: > > On Sunday 17 December 2006 16:32, David Schwartz wrote: > > > > I would argue that this is _particularly_ pertinent with regards to > > > > Linux. For example, if you look at many of our atomics or locking > > > > operations a good number of them (depending on architecture and > > > > version) are inline assembly that are directly output into the code > > > > which uses them. As a result any binary module which uses those > > > > functions from the Linux headers is fairly directly a derivative work > > > > of the GPL headers because it contains machine code translated > > > > literally from GPLed assembly code found therein. There are also a > > > > fair number of large perhaps-wrongly inline functions of which the > > > > use of any one would be likely to make the resulting binary > > > > "derivative". > > > > > > That's not protectable expression under United States law. See Lexmark > > > v. Static Controls and the analogous case of the TLP (ignore the DMCA > > > stuff in that case, that's not relevant). If you want to make that kind > > > of content protectable, you have to get it out of the header files. > > > > > > You cannot protect, by copyright, every reasonably practical way of > > > performing a function. Only a patent can do that. If taking something > > > is reasonably necessary to express a particular idea (and a Linux > > > module for the ATI X850 card is an idea), then that something cannot be > > > protected by copyright when it is used to express that idea. (Even if > > > it would clearly be protectably expression in another context.) > > > > > > The premise of copyright is that there are millions of equally-good > > > ways to express the same idea or perform the same function, and you > > > creatively pick one, and that choice is protected. But if I'm > > > developing a Linux module for a particular network card, choosing to > > > use the Linux kernel header files is the only practical choice to > > > perform that particular function. So their content is not protectable > > > when used in that context. (If you make another way to do it, then the > > > content becomes protectable in that context again.) > > > > > > IANAL. > > > > > > DS > > > > Agreed. You missed the point. Since the Linux Kernel header files contain > > a chunk of the source code for the kernel in the form of the macros for > > locking et. al. then using the headers - including that code in your > > module - makes it a derivative work. > > David didn't miss the point; Lexmark vs. Static Controls, however > unintuitively, ruled that even _verbatim_ copying is not always > copyright infringement in the case of software because of issues like > the doctrine of scenes a faire. In the case of spinlocks, if the only > way to accomplish atomic operations on an architecture is to use > something like the assembler that the inclusion of spinlock.h injects > into your binary, then according to Lexmark vs. Static Controls that > makes that included code unprotectable by copyright. Ah, okay. However I'm quite sure that there are more ways to accomplish the tasks handled by the code in the header files (in most cases). > Where I disagree with David (as I have publicly before on this list), > is that he incorrectly applies the concept of "functional idea" to > "write a linux kernel module." I don't believe that is a "functional > idea" in the sense that is meaningful in the context of software > copyright or patents (at least until someone writes a piece of > software that writes kernel modules). Agreed. And thanks for clarifying that. 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 only modules
On Monday 18 December 2006 10:47, Dave Neuer wrote: On 12/17/06, D. Hazelton [EMAIL PROTECTED] wrote: On Sunday 17 December 2006 16:32, David Schwartz wrote: I would argue that this is _particularly_ pertinent with regards to Linux. For example, if you look at many of our atomics or locking operations a good number of them (depending on architecture and version) are inline assembly that are directly output into the code which uses them. As a result any binary module which uses those functions from the Linux headers is fairly directly a derivative work of the GPL headers because it contains machine code translated literally from GPLed assembly code found therein. There are also a fair number of large perhaps-wrongly inline functions of which the use of any one would be likely to make the resulting binary derivative. That's not protectable expression under United States law. See Lexmark v. Static Controls and the analogous case of the TLP (ignore the DMCA stuff in that case, that's not relevant). If you want to make that kind of content protectable, you have to get it out of the header files. You cannot protect, by copyright, every reasonably practical way of performing a function. Only a patent can do that. If taking something is reasonably necessary to express a particular idea (and a Linux module for the ATI X850 card is an idea), then that something cannot be protected by copyright when it is used to express that idea. (Even if it would clearly be protectably expression in another context.) The premise of copyright is that there are millions of equally-good ways to express the same idea or perform the same function, and you creatively pick one, and that choice is protected. But if I'm developing a Linux module for a particular network card, choosing to use the Linux kernel header files is the only practical choice to perform that particular function. So their content is not protectable when used in that context. (If you make another way to do it, then the content becomes protectable in that context again.) IANAL. DS Agreed. You missed the point. Since the Linux Kernel header files contain a chunk of the source code for the kernel in the form of the macros for locking et. al. then using the headers - including that code in your module - makes it a derivative work. David didn't miss the point; Lexmark vs. Static Controls, however unintuitively, ruled that even _verbatim_ copying is not always copyright infringement in the case of software because of issues like the doctrine of scenes a faire. In the case of spinlocks, if the only way to accomplish atomic operations on an architecture is to use something like the assembler that the inclusion of spinlock.h injects into your binary, then according to Lexmark vs. Static Controls that makes that included code unprotectable by copyright. Ah, okay. However I'm quite sure that there are more ways to accomplish the tasks handled by the code in the header files (in most cases). Where I disagree with David (as I have publicly before on this list), is that he incorrectly applies the concept of functional idea to write a linux kernel module. I don't believe that is a functional idea in the sense that is meaningful in the context of software copyright or patents (at least until someone writes a piece of software that writes kernel modules). Agreed. And thanks for clarifying that. 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 only modules
On Monday 18 December 2006 14:41, Alexandre Oliva wrote: On Dec 17, 2006, Kyle Moffett [EMAIL PROTECTED] wrote: On the other hand, certain projects like OpenAFS, while not license- compatible, are certainly not derivative works. Certainly a big chunk of OpenAFS might not be, just like a big chunk of other non-GPL drivers for Linux. But what about the glue code? Can that be defended as not a derived work, such that it doesn't have to be GPL? That has never been an issue, really. Its what 99% of the binary drivers believe - hence the reason that there is the user-compiled component to all of them. If not, can the whole containing both the non-derivative work and the source code providing the glue without which the whole wouldn't fulfill its intended purpose be regarded as a mere aggregate, and thus not be subject to the requirement that the whole be released under the GPL? The view that binary vendors take is Linking does not create a derived work - regardless of the fact that you cannot have a complete compiled program or module *WITHOUT* that linking. However I have a feeling that the lawyers in the employ of the companies that ship BLOB drivers say that all they need to do to comply with the GPL is to ship the glue-code in source form. And I have to admit that this does seem to comply with the GPL - to the letter, if not the spirit. 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 only modules
On Monday 18 December 2006 20:35, David Schwartz wrote: For both static and dynamic linking, you might claim the output is an aggregate, but that doesn't matter. What matters is whether or not the output is a work based on the program, and whether the mere aggregation paragraph kicks in. If the output is not an aggregate, which is quite likely to be the case for dynamic linking, and quite possibly also for many static linking cases, then the mere aggregation paragraph of clause 2 does not kick in. If the output is indeed an aggregate, as it may quite likely be in the case of static linking, then the mere aggregation considerations of clause 2 may kick in and enable the 'anything else' to not be brought under the scope of the license. You still need permission to distribute the whole. The GPL asserts its non-interference with your ability to distribute the separate portion separately, under whatever license you can, as long as it's not a derived work from the GPL portion. No! It makes no difference whether the mere aggregation paragraph kicks in because the mere aggregation paragraph is *explaining* the *law*. What matters is what the law actually *says*. We are talking about what works are within the GPL's scope. The text of the GPL does not matter because the GPL does not set its own scope, copyright law does. The GPL could say that if you ever see the source code to a GPL'd work, every work you ever write must be placed under the GPL. But that wouldn't make it true, because that would be a requirement outside the GPL's scope. We are talking about works are inside the GPL's legal scope, and in that case, nothing the GPL says can enlarge the scope. DS Actually, after rereading the GPLv2 because of this discussion I came to a most surprising conclusion. While there are *IMPLICIT* and *EXPLICIT* copyrights on the code, they have no bearing on the text of the GPL. The GPL is a License that covers how the code may be used, modified and distributed. This is the reason that the FSF people had to make the big exception for Bison, because the parser skeleton is such an integral part of Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the program) that truthfully, any parser built using Bison is a derivative work of code released under the GPL. That said, since there is a distribution, use and modification license on the Linux Kernel - the GPLv2 - there are those extra restrictions on the code *OUTSIDE* the copyright rules. 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 only modules
On Monday 18 December 2006 12:16, David Schwartz wrote: Combined responses to save bandwidth and reduce the number of times people have to press d. Agreed. You missed the point. I don't understand how you could lead with agreed and then proceed to completely ignore the entire point I just made. I *initially* thought you had missed the point. After your later post clarifying things I saw that my statement had been in error and that I did agree with you completely. Since the Linux Kernel header files contain a chunk of the source code for the kernel in the form of the macros for locking et. al. then using the headers - including that code in your module - makes it a derivative work. No, it does not. The header files are purely function and not expressive in this case. Copyright only protects one choice among many equally-practical choices for expressing the same idea or performing the same function. In this case, well. We aren't talking Copyright, but the license under which the software is distributed. According to the USPTO placing a statement such as (c) 2006 Pornrat Watanabe on a work you have created automatially places it under a copyright. The kernel source code, copyrighted as it is, is then distributed under the terms of the GNU GPL. Using the code from the header files may not make the module a derivative, but it is including parts of a copyrighted work. By *NOT* complying with the license under which said copyrighted work is distributed, you are giving up your rights under the license. This doesn't negate any problems with people making Blob drivers, because, as you pointed out, under the same laws they aren't a derivative work, which means that that clause of the license doesn't apply. Now if the GPL contained a clause specifically defining what it considered a derivative work things would be different. Actually, thinking about it, the way a Linux driver module works actually seems to make *ANY* driver a derivative work, because they are loaded into the kernels memory space and cannot function without having that done. If every practical way of expressing an idea contains something, then that something is *not* protectable when used to express an idea of that kind. Not what I was saying. There are any number of ways to make a driver function - the FUSE system has shown that clearly. But by making that driver one that is loaded directly into the kernels memory space... It's that act that *I* *FEEL* makes it a derivative work. *IF* the Usermode Driver interface that is being worked on ever proves useful then, and only then, could you consider it *NOT* a derivative work. Because then the only thing it is using *IS* an interface, not complete chunks of the source as generated when the pre-processor finishes running through the file. No, you have it completely backwards. No, you missed my point. I was saying that the Usermode Driver interface would make the current style of kernel modules fully derivative works. This being because they are using an open system interface and *NOT* including code distributed with the kernel. If a usermode driver interface was equally practical to develop a particular type of driver, then using the kernel headers would make the driver a derivative work. Because, in that case, the choice to use the kernel headers would be a creative choice -- one chosen method among many equally practical one. And this is what I was saying. Perhaps I didn't state it in clear and concise english. Copyright only protects creative choices, not purely functional ones. A Linux 2.6 driver for the ATI X800 graphics chipset is an idea. If the only reasonably practical way to express that idea is with the Linux kernel header files, then using the Linux kernel header files is scenes a fair, not protected content. Okay. I understood this back at the start of your reply. snip DS Okay, after a lot of thought and me realizing some mistakes I had made in interpreting the law and legal precedents I see we are on the same page. 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 only modules
On Sunday 17 December 2006 16:32, David Schwartz wrote: > > I would argue that this is _particularly_ pertinent with regards to > > Linux. For example, if you look at many of our atomics or locking > > operations a good number of them (depending on architecture and > > version) are inline assembly that are directly output into the code > > which uses them. As a result any binary module which uses those > > functions from the Linux headers is fairly directly a derivative work > > of the GPL headers because it contains machine code translated > > literally from GPLed assembly code found therein. There are also a > > fair number of large perhaps-wrongly inline functions of which the > > use of any one would be likely to make the resulting binary > > "derivative". > > That's not protectable expression under United States law. See Lexmark v. > Static Controls and the analogous case of the TLP (ignore the DMCA stuff in > that case, that's not relevant). If you want to make that kind of content > protectable, you have to get it out of the header files. > > You cannot protect, by copyright, every reasonably practical way of > performing a function. Only a patent can do that. If taking something is > reasonably necessary to express a particular idea (and a Linux module for > the ATI X850 card is an idea), then that something cannot be protected by > copyright when it is used to express that idea. (Even if it would clearly > be protectably expression in another context.) > > The premise of copyright is that there are millions of equally-good ways to > express the same idea or perform the same function, and you creatively pick > one, and that choice is protected. But if I'm developing a Linux module for > a particular network card, choosing to use the Linux kernel header files is > the only practical choice to perform that particular function. So their > content is not protectable when used in that context. (If you make another > way to do it, then the content becomes protectable in that context again.) > > IANAL. > > DS Agreed. You missed the point. Since the Linux Kernel header files contain a chunk of the source code for the kernel in the form of the macros for locking et. al. then using the headers - including that code in your module - makes it a derivative work. Actually, thinking about it, the way a Linux driver module works actually seems to make *ANY* driver a derivative work, because they are loaded into the kernels memory space and cannot function without having that done. *IF* the "Usermode Driver" interface that is being worked on ever proves useful then, and only then, could you consider it *NOT* a derivative work. Because then the only thing it is using *IS* an interface, not complete chunks of the source as generated when the pre-processor finishes running through the file. But as David said - IANAL D. Hazelton - 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 only modules
On Sunday 17 December 2006 16:32, David Schwartz wrote: I would argue that this is _particularly_ pertinent with regards to Linux. For example, if you look at many of our atomics or locking operations a good number of them (depending on architecture and version) are inline assembly that are directly output into the code which uses them. As a result any binary module which uses those functions from the Linux headers is fairly directly a derivative work of the GPL headers because it contains machine code translated literally from GPLed assembly code found therein. There are also a fair number of large perhaps-wrongly inline functions of which the use of any one would be likely to make the resulting binary derivative. That's not protectable expression under United States law. See Lexmark v. Static Controls and the analogous case of the TLP (ignore the DMCA stuff in that case, that's not relevant). If you want to make that kind of content protectable, you have to get it out of the header files. You cannot protect, by copyright, every reasonably practical way of performing a function. Only a patent can do that. If taking something is reasonably necessary to express a particular idea (and a Linux module for the ATI X850 card is an idea), then that something cannot be protected by copyright when it is used to express that idea. (Even if it would clearly be protectably expression in another context.) The premise of copyright is that there are millions of equally-good ways to express the same idea or perform the same function, and you creatively pick one, and that choice is protected. But if I'm developing a Linux module for a particular network card, choosing to use the Linux kernel header files is the only practical choice to perform that particular function. So their content is not protectable when used in that context. (If you make another way to do it, then the content becomes protectable in that context again.) IANAL. DS Agreed. You missed the point. Since the Linux Kernel header files contain a chunk of the source code for the kernel in the form of the macros for locking et. al. then using the headers - including that code in your module - makes it a derivative work. Actually, thinking about it, the way a Linux driver module works actually seems to make *ANY* driver a derivative work, because they are loaded into the kernels memory space and cannot function without having that done. *IF* the Usermode Driver interface that is being worked on ever proves useful then, and only then, could you consider it *NOT* a derivative work. Because then the only thing it is using *IS* an interface, not complete chunks of the source as generated when the pre-processor finishes running through the file. But as David said - IANAL D. Hazelton - 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: Overriding X on panic
On Sunday 26 November 2006 17:19, Dave Airlie wrote: > On 11/27/06, Alan <[EMAIL PROTECTED]> wrote: > > On Sun, 26 Nov 2006 09:18:41 +0100 > > > > Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > > > The mode switch sequences for modern cards are a bit more hairy than > > > > lists of I/O poking unfortunately. > > > > > > for the Intel hw Keith doesn't seem to think it's all that much of a > > > problem though... > > > > Including the TV out, odder LCD panels, non BIOS modes etc ? If so then > > it might be an interesting test case for intelfb to grow some kind of > > console helper interface > > It's non-trivial, I think you are better off going initially with just > using the current framebuffer that X is using, I know ajax was doing > some hacking on this with a "user"-framebuffer, until I disuaded him > due to I think the trouble caused by dual-head and something else I > can't remember.. > > I personally think we need to probably just bite the bullet and start > sticking graphics drivers into the kernel, the new randr-1.2 interface > for X is probably a good starting point for a generic mode setting > interface that isn't so X dependent and could replace fbdev with > something more sane wrt dualhead and multiple outputs... fbdev could > be implemented on top of that layer then.. also suspend/resume really > needs this sort of thing I've been working on this myself. Unfortunately the box I was using for devel has died and the start I made on the work was lost several months ago when I had a hard drive die on me. (I really need to go buy a UPS and a better surge protector - the box I was doing devel on bought it in a lightning strike and the hard drive I had used as a backup just died) > My main worry with integrating graphics drivers into the kernel is > that when they don't work the user gets no screen, with network/sound > etc this isn't so bad, but if they can't see a screen debugging gets > to be a bit more difficult Yeah - this is why the work I was doing kept the old vgacon around and used fbcon on those platforms that needed it (unchanged). My plan was to add a graphics system that would "take over" from the boot console when it was ready to take over. 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: Overriding X on panic
On Sunday 26 November 2006 17:19, Dave Airlie wrote: On 11/27/06, Alan [EMAIL PROTECTED] wrote: On Sun, 26 Nov 2006 09:18:41 +0100 Arjan van de Ven [EMAIL PROTECTED] wrote: The mode switch sequences for modern cards are a bit more hairy than lists of I/O poking unfortunately. for the Intel hw Keith doesn't seem to think it's all that much of a problem though... Including the TV out, odder LCD panels, non BIOS modes etc ? If so then it might be an interesting test case for intelfb to grow some kind of console helper interface It's non-trivial, I think you are better off going initially with just using the current framebuffer that X is using, I know ajax was doing some hacking on this with a user-framebuffer, until I disuaded him due to I think the trouble caused by dual-head and something else I can't remember.. I personally think we need to probably just bite the bullet and start sticking graphics drivers into the kernel, the new randr-1.2 interface for X is probably a good starting point for a generic mode setting interface that isn't so X dependent and could replace fbdev with something more sane wrt dualhead and multiple outputs... fbdev could be implemented on top of that layer then.. also suspend/resume really needs this sort of thing I've been working on this myself. Unfortunately the box I was using for devel has died and the start I made on the work was lost several months ago when I had a hard drive die on me. (I really need to go buy a UPS and a better surge protector - the box I was doing devel on bought it in a lightning strike and the hard drive I had used as a backup just died) My main worry with integrating graphics drivers into the kernel is that when they don't work the user gets no screen, with network/sound etc this isn't so bad, but if they can't see a screen debugging gets to be a bit more difficult Yeah - this is why the work I was doing kept the old vgacon around and used fbcon on those platforms that needed it (unchanged). My plan was to add a graphics system that would take over from the boot console when it was ready to take over. 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: [PATCH] ALSA: hda-intel - Disable MSI support by default
On Wednesday 15 November 2006 23:25, Lu, Yinghai wrote: > I think the root cause in hda_intel driver's self. > > It gets io-apic irq initialized at first, and it will use > azx_acquire_irq to install handler after check if MSI can be enabled. > And when it try to enable the MSI, that will start the int in the chip. > Even handler for MSI is not installed. > > YH That seems rather stupid. Perhaps installing a conditional handler before doing anything with MSI will solve that problem... The problem then just revolves around replacing the conditional handler with the real one when MSI is fully enabled. If I understood the code for this driver better I'd try to make this work. As it stands I'm still trying to recover from the loss of the work I did on another project. (DRM based uniform kernel graphics interface - had a blackout here that caused my devel machine to crash and left me with a trashed drive) 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: [PATCH] ALSA: hda-intel - Disable MSI support by default
On Wednesday 15 November 2006 23:25, Lu, Yinghai wrote: I think the root cause in hda_intel driver's self. It gets io-apic irq initialized at first, and it will use azx_acquire_irq to install handler after check if MSI can be enabled. And when it try to enable the MSI, that will start the int in the chip. Even handler for MSI is not installed. YH That seems rather stupid. Perhaps installing a conditional handler before doing anything with MSI will solve that problem... The problem then just revolves around replacing the conditional handler with the real one when MSI is fully enabled. If I understood the code for this driver better I'd try to make this work. As it stands I'm still trying to recover from the loss of the work I did on another project. (DRM based uniform kernel graphics interface - had a blackout here that caused my devel machine to crash and left me with a trashed drive) 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: GFS, what's remaining
On Saturday 03 September 2005 02:14, Arjan van de Ven wrote: > On Sat, 2005-09-03 at 13:18 +0800, David Teigland wrote: > > On Thu, Sep 01, 2005 at 01:21:04PM -0700, Andrew Morton wrote: > > > Alan Cox <[EMAIL PROTECTED]> wrote: > > > > > - Why GFS is better than OCFS2, or has functionality which > > > > > OCFS2 cannot possibly gain (or vice versa) > > > > > > > > > > - Relative merits of the two offerings > > > > > > > > You missed the important one - people actively use it and > > > > have been for some years. Same reason with have NTFS, HPFS, > > > > and all the others. On that alone it makes sense to include. > > > > > > Again, that's not a technical reason. It's _a_ reason, sure. > > > But what are the technical reasons for merging gfs[2], ocfs2, > > > both or neither? > > > > > > If one can be grown to encompass the capabilities of the other > > > then we're left with a bunch of legacy code and wasted effort. > > > > GFS is an established fs, it's not going away, you'd be hard > > pressed to find a more widely used cluster fs on Linux. GFS is > > about 10 years old and has been in use by customers in production > > environments for about 5 years. > > but you submitted GFS2 not GFS. I'd rather not step into the middle of this mess, but you clipped out a good portion that explains why he talks about GFS when he submitted GFS2. Let me quote the post you've pulled that partial paragraph from: "The latest development cycle (GFS2) has focused on improving performance, it's not a new file system -- the "2" indicates that it's not ondisk compatible with earlier versions." In other words he didn't submit the original, but the new version of it that is not compatable with the original GFS on disk format. While it is clear that GFS2 cannot claim the large installed user base or the proven capacity of the original (it is, after all, a new version that has incompatabilities) it can claim that as it's heritage and what it's aiming towards, the same as ext3 can (and does) claim the power and reliability of ext2. In this case I've been following this thread just for the hell of it and I've noticed that there are some people who seem to not want to even think of having GFS2 included in a mainline kernel for personal and not technical reasons. That does not describe most of the people on this list, many of whom have helped debug the code (among other things), but it does describe a few. I'll go back to being quiet now... DRH 0xA6992F96300F159086FF28208F8280BB8B00C32A.asc Description: application/pgp-keys pgp0QhxWOkyt5.pgp Description: PGP signature
Re: GFS, what's remaining
On Saturday 03 September 2005 02:14, Arjan van de Ven wrote: On Sat, 2005-09-03 at 13:18 +0800, David Teigland wrote: On Thu, Sep 01, 2005 at 01:21:04PM -0700, Andrew Morton wrote: Alan Cox [EMAIL PROTECTED] wrote: - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot possibly gain (or vice versa) - Relative merits of the two offerings You missed the important one - people actively use it and have been for some years. Same reason with have NTFS, HPFS, and all the others. On that alone it makes sense to include. Again, that's not a technical reason. It's _a_ reason, sure. But what are the technical reasons for merging gfs[2], ocfs2, both or neither? If one can be grown to encompass the capabilities of the other then we're left with a bunch of legacy code and wasted effort. GFS is an established fs, it's not going away, you'd be hard pressed to find a more widely used cluster fs on Linux. GFS is about 10 years old and has been in use by customers in production environments for about 5 years. but you submitted GFS2 not GFS. I'd rather not step into the middle of this mess, but you clipped out a good portion that explains why he talks about GFS when he submitted GFS2. Let me quote the post you've pulled that partial paragraph from: The latest development cycle (GFS2) has focused on improving performance, it's not a new file system -- the 2 indicates that it's not ondisk compatible with earlier versions. In other words he didn't submit the original, but the new version of it that is not compatable with the original GFS on disk format. While it is clear that GFS2 cannot claim the large installed user base or the proven capacity of the original (it is, after all, a new version that has incompatabilities) it can claim that as it's heritage and what it's aiming towards, the same as ext3 can (and does) claim the power and reliability of ext2. In this case I've been following this thread just for the hell of it and I've noticed that there are some people who seem to not want to even think of having GFS2 included in a mainline kernel for personal and not technical reasons. That does not describe most of the people on this list, many of whom have helped debug the code (among other things), but it does describe a few. I'll go back to being quiet now... DRH 0xA6992F96300F159086FF28208F8280BB8B00C32A.asc Description: application/pgp-keys pgp0QhxWOkyt5.pgp Description: PGP signature
Re: oops in 2.6.13-rc6-git5
On Monday 15 August 2005 08:22, Jesper Juhl wrote: > Can you reproduce the crash reliably? > Can you reproduce the crash with a non-tainted kernel? I've tried several times now to reproduce the oops, but there might have been another factor that led to the oops, because just booting the kernel and shutting down does not trigger it. I have tried reproducing all conditions up to the time that the oops actually occurred and think it might just be my hardware going flaky - so I have reloaded the module that taints the kernel (have done this already and having the module loaded when the powerdown started did not trigger the oops) and am seeing if using it for any period of time causes the oops to occur. If it does I will try the other driver available for the modem, although that one also contains proprietary code. The upside is that it does not make use of any functions marked as deprecated in any version of the kernel, where the official driver requires me to re-enable a deprecated function that had been made non-exported by the kernel. DRH 0xA6992F96300F159086FF28208F8280BB8B00C32A.asc Description: application/pgp-keys pgpQYkGfgjBlh.pgp Description: PGP signature
Re: oops in 2.6.13-rc6-git5
On Monday 15 August 2005 08:22, Jesper Juhl wrote: Can you reproduce the crash reliably? Can you reproduce the crash with a non-tainted kernel? I've tried several times now to reproduce the oops, but there might have been another factor that led to the oops, because just booting the kernel and shutting down does not trigger it. I have tried reproducing all conditions up to the time that the oops actually occurred and think it might just be my hardware going flaky - so I have reloaded the module that taints the kernel (have done this already and having the module loaded when the powerdown started did not trigger the oops) and am seeing if using it for any period of time causes the oops to occur. If it does I will try the other driver available for the modem, although that one also contains proprietary code. The upside is that it does not make use of any functions marked as deprecated in any version of the kernel, where the official driver requires me to re-enable a deprecated function that had been made non-exported by the kernel. DRH 0xA6992F96300F159086FF28208F8280BB8B00C32A.asc Description: application/pgp-keys pgpQYkGfgjBlh.pgp Description: PGP signature
