Software, reverse engineering and the law

May 4, 2005

By Pamela Jones, Editor of Groklaw

Reading about proprietary software law is sometimes a shock, when you are used to the freedoms of the free software community, because your natural response to hearing how the law works outside the community is to say: "But that's awful. That can't be the law." And frankly there is nothing that advertises the benefits of free licenses as clearly as a brief rundown on what you can't do outside that realm of freedom. But with the recent flap about BitKeeper, it might be good to review what the current state of the law is on reverse engineering.

Unfortunately, if we define reverse engineering as "trying to figure out how something works," then the state of the law is that there are places on Planet Earth where there are laws restricting what you are allowed to do. The center of that restrictive universe right now is the US. Cem Kaner, Professor of Software Engineering and Director, Center for Software Testing Education & Research at the Florida Institute of Technology, believes that restrictions on reverse engineering are holding American programmers back from being able to compete:

The recent flurry of rulings that reverse engineering of mass-market products is not fair use have tied one arm behind American programmers' backs while leaving everyone else free to compete with us. . . . These days I teach university courses (undergrad through doctoral) as a Professor of Software Engineering at Florida Tech. We have a lot of grad students from other countries. They are often surprised by our restrictions on reverse engineering -- they certainly don't have their hands tied by these restrictions in their companies.

The United States used to have a commanding lead in software development. We have been steadily losing that lead. Part of the reason for this is that for the last 15 years, lawyers for software publishers have been pushing for short-term advantages for their clients over the long term health of the industry. The ban on reverse engineering is just another example -- we are shooting the American industry in the head, with little actual benefit for anyone (publisher or engineer) in the United States, but plenty of benefit for engineers in all the rest of the world.

Let's take a look at what you can and can't do around the world, when you wish to reverse engineer proprietary software. We can view it as we would learning about a repressive government's laws about dress code or some other issue you don't normally worry about, but need to study and obey for travel there, so you don't end up in the clink, so to speak, for wearing shorts or sandals or whatever else they have in their beanie as being worth making a law about.

I polled attorneys and engineers in the US, the UK, and Australia, and I've collected some resources as well, and I've found that there is a good deal of flux and some confusion in this area of law. I am not a lawyer, as you know, so if you need to know how the law applies in a particular situation in your area, please get advice from an attorney.

Why Do People Reverse Engineer Anyway?

People have many reasons why they might wish to reverse engineer software, but two important ones are 1) to make software that can interoperate with the software being studied and 2) to make a product that will compete with it. Why might the the knowledge not be visible? Dan Shearer, Samba Team and open source virtualization specialist, provides some possible reasons:

The original programmer is dead, or the company has died, or otherwise events have buried the explanation for how a technology works from the engineer and perhaps everyone else;
Commercial protection. A company feels its commercial goals would be compromised if the knowledge was published, so it keeps the knowledge secret (and often tries to obscure the knowledge so it is difficult for anyone to find it.)
Encumbrance on the knowledge. The knowledge might be published, but under such terms as anyone who agrees to the conditions under which the publication is made is limited in what he can do with it. Example: Microsoft's approach to detailed API sharing (Kerberos etc etc.) So the reverse engineer may choose not to see the knowledge. A basic encumbrance is sometimes cost for access to the documentation.

Having said that, the problem with seeking to know whether you can do reverse engineering or not is that it isn't consistent around the world, so your answer depends on where you do it and why.

A Brief US History of the Law on Reverse Engineering

Reverse engineering of manufactured products was originally designed, in US law, as a kind of balancing limit on trade secret protection, to ensure that a company couldn't gain, through that back door, a perpetual, unlimited monopoly on unpatented inventions. With manufactured products, the system worked well. As long as you bought the product legally, you were free to take it apart and see how it ticked. Most of us did that to clocks, radios and various other appliances when we were kids. We were free to do that because trade secret law didn't grant the owner the exclusive right to possess the secret. It only protected the owner against improper acquisition and/or disclosure of the trade secret.

That means that if I broke into your factory and stole your product and then reverse engineered it to figure out how you did it, it wasn't all right, but if I bought your product, it was perfectly legal, and you couldn't prevent me from discovering your secret, if I was willing to put in the time and effort to reverse engineer to obtain it. Reverse engineering was a lawful way to obtain a trade secret. And the time and effort involved was considered enough of a barrier that it gave the owner of the trade secret a measure of protection, by giving him a running start ahead of any copycats.

In fact, reverse engineering was considered to be a good thing, and in the 1989 U.S. Supreme Court decision, Bonito Boats, Inc. v. Thunder Craft Boats, Inc., the court said that reverse engineering was "an essential part of innovation," because it could lead to advances in technology. If you remember the DVD Copy Control Association v. Andrew Bunner case in California, it was a trade secrets case that held that reverse engineering is presumptively legal.

Both white box reverse engineering (decompiling the object code to reveal its structure and figure out the interface specifications for interoperability purposes) and black box reverse engineering (where you only look at a program's input and outputs) are legal normally in the US, if the goal is interoperability. I say normally because fair use is decided case by case. Bypassing anticircumvention devices, however, is a separate no no. Section 1201 of the DMCA forbids reverse engineering if it involves circumvention of a technological protection measure, with limited exceptions, such as for encryption research and security testing. You could probably get away with reverse engineering to fix something, and, while security testing is explicitly allowed under the DMCA, this exception is unclear enough that some have become afraid to avail themselves of it. Fred Von Lohmann of the EFF has described Section 1201 like this: "thou shalt not circumvent" and "do not break into my castle and do not violate my house rules -- seen from the perspective of a copyright holder".

Why Software is Different from a Cotton Gin

There are differences between reverse engineering a mechanical device, like a cotton gin, and reverse engineering software. Shearer says this about the difference:

By reverse engineering in software we generally mean one of the following:

Exposing knowledge not visible to the Reverse Engineer which is encapsulated in an computing/electronic format, without necessarily doing anything much with that knowledge. For example, I might reverse engineer a protocol and publish an opinion about whether or not it meets the standards the manufacturer of the software claims it does. Myth: reverse engineering involves creating software, necessarily. It often does in the sense that you need to test your assumptions as you reverse engineering, but the very act of figuring it out is reverse engineering. Very different from the mechanical use of reverse engineering.
Creating functional equivalency for something whose internals are obscured. The working result is an example of reverse engineering and it is usual that the internals of the result are very unlike the internals of the original. This differs greatly from the normal case in mechanical reverse engineering.

Another term is "decrypting". This is a specialized subset of reverse engineering.

Because computer software can be protected not only by trade secret law but by copyright and patent law as well, the issue of when you can and when you can't reverse engineer gets complex. If I invented the cotton gin, I could patent it for a time, gaining a monopoly for a time with the tradeoff that I must reveal all my secrets, or I could protect how I did it as a trade secret, and I couldn't use patents to protect the product at all. So my cotton gin invention got one form of protection, tops.

With software, you can get at least two bites of the apple simultaneously. Software is automatically copyrighted, and it can be patented too. And you can opt for trade secret protection instead of patents. Then you can slap a restrictive license on top, if the market will let you get away with it. And that is part of what makes it so complicated to figure out when you can and when you can't reverse engineer. It's also why some view software patents as overkill. Kaner on recent US decisions that reverse engineering is not fair use:

The saddest aspect of these rulings is that judges seem to have little understanding of what they are actually ruling on. For example, the court in Bowers v Baystate Technologies (Federal Circuit, 2002 U.S. App. LEXIS 17184) tells us that

In this case, the contract unambiguously prohibits "reverse engineering." That term means ordinarily "to study or analyze (a device, as a microchip for computers) in order to learn details of design, construction, and operation, perhaps to produce a copy or an improved version." Random House Unabridged Dictionary (1993); see also The Free On-Line Dictionary of Computing (2001).... Thus, the contract in this case broadly prohibits any "reverse engineering" of the subject matter covered by the shrink-wrap agreement.

This prohibits not only decompilation and disassembly but any detailed study of the product, including study by examining its behavior. It would forbid independent behavioral testing of a product by a third party (evaluating its security flaws, for example, prior to a purchase decision). It would forbid independent behavioral testing by a third party licensee for the purpose of publishing product reviews in a magazine.

Even a narrow ban on reverse engineering bans much, much more than competitive activity by another business. Take a look at http://www.kaner.com/pdfs/ucreveng.pdf. The examples provided in that article are banned by the industry-wide practice of including a didn't-used-to-be-enforceable prohibition of reverse engineering in their licenses.

The fact that software can be protected so many ways also means you can be sued on all of them - trade secret, copyright, patent and contract law theories - if you were unfortunate enough to have signed away your rights to reverse engineer (or to tell what you learned from doing so). Software licenses that forbid reverse engineering may or may not stand up to a challenge, but most folks think that they will. At any rate, there was a case where a federal court of appeals said that such a provision is enforceable and does not conflict with the Copyright Act, and the Supreme Court declined to review the decision, and they would have, if they had seriously disagreed. So be careful what you agree to.

Software is therefore a separate issue when it comes to reverse engineering. The time and effort involved isn't equivalent to reverse engineering a cotton gin, particularly with computers automating some of the heavy lifting.

When Can You Reverse Engineer? -- It Depends

Copyright protects the expression of an idea, but not the idea itself. That is why you can do reverse engineering to figure out how software works and then write your own program to do the same thing. The problem that arises with copyright and reverse engineering is well expressed in this explanation of how to avoid a copyright infringement claim:

If the same person both reverse engineers the old product and designs the new product, and there are similarities, it is hard to avoid an assumption that some copying has taken place, and so reverse engineering "best practice" involves breaking the chain, so far as possible, at the specification stage. The specification is made as abstract and functional as possible by the reverse engineers, and is then handed over to a "clean room" design team who have no other contact with the old product, or the team who analysed it, and who will then design the new product using as little low-level information as possible from the old product.

Patents protect the implementation of the idea, and that makes it the bully on the block, particularly in software, where there may be limited optimal ways to accomplish something. There is no fair use or reverse engineering exemption with patents. So you can argue all you want about how you had a fair use right to reverse engineer under copyright law, but if the part of the software you reverse engineered was also patented, you are, with some limited exceptions, sunk.

And how do you know in advance if you are going to end up violating a patent? Don't ask me. Nobody seems to know how to avoid violating someone's software patent under the current US system. You seem to find out mainly when someone sues you. Many observers believe the US patent system is broken and needs to be reformed, at a minimum, so that honest people can figure out how to avoid infringement. Meanwhile, ask your lawyer.

But just know that there is no reverse engineering right per se with patented inventions to find out how they work. It was originally the case that with patents you were supposed to reveal the tricks you used. It was the tradeoff. Sadly, software patents are now granted in the US without applicants having to reveal all the inner workings, so some legal commentators have argued that reverse engineering doesn't infringe under the first sale principle of patent law, or if you do it to satisfy your scientific curiosity, that you could assert an experimental use defense. And note that while under copyright law interfaces are not protected, they can be under patent law.

Whether or not reverse engineering is legal also depends, I've learned, on where you do it and why. Note that what matters is where the reverse engineering was done, not where the software was written. If you are in the US and you are doing it for interoperability purposes, as opposed to for the purpose of creating a similar and competitive product, you are probably safe from a copyright infringement claim, but may run afoul of a patent. (But in any particular situation, hire a lawyer to advise you.)

What About Outside the US?

The US is easy to figure out, compared to, say, Japan. At least in the US, they put it in writing. In Japan, it's assumed that reverse engineering for interoperability purposes is probably legal, but the law doesn't come right out and say so. In Japan, the law has no "fair use" concept for computer software, so reverse engineering is technically copyright infringement. Yet, as noted, most legal scholars say that reverse engineering is probably legal in Japan in a practical sense, even though their copyright law doesn't explicitly say that. Note that Japan does accept software patents.

Here's a PDF that tells you what you can use reverse engineering to accomplish in Australia, and as you can see, it's essentially similar to the US:

A computer program may be reproduced or adapted in order to get information necessary to enable an interoperable product to be made. The relevant provision also allows the person making the interoperable product to reproduce or adapt the original program in the interoperable product, but only to the extent necessary to enable interoperability either with that program or any other program.

I asked Brendan Scott, of Open Source Law, an expert on tech law there, if it would be accurate to say that you can do more in Australia than in the US, or if their new law is as restrictive; here is his answer:

Hard to say, since I don't have a good understanding of the US position. However, the A-US FTA [Free Trade Agreement] requires Australia to implement a provision relating to anti-circumvention. There is a 2-year period from the implementation of the FTA in which the anti-circumvention provisions must be implemented -- so they are not in our law at the moment.

At the moment there is an exception to infringement for the reproduction of literary works which are computer programs -- the issue is that a work may comprise both a literary work and subject matter which is not a literary work. If multiple copyright exists then the exception is a bit useless -- for the purposes of making interoperable programs (s 47D), to correct errors (s 47E) or for security testing (s 47F). Whether interoperability between programs includes interoperability between a program and some data has not been considered.

Further, if analysis of the program relies on reproducing anything which is not a literary work the exception won't help. The Full Federal Court has held that the "aggregate of the visual images generated by the playing of [specific video games - the subject of the suit] constituted a cinematograph film [ie something other than a literary work]" (Galaxy Electronics v Sega Enterprises [1997] 403 FCA). So there is definitely scope to argue that these exceptions are even narrower than they seem.

The anti-circumvention language in the FTA looks likely to keep lawyers employed for some time:

The anti-circumvention provisions in the FTA are marvelously Byzantine. I invite you to make sense of them on a first or second reading. Stucturally:

(a) they set up a number of prohibitions and a number of possible exceptions;
(b) implementing the prohibitions in local law is mandatory, implementing the exceptions is discretionary;
(c) no exceptions other than those set out in the relevant clause may be implemented;
(d) not all exceptions apply in respect of each prohibition;
(e) arguably, the prohibition on circumvention does not require that the circumvention be or lead to an infringement in order to be actionable -- removing a technological protection which has been applied to Hamlet will still be an infringement. The Hamlet argument is available where the words "a protected work" are read as meaning protected by the technological protection measure. They might also be read to mean "protected by this chapter" or "protected by copyright" which may have a different effect (in any event, bundling a protected with an unprotected work under the protection measure would probably still qualify);
(f) the exceptions to circumvention generally require that the circumvention itself be non infringing.

So, for example, 'non-infringing reverse engineering activities with regard to a lawfully obtained copy of a computer program, carried out in good faith with respect to particular elements of that computer program that have not been readily available to the person engaged in those activities, for the sole purpose of achieving interoperability of an independently created computer program with other programs' (17.4.7(e)(i)) is a possible exception to the prohibition, required to be implemented by the FTA, against circumventing protection measures. However, someone wishing to analyze a program covered by a protection measure would not only have to meet this requirement, they would also need to comply with section 47D of the Copyright Act. The relevant FTA provisions are here.

The current Copyright Act is available here.

In the European Union, reverse engineering is allowed under Article 6 of the European Software Directive, for interoperability purposes only, not for creating a competing program, and the law strictly limits what you can do with the knowledge you gain. You can't publish it, for example. As you know, the patent situation in the EU is a bit messy at the moment. Software patents are supposedly not allowed, after the Munich Convention, but folks have found ways, and that effort continues. Should the directive pass as presently written, it is expected to make reverse engineering of any patented materials illegal, except for limited exceptions. The directive also states that the ideas and principles underlying a program are not protected by copyright, and that logic, algorithms and programming languages may to some extent comprise ideas and principles.

There are some differences between US and UK law, and here's a paragraph from the UK Patent Office website on what constitutes a copy of a computer program in the UK:

Computer programs are protected on the same basis as literary works. Conversion of a program into or between computer languages and codes corresponds to "adapting" a work and storing any work in a computer amounts to "copying" the work. Also, running a computer program or displaying a work on a VDU will usually involve copying and thus require the consent of the copyright owner. The copyright owner will usually need to give permission for 'adapting' and 'copying' a work, however you may not need permission to make transient or incidental temporary copies.

There is no provision for decompilation (white-box reverse engineering) in UK copyright law, and no fair use defense if the reverse engineering is for commercial research or study. And, there is no right to breach confidentiality agreements. In Stac Electronics v. Microsoft Corp., Stac was found to have committed a trade secret violation by reverse engineering a beta version of MS DOS that they had gotten in confidence and then using the information they gained in making their own product. However, in the UK, the EU copyright directive trumps any contractual agreement that it contradicts, so decompilation carried out for the purpose of interoperability is allowed, under that umbrella, as long as you don't reveal any confidential data.

There is also a provision (50BA) made for "observing, studying and testing of computer programs":

(1) It is not an infringement of copyright for a lawful user of a copy of a computer program to observe, study or test the functioning of the program in order to determine the ideas and principles which underlie any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.

(2) Where an act is permitted under this section, it is irrelevant whether or not there exists any term or condition in an agreement which purports to prohibit or restrict the act (such terms being, by virtue of section 296A, void).

So, there is no fair use (or fair dealing, UK's much stricter escape hatch) for decompliation or copying during decompilation. However, sniffing (black-box reverse engineering) for interoperability purposes is allowed.

Note that the UK began to revise its patent law in January of 2005.

Summing Up

Kaner points out that there is research going on to make reverse engineering technically impossible:

I think the most interesting development in this area is technical, not judicial. Significant progress is being made on making object code essentially indecipherable. This is the subject of ongoing doctoral research in computing, industrial research, and at least one book in development.

Shearer brings up an interesting point:

Virtualization is the bane of the anti-reverse engineering crowd and especially the DRM and we-lock-down-your-hardware subtypes, although it is seldom identified as such. This is because if the hardware is in fact software, we can trick it to tell all sorts of lies or truths -- a bit like the old days of changing the operating system date back in time so your legal but time-restricted program would run. When a DRM-protected media player thinks it is drawing on a big digital LCD screen in may in fact be a window on your desktop - or a network connection to the world! And only run certain software on frotz-certified chipsets? No problem, just implement the chips in software.

The general trend in the law is to harmonize laws around the world, so they are interoperable, so to speak, to reach an international working consensus on what the laws on copyright and patents ought to be. It's obvious why that would bring benefits. Legislators can see that clearly. Unfortunately, not everyone in the world as readily sees the real benefits that come from interoperability in software.

Everyone sees the benefits of having train tracks be uniform, so you can get on a train in New York and arrive in California safely, and without having to get off and then on another train for another width of tracks. It's no different with software. And as software becomes more and more obviously the underpinning of a globalized society, including its commerce, hopefully more and more legislation will reflect that awareness.

In the meantime, please be careful. That includes using this article only as a jumping off point, and asking your attorney for advice for any real-world application of the law in your area of the world.

Additional resources

Please see this page for a set of pointers to additional reading in international copyright law and reverse engineering.

Index entries for this article
GuestArticles	Jones, Pamela

Software, reverse engineering and the law

Posted May 4, 2005 19:24 UTC (Wed) by lacostej (guest, #2760) [Link] (2 responses)

I have a question related to reverse engineering. Let's say that a company provides a library and I implement an open source tool that integrates with it (thanks to a plugin provided by someone else). Now in order for anyone to create a full binary version of the open source tool, one needs to have access to this third party library. Unfortunately this library might not be redistributable.

So I've made a mock library that I intend to redistribute freely. It's an interface-only version of the library (no implementation at all) which is complete enough for anyone to correctly compile the tool.

To create this mock library I've used a 2 step procedure: someone wrote a client of that official library, and I wrote the mock library based on the client's code. I never had access to the official library.

My questions are:
- does anyone think that this action could be considered illegal? (After all my mock library needs to use the exact same names as the original one)

- does anyone think that a tool that automates the writing of this mock library could be illegal? The tool could use a 2 step approach as described above, or a one step one, reading the official library and producing the mock from it right away.

Comments appreciated.

jerome(at)coffeebreaks.org

Software, reverse engineering and the law

Posted May 4, 2005 20:04 UTC (Wed) by MathFox (guest, #6104) [Link]

For your first question: I can't say; IANAL and jurisdiction and licences are very important here. See a real lawyer.

I see no problems with a program that takes an interface specification and writes out a skeleton implementation of the interface. (As long as it is an original work that doesn't infringe patents.) There is a snag here: A judge will consider the output from your program a "derivative work" from the input. Running the program on a third party library could be against its license conditions.

Software, reverse engineering and the law

Posted May 4, 2005 22:08 UTC (Wed) by khim (subscriber, #9252) [Link]

The only one who can do something illegal is person who wrote client program. If there were nothing in library license preventing this then everything should be legal.

Writing such a tool is not illegal - it's usage can be illegal if library in question has really strict license.

Software, reverse engineering and the law

Posted May 4, 2005 19:27 UTC (Wed) by littlejohn (guest, #17354) [Link] (1 responses)

I'm European and there's a friend of mine who is writing a decompiler. From the article above there are no considerations for people who build tools which could be strictly related to reverse engineering. From my experience a debugger and a decompiler are more than enough for almost any reverse engineering task, and these tools are far from being unlawful. But how easy could it be to prove a decompiler is used for legal (referring to the current law) tasks?

Software, reverse engineering and the law

Posted May 4, 2005 20:22 UTC (Wed) by MathFox (guest, #6104) [Link]

Document what you are doing with it!

In general: you don't have to prove your innocence, in a civil case "the preponderance of evidence" has to show your wrongdoing; in a criminal case the proscecutor has to prove your guilt "beyond reasonable doubt". The mere presence of tools like "objdump" and "gdb" is no indication of illegal activities.
If you are seriously considering to do some reverse engineering, discuss your plans with a lawyer before you start. He can tell you what the law does and doesn't allow and he can help you to document the steps that you take, such that the probability of conviction is minimized.

Difficult for a farm boy like me

Posted May 4, 2005 22:21 UTC (Wed) by ccyoung (guest, #16340) [Link] (17 responses)

I'm having real difficulty. When "software patents" and "EULA's" are being talked about, this is coming close to how "extortion" and "blackmail" were explained to me when I was a young man.

This reminds me of the Middle Ages when commerce began to die in part because each rich duke along the roadway or canal wanted his cut.

To patent a protocol or interface is nuts. It's anti-capitalism. It's simply a means to block innovation and commerce, or make it illegal. It's much more difficult than prohabition because more police chiefs like to drink more than program. But like prohatition it's forcing whole generations into breaking the law just to have a little fun. Give me a break.

Personally, I do my programming in Thailand. Paying off a corrupt cop there is literally pennies compared to paying off unnamed corporations here. And my sites are hosted in that wonderful hippy country call elsewhere.

Back in the US, back in the US, back in the ...

Difficult for a farm boy like me

Posted May 5, 2005 1:49 UTC (Thu) by tjc (guest, #137) [Link] (15 responses)

I'm having real difficulty. When "software patents" and "EULA's" are being talked about, this is coming close to how "extortion" and "blackmail" were explained to me when I was a young man.

As far as I can tell the main difference between software patents and extortion is the matter of legality. Extortion is illegally using one's position of power or influence to obtain some benefit, whereas a software patent is government-granted permission to do so legally within the scope of the patent. Is this correct?

Difficult for a farm boy like me

Posted May 5, 2005 10:14 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (14 responses)

Yes, you're pretty much right that a patent is a legal right to obtain money or a monopoly using threats (of legal enforcement). Extortion is much the same except the right claimed is not legally granted and the threat is prohibited rather than legally sanctioned.

Our legislatures seem to have forgotten why patents were first introduced: to preserve knowledge and to allow progress extending beyond one person's lifetime. Originally a master craftsman kept his best tricks secret, so as to prevent every other lesser craftsman from undercutting him. If the world was lucky he trained an apprentice or two, or pooled his knowledge within a guild of master craftsmen. But all too often, knowledge died with its posessors.

A patent was a legal monopoly to exploit an idea and to prevent others from doing so, granted in exchange for full disclosure. After the patent expired, anyone could use the idea. There was no longer any risk of it dying with its inventor. Progress once made was progress forever.

It's time that full disclosure is again insisted on as part of a patent. There should be a hard line between a patent and a trade secret: if the patent makes insufficient disclosure for it to be easily copied after the patent expires, it should automatically be invalid.

Difficult for a farm boy like me

Posted May 5, 2005 11:28 UTC (Thu) by tjasper (subscriber, #4310) [Link]

Perhaps also, patents should have a much shorter lifespan - like two years - before being made public. Software develops so fast that they should relate to the lifetime of the product. When cotton gins were invented, patents were useful for half a lifetime, enough for people to benefit from the invention. With software, if it is patentable at all, then it should be for half the life of the product and four years is about the useful life of a software product. After two years, the patented software should be made public for the greater benefit of all, just as patents do/did for more mechanical based inventions for everyone in the past.

Just my $0.02 worth

Trevor

Difficult for a farm boy like me

Posted May 6, 2005 23:20 UTC (Fri) by giraffedata (guest, #1954) [Link] (9 responses)

As a contract lawyer, I am frequently amused by how people are willing to call any sale "extortion" if they don't like the terms.

Here's the difference: extortion is an offer to sell something that the seller has a moral obligation to give for free. It's a form of theft. That moral obligation is, of course, highly subject to personal values and biases. Consequently, statutes that outlaw extortion just cover very specific cases of it and the argument "this is extortion, your honor," just doesn't appear in court (at least not when parties are represented by lawyers).

Examples (of the terminology, not any particular statutes):

For $1000, I offer to give you my car. Not extortion.
For $1000, I offer not to punch you in the face. Extortion.
For $1000, I offer not to tell any one but you how my invention works. Not extortion.
For $1000, I offer not to tell your wife where you were last Thursday. Extortion.
For $1000, I offer to vote for your shareholder proposal (which I favor anyway). Not extortion.
For $1000, I offer to vote for your zoning ordinance (which I favor anyway). Extortion.

"Blackmail," by the way is a subset of extortion. It's extortion where the thing offered is not to tell someone something.

Our laws tend to reflect our collective morals, so it's reasonable to say that when you offer to sell something that you're legally entitled not to give, then it's not extortion. So where the law explicitly says you're allowed to stop someone from practicing your invention, it's not extortion to demand payment from him not to.

with all due respect

Posted May 7, 2005 23:34 UTC (Sat) by ccyoung (guest, #16340) [Link] (6 responses)

you certainly know more about this than me.

but consider if I were to take a couple of week programming, and, using common sense in this profession, say, "it'd be cool if the user moved her mouse this way then that would happen," or say, "in this XML format I'll let the user define a macro that could have a dynamic effect on what the user sees." what if there were an unnamed company with unlimited resources that patented these ideas. are you saying I no longer "own" them? does the company now have right to come after me however it chooses because I applied commons sense to my profession?

this is patently absurd.

consider if you like to barbeque on weekends and have actually gotten pretty good at it. your innovation is to marinate your brisket and then freeze it a little before grilling to help set the juices. however, Kraft has patented this method. you're legally allowed to freeze your brisket only if you pay Kraft a royalty each time you light your charcol. say you own a steakhouse - Kraft comes to your door saying you don't even know how many pantents of ours you are violating every night straight off your menu - it really makes sense just to pay us this yearly fee.

there's the beef.

are you going to hire $50,000 for a patent attorney? no, if you own that steakhouse you're just going to pay. if you are in your backyard, you're just going to ignore those Kraft patents as being completely absurd.

forgive my lack of sophistication, but this sure as hell sounds like extortion to me. that the government might be complicit really makes no difference.

with all due respect

Posted May 8, 2005 18:09 UTC (Sun) by giraffedata (guest, #1954) [Link] (5 responses)

You bring up several ways the patent system isn't right, but it isn't clear that any of it amounts to extortion.

In your last paragraph, you hint that the barbecuer doesn't legally owe the royalties -- that if he paid for legal process, he wouldn't have to pay the royalties. If that's true, and Kraft knows it, then we have extortion. Kraft has a moral (and often legal!) obligation to leave him alone for free, but is offering to sell it. This has nothing to do with patents; this kind of extortion exists throughout the legal system.

But if Kraft really has a case, you have to dig deeper to find any extortion. You have to base it on a personal belief (which many don't share) that a person can't morally own an invention of this type. Much like many people believe one can't morally own, in one way or another, a person, a body part, or land.

With respect to some of the other problems you brought up: I am not a patent lawyer; most of what I know about patents comes from places like LWN reader comments. But I can tell you this:

US patent law requires an invention to be nonobvious to have patent protection. The US patent office seems to be largely ignoring that rule these days, but courts have been sticking to it better. If you can invent something by "applying common sense to [your] profession," it's legally "obvious."

The fact that independent invention doesn't excuse you from patent liability (i.e. if I invent something without knowing that you already did, I still can't use the invention) is based on the original purpose of patents referred to in an earlier comment: The patent protection is compensation for contributing an invention to the public (within limits). It's not a recognition of a moral right of an inventor to his ideas. The guy who gave the mouse invention to the public did his part; as a member of the public, your part is to pay him when you use it, regardless of whether you had the same idea.

I believe with the current state of technology, the public is getting a bad deal on most patents -- it's paying for inventions that would have been contributed anyway, because there would be no way to keep it secret and it cost practically nothing to invent.

extortion - a rose by any other name

Posted May 9, 2005 0:45 UTC (Mon) by ccyoung (guest, #16340) [Link] (1 responses)

Example One:

1. using your definition that an idea that any one of 100K hackers could have "appl[ied] common sense to [his/her] profession," it's legally "obvious", assume more than 90% of all software patents are nonobvious.

2. assume that corporation A collects these patents.

3. assume that corporation A has, for all practical purposes, unlimited resources.

4. assume you are Corporation B, a software house or company that writes software in-house.

5. assume that Corporation A tells you that you are violating their patents and that it would be in your best interest to pay for usage of those patents.

what are your choices of action?
a) take them to court and fight them over serval years at the cost of several million dollars, with your business dead in the water.
b) pay them off.

Example Two

1. assume you have a small but thriving restaurant in New York.

2. assume Mr Saprano visits you, telling you many restaurants have had many violations and, if you pay him monthly, he will arrange it so you don't have similar problems.

what are your choices of action?
a) take them to court and fight them over serval years at the cost of several million dollars, with your business dead in the water.
b) pay them off.

Your point is that, if it's legal, it's not extortion. My point is that, if I cannot show it's illegal, it doesn't matter.

My second point is that if I see someone hurt and I need to drive on the wrong side of the road to help them then I'll drive on the wrong side of the road. What's the discussion?

It's why I mentioned prohabiton - it was a collosal failure because people simply ignored it - and ignored it with gaity. Whenever I boot up my Linux it says, "have fun!"

extortion - a rose by any other name

Posted May 9, 2005 16:03 UTC (Mon) by giraffedata (guest, #1954) [Link]

Isn't example One the same as from your previous comment? So the analysis is the same. You hint that Corporation A's patents aren't valid -- otherwise, option (a) (taking A to court) wouldn't be an option. That being the case, there's extortion just like in the Soprano example. Corporation A is obligated to leave you alone for free, just as Mr. Soprano is obligated not to trump up charges against you, for free. Offering to perform the obligation for money is extortion.

The transfer of a patent from one person to another doesn't really change the morality of the patent at all. The inventor was paid by the public with a patent for disclosing his invention. The inventor converted the payment to cash by selling the patent to Corporation A. Corporation A is converting its investment to cash by enforcing the patent. The system's doing what it's supposed to do.

Your point is that, if it's legal, it's not extortion.

It wasn't that simple. I talked about moral, not legal. I drew a connection between the two, saying that the fact that something is legal is a strong indication that society in general believes it is moral. Society has caused patent law to exist and grow for hundreds of years. Lots of people must believe in it -- I.e. believe it's moral to demand payment for use of an invention.

My point is that, if I cannot show it's illegal, it doesn't matter.

I agree. It is extortion, and wrong, and often illegal, to file or defend a lawsuit when you know you're legally wrong, in hopes that the other side will find it cheaper to pay you than pay legal fees. This is not a patent issue. But I believe this thread started out with discussion of patents that are valid under present patent law.

1. using your definition that an idea that any one of 100K hackers could have "appl[ied] common sense to [his/her] profession," it's legally "obvious", assume more than 90% of all software patents are nonobvious.

I don't think it's germane to the extortion question, but: from what I've seen, about 2% of software patents are nonobvious.

My second point is that if I see someone hurt and I need to drive on the wrong side of the road to help them then I'll drive on the wrong side of the road. What's the discussion?

I agree. I didn't think we were discussing that.

"non-obvious" non-obvious

Posted May 10, 2005 0:43 UTC (Tue) by roelofs (guest, #2599) [Link] (2 responses)

That's not how I understand it from speaking to at least a couple of patent lawyers/attorneys. My understanding is that the "non-obvious" rule is decided on an almost algorithmic basis, one that could be described in terms of an automaton (my terminology). To wit: given as input all patents and publicly disclosed prior art to date, if an automaton could glue various bits together to come up with your "invention," it's obvious. Anything else is non-obvious.

I don't claim that either my memory, my understanding, or that of the folks to whom I spoke is correct, but at least in the latter case, this is what they do professionally, so I tend to believe them. On the other hand, even if everything I've said is fundamentally correct, there's obviously still plenty of room for interpretation on the part of the examiners (as I've found out the hard way on at least one occasion). One can also see a little more easily how a lot of stupid patents have gotten granted over the years.

"non-obvious" non-obvious

Posted May 10, 2005 4:11 UTC (Tue) by giraffedata (guest, #1954) [Link] (1 responses)

Yeah, that does seem consistent with the patents we see in the news. What I remember is some words from the one patent class I took 15 years ago. I distinctly remember the words, "a person skilled in the art" in the definition of obvious. Something like, "A person skilled in the art, faced with the same problem, would reasonably be expected to arrive at the same invention."

On the other hand, lets remember that all the silly patents we hear about are just issued -- I never hear about them actually standing up in court. The patent office may be taking a less-than-legal stance on the obviousness test, biasing itself toward granting patents.

"non-obvious" non-obvious

Posted May 10, 2005 15:18 UTC (Tue) by roelofs (guest, #2599) [Link]

I distinctly remember the words, "a person skilled in the art" in the definition of obvious. Something like, "A person skilled in the art, faced with the same problem, would reasonably be expected to arrive at the same invention."

Yes, I think that's more or less the exact statement of law (or whatever) surrounding patentability. But that just pushes the definition question back a step: how do you define "skilled in the art"? That's where the definition I gave comes in--someone who knows everything (that's been published) and can rearrange bits of it to make arbitrary new combinations but who is incapable of any creative insights, no matter how trivial. As poor as this definition sounds, if you think about it, it may be the best you can do--at least it's prescriptive, whereas almost any other definition of "skilled" is wide open to interpretation.

Difficult for a farm boy like me

Posted Jun 1, 2005 0:56 UTC (Wed) by wookey (guest, #5501) [Link] (1 responses)

Thank you for that set of explanatory examples. However, not being USian I didn't understand the distinction the last two are trying to elcuidate:
# For $1000, I offer to vote for your shareholder proposal (which I favor anyway). Not extortion.
# For $1000, I offer to vote for your zoning ordinance (which I favor anyway). Extortion.

Could you clarify why one of these is extortion and the other one isn't. I suspect the main problem is that I have no idea what a 'zoning ordnance' is - sounds like something to do with local government?

Extortion vs legitimate sale

Posted Jun 1, 2005 2:42 UTC (Wed) by giraffedata (guest, #1954) [Link]

"Ordinance" means statute. For some reason, statutes passed by local jurisdictions (city or county) are called ordinances. (Statutes, btw, are what most people call "laws," but lawyers recognize that law can come from places other than legislation, so prefer the more precise term "statute.").

A zoning ordinance is an ordinance that tells what uses of a piece of land are permissible. (It's called that because the form it takes is that it divides the city into zones -- this part is the residential zone; that part is the industrial zone, etc.) A zoning ordinance can shift wealth enormously, so the process is ripe for corruption.

A city council member has a moral obligation to vote for a zoning ordinance if he believes it is in the city's best interest. Therefore, offering to a developer to vote for it for $1000 is extortion. Remember the basic definition: offering to sell something you're morally obligated to give for free.

In a business corporation, shareholder votes are pure business. There's no morally right or wrong vote; it's all about the money. Shareholders vote to try to maximize their own wealth, and are free to sell their votes. And just as it's OK for me to charge $1000 rent for a building even if it otherwise would have been vacant, it's OK to ask $1000 for a vote even if I wanted to vote that way anyhow.

Difficult for a farm boy like me

Posted May 6, 2005 23:33 UTC (Fri) by njhurst (guest, #6022) [Link] (2 responses)

Perhaps software patents should be required to give a complete implementation to be released into the public domain on completion of the patent interval?

Difficult for a farm boy like me

Posted May 12, 2005 14:37 UTC (Thu) by zakaelri (guest, #17928) [Link] (1 responses)

From what I read above concerning patents, and the handful of patents I have seen before (maybe on the order of 2 or 3), I thought that was the point of the patent. Otherwise, I could patent "amino-based toilet bowl cleaner" and be done with it.

Then again, I believe that most people feel our patent system needs to be re-thought.

Difficult for a farm boy like me

Posted May 25, 2005 22:10 UTC (Wed) by njhurst (guest, #6022) [Link]

I think they have to have a description that others can understand, but I was suggesting a further requirement that an actually usable implmentation be included. That is, the actual source code used.

wonderful hippy country

Posted May 6, 2005 23:21 UTC (Fri) by giraffedata (guest, #1954) [Link]

my sites are hosted in that wonderful hippy country call elsewhere.

Excuse me -- what does this say?

Software, reverse engineering and the law

Posted May 5, 2005 12:51 UTC (Thu) by vblum (guest, #1151) [Link]

So do I read correctly:

The European software directive would not only implement patents. but also prohibit someone from reverse engineering, say, Microsoft's SMB protocols, and making availabla a competing product under the GPL?

If this were true, it would be at least as grave as the patents proposal, in my view - a second obstacle for the creation of competition, if the first, obvious bait (patents) happens to be thrown out.

Is that so?

EU Software Copyright Directive being reviewed

Posted May 5, 2005 15:40 UTC (Thu) by j_heald (guest, #15398) [Link]

As well as the ongoing debate over the Software Patents Directive, which is now of course at the legislative stage, the EU Commission is also currently doing preliminary thinking about how or whether the Software Copyright Directive should be amended.

Interestingly IBM, which in the 1980s was at the forefront of efforts to limit when decompilation and white-box reverse engineering should be allowed, is now at the forefront of the opposite position, calling on the Commission to do whatever it can to sweep away barriers to interoperability (including interoperability by directly competing programs).

The question of patent use rights for interoperability is also one of the issues very much in play in the Software Patents Directive, in particular the new Article 6a proposed by the European Parliament, but initially rejected by the EU Council of Ministers.