You know, compiling something is not an act of intellectual creation
I think you are confusing two very different steps: the creation of a copyrighted work, and copying.
The header is a work of intellectual creation when its author writes it. Thus, it is and remains copyrightable art.
The header is copied when it is included into a driver. It doesn't matter whether that copying is automatic, the copyright holder still is the only one who can grant the right to make that copy. By the way, it isn't automatic - writing "#include " is a manual direction to the preprocessor to perform the act of copying.
A blanket declaration that the output of programs is not copyrightable is too simplistic to work - a trivial example is that I could put two works by different people together using "cat" (the very simple Unix/Linux program that combines two files), and the result would be a derivative work containing components that are copyrighted by those two people, even though the only act of intellectual creation would be the command to combine the files. Running the "cat" program over copyrighted text would not automaticaly strip their copyright.
if the interfaces turn out to be non-copyrightable.
To make sense of this, it helps to distinguish interfaces from implementations of interfaces. The API implemented by the headers might not be copyrightable, but the particular way that API is expressed in the headers is copyrightable.
There is a pervasive belief... that the GPL can make someone else's work GPLed just by coming in contact with it,
That's not really far from the truth. If your work touches GPL work it becomes likely that yours is a derivative work. You may not create deriviative works without a license. That license is the GPL, and it says that you must apply a GPL-compatible license to the derivative work. So, suppose you had an existing infringement. Suppose the court finds your work to be infringing. Your obligation would be to remedy the infringement. The copyright holder of the original work might accept it if you simply stop distributing the derivative work. Or, you could apply a GPL-compatible license to your work. Or you could pay damages. Or some combination of those three, with the copyright holder saying what he wishes to accept and the judge making the final decision.
The part of the SCO trials I was referring to was when SCO brought up allegations that Linus had copied Unix header files in the creation of Linux. Part of the community's response to that claim was that such header files were not copyrightable.
Yes, but that is not because they are fundamentally not copyrightable. It is because of the fact that they were originally distributed without a copyright notice back when the default in copyright law was that such works were in the public domain. And that copyright releases were made for a number of standards, including ANSI C and POSIX.
Regarding the U.S. law issue. I understand that you could bring suit in other countries. Most of the offenders are U.S. corporations, and there are viable U.S. plaintiffs. The result of a successful lawsuit in the U.S. probably would restrain the infringer from distributing a non-GPL Linux driver anywhere.
A driver is not a derivative work, as it does not use code from the kernel.
That is a simplistic explanation that leads to misconceptions. You believe that a driver is not a derivative work because the source doesn't include code directly from Linux. But you need not copy code from the kernel into your source to create a derivative work. For example, the binary loadable module always is a derivative work simply because of the textual inclusion of headers and symbol tables. And companies like nVidia are doing binary distribution. And even were that not the case, you would have to be very careful indeed to keep the driver source from being a derivative work on its own. But that's moot because once the binary is a derivative work, the GPL must be applied to the source and the source must be distributed.
You're a bit confused when you say "non interface". If I write a book with an API, it's going to be difficult to assert that any use of that API is a derivative work requiring licensing. However, if I implement that API in a group of headers and linkable symbols, that is a copyrighted work of software. That work is textually included in compiling the driver, and the symbols used for dynamic linking are textually included when the loadable module is built.
Yes. Distributors of proprietary drivers for the Linux kernel should either stop, or GPL their driver. Either would be an acceptable way to remedy the infringement.
I thought the general opinion was that "structure definitions" were not copyrightable. Or at least that's what you guys told SCO:)
The SCO case didn't get there, and probably never will. APIs like POSIX would be difficult to protect, because they don't depend on any single copyrighted work. In contrast, to build a driver there is a good deal of actual textual inclusion that goes on in the form of headers and symbols, as well as snippets of Linux code that are copied into any driver, and copyright law is pretty clear on textual inclusion. In the case of SCO, that textual inclusion was removed before the driver was brought to Linux.
Connecting to GPL code isn't the same as using GPL code.
To explain the complexity of the problem, you should be aware that software "connecting to other software" is not a concept that appears in the U.S. copyright law. You are also confused about "use". Use is a separate right in copyright law that doesn't really come into this discussion. Some other rights are the creation of derivative works, and distribution of a copyrighted work. You will need to learn something about them and think in those terms before you can say anything sensible in this sort of discussion. It's really very interesting, but will take some time.
There might have been a promissory estoppel connected to EXPORT_SYMBOL if all developers had gotten to make that choice. The way it was phased in, old code was all set to EXPORT_SYMBOL and only developers of brand-new interfaces had that choice.
It doesn't matter whether or not APIs are copyrightable, because the driver needs more than just an API to work. It requires the actual textual inclusion of material from the kernel.Bruce
The most serious misconception you have is that there is no requirement to GPL one's derivative code since the GPL isn't a contract. This is not true because the default in copyright law is that there is no permission to either create or distribute a derivative work at all. What do you do to get those permissions? You accept the GPL.
In the SCO case, while the IBM drivers and filesystems retained information specific to SCO Unix internals (not POSIX APIs) they were licensed derivative works of the SCO system. When they were ported to Linux, the SCO-specific material was removed and they could no longer be considered derivative of SCO. To make them work on Linux they had to become, to some extent, derivative works of Linux. The IBM folks did indeed use GPL-compatible licensing for them at that point.
Perhaps a simple driver could work entirely within a published API without copying in stuff from Linux, but the nVidia driver isn't that simple.
Well, Saheed, if you want me to believe you, you are going to have to try a bit harder than just contradicting me without contributing any argument to the discussion. For example, you might look at the one court case that touches on this matter, and discuss it. But first, you'd have to find it (don't cheat and give it to him, folks). And you'd have to make a pretty good argument to fit its circumstances to what we are discussing.
The fact is, I've discussed this with a number of different attorneys for years. Their answers are not all the same. But Eben Moglen, who is probably the smartest of the bunch, told me in front of a room of people at the OSDL conference a few months ago that if the case had been offered to him, he would have taken it on.
It's a reflex. I didn't want to say "intellectual property". Richard virtually bonks me on the head every time I do that.
The fact is that you can't make a derived work of that kind without pulling in lots of little snippets of the kernel it's marrying. Structure definitions, for one thing.
It is an unauthorized derived work, even though nVidia wrote the whole thing. It incorporates a significant amount of copyrighted information on kernel internals that it must connect to. It doesn't access them through the normal system call interface that is exported for use by proprietary applications.
If they've given you a binary, you have the right to the source code under the GPL.
If I understand correctly, kernel copyright holders and OSDL looked into it, but you would probably know about that.
OSDL can be a useful organization, but we have to be realistic about the interests of their membership. They would never help kernel copyright holders prosecute companies that make non-GPL device drivers, nor would they say anything negative about their legality.
FSF does not own copyrights on the Linux kernel, and I don't know of anyone who has come to FSF who does own such copyrights. But we now have the resources to pursue such matters outside of FSF. I would like to hear from kernel copyright holders who would help with that. If we let the unauthorized derivative works go on for too long, I'm afraid we will create an estoppel that would limit the effect of the GPL.
This would bring a completely unnecessary level of noise into the process. Film grain is noisy and doesn't contribute extra information once you can resolve a single crystal. What you really should do is defocus just enough so that the grain noise is averaged out, or digitize at a higher resolution than the grain and then filter out the frequency band of the grain noise. The effect of those two processes might be identical.
I worked on the Snow White restoration with Kodak Cinesite while at Pixar. The film was made with nitrate stock, as were all films back then - there wasn't another good method to make clear plastic stock. Nitrate is great organic fertilizer - as well as being chemically quite close to nitroglycerine and a tremendous fire hazard if the projector jams and the hot lamp burns the film.
The negative was preserved in a climate-controlled vault for 60 years. When it was finally opened, they found that fungus had grown on the negative.
The negative was chemically cleaned. Then, it was digitized in a wet-gate telecine. This is an impressive bit of optical technology: the film is immersed in a fluid with the same refractive index as the film itself. The fluid fills pits and scratches in the film, and they disappear.
The resulting digital movie went through an algorithmic "dust-buster" process, and then the reels with the worst damage were retouched by hand frame-by-frame. An operator got about 90 seconds to retouch a frame. There are 24 frames per second of film. This stretched the computer technology at the time, MIPS-based Sun or SGI workstations with clock speeds of a few hundred MHz, as it was difficult to simply read and write the film frame in sufficient time. It would be easier today on a fast PC.
I agree with you in this case. But I haven't looked at all of the implications of the patch. It may also be that some distributions ship with this as standard. Red Hat might, but I've not confirmed it.
I believe that the current best practice is to have a bit in the header that enables the patch on a per-executable basis. It used to be that signal trampolines (used to switch stacks when calling an asynchronous signal handler) broke, as they actually built some executable code on the stack. But this may no longer be true.
Look up the "solar designer" patch for Linux, included in some versions of secure Linux. It uses a segment to address the stack, and manages to execute-protect it, even though the processor is running in page mode and does not have an execute permission bit in its page-table implementation. IMO Microsoft could use this and does not. But Linus has objected to it as ugly and insufficient and won't accept it into his own sources.
The basic problem is that Intel didn't include an execute protection bit in the i386 page-table implementation and was incredibly late to add one, even though there was a spare field in the page-table-entry that could have been used. We had this in the VAX in 1981, in other processors before that time. Linux has taken advantage of it, where it exists, for more than a decade, Unix since the 1970's.
How does an application find out how many CPUs there are in the box?
I usually read/proc/cpuinfo. And this is another area where speed does not matter. I read it once, in an interpretive program, and it's easier to program that using the ASCII than it would be to parse yet another binary interface. If I want it in a fast integer variable accessable from tight loops on compiled code, I can put it in one after I read it.
Slashdot Mirror
This is why we apply the LGPL, not the GPL, to the C library and its headers.
Bruce
I think you are confusing two very different steps: the creation of a copyrighted work, and copying.
The header is a work of intellectual creation when its author writes it. Thus, it is and remains copyrightable art.
The header is copied when it is included into a driver. It doesn't matter whether that copying is automatic, the copyright holder still is the only one who can grant the right to make that copy. By the way, it isn't automatic - writing "#include " is a manual direction to the preprocessor to perform the act of copying.
A blanket declaration that the output of programs is not copyrightable is too simplistic to work - a trivial example is that I could put two works by different people together using "cat" (the very simple Unix/Linux program that combines two files), and the result would be a derivative work containing components that are copyrighted by those two people, even though the only act of intellectual creation would be the command to combine the files. Running the "cat" program over copyrighted text would not automaticaly strip their copyright.
Bruce
To make sense of this, it helps to distinguish interfaces from implementations of interfaces. The API implemented by the headers might not be copyrightable, but the particular way that API is expressed in the headers is copyrightable.
There is a pervasive belief ... that the GPL can make someone else's work GPLed just by coming in contact with it,
That's not really far from the truth. If your work touches GPL work it becomes likely that yours is a derivative work. You may not create deriviative works without a license. That license is the GPL, and it says that you must apply a GPL-compatible license to the derivative work. So, suppose you had an existing infringement. Suppose the court finds your work to be infringing. Your obligation would be to remedy the infringement. The copyright holder of the original work might accept it if you simply stop distributing the derivative work. Or, you could apply a GPL-compatible license to your work. Or you could pay damages. Or some combination of those three, with the copyright holder saying what he wishes to accept and the judge making the final decision.
The part of the SCO trials I was referring to was when SCO brought up allegations that Linus had copied Unix header files in the creation of Linux. Part of the community's response to that claim was that such header files were not copyrightable.
Yes, but that is not because they are fundamentally not copyrightable. It is because of the fact that they were originally distributed without a copyright notice back when the default in copyright law was that such works were in the public domain. And that copyright releases were made for a number of standards, including ANSI C and POSIX.
Thanks
Bruce
Bruce
That is a simplistic explanation that leads to misconceptions. You believe that a driver is not a derivative work because the source doesn't include code directly from Linux. But you need not copy code from the kernel into your source to create a derivative work. For example, the binary loadable module always is a derivative work simply because of the textual inclusion of headers and symbol tables. And companies like nVidia are doing binary distribution. And even were that not the case, you would have to be very careful indeed to keep the driver source from being a derivative work on its own. But that's moot because once the binary is a derivative work, the GPL must be applied to the source and the source must be distributed.
Bruce
Bruce
Bruce
The SCO case didn't get there, and probably never will. APIs like POSIX would be difficult to protect, because they don't depend on any single copyrighted work. In contrast, to build a driver there is a good deal of actual textual inclusion that goes on in the form of headers and symbols, as well as snippets of Linux code that are copied into any driver, and copyright law is pretty clear on textual inclusion. In the case of SCO, that textual inclusion was removed before the driver was brought to Linux.
Bruce
To explain the complexity of the problem, you should be aware that software "connecting to other software" is not a concept that appears in the U.S. copyright law. You are also confused about "use". Use is a separate right in copyright law that doesn't really come into this discussion. Some other rights are the creation of derivative works, and distribution of a copyrighted work. You will need to learn something about them and think in those terms before you can say anything sensible in this sort of discussion. It's really very interesting, but will take some time.
Bruce
It doesn't matter whether or not APIs are copyrightable, because the driver needs more than just an API to work. It requires the actual textual inclusion of material from the kernel.Bruce
Thanks
Bruce
In the SCO case, while the IBM drivers and filesystems retained information specific to SCO Unix internals (not POSIX APIs) they were licensed derivative works of the SCO system. When they were ported to Linux, the SCO-specific material was removed and they could no longer be considered derivative of SCO. To make them work on Linux they had to become, to some extent, derivative works of Linux. The IBM folks did indeed use GPL-compatible licensing for them at that point.
Perhaps a simple driver could work entirely within a published API without copying in stuff from Linux, but the nVidia driver isn't that simple.
Thanks
Bruce
The fact is, I've discussed this with a number of different attorneys for years. Their answers are not all the same. But Eben Moglen, who is probably the smartest of the bunch, told me in front of a room of people at the OSDL conference a few months ago that if the case had been offered to him, he would have taken it on.
Bruce
The fact is that you can't make a derived work of that kind without pulling in lots of little snippets of the kernel it's marrying. Structure definitions, for one thing.
Bruce
Bruce
If they've given you a binary, you have the right to the source code under the GPL.
Bruce
OSDL can be a useful organization, but we have to be realistic about the interests of their membership. They would never help kernel copyright holders prosecute companies that make non-GPL device drivers, nor would they say anything negative about their legality.
Bruce
Bruce
Yes. It was simply a function of work to do / operator time.
Bruce
The negative was preserved in a climate-controlled vault for 60 years. When it was finally opened, they found that fungus had grown on the negative.
The negative was chemically cleaned. Then, it was digitized in a wet-gate telecine. This is an impressive bit of optical technology: the film is immersed in a fluid with the same refractive index as the film itself. The fluid fills pits and scratches in the film, and they disappear.
The resulting digital movie went through an algorithmic "dust-buster" process, and then the reels with the worst damage were retouched by hand frame-by-frame. An operator got about 90 seconds to retouch a frame. There are 24 frames per second of film. This stretched the computer technology at the time, MIPS-based Sun or SGI workstations with clock speeds of a few hundred MHz, as it was difficult to simply read and write the film frame in sufficient time. It would be easier today on a fast PC.
Bruce
I believe that the current best practice is to have a bit in the header that enables the patch on a per-executable basis. It used to be that signal trampolines (used to switch stacks when calling an asynchronous signal handler) broke, as they actually built some executable code on the stack. But this may no longer be true.
Bruce
The basic problem is that Intel didn't include an execute protection bit in the i386 page-table implementation and was incredibly late to add one, even though there was a spare field in the page-table-entry that could have been used. We had this in the VAX in 1981, in other processors before that time. Linux has taken advantage of it, where it exists, for more than a decade, Unix since the 1970's.
Bruce
I like writing CodeThatYouCanReadLikeANewspaper. That SometimesRequiresLongNames :-)
I usually read /proc/cpuinfo. And this is another area where speed does not matter. I read it once, in an interpretive program, and it's easier to program that using the ASCII than it would be to parse yet another binary interface. If I want it in a fast integer variable accessable from tight loops on compiled code, I can put it in one after I read it.
People are worth more than computers.
Bruce