Quotes of the week [LWN.net]

I talked with Alexandre [Oliva] a few months ago, and we decided to change the way Linux Libre deals with outside nonfree firmware. The current practice is to change the code to fail instead of trying to load any firmware.

The change is to obfuscate the names of the firmware files in the Linux source code. That way, if a user tracks down what firmware to install and installs it under the name that the code wants, it will. But Linux Libre will still not suggest installation of the nonfree firmware file to handle a particular device.

-- Richard Stallman on freedom through obscurity

The final BKL removal isn't really a big step forward for Linux. It's more a symbolic gesture, but I prefer to leave those to politicians and priests.

-- Andi Kleen

In conclusion: don't get surprised if technically inferior propositions, such as proprietary 3D libraries coupled with kernel-side interfaces, are met with strong or even vehement opposition. Some people will be sufficiently moderated to tell you that if you want to do such thing then you get to deal with it all yourself and that they are not interested in any accommodation that would help you. But it is clear that you will never get a consensus for supporting such technically inferior solution in the mainline tree, as from an Open Source point of view such a move simply makes no sense.

Accepting such things in mainline would weaken the very principle that as made Open source in general and Linux in particular such a success, while refusing it isn't going to affect the survival of Open Source anyway. The compromise here would be only in the corporate world's favor. And as the past history has shown in such cases, the Open Source way always ends up prevailing eventually, despite the lack of corporate assistance.

-- Nicolas Pitre

Anyone can try shipping this and risk a lawsuit, and all copyright holders of the kernel can try suing people that distribute such code. Most sensible people stay out of both the shipping questionable code and the suing part, but apparently the entire mobile phone industry is already doing both, so we can just wait and see if anyone has deep enough pockets to bring this up in court first.

-- Arnd Bergmann

(Log in to post comments)

Quotes of the week

Posted Dec 23, 2010 6:28 UTC (Thu) by butlerm (subscriber, #13312) [Link]

"My point which people keep missing is that graphics stacks are a single entity, that span kernel and userspace, one cannot exist without the other, and there are interfaces that join them..."

Here we have someone perpetuating the popular legal fiction that the derivative status of a work is affected by how it may be used.

A derivative work is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a derivative work. (17 USC 101)

In what way, exactly, is an arbitrary user space program (that uses some sort of kernel interface) necessarily "based upon" protected elements of an arbitrarily selected piece of pre-existing kernel code?

In the United States, even relatively elaborate technical interfaces have been held to be unprotectable by copyright. And that question would only arise if the technical interface itself was created by someone who wished to attempt to make it impossible for differently licensed code to use it. A random contributor to some other part of the kernel code cannot enforce the copyright on the contributions of someone else.

Quotes of the week

Posted Dec 23, 2010 10:10 UTC (Thu) by kronos (subscriber, #55879) [Link]

>Here we have someone perpetuating the popular legal fiction that the derivative status of a work is affected by how it may be used.
I think Dave's comment is not about the legal status of such a stack. He's saying that since the two parts are closely coupled it makes little sense to merge only the kernel component: there are no advantages but plenty of downsides (e.g. maintenance burden falls on the community, now way to change the interface since the other part is not modifiable, etc).

Derivative work

Posted Dec 23, 2010 23:15 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

Here we have someone perpetuating the popular legal fiction that the derivative status of a work is affected by how it may be used.

Do you believe that an additional chapter for an existing book is a derivative work of that book? Or that a book that contains a character from an existing book is? I'm sure I read a copyright lawyer saying those are well understood to be derivative works, in spite of the fact that they don't fit the actual language of the statutes. The rationale had something to do with the fact that the chapter or character didn't have any use except in combination with the original book, so the real work was the combination, regardless of the new work being distributed separately.

If you believe a supplemental chapter for a book is a derivative work, then it isn't much of a stretch to say that a piece of code whose only function is to extend the function of some other particular piece of code is a derivative work of it.

Derivative work

Posted Dec 24, 2010 8:19 UTC (Fri) by NAR (subscriber, #1313) [Link]

I think that the argument here is that user space doesn't extend the kernel code, it uses the kernel code. If I write a wrapper over the open(2) system call, would it be a derivative work? I think it would be unless the license for the kernel would explicitly said otherwise. And actually it says otherwise: This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".

Derivative work

Posted Dec 24, 2010 20:10 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

Sort of. The open(2) system call is a POSIX invention, as such any wrapper over it is not a derivative of Linux. If you take some Linux-specific call (like clone(2) or the ones for managing modules) it is a different story.

Derivative work

Posted Dec 25, 2010 15:02 UTC (Sat) by butlerm (subscriber, #13312) [Link]

If you take some Linux-specific call (like clone(2) or the ones for managing modules) it is a different story.

U.S. courts have ruled that technical interfaces hundreds of times more sophisticated than clone(2) are not protectable by copyright, to the level of specific structure names, layouts, and element names. See for example Baystate v. Bentley Systems (D. Mass. 1996). Nice explanation here (pdf). I doubt any other court would rule differently.

Derivative work

Posted Dec 26, 2010 18:47 UTC (Sun) by giraffedata (subscriber, #1954) [Link]

[From kernel copyright license]

This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".

I'd like to make one thing clear: the authors of code don't get to decide what the copyright on it covers and don't get to decide what falls under the heading of "derived work." Legislators decide what the copyright covers and what a derived work (which is one of the things the copyright covers) is.

Of course, the authors can promise not to avail themselves of some of what the copyright covers and might promise not to exercise their rights to control certain kinds of derived works. That would be a copyright license. I suppose a court interpreting the above text, which as worded is ineffective, might convert it to an equivalent license.

Derivative work

Posted Dec 25, 2010 15:23 UTC (Sat) by butlerm (subscriber, #13312) [Link]

Do you believe that an additional chapter for an existing book is a derivative work of that book?

In some cases, yes. In general no. It depends whether the content of the additional chapter is "recast, adapted, or transformed" from the original. An additional chapter for a work of fiction is likely to be considered an adaptation of material in the original. As far as I know, the courts have never established a legal doctrine to the contrary for works of fiction. They have on multiple occasions for technical interfaces.

A user space program could be considered a derivative work of kernel code if it was "based upon" existing kernel code in a manner beyond that of interface compatibility, and the scenes a faire doctrine in general. No driver, user space or otherwise, is likely to be considered infringing, unless it was a copy of existing kernel code to a considerably greater degree than that required for it to work at all. That is my understanding.

Quotes of the week

Posted Dec 23, 2010 8:24 UTC (Thu) by neilbrown (subscriber, #359) [Link]

> The final BKL removal isn't really a big step forward for Linux. It's more a symbolic gesture, but I prefer to leave those to politicians and priests.

I don't really agree with Andi here. I agree that it isn't a big step forward in a technical sense (though I seem to recall hearing that removing the BKL simplified the scheduler a little, and that cannot be bad).

But the strengths of Linux aren't just in the technology. They are also in the community, the attitudes of developers, the perception of the quality.

Consequently, I think symbolic gestures can be very important. They say 'we care about quality', 'we fix our mistakes', 'we remove crap'.

Now it may be that we actually add more crap than we remove (statistically that seems very likely) but in that case it is even more important to make the symbolic gestures so that we can have a concrete basis to encourage each other to improve quality.

Quotes of the week

Posted Dec 23, 2010 12:10 UTC (Thu) by epa (subscriber, #39769) [Link]

I write code for a living, but I only truly get job satisfaction when removing code.

Quotes of the week

Posted Dec 24, 2010 15:50 UTC (Fri) by MisterIO (guest, #36192) [Link]

I get what you mean, but I still prefer the "Aha!" moments! To translate the concept, an "Aha!" moment is when I have an intuition about how to rewrite(or rethink, if I'm lucky enough to have the inspiration before I start to write) a piece of code in a better way. I think the "Aha!" moments are usually a superset of what you describe.

By the way, the quote of Stallman is hard to believe! Is that really acceptable?

Quotes of the week

Posted Dec 24, 2010 20:12 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

RMS is free to say whatever he likes. To you agree with him, or think he finally went off the deep end, is your prerogative.

Quotes of the week

Posted Dec 24, 2010 20:52 UTC (Fri) by MisterIO (guest, #36192) [Link]

I certainly didn't mean that he can't say that or whatever else for that matter! My question was: Is _doing_ something like that generally considered acceptable? And by the way, it's not a suggestion to censor that kind of decision, it was more like an hopefully more civilised version of something like : "WTF is wrong with these people!?".

Jumping the Shark

Posted Dec 24, 2010 20:34 UTC (Fri) by jmorris42 (subscriber, #2203) [Link]

No it really shouldn't be acceptable to go out of your way to make software harder to use. RMS has at long last jumped the shark. This latest stunt is so far worse than the GNU/Linux trademark hijack hijinks it isn't even in the same category.

This goes form eyerolling while remembering his irreplacable contributions to Free Software to making him and the FSF itself untrustworthy. Before reading that I'd have never thought twice about putting "or any later verion" in a header, confident the FSF wouldn't be likely to go completely batty. Well they are now officially batty as far as I'm concerned. Still no objections to GPL 2 or GPL 3 but no way I'm blindly trusting them to make future changes.

Quotes of the week

Posted Dec 27, 2010 2:00 UTC (Mon) by Trelane (subscriber, #56877) [Link]

Can I nominate this to QotW somewhere?