FreeType, a FOSS project developing a font rendering engine, cheers on its webpage the expiration of three Apple patents related to the rendering of TrueType fonts.
While those patents were valid, the project disabled one technical component called the "bytecode interpreter" and called on its users not to use it even though the program code was in place. Now that functionality is enabled by default. Yesterday FreeType just released its latest version, 2.4.1.
Two of the three Apple patents in question were filed for in May 1989. The third one was applied for in 1992, and I presume Apple decided not to renew it because there wasn't much (if any) commercial value left after the other two TrueType patents were past the end of the 20-year maximum term of validity of US software patents.
[Update] Through Slashdot I became aware of a juxtaposition of two screenshots that shows what difference in quality the "bytecode" algorithm makes. It's pretty visible. [/Update]
It was interesting to read this because two days ago I commented on Richard Stallman's concerns over patents that could affect Mono and DotGNU and in that context I said that if RMS wants a totally patent-unencumbered development platform, it will have to be more than 20 years old. Plus it would have had to be open-sourced back then because without publication something cannot serve as prior art (meaning as a previous invention in order to invalidate patents filed later). Even the slightest change to a code base during that time span could result in some new patent infringement. But the part that's more than 20 years old is (provided that it was published back then) safe.
The FreeType example shows that sometimes useful things do become available for free thanks to patent expiration. That doesn't solve all problems, but every useful thing is potentially good news for someone. In this case, for the FreeType folks, who probably had been awaiting that moment for many years.
Several years ago, the nastiest patent related to the Graphics Interchange Format (GIF) also expired. Unisys had acted pretty much like a patent troll because its core business was in bad shape and the GIF patent became a key asset to the once-great company.
That GIF patent is the only important software patent expiration I had been aware of before reading about TrueType.
In political debates over whether or not software should be patentable, I criticized the 20-year term as being way too long for software. In a speech I gave at a demonstration against software patents in Munich in April 2004, I said that the patents reaching the end of the 20 years at that time were basically from the heyday of the Commodore 64. That was about right, although the IBM PC was already a few years old in 1984, and the Commodore Amiga was launched a year later. The TrueType stuff is now at least from the era of the breakthrough of Windows.
It will be interesting to see which FOSS projects will benefit from the expiration of the next relevant software patents.
If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.
Monday, July 19, 2010
Saturday, July 17, 2010
Richard Stallman's Mono and DotGNU patent concerns
Glyn Moody, a true FOSS expert among journalists and author of the OpenDotDotDot blog, has interviewed Richard Stallman, the founder of the software freedom movement, by email to discuss RMS's concerns over software patents in connection with free implementations of the .NET programming interface (Mono and DotGNU).
Glyn's article was published by Computerworld UK.
To sum up the key points, RMS stated the following in the interview:
RMS's utopian advice runs counter to commercial logic and fails to advance the cause of software freedom
Adopting his advice would be an utterly stupid decision for any developer from a business point of view, which is actually normal because RMS's agenda is all about software freedom and not at all about commercial success. But even from a non-commercial free software point of view I think this kind of advice doesn't make sense in the world in which we actually live.
The only alternatives in terms of programming languages and platforms that could perhaps be supported under RMS's premises would have had to be open-sourced in exactly the same form more than 20 years ago (without even the smallest modification made ever since) and then the new software one writes on top of it today wouldn't be guaranteed to be truly free software for another 20 years. 20 years is the potential life expectancy of a software patent, and I'll explain the logic of this further below.
So unless someone wants to waste 20 years or even an entire professional life of 40 years just for the sake of an ideology, it's better to reject such utopian advice and take a realistic perspective on patent-related risks.
There's no particular reason not to develop software for .NET (as compared to any other platform on this planet), and free implementations of .NET such as Mono and DotGNU aren't really less free than a free Java application server or a PHP interpreter for Apache.
RMS focuses on the lesser risk and ignores the greater one
The fundamental mistake made by RMS in the aforementioned interview is that he narrows the whole patent-related risk down to only one company (Microsoft), which actually has a stronger commercial interest than any other in the world to make the .NET platform popular and to ensure developers succeed with the applications they build on top of it. And we all know how much competition there is between platform companies for the hearts and minds of developers. More importantly, Richard completely ignores the fact that hostilities against Mono and DotGNU could also come from other patent holders.
Even if one sides with RMS concerning what the greater risk is and rejects my business logic for the platform company itself being most likely to want the best for its application developers, no one can reasonably deny that there's a huge number of patent holders other than Microsoft whom RMS fails to take into consideration. That mistake is sufficient all by itself -- regardless of how to assess the different risks -- to prove RMS's advice concerning C#, .NET, Mono and DotGNU wrong in the sense that there are also patent risks concerning any other programming language or platform out there.
Yes, free software is incompatible with patents, but software patents exist on pretty much every kind of software technology and therefore I don't think one can make the case that free .NET implementations or software written to run on them is inherently less free than other software available under the same licenses.
Time heals the wounded and invalidates patents
In the patent minefield that exists, there's no such thing as a reliably patent-unencumbered programming language or API (application programming interface) except for a hypothetical scenario of no practical relevance. That scenario is one in which all patents that may read on the platform have either expired or can be easily invalidated.
Since software patents (at least in the jurisdictions I know) have a maximum term of validity of 20 years and patented ideas must be new by the time of the application (or they can be invalidated later on the basis of "prior art"), one can argue that if software was published (as open source) more than 20 years ago, all patents will either have expired or the published source code (which should be time-stamped to prove its vintage year) could be used as prior art to take down younger patents on the same technology.
Therefore, free software developers would have to use free platforms that are more than 20 years old (and were published as free software back then, not just later). The applications they write couldn't be guaranteed to be patent-unencumbered for another 20 years after the publication of their source code.
In other words, the price to be paid for a guarantee of being patent-unencumbered is to be decades behind the evolution of technology, and to be extremely patient relative to the duration of a human professional life.
The pragmatic alternative is to regard free software as a great idea and a wonderful vision, but to understand that patents make all software potentially non-free, regardless of whether the patents in question are held by Microsoft or anyone else.
The solution proposed by RMS (an "ironclad commitment") would be desirable but insufficient
At the end of the interview, RMS made the proposal I mentioned in item 3 of my summary of his position at the beginning of this posting. He said that Microsoft should make an "ironclad commitment" not to use current or future patents against free implementations of the .NET API.
I, for my part, would very much welcome such a commitment. But I disagree that it would make all the difference that RMS suggests it would make. It wouldn't solve the problem of third-party patents. Every other current or future software patent holder in the world would also have to make that promise in order for RMS's vision to materialize.
The second part also applies to platforms for which the original developer makes an "ironclad" patent promise. Even a free programming language like PHP can infringe and almost certainly will infringe on some third-party patents out there, unless you take a programming platform that was open-sourced more than 20 years back (as I explained further above).
So I strongly recommend to focus on how patent holders actually use their rights. In that respect, I will comment on Microsoft in greater detail in some other posting, but I can already say at this stage that there simply isn't any evidence of Microsoft using patents in a way that would drive companies out of business or jeopardize the existence of FOSS projects.
Don't cut off your nose to spite your face
RMS also refers to Eben Moglen's assessment that Microsoft's Open Specification Promise "is not something we can rely on." I can see why Richard and Eben say so. But I can also see reasons for which one could say the same about (to name but a few examples) Red Hat's patent policy, the promises Oracle made concerning the acquisition of MySQL (without wanting to comment on what Oracle is doing now), Google's vague assurances concerning WebM, the Open Invention Network's arbitrary scope of protection, or IBM's broken patent pledge.
Concerning IBM's pledge, I remember that RMS also commented on it unfavorably back in 2005 when it was made (not as aggressively as I did, but it was clear that Richard also rejected that approach). So he's aware of the fact that vendors don't make those public commitments in an "ironclad" form. That's a general problem and it's not particular to .NET, C#, Mono and DotGNU. Nor are the other concerns voiced by RMS specific to those technologies.
That's why I think a decision to write software for .NET, or to implement .NET interfaces in free software, isn't a statement against freedom any more than using any other current platform: Java, PHP, you name it. But acting in accordance with RMS's advice would be a self-imposed restriction of freedom, for no good reason.
With the greatest respect (which he deserves), he sometimes proposes to cut off one's nose to spite one's face.
If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.
Glyn's article was published by Computerworld UK.
To sum up the key points, RMS stated the following in the interview:
- Due to patents held by Microsoft on its .NET technology, the availability of two .NET implementations (Mono and DotGNU) under free software licenses doesn't mean that free software developers should, according to RMS, write code for the platform. His call on the free software community: "You shouldn't write software to use .NET. No exceptions." RMS says that Microsoft could one day use patents against free .NET implementations.
- RMS thinks that the C# ("C Sharp") programming language should also be avoided. He makes a distinction between that one and .NET because C# was "standardized by a standards committee" and Microsoft made "a stronger commitment" concerning patents than for alternative implementations of other elements of .NET.
- As a requirement for RMS to encourage the development of free software on free implementations of .NET, Micosoft would have to "make an ironclad commitment that its present and future patents will never be used against implementations of DotNET."
RMS's utopian advice runs counter to commercial logic and fails to advance the cause of software freedom
Adopting his advice would be an utterly stupid decision for any developer from a business point of view, which is actually normal because RMS's agenda is all about software freedom and not at all about commercial success. But even from a non-commercial free software point of view I think this kind of advice doesn't make sense in the world in which we actually live.
The only alternatives in terms of programming languages and platforms that could perhaps be supported under RMS's premises would have had to be open-sourced in exactly the same form more than 20 years ago (without even the smallest modification made ever since) and then the new software one writes on top of it today wouldn't be guaranteed to be truly free software for another 20 years. 20 years is the potential life expectancy of a software patent, and I'll explain the logic of this further below.
So unless someone wants to waste 20 years or even an entire professional life of 40 years just for the sake of an ideology, it's better to reject such utopian advice and take a realistic perspective on patent-related risks.
There's no particular reason not to develop software for .NET (as compared to any other platform on this planet), and free implementations of .NET such as Mono and DotGNU aren't really less free than a free Java application server or a PHP interpreter for Apache.
RMS focuses on the lesser risk and ignores the greater one
The fundamental mistake made by RMS in the aforementioned interview is that he narrows the whole patent-related risk down to only one company (Microsoft), which actually has a stronger commercial interest than any other in the world to make the .NET platform popular and to ensure developers succeed with the applications they build on top of it. And we all know how much competition there is between platform companies for the hearts and minds of developers. More importantly, Richard completely ignores the fact that hostilities against Mono and DotGNU could also come from other patent holders.
Even if one sides with RMS concerning what the greater risk is and rejects my business logic for the platform company itself being most likely to want the best for its application developers, no one can reasonably deny that there's a huge number of patent holders other than Microsoft whom RMS fails to take into consideration. That mistake is sufficient all by itself -- regardless of how to assess the different risks -- to prove RMS's advice concerning C#, .NET, Mono and DotGNU wrong in the sense that there are also patent risks concerning any other programming language or platform out there.
Yes, free software is incompatible with patents, but software patents exist on pretty much every kind of software technology and therefore I don't think one can make the case that free .NET implementations or software written to run on them is inherently less free than other software available under the same licenses.
Time heals the wounded and invalidates patents
In the patent minefield that exists, there's no such thing as a reliably patent-unencumbered programming language or API (application programming interface) except for a hypothetical scenario of no practical relevance. That scenario is one in which all patents that may read on the platform have either expired or can be easily invalidated.
Since software patents (at least in the jurisdictions I know) have a maximum term of validity of 20 years and patented ideas must be new by the time of the application (or they can be invalidated later on the basis of "prior art"), one can argue that if software was published (as open source) more than 20 years ago, all patents will either have expired or the published source code (which should be time-stamped to prove its vintage year) could be used as prior art to take down younger patents on the same technology.
Therefore, free software developers would have to use free platforms that are more than 20 years old (and were published as free software back then, not just later). The applications they write couldn't be guaranteed to be patent-unencumbered for another 20 years after the publication of their source code.
In other words, the price to be paid for a guarantee of being patent-unencumbered is to be decades behind the evolution of technology, and to be extremely patient relative to the duration of a human professional life.
The pragmatic alternative is to regard free software as a great idea and a wonderful vision, but to understand that patents make all software potentially non-free, regardless of whether the patents in question are held by Microsoft or anyone else.
The solution proposed by RMS (an "ironclad commitment") would be desirable but insufficient
At the end of the interview, RMS made the proposal I mentioned in item 3 of my summary of his position at the beginning of this posting. He said that Microsoft should make an "ironclad commitment" not to use current or future patents against free implementations of the .NET API.
I, for my part, would very much welcome such a commitment. But I disagree that it would make all the difference that RMS suggests it would make. It wouldn't solve the problem of third-party patents. Every other current or future software patent holder in the world would also have to make that promise in order for RMS's vision to materialize.
The second part also applies to platforms for which the original developer makes an "ironclad" patent promise. Even a free programming language like PHP can infringe and almost certainly will infringe on some third-party patents out there, unless you take a programming platform that was open-sourced more than 20 years back (as I explained further above).
So I strongly recommend to focus on how patent holders actually use their rights. In that respect, I will comment on Microsoft in greater detail in some other posting, but I can already say at this stage that there simply isn't any evidence of Microsoft using patents in a way that would drive companies out of business or jeopardize the existence of FOSS projects.
Don't cut off your nose to spite your face
RMS also refers to Eben Moglen's assessment that Microsoft's Open Specification Promise "is not something we can rely on." I can see why Richard and Eben say so. But I can also see reasons for which one could say the same about (to name but a few examples) Red Hat's patent policy, the promises Oracle made concerning the acquisition of MySQL (without wanting to comment on what Oracle is doing now), Google's vague assurances concerning WebM, the Open Invention Network's arbitrary scope of protection, or IBM's broken patent pledge.
Concerning IBM's pledge, I remember that RMS also commented on it unfavorably back in 2005 when it was made (not as aggressively as I did, but it was clear that Richard also rejected that approach). So he's aware of the fact that vendors don't make those public commitments in an "ironclad" form. That's a general problem and it's not particular to .NET, C#, Mono and DotGNU. Nor are the other concerns voiced by RMS specific to those technologies.
That's why I think a decision to write software for .NET, or to implement .NET interfaces in free software, isn't a statement against freedom any more than using any other current platform: Java, PHP, you name it. But acting in accordance with RMS's advice would be a self-imposed restriction of freedom, for no good reason.
With the greatest respect (which he deserves), he sometimes proposes to cut off one's nose to spite one's face.
If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.
Saturday, July 10, 2010
The silver lining in the Bilski decision isn't where most people believe
About two weeks ago the Supreme Court of the United States (SCOTUS) handed down its opinion in re Bilski, a business method patent case. The patent application was rejected, but in a way that didn't draw any kind of line that would affect patents on software technology.
I commented on it within about an hour of its publication, concluding that the decision didn't invalidate even one software patent (the Bilski application itself wasn't a software patent application) and that only a decision to grant a patent on the Bilski application could have been any less restrictive. On the following day I listed the top ten losers.
Meanwhile discussion has continued and I've read a number of other opinions. Some of those were very realistic, such as Steven Vaughan-Nichols's analysis. Others took a more optimistic perspective and argued that the narrow scope of the ruling left the door open to more restrictive decisions in the future.
As the saying goes, every cloud has a silver lining. So where is it in the Supreme Court's Bilski opinion? There is one, but it's not where others seem to think it is. I'll start with where I believe many others are on the wrong track.
The "abstract idea" approach is a losing strategy
The conclusion from the Bilski ruling that patents on software technologies might one day be invalidated on the basis of being abstract ideas -- which is how the non-software Bilski application got rejected by the SCOTUS -- is
Ideological blindness is the number one reason to which I attribute the fact that software patent abolitionism hasn't made any real headway (other than some defensive success).
There are many different angles from which one can come to the conclusion that software should be a largely or entirely patent-free field. Often when I talk to people who have that belief, it turns out that each person believes his reasoning for why software patents are undesirable is the truth and the winning argument. There are activists who think like it; there are also executives of smaller companies whose narrow perspective prevents them from recognizing that politics bears some -- but only limited -- resemblance with marketing.
Let's better face this fact: there isn't a single killer argument against software patents that will convince a non-programmer if that same counterpart has also heard the pro-patent argument. If you can ever convince a majority of decision-makers, you'll have to do it indirectly. The direct approach has been tried by many people for many years -- to no avail (except, as I mentioned before, in a defensive situation).
The Bilski case was likened to two past cases and deemed different from a third past case
A lot of FOSS advocates basically argue that since the SCOTUS didn't explicitly say that software must be patentable, there's always a chance to go back with another case. That's just wrong. It's a typical exhortation to hold out (or, more precisely, to cling to a flawed strategy).
Don't let others fool you just because they don't want to adjust to reality. Here's a non-legalese explanation of what the SCOTUS really said.
The SCOTUS clearly stated that it did not want to issue a wide-ranging ruling with unintended consequences on other areas of patentable subject matter than the Bilski type of non-software business methods. And the SCOTUS determined that it wasn't really forced to overshoot: there already were precedents for similar concepts that were found unpatentable on the grounds of representing "abstract ideas."
The dreamers who think that software patents could be abolished on that same basis base their hopes on the fact that the SCOTUS didn't specify a set of rules that would define what an unpatentable "abstract idea" is. Experts would say: the court didn't establish a legal test (or a set of legal tests) that can be used to make that determination.
But the SCOTUS gave a couple of examples, and in the usual case-law style, those are cases put before it in the past. The court found that -- without even attempting to put it onto an objective basis -- the Bilski application was of a very similar nature as the ideas held unpatentable in two past cases (Benson and Flook). The court furthermore determined that the Bilski application didn't have enough in common with the patent considered valid in the Diehr case.
Without digressing into the details of those cases, let me just say that Benson and Flook related to general ideas without a very specific application and implementation. In my opinion, the Diehr patent shouldn't have been granted either, but there's no denying the fact that it was much more specifically tied to a technical purpose than Benson and Flook -- and than Bilski, of course.
There was a lot of disappointment among patent abolitionists that the SCOTUS didn't seize the opportunitay presented by the Bilski case to do some more specific line-drawing. While no one wanted to insult the court directly, the criticism suggested a lack of courage. I don't think that's fair. I believe the SCOTUS was right to find that the Bilski case per se presented nothing that hadn't been answered by it before. It was more of the same, and that's why it was the waste of time and money that the Software Freedom Law Center said it became. The case just wasn't suitable to what some people -- such as the SFLC -- would have liked to achieve. So don't blame the court.
The SCOTUS didn't draw a clear line but gave plenty of hints
Obviously a ruling based exclusively on similarities to past cases (without elaborating on inhowfar there were common elements) is less clear than a set of rules. The court almost implied that "if something is an abstract idea, we'll see it anyway." In the meantime, people should just look at the examples and draw inferences from those.
But the SCOTUS made some clear statements in its reasoning as far as software patents are concerned. Note that in the following I'm referring to some passages of the reasoning that were written by Justice Kennedy, who also presented the majority opinion, but those particular passages were not supported by Justice Scalia.
On page 9 of the decision, a more restrictive approach was rejected because it "would create uncertainty as to the patentability of software, advanced diagnostic medicine techniques, and inventions based on linear programming, data compression, and the manipulation of digital signals." While that is based on a reference to position papers (amicus briefs) submitted by pro-software-patent organizations, the way the SCOTUS refers to those concerns leaves no doubt that the justices who supported the passage agreed that the Bilski decision shouldn't cause collateral damage in those areas.
Now look at that list again: if even "data compression" should be patentable in principle, there's just no way that software would be considered too abstract an idea. Data compression is the kind of software patent that is closest to pure mathematics. One may argue -- and I personally believe -- that it is essentially pure mathematics and the argument of proponents of patentability that it's "applied mathematics" doesn't convince me at all. I can see "applied mathematics" in play if a car brake is computer-controlled to maximize its efficiency. I can't dismiss the idea that computer graphics can involve "applied mathematics" (I may not want patents on graphics algorithms for other reasons). But with "data compression" I just consider it incredible that some people would (and actually do) claim that those are "applied" as opposed to pure mathematics.
So if there's such a widespread belief that data compression should remain patentable in the Information Age (and that's what it does unless one wants to just interpret the ruling in completely unreasonable ways), then this suggests to me that the entirety of patents on software technologies is safely outside of whatever the SCOTUS would consider an "abstract idea."
The SCOTUS makes it very clear that as new technologies evolve, the patent system was intended (by the Founding Fathers) to expand accordingly, unless there's legislative intervention to restrict it. In this regard, a majority of the court also referred to "technologies for conducting a business more efficiently" (which I mentioned in connection with what Bilski means for Salesforce.com).
That's just one of several examples -- but in my opinion the best one -- of where the SCOTUS makes it clear that at least some business methods must be patentable.
So if even software-implemented business methods are patentable, there's just no way that future SCOTUS rulings would hold typical software patents to be "abstract ideas" and therefore unpatentable.
Ideologues will say that software is a product of authorship rather than of engineering. I understand some of the reasoning and I support it, but many critics of software patents are just unrealistic in terms of how they make that point. Claiming that software development is closer to composing music than to electrical engineering is crazy. I've been in the software industry for 25 years now and I've always referred to software as "technology" and to professional programmers as "software engineers", even though I can also see what programming has in common with writing. Having authored twelve computer books, I believe I can -- and I do -- appreciate that.
So programming has common elements with both engineering and authoring: that doesn't mean I can deny the engineering part of it just because I don't want to deal with patents in my field. I can have other reasons, but that one isn't a useful argument.
The idea that every software patent is just an abstract idea is an abstract idea in and of itself. And it won't get us nowhere.
The actual silver lining: the SCOTUS' remark on striking the balance
Radicals are always more receptive to fundamentalism than to an argument based on striking a reasonable balance. But the latter is what works best to convince rational decision-makers.
Near the top of page 10, the Bilski decision contains a wonderful passage that is infinitely more helpful with a view to the future than the whole "abstract idea" thing:
The quoted passage basically says: In the past there was a much smaller number of people who came up with potentially patentable ideas as part of their work. There were a few scientists in laboratories (not literally, but that's roughly the idea). These days there are tens or hundreds of millions of people who have a computer at home or at work and know how to program it, and maybe the traditional approach taken under patent law doesn't work well in such a situation and results in too many patents and -- a highly important aspect -- too many incidents of inadvertent infringement through independent creation.
While that doesn't sum up all of the reasons for which I dislike software patents, it addresses the core part of it. I mentioned in other contexts that my fundamental problem with software patents is the risk of inadvertent infringement. With copyright, that risk exists in a theoretical form but not in a practical one. With patents, it's a serious issue, especially in the field of software.
I believe that the oppponents of software patents should focus on that part of the Bilski opinion and try to build a case on that basis. Maybe there shouldn't be just another legal case because the SCOTUS also stated on several occasions that the courts "should not read into the patent laws limitations and conditions which the legislature has not expressed." But at the very least the quoted passage from the decision gives some guidance in terms of how the case should be presented to lawmakers.
I know that many in this movement won't want to go down that avenue for the fear that the outcome would be some patent quality initiative as opposed to abolition. And if such a patent quality initiative didn't live up to expectations, it wouldn't change anything. I understand. I share the concern. But I don't see any other silver lining in the Bilski decision (as far as the majority position is concerned). The argument that the number of innovators is huge and that too many patents result in too much inadvertent infringement is one that non-programmers can understand. Unlike the "abstract idea" that won't ever have any material impact.
If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.
I commented on it within about an hour of its publication, concluding that the decision didn't invalidate even one software patent (the Bilski application itself wasn't a software patent application) and that only a decision to grant a patent on the Bilski application could have been any less restrictive. On the following day I listed the top ten losers.
Meanwhile discussion has continued and I've read a number of other opinions. Some of those were very realistic, such as Steven Vaughan-Nichols's analysis. Others took a more optimistic perspective and argued that the narrow scope of the ruling left the door open to more restrictive decisions in the future.
As the saying goes, every cloud has a silver lining. So where is it in the Supreme Court's Bilski opinion? There is one, but it's not where others seem to think it is. I'll start with where I believe many others are on the wrong track.
The "abstract idea" approach is a losing strategy
The conclusion from the Bilski ruling that patents on software technologies might one day be invalidated on the basis of being abstract ideas -- which is how the non-software Bilski application got rejected by the SCOTUS -- is
- a gross misinterpretation of the ruling, blatantly ignoring the court's unambiguous endorsement of patents on software technologies,
- an ideological argument that bears no legal or political weight with a majority of reasonable decision-makers,
- and, therefore, destined to remain unproductive at best and counterproductive at worst.
Ideological blindness is the number one reason to which I attribute the fact that software patent abolitionism hasn't made any real headway (other than some defensive success).
There are many different angles from which one can come to the conclusion that software should be a largely or entirely patent-free field. Often when I talk to people who have that belief, it turns out that each person believes his reasoning for why software patents are undesirable is the truth and the winning argument. There are activists who think like it; there are also executives of smaller companies whose narrow perspective prevents them from recognizing that politics bears some -- but only limited -- resemblance with marketing.
Let's better face this fact: there isn't a single killer argument against software patents that will convince a non-programmer if that same counterpart has also heard the pro-patent argument. If you can ever convince a majority of decision-makers, you'll have to do it indirectly. The direct approach has been tried by many people for many years -- to no avail (except, as I mentioned before, in a defensive situation).
The Bilski case was likened to two past cases and deemed different from a third past case
A lot of FOSS advocates basically argue that since the SCOTUS didn't explicitly say that software must be patentable, there's always a chance to go back with another case. That's just wrong. It's a typical exhortation to hold out (or, more precisely, to cling to a flawed strategy).
Don't let others fool you just because they don't want to adjust to reality. Here's a non-legalese explanation of what the SCOTUS really said.
The SCOTUS clearly stated that it did not want to issue a wide-ranging ruling with unintended consequences on other areas of patentable subject matter than the Bilski type of non-software business methods. And the SCOTUS determined that it wasn't really forced to overshoot: there already were precedents for similar concepts that were found unpatentable on the grounds of representing "abstract ideas."
The dreamers who think that software patents could be abolished on that same basis base their hopes on the fact that the SCOTUS didn't specify a set of rules that would define what an unpatentable "abstract idea" is. Experts would say: the court didn't establish a legal test (or a set of legal tests) that can be used to make that determination.
But the SCOTUS gave a couple of examples, and in the usual case-law style, those are cases put before it in the past. The court found that -- without even attempting to put it onto an objective basis -- the Bilski application was of a very similar nature as the ideas held unpatentable in two past cases (Benson and Flook). The court furthermore determined that the Bilski application didn't have enough in common with the patent considered valid in the Diehr case.
Without digressing into the details of those cases, let me just say that Benson and Flook related to general ideas without a very specific application and implementation. In my opinion, the Diehr patent shouldn't have been granted either, but there's no denying the fact that it was much more specifically tied to a technical purpose than Benson and Flook -- and than Bilski, of course.
There was a lot of disappointment among patent abolitionists that the SCOTUS didn't seize the opportunitay presented by the Bilski case to do some more specific line-drawing. While no one wanted to insult the court directly, the criticism suggested a lack of courage. I don't think that's fair. I believe the SCOTUS was right to find that the Bilski case per se presented nothing that hadn't been answered by it before. It was more of the same, and that's why it was the waste of time and money that the Software Freedom Law Center said it became. The case just wasn't suitable to what some people -- such as the SFLC -- would have liked to achieve. So don't blame the court.
The SCOTUS didn't draw a clear line but gave plenty of hints
Obviously a ruling based exclusively on similarities to past cases (without elaborating on inhowfar there were common elements) is less clear than a set of rules. The court almost implied that "if something is an abstract idea, we'll see it anyway." In the meantime, people should just look at the examples and draw inferences from those.
But the SCOTUS made some clear statements in its reasoning as far as software patents are concerned. Note that in the following I'm referring to some passages of the reasoning that were written by Justice Kennedy, who also presented the majority opinion, but those particular passages were not supported by Justice Scalia.
On page 9 of the decision, a more restrictive approach was rejected because it "would create uncertainty as to the patentability of software, advanced diagnostic medicine techniques, and inventions based on linear programming, data compression, and the manipulation of digital signals." While that is based on a reference to position papers (amicus briefs) submitted by pro-software-patent organizations, the way the SCOTUS refers to those concerns leaves no doubt that the justices who supported the passage agreed that the Bilski decision shouldn't cause collateral damage in those areas.
Now look at that list again: if even "data compression" should be patentable in principle, there's just no way that software would be considered too abstract an idea. Data compression is the kind of software patent that is closest to pure mathematics. One may argue -- and I personally believe -- that it is essentially pure mathematics and the argument of proponents of patentability that it's "applied mathematics" doesn't convince me at all. I can see "applied mathematics" in play if a car brake is computer-controlled to maximize its efficiency. I can't dismiss the idea that computer graphics can involve "applied mathematics" (I may not want patents on graphics algorithms for other reasons). But with "data compression" I just consider it incredible that some people would (and actually do) claim that those are "applied" as opposed to pure mathematics.
So if there's such a widespread belief that data compression should remain patentable in the Information Age (and that's what it does unless one wants to just interpret the ruling in completely unreasonable ways), then this suggests to me that the entirety of patents on software technologies is safely outside of whatever the SCOTUS would consider an "abstract idea."
The SCOTUS makes it very clear that as new technologies evolve, the patent system was intended (by the Founding Fathers) to expand accordingly, unless there's legislative intervention to restrict it. In this regard, a majority of the court also referred to "technologies for conducting a business more efficiently" (which I mentioned in connection with what Bilski means for Salesforce.com).
That's just one of several examples -- but in my opinion the best one -- of where the SCOTUS makes it clear that at least some business methods must be patentable.
So if even software-implemented business methods are patentable, there's just no way that future SCOTUS rulings would hold typical software patents to be "abstract ideas" and therefore unpatentable.
Ideologues will say that software is a product of authorship rather than of engineering. I understand some of the reasoning and I support it, but many critics of software patents are just unrealistic in terms of how they make that point. Claiming that software development is closer to composing music than to electrical engineering is crazy. I've been in the software industry for 25 years now and I've always referred to software as "technology" and to professional programmers as "software engineers", even though I can also see what programming has in common with writing. Having authored twelve computer books, I believe I can -- and I do -- appreciate that.
So programming has common elements with both engineering and authoring: that doesn't mean I can deny the engineering part of it just because I don't want to deal with patents in my field. I can have other reasons, but that one isn't a useful argument.
The idea that every software patent is just an abstract idea is an abstract idea in and of itself. And it won't get us nowhere.
The actual silver lining: the SCOTUS' remark on striking the balance
Radicals are always more receptive to fundamentalism than to an argument based on striking a reasonable balance. But the latter is what works best to convince rational decision-makers.
Near the top of page 10, the Bilski decision contains a wonderful passage that is infinitely more helpful with a view to the future than the whole "abstract idea" thing:
This Age puts the possibility of innovation in the hands of more people and raises new difficulties for the patent law. With ever more people trying to innovate and thus seeking patent protections for their inventions, the patent law faces a great challenge instriking the balance between protecting inventors and not granting monopolies over procedures that others would discover by independent, creative application of general principles.This passage is another reason for which I think a lot of critics of the decision are biased. What I just quoted shows that the justices supporting that passage understood very well that there may be a problem with software patents. However, a majority of the SCOTUS didn't consider the Bilski case the right occasion on which to address it, and it may not even regard any future case as an opportunity to determine "where that balance ought to be struck."
The quoted passage basically says: In the past there was a much smaller number of people who came up with potentially patentable ideas as part of their work. There were a few scientists in laboratories (not literally, but that's roughly the idea). These days there are tens or hundreds of millions of people who have a computer at home or at work and know how to program it, and maybe the traditional approach taken under patent law doesn't work well in such a situation and results in too many patents and -- a highly important aspect -- too many incidents of inadvertent infringement through independent creation.
While that doesn't sum up all of the reasons for which I dislike software patents, it addresses the core part of it. I mentioned in other contexts that my fundamental problem with software patents is the risk of inadvertent infringement. With copyright, that risk exists in a theoretical form but not in a practical one. With patents, it's a serious issue, especially in the field of software.
I believe that the oppponents of software patents should focus on that part of the Bilski opinion and try to build a case on that basis. Maybe there shouldn't be just another legal case because the SCOTUS also stated on several occasions that the courts "should not read into the patent laws limitations and conditions which the legislature has not expressed." But at the very least the quoted passage from the decision gives some guidance in terms of how the case should be presented to lawmakers.
I know that many in this movement won't want to go down that avenue for the fear that the outcome would be some patent quality initiative as opposed to abolition. And if such a patent quality initiative didn't live up to expectations, it wouldn't change anything. I understand. I share the concern. But I don't see any other silver lining in the Bilski decision (as far as the majority position is concerned). The argument that the number of innovators is huge and that too many patents result in too much inadvertent infringement is one that non-programmers can understand. Unlike the "abstract idea" that won't ever have any material impact.
If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.
Thursday, July 1, 2010
{Interoperability} Significant market players to face EU interoperability rules
Amid all the brouhaha over the European Commission's approach to open standards, there's been hardly any attention for an exciting initiative that could greatly advance the cause of interoperability (the ability to make different IT products work together efficiently, such as through application programming interfaces and the exchange of data).
The aforementioned new initiative aims to create a legal requirement for interoperability that would affect all "significant market players", not only the ones who fall under the scope of antitrust law.
An oversimplified description of what a fundamental change this would mean is that the kinds of interoperability requirements the European Commission previously imposed on Microsoft with respect to Windows could then also affect others, such as Apple, Nokia and RIM with respect to their smartphones, or Adobe with respect to Flash, PDF and Photoshop. And many others.
"Significant" is the key word. Antitrust law can be used to fight abuse of a "dominant" market position. Dominating a market implies a sizeable gap between a market leader and the rest. That legal test puts many powerful companies beyond reach for antitrust proceedings, but a wider circle of non-dominant companies can clearly be considered significant and it's time to do something about them.
This wouldn't mean an exploding number of antitrust cases. On the contrary, a major design goal is to achieve interoperability without having to go through lengthy antitrust proceedings. At the end of the process there would be a new European law, specific to the subject of interoperability between IT products. It would set out the rules for all significant players in that market.
The legislative process hasn't begun yet. The European Commission is now going to explore the feasibility of this plan, and if there's green light, then the actual lawmaking process will likely begin in 2012. This will take time, but it can have such a profound and highly positive impact that it's worth it.
Free software and open source can gain from this in two ways. One, software that is available under a FOSS license will probably meet all of the criteria set out by the possible new law. Two, a number of proprietary software vendors beyond the reach of antitrust law would be required to make interfaces and data formats available to all competitors, including FOSS-based competitors, on a fair, reasonable and non-discriminatory basis. Short of abolishing software patents, it's hard to imagine a FOSS-friendlier legislative initiative.
I recently heard the European Commission's Vice President for the Digital Agenda, Neelie Kroes, talk about this idea at a Brussels event. It became clear that she's very enthusiastic about this, and rightly so. She said in a recent interview: "Any kind of IT product should be able to communicate with any type of service in the future." This could be great stuff indeed.
You now have the basic idea, and I will report on this initiative when there are new developments. This one is just the first posting in a four-part series on the subject. Click here for the second part, which discusses the regulatory gap that currently exists because many major companies are not dominant in a legal sense. And by the way, you can follow me on Twitter @FOSSpatents.
The aforementioned new initiative aims to create a legal requirement for interoperability that would affect all "significant market players", not only the ones who fall under the scope of antitrust law.
An oversimplified description of what a fundamental change this would mean is that the kinds of interoperability requirements the European Commission previously imposed on Microsoft with respect to Windows could then also affect others, such as Apple, Nokia and RIM with respect to their smartphones, or Adobe with respect to Flash, PDF and Photoshop. And many others.
"Significant" is the key word. Antitrust law can be used to fight abuse of a "dominant" market position. Dominating a market implies a sizeable gap between a market leader and the rest. That legal test puts many powerful companies beyond reach for antitrust proceedings, but a wider circle of non-dominant companies can clearly be considered significant and it's time to do something about them.
This wouldn't mean an exploding number of antitrust cases. On the contrary, a major design goal is to achieve interoperability without having to go through lengthy antitrust proceedings. At the end of the process there would be a new European law, specific to the subject of interoperability between IT products. It would set out the rules for all significant players in that market.
The legislative process hasn't begun yet. The European Commission is now going to explore the feasibility of this plan, and if there's green light, then the actual lawmaking process will likely begin in 2012. This will take time, but it can have such a profound and highly positive impact that it's worth it.
Free software and open source can gain from this in two ways. One, software that is available under a FOSS license will probably meet all of the criteria set out by the possible new law. Two, a number of proprietary software vendors beyond the reach of antitrust law would be required to make interfaces and data formats available to all competitors, including FOSS-based competitors, on a fair, reasonable and non-discriminatory basis. Short of abolishing software patents, it's hard to imagine a FOSS-friendlier legislative initiative.
I recently heard the European Commission's Vice President for the Digital Agenda, Neelie Kroes, talk about this idea at a Brussels event. It became clear that she's very enthusiastic about this, and rightly so. She said in a recent interview: "Any kind of IT product should be able to communicate with any type of service in the future." This could be great stuff indeed.
You now have the basic idea, and I will report on this initiative when there are new developments. This one is just the first posting in a four-part series on the subject. Click here for the second part, which discusses the regulatory gap that currently exists because many major companies are not dominant in a legal sense. And by the way, you can follow me on Twitter @FOSSpatents.
{Interoperability} Market dominance vs. significance: closing a regulatory gap
This posting is the second one in a four-part series on a legislative initiative for interoperability currently being evaluated by the EU. Click here for the first part of the series (a brief overview of what this is all about).
EU competition law has four main areas: cartels, mergers, state aid, and cases against the abuse of a dominant market position.
The fourth area is the one to leverage if you aim to restrict the way a single powerful company (that doesn't form a cartel with others) uses its patents. That part of the law can only solve a problem if a company (i) dominates its market AND (ii) behaves in a way that is considered anticompetitive (such as refusing to disclose technical information necessary to interoperate with its dominant products, or wielding its patent arsenal to shut down reverse engineering of the same).
In connection with interoperability, the Microsoft case has established some helpful principles. In fact, the EU leads the world by example as far as interoperability is concerned, in no small part thanks to Mrs. Kroes's work as competition commissioner in recent years. The most recent example of how companies with an interoperability concern rest their hopes on the EU is a complaint by a US company named Versata against SAP.
However, if a company is not dominant in a competition law sense, then there's simply no case, neither in the EU nor in any other jurisdiction I know (such as the US) on the grounds of an abuse of a market position.
Even many big players can claim not to be dominant
Many companies can escape that part of the law because the legal test for market dominance is a very high hurdle. If a company has a quasi-monopoly and dwarfs its competitors, then it's certainly dominant in the given market. But if it's "only" a clear number one, there could still be enough competition in the market that dominance must be denied.
Let me give you an example for how high a hurdle it is: in my personal opinion, Oracle dominates the market for database software. It has roughly a 50% market share based on revenues, and it acquired MySQL, which is by far and away the most popular open source database. However, if a court of law had to decide whether Oracle is dominant in a legal sense, the counterargument would be that IBM's DB2 and Microsoft SQL Server are competitive forces to be taken into account.
Whether or not a company is dominant heavily depends on how the relevant market is defined: geographically and in terms of product characteristics. In the total worldwide market for mobile phones, Apple would probably not be considered dominant because Nokia still sells more units, the collective volume of Android-based phones is quite high, and RIM (BlackBerry) is also strong. But in a more narrowly defined subset of the market, Apple's market share could be considered to be much higher. Also, Apple could be considered dominant as an online music distributor or as a distributor of iPhone/iPad applications.
The outcome of the dominance test is always binary: there is a case, or there isn't. There can be intervention, or there can't. As a result, there's a huge regulatory gap.
While a few companies are considered dominant in certain markets, such as Microsoft for client PC operating systems or IBM for mainframes, there are many others who are also extremely powerful and have their customers locked in, but under antitrust rules they can't be pursued no matter what they do.
The EU can't and won't try to expand the scope of antitrust law as a whole. But the European Commission has apparently recognized that it shouldn't be required to bear the burden of proof that a company is dominant only to ensure interoperability. There should be a general obligation affecting not only dominant players but also the much wider circle of "significant market players", many of whom could also use their intellectual property rights (especially patents) to limit choice and stifle innovation.
How to define significance, such as in terms of percentage of market share, is one of many things the Commission is now presumably pondering.
For the next (third) posting in this four-part series on legislative initiative for interoperability currently being evaluated by the EU, please click here.
EU competition law has four main areas: cartels, mergers, state aid, and cases against the abuse of a dominant market position.
The fourth area is the one to leverage if you aim to restrict the way a single powerful company (that doesn't form a cartel with others) uses its patents. That part of the law can only solve a problem if a company (i) dominates its market AND (ii) behaves in a way that is considered anticompetitive (such as refusing to disclose technical information necessary to interoperate with its dominant products, or wielding its patent arsenal to shut down reverse engineering of the same).
In connection with interoperability, the Microsoft case has established some helpful principles. In fact, the EU leads the world by example as far as interoperability is concerned, in no small part thanks to Mrs. Kroes's work as competition commissioner in recent years. The most recent example of how companies with an interoperability concern rest their hopes on the EU is a complaint by a US company named Versata against SAP.
However, if a company is not dominant in a competition law sense, then there's simply no case, neither in the EU nor in any other jurisdiction I know (such as the US) on the grounds of an abuse of a market position.
Even many big players can claim not to be dominant
Many companies can escape that part of the law because the legal test for market dominance is a very high hurdle. If a company has a quasi-monopoly and dwarfs its competitors, then it's certainly dominant in the given market. But if it's "only" a clear number one, there could still be enough competition in the market that dominance must be denied.
Let me give you an example for how high a hurdle it is: in my personal opinion, Oracle dominates the market for database software. It has roughly a 50% market share based on revenues, and it acquired MySQL, which is by far and away the most popular open source database. However, if a court of law had to decide whether Oracle is dominant in a legal sense, the counterargument would be that IBM's DB2 and Microsoft SQL Server are competitive forces to be taken into account.
Whether or not a company is dominant heavily depends on how the relevant market is defined: geographically and in terms of product characteristics. In the total worldwide market for mobile phones, Apple would probably not be considered dominant because Nokia still sells more units, the collective volume of Android-based phones is quite high, and RIM (BlackBerry) is also strong. But in a more narrowly defined subset of the market, Apple's market share could be considered to be much higher. Also, Apple could be considered dominant as an online music distributor or as a distributor of iPhone/iPad applications.
The outcome of the dominance test is always binary: there is a case, or there isn't. There can be intervention, or there can't. As a result, there's a huge regulatory gap.
While a few companies are considered dominant in certain markets, such as Microsoft for client PC operating systems or IBM for mainframes, there are many others who are also extremely powerful and have their customers locked in, but under antitrust rules they can't be pursued no matter what they do.
The EU can't and won't try to expand the scope of antitrust law as a whole. But the European Commission has apparently recognized that it shouldn't be required to bear the burden of proof that a company is dominant only to ensure interoperability. There should be a general obligation affecting not only dominant players but also the much wider circle of "significant market players", many of whom could also use their intellectual property rights (especially patents) to limit choice and stifle innovation.
How to define significance, such as in terms of percentage of market share, is one of many things the Commission is now presumably pondering.
For the next (third) posting in this four-part series on legislative initiative for interoperability currently being evaluated by the EU, please click here.
{Interoperability} Procedural framework: an action item in the Digital Agenda
This posting is the third one in a four-part series on a legislative initiative for interoperability currently being evaluated by the EU. Click here for the first part of the series (a brief overview of what this is all about) or here for the previous part, which discusses a regulatory gap that currently exists.
In terms of a legislative process, this one isn't even in its infancy. It's in a prenatal state. I believe there's a pretty good chance that the underlying idea will result in a new law within a couple of years. But if, when and in which form will depend on the process.
Legislative proposals at the EU level don't come as surprises. There's always some deliberation prior to kick-off, and while a lot of meetings are private, the overall direction in which an initiative is heading is written and talked about in public.
The idea of possible legislation on interoperability requirements for significant market players is part of a comprehensive work program called Digital Agenda for Europe. The official working document (HTML, PDF, other languages) was published in the second half of May. It identifies eight "action areas" and 16 "key actions" as well as many items that are called "other actions".
Subsection 2.2.3 of the Digital Agenda talks about ways to enhance interoperability and makes the following statement that I'll quote and explain:
The word "license" makes it clear that intellectual property rights are involved. In the interoperability context, patents are particularly relevant, and they are information documents (hence the word "patent"). But the Commission's wording leaves room for additional options.
The bold-face passage is very broad and vague. To "lead significant market players to [...]" could per se mean anything from politely asking to soft pressure to the creation of legal obligations. Below that paragraph, there's a list of action items. The last one of them is:
A legislative initiative is the preferred course of action
A recent speech by the European Commission's Vice President for the Digital Agenda, Neelie Kroes, made it perfectly clear that the measure she wants to take is to create a new piece of legislation:
At this stage, many key aspects of the future proposal have not yet been determined. Here's another quote from Mrs. Kroes speech that underscores the need for consultation and deliberation:
For the next (and final) posting in this four-part series on legislative initiative for interoperability currently being evaluated by the EU, please click here.
In terms of a legislative process, this one isn't even in its infancy. It's in a prenatal state. I believe there's a pretty good chance that the underlying idea will result in a new law within a couple of years. But if, when and in which form will depend on the process.
Legislative proposals at the EU level don't come as surprises. There's always some deliberation prior to kick-off, and while a lot of meetings are private, the overall direction in which an initiative is heading is written and talked about in public.
The idea of possible legislation on interoperability requirements for significant market players is part of a comprehensive work program called Digital Agenda for Europe. The official working document (HTML, PDF, other languages) was published in the second half of May. It identifies eight "action areas" and 16 "key actions" as well as many items that are called "other actions".
Subsection 2.2.3 of the Digital Agenda talks about ways to enhance interoperability and makes the following statement that I'll quote and explain:
Since not all pervasive technologies are based on standards the benefits of interoperability risk being lost in such areas. The Commission will examine the feasibility of measures that could lead significant market players to license interoperability information while at the same time promoting innovation and competition.The meaning of this is that in addition to official standards controlled by consortia, there can also be de facto standards (such as data formats or interfaces that are as widely used as official standards) belonging to individual companies. The European Commission would like to ensure that such companies don't monopolize their data formats and interfaces.
The word "license" makes it clear that intellectual property rights are involved. In the interoperability context, patents are particularly relevant, and they are information documents (hence the word "patent"). But the Commission's wording leaves room for additional options.
The bold-face passage is very broad and vague. To "lead significant market players to [...]" could per se mean anything from politely asking to soft pressure to the creation of legal obligations. Below that paragraph, there's a list of action items. The last one of them is:
Examine the feasibility of measures that could lead significant market players to license interoperability information to report by 2012.This is still very broad. It adds specificity in the sense that the Commission wants to know by 2012 which options it has. But a speech provided clarification.
A legislative initiative is the preferred course of action
A recent speech by the European Commission's Vice President for the Digital Agenda, Neelie Kroes, made it perfectly clear that the measure she wants to take is to create a new piece of legislation:
Whereas in ex-post investigations we have all sorts of case-specific evidence and economic analysis on which to base our decisions, we are forced to look at more general data and arguments when assessing the impact of ex-ante legislation. Just to be clear, while it is still early days, it is certainly possible that I will go for a legislative proposal.Not only was the preferred way forward clarified but also that the envisaged measure will be far-reaching:
This could have a profound impact on the industry concerned so it is not a decision taken lightly. Many of you work for companies that could be concerned by such a measure. I invite you all to let me have your views.This invitation for stakeholders to communicate their positions to the Commission suggests that a formal consultation process will take place sooner or later. That's the usual approach taken by the Commission.
At this stage, many key aspects of the future proposal have not yet been determined. Here's another quote from Mrs. Kroes speech that underscores the need for consultation and deliberation:
We are thinking very hard about how this could be achieved. Any such initiative would probably be limited to certain types of IT products. And it would likely involve some form of pricing constraints.I have seen other legislative initiatives where it was fairly predictable at a comparable stage what the Commission had in mind to do. In this case, it appears that there actually are a lot of questions, including some fundamental ones, that have not yet been answered. That's why those of us who like the basic idea of this should make our contributions to the thought process sooner rather than later.
For the next (and final) posting in this four-part series on legislative initiative for interoperability currently being evaluated by the EU, please click here.
{Interoperability} FOSS-related opportunities and priorities
This posting is the fourth (and final one) in a four-part series on a legislative initiative for interoperability currently being evaluated by the EU. Click here for the first part of the series (a brief overview of what this is all about) or here for the previous part, which discusses procedures.
Like I wrote in the first part of this series of postings, I regard the initiative to impose interoperability requirements on significant market players as a first-rate opportunity for free software and open source.
Beneficial with or without software patents
There's no question that the number one item on the political wishlists of most community members is -- and will continue to be -- the abolition of software patents. I'm also aware that many in the community would prefer for interoperability-related patents to be available on a royalty-free basis. The last quote above from Mrs. Kroes's speech indicates "pricing constraints" as a likely option, which makes it pretty clear that patent holders won't be required to grant licenses on a royalty-free basis.
But even if some of us fear the initiative might not go far enough, we should at least support the parts we like and get as much mileage out of it as possible.
The FOSS community should embrace and support this interoperability initiative. There really is the chance to make some important headway. Everyone who opposes software patents (and patent royalties) altogether can continue to advocate that position. Even if we achieved the abolition of software patents one day against the odds, this interoperability initiative would still have value because it will very likely deal with more than just patents. For an example, undocumented interfaces are a problem with or without patents, but the future interoperability law could solve it.
Looking at Mrs. Kroes's track record, I'm sure she will make the most open-source-friendly proposal she can under the legal parameters and political circumstances that exist. Even if she may prefer royalty-free interoperability, it's not only politically but also legally impossible for a government to expropriate right holders without adequate compensation.
Politics is the art of the possible
The potential benefits of a European IT interoperability law are huge. Let's try to achieve as much as feasible. Politics is the art of the possible, and progress has to be made one step at a time. I don't see any other legislative idea in Europe (and this one would certainly have repercussions around the globe) that offers such an attractive combination of being potentially helpful and politically achievable in the near to mid term.
I believe SMEs (small and medium-sized enterprises) could be important allies to make this happen. We should work with them to give Mrs. Kroes the input and political support that will be needed to overcome whatever resistance some may try to mount (including some who demanded interoperability in the past, when other companies' intellectual property was concerned, but don't want to provide it with their own products and will therefore try to get the bill diluted if not derailed).
We can still be against software patents in general and explore ever more ways to achieve that goal. But that shouldn't preclude us from seizing what looks like a wonderful opportunity on the interoperability front.
If you are also excited about this initiative, please stay in touch by bookmarking this blog, emailing me via the contact form, or following me on Twitter @FOSSpatents.
Like I wrote in the first part of this series of postings, I regard the initiative to impose interoperability requirements on significant market players as a first-rate opportunity for free software and open source.
Beneficial with or without software patents
There's no question that the number one item on the political wishlists of most community members is -- and will continue to be -- the abolition of software patents. I'm also aware that many in the community would prefer for interoperability-related patents to be available on a royalty-free basis. The last quote above from Mrs. Kroes's speech indicates "pricing constraints" as a likely option, which makes it pretty clear that patent holders won't be required to grant licenses on a royalty-free basis.
But even if some of us fear the initiative might not go far enough, we should at least support the parts we like and get as much mileage out of it as possible.
The FOSS community should embrace and support this interoperability initiative. There really is the chance to make some important headway. Everyone who opposes software patents (and patent royalties) altogether can continue to advocate that position. Even if we achieved the abolition of software patents one day against the odds, this interoperability initiative would still have value because it will very likely deal with more than just patents. For an example, undocumented interfaces are a problem with or without patents, but the future interoperability law could solve it.
Looking at Mrs. Kroes's track record, I'm sure she will make the most open-source-friendly proposal she can under the legal parameters and political circumstances that exist. Even if she may prefer royalty-free interoperability, it's not only politically but also legally impossible for a government to expropriate right holders without adequate compensation.
Politics is the art of the possible
The potential benefits of a European IT interoperability law are huge. Let's try to achieve as much as feasible. Politics is the art of the possible, and progress has to be made one step at a time. I don't see any other legislative idea in Europe (and this one would certainly have repercussions around the globe) that offers such an attractive combination of being potentially helpful and politically achievable in the near to mid term.
I believe SMEs (small and medium-sized enterprises) could be important allies to make this happen. We should work with them to give Mrs. Kroes the input and political support that will be needed to overcome whatever resistance some may try to mount (including some who demanded interoperability in the past, when other companies' intellectual property was concerned, but don't want to provide it with their own products and will therefore try to get the bill diluted if not derailed).
We can still be against software patents in general and explore ever more ways to achieve that goal. But that shouldn't preclude us from seizing what looks like a wonderful opportunity on the interoperability front.
If you are also excited about this initiative, please stay in touch by bookmarking this blog, emailing me via the contact form, or following me on Twitter @FOSSpatents.
Subscribe to:
Posts (Atom)