How about I use Windows, like everyone else? How about I click on e-mailed attachments, like everyone else? How about I don't customize my computer for my way of working, like everyone else? How about I use proprietary document formats, like everyone else? How about I let someone else dictate what I will do, how I will do it, and how much I have to pay in time and trouble and money to keep access to my data, like everyone else? How about I don't have control over the hardware I've legitimately purchased with money I've earned myself, like everyone else?
Or, you know, companies who proudly claim to "support Linux" could be a little bit more clear about what they actually do support -- that is, x86 Linux users who don't mind opaque binary blobs that could do absolutely anything.
nVidia and ATI (and even Matrox, after much grumbling) _have_ released Linux drivers.
Funny; their drivers have no chance of working on my PPC/Linux machine. They might as well not have released drivers for me. Some Linux support that is.
Linux developers would have to depend on users buying almost all of the popular hardware out there and then test it fully on every popular distribution of Linux.
Why is that? What differences are there between distributions that make driver support so difficult?
It's very confusing for a new user to learn one desktop interface, say KDE, and then realize that some distributions use another, like GNOME, as a default.
Why is that? How many users have to switch between desktop interfaces? Or do you mean that the cognitive burden of realizing that some people have different desktops is too difficult for certain users regardless of whether they ever encounter these differences?
Without copyright laws there would be little motive for many of the great authors, musicians, artists, photographers and playwrites that myself and many others have come to admire to make and publish their works.
Steamboat Willie, released in 1928, is still undercopyright, but we haven't seen anything out of Walt Disney for almost 40 years to the day. I don't think copyright extensions will encourage him to release more.
Let debian, mandriva, redhat, suse, ubunto, gentoo and all the other distros decide for themselves whether they want to ban binary modules...
It's not their decision. If binary modules are derivative works of the Linux kernel (and I don't know how you can argue otherwise; read a kernel header sometime), they have no right to distribute compiled binary modules.
Distributing them as source and compiling them on user machines might skirt the copyright requirements, but I wonder if there's a DMCA violation in there. I don't know.
I'm not really familiar with the licensing structure of other major databases, excepting PostgreSQL and SQLite (if it counts as major), but my point was only that there's a big difference between usage and distribution, with regard to copyright. It's important to maintain that distinction when comparing copyleft licenses.
GNU/Linux, good though it is, is nowhere near ready to take on microsoft for home users. The simple reason being that... I won't give up my games, and I'm not alone.
Hey, look--a hasty generalization!
Count the number of home desktops last year. Count the highest-selling PC game last year (sold-through, not sold-in). Compare. I bet the second number is at least an order of magnitude less.
Yes, that's completely correct. The copyright holder always has the option to relicense the software under any license. Adding the "at your option" clause to the GPL v2 only affects people who receive the software and want to redistribute it under that license, or subsequent versions of the GPL.
How does a binary not derive somehow from the headers, especially if (as in this case), the headers include constants, macros, and structure declarations?
They do distribute a shim, which is clearly a derived work of the kernel...
It's clear that a binary compiled against Linux kernel headers is a derivative work of those headers, but it's not clear that the source code itself is a derivative work. Otherwise, I completely agree. Great post.
Or you could be less jumpy and agile and use the code that's already there to start with.
Oh, of course. Sometimes I do that. Other times I don't, because it takes me a couple of refactorings to see that two different pieces of codes are a refactoring or two away from being a bigger refactoring themselves.
Correct me if I'm out of line here, but what you appear to be saying is that you're a good programmer if you keep rewriting your code instead of getting it right the first time. Is that the case?
No. That's not what refactoring is.
I suppose that if you knew exactly what you had to build and could design it completely before you ever started coding and you never had to change any part of the design, ever, you wouldn't need to refactor. I've never worked on a project like that, however--at least not one longer than about ten lines of code.
Refactoring is the disciplined and organized process of improving the design of code, especially to remove duplication and to simplify the design. Perhaps the easiest way to understand it is to imagine that you add a feature to a program and then realize that the code you just added is remarkably similar to another piece of code you already had. You could leave them both there, or you could refactor both pieces of code into a single parameterized representation. The behavior of the system remains the same, but you've generalized something that needed generalization and removed duplication or near-duplication.
Again, if you can design the whole system completely in advance and never change the design at all, you can probably get away without refactoring.
How about I use Windows, like everyone else? How about I click on e-mailed attachments, like everyone else? How about I don't customize my computer for my way of working, like everyone else? How about I use proprietary document formats, like everyone else? How about I let someone else dictate what I will do, how I will do it, and how much I have to pay in time and trouble and money to keep access to my data, like everyone else? How about I don't have control over the hardware I've legitimately purchased with money I've earned myself, like everyone else?
Or, you know, companies who proudly claim to "support Linux" could be a little bit more clear about what they actually do support -- that is, x86 Linux users who don't mind opaque binary blobs that could do absolutely anything.
I believe that was actually Christine Peterson, though ESR was at the summit.
In my mind, ESR stopped any pretense of showing moderation in 1999. See Communist China adopts Linux? and Surprised By Wealth. Uncoincidentally, he stopped speaking for me that same year.
Funny; their drivers have no chance of working on my PPC/Linux machine. They might as well not have released drivers for me. Some Linux support that is.
Why is that? What differences are there between distributions that make driver support so difficult?
Why is that? How many users have to switch between desktop interfaces? Or do you mean that the cognitive burden of realizing that some people have different desktops is too difficult for certain users regardless of whether they ever encounter these differences?
Now that's a use of the phrase standard library which I never expected to hear!
It's actually copyright that's "viral", and plenty of cases have explored what makes a derivative work.
Steamboat Willie, released in 1928, is still undercopyright, but we haven't seen anything out of Walt Disney for almost 40 years to the day. I don't think copyright extensions will encourage him to release more.
It's not their decision. If binary modules are derivative works of the Linux kernel (and I don't know how you can argue otherwise; read a kernel header sometime), they have no right to distribute compiled binary modules.
Distributing them as source and compiling them on user machines might skirt the copyright requirements, but I wonder if there's a DMCA violation in there. I don't know.
I run GNU/Linux on architectures besides x86. Good luck getting support for those.
I'm not really familiar with the licensing structure of other major databases, excepting PostgreSQL and SQLite (if it counts as major), but my point was only that there's a big difference between usage and distribution, with regard to copyright. It's important to maintain that distinction when comparing copyleft licenses.
If you don't distribute the application, why would copyright have an effect?
No kidding! I can't think of the last book review I read that didn't mention some sort of product for sale, usually a book!
That's exactly what a hasty generalization is, unless you somehow know most or all of the people who use Linux.
Hey, look--a hasty generalization!
Count the number of home desktops last year. Count the highest-selling PC game last year (sold-through, not sold-in). Compare. I bet the second number is at least an order of magnitude less.
Yes, that's completely correct. The copyright holder always has the option to relicense the software under any license. Adding the "at your option" clause to the GPL v2 only affects people who receive the software and want to redistribute it under that license, or subsequent versions of the GPL.
That clause has no binding on the copyright holder of the software, only on recipients who wish to distribute the software under the terms of the GPL.
How does a binary not derive somehow from the headers, especially if (as in this case), the headers include constants, macros, and structure declarations?
It's clear that a binary compiled against Linux kernel headers is a derivative work of those headers, but it's not clear that the source code itself is a derivative work. Otherwise, I completely agree. Great post.
Perhaps they could learn the art of the craft rather than the mechanics of specific tools..
I didn't say it was a good hobby, but it's mine and I like it.
There'd be fewer members of MADD if drunk drivers hadn't killed their loved ones too, but I'm not sure you ought to defend vehicular manslaughter.
Oh, of course. Sometimes I do that. Other times I don't, because it takes me a couple of refactorings to see that two different pieces of codes are a refactoring or two away from being a bigger refactoring themselves.
Perhaps the people who pay for the development of software are finally sick of not getting what they want.
No. That's not what refactoring is.
I suppose that if you knew exactly what you had to build and could design it completely before you ever started coding and you never had to change any part of the design, ever, you wouldn't need to refactor. I've never worked on a project like that, however--at least not one longer than about ten lines of code.
Refactoring is the disciplined and organized process of improving the design of code, especially to remove duplication and to simplify the design. Perhaps the easiest way to understand it is to imagine that you add a feature to a program and then realize that the code you just added is remarkably similar to another piece of code you already had. You could leave them both there, or you could refactor both pieces of code into a single parameterized representation. The behavior of the system remains the same, but you've generalized something that needed generalization and removed duplication or near-duplication.
Again, if you can design the whole system completely in advance and never change the design at all, you can probably get away without refactoring.
You might want to read a dissenting opinion on Steve Yegge's hatchet job on agile development. Having been on both agile and non-agile development projects, my experience is that it's very easy to criticize agile development if you don't know anything about it.