Alan Cox on Patent Law and GPLv3

tykev writes "Linux kernel guru Alan Cox talks about kernel features, cooperation with hardware vendors, and software patents. From the interview: 'I don't think [Microsoft's patent threats] are the biggest danger. As Microsoft has been finding out recently it is the patent trolls, and organisations with buried patents in interesting areas that are the biggest threat in the USA. The real answer to that problem, however, is to pull the USA back into line with the majority of the world which simply does not recognize patents on software but respects them as literary works subject to copyright law.'"

Comments

Re:One extreme to the next

[cpt kangarooski]

The problem becomes, how many ways can you write a single piece of code? At present, you are fairly limited by the languages available as to what you can and cannot do. This means that you could get several pieces of code doing the same task that look nearly identical. Now is this going to be copyright infringement? Variable names could even come out looking very similar if both programs were coded using the same naming convention. There is a huge problem with treating a software copyright like an "art" copyright.

Actually, it's not. Copyright pertains to the expression portion of software, but not the underlying ideas, functionality, etc. Ultimately, maintaining this distinction takes priority over copyrightability. For example, where there is only one or only a limited way of expressing a given idea, the idea and expression are considered to have merged, and there cannot be a copyright, lest it effectively protect the uncopyrightable idea. This is known as the merger docrine.

There's also the scenes a faire doctrine, which makes uncopyrightable things like stock story elements. For example, in horror movies, someone originated the routine bit where the mood is set when you see a wolf howling, silhouetted against the moon. But it's unprotectable since it's a common, stock element. The doctrine is used in the software field, both for elements which would be common across much software, as well as for portions of the code which are dictated by external considerations such as efficiency or platform compatability, and so lack some originality.

Finally, there's the fact that copyright infringement has nothing to do with identicality, but rather has to do with originality. That is, it isn't unlawful for Alice's program to be identical to Bob's program, so long as Alice didn't copy her program from Bob. For many works, independent creation -- when it happens -- can still be tricky to show. But for closed source software, it would be tricky for the alleged infringer to have seen the source. The accused would want to have kept some records to help vindicate themselves, and if they did have some kind of access (e.g. Alice used to work for Bob's company and could reasonably have snuck a copy out), they'd have a pretty strong case. Reverse engineering can qualify as access -- e.g. if you decompile the binary -- but again, the underlying functionality isn't protected by copyright, only the way in which it is expressed can be, subject to the limits discussed above. That's why cleanroom reverse engineering is a good strategy to follow.

You might also want to look at the abstraction-filtration-comparison test in the Altai case to see how courts will often compare two pieces of software to see if there has been infringement.

Re:One extreme to the next

[cpt kangarooski]

No it's not. The presence of citations in a quote doesn't affect whether it is infringing or not. Rather, it is good practice for purposes of avoiding plagarism (which isn't illegal). Citing others' work, when it is used, is good academic and professional practice. Nothing to do with the law, though.

Re:Simplify the whole thing

[stony3k]

My idea is simply that multiple protections should not apply. You cannot both have trade secrets and copyrights. Think of books or paintings - by their very nature, they cannot be kept trade secret. Now the way to print the book or mix paints can be a trade secret, but not the book itself. Similarly the source code cannot be both a trade secret and copyrighted. Any techniques used to create the actual code can be kept trade secret, however.

Now it could be argued that the source code is only the 'recipe' and not the product itself and hence deserves copyright. But again if you think of copyrighted recipes, they need to have been published to be copyrighted. The minute you publish your recipe (in a book, magazine or online), it becomes copyright and loses its trade secret status.

I hope you get my point now.

Re:20 years!

[Chandon Seldon]

That scenario sounds great, doesn't it. We'll protect the little guy who invented something amazing from "unfair competition" by the big guy. Unfortunately, it doesn't work out that way in any significant number of cases.

Here's some more realistic scenarios:

• Some major company produces a new product. In the process, they come up with 753 different reasonably obvious ideas necessary to implement that product. They file for 753 patents, but the patent office only grants 218 of them. Small company separately produces an unrelated product that happens to use an idea they came up with that happens to look vaguely like one of the major company's patents. Small company ends up agreeing to pay $5,000,000 in protection money to avoid the lawsuit that they can't afford at all.
• Someone comes up with a good idea that to any professional in the field is so obvious that you wouldn't bother to write a paper about it. Say "storing session state information in an HTTP cookie". They think it's an amazing invention, so they file a patent. There's no explicit prior art in the literature, so the patent is granted. They then go around suing / collecting protection money from everyone using the technique.
• Here's my favorite: Small company invents something reasonably novel, gets a patent. Big company copies them. Small company sues. Big company counter-sues based on their massive collection of patents ("We have 23,751 patents - you're probably infringing something"). Small company ends up paying big company $20,000,000 to sign a cross licensing agreement. Big company continues to sell copied product, and has made $20 million.

At least that's how it works with software. Patents aren't about inventions, they're about "intellectual property portfolios" and "license fee revenue" and, more quietly, about excluding new entrants into existing markets.

Re:One extreme to the next

[Weedlekin]

"as someone familiar with the hardware patent world I've never understood why software people think that conflicting, overly-broad patents on the basic process required to achieve some end result are unique to software"

The objection people have to software patents is due to the fact that they cover concepts, not specific mechanisms that embody those concepts. Your example of thousands of different and possibly overlapping compressor designs illustrates this nicely, because applying software patent principles to the hardware world would mean that somebody could hold a patent on processes that reduce the volume of compressable fluids which would (in summary) read something like this:

1) The fluid is drawn or pumped in from a higher volume source.
2) One or more mechanical processes reduces its volume by compression.
3) The resultant compressed fluid is then either used directly, or stored in a suitable compression vessel.

So all those thousands of compressor designs would have to pay royalties to whoever owned that single broad patent on "Compressing Compressable Fluids", even though the patent itself doesn't tell people how to do any of the things it covers, so it's completely useless to anyone who has to design a compressor. Then, when people were breathing a sigh of relief because it's at the point of expiring, the patent office grants an extension because the original owner added some "innovative steps":

4) If used directly, the compressed fluid can distributed via rigid pipes or flexible tubes.
5) In cases where it is stored in a pressure vessel, the vessel may form part of the device.
6) If it is not part of the device, and therefore is a separate component, this component can be placed in a storage facility.
7) Components in storage facilities from step (6) can be given or sold* to others who do not possess a device for compressing compressable fluids.
*Please see separate patent number 8199477728 "A Process For Giving Away Or selling Stored Compressed Fluids"