Leading items

Software patents take a beating at the US Supreme Court

As LWN reported back in early April, the Supreme Court of the US (SCOTUS) has been looking at the patent-eligibility of software, through the lens of the case Alice Corp. v CLS Bank International. On June 19, the court released a unanimous ruling [PDF] throwing out Alice's patents. Its rationale for doing so will have a profound effect on patent litigation in the software industry.

To briefly review the dispute, Alice held patents on a method, system, and process for a particular type of financial risk hedging: namely, that one party to a set of financial transactions won't pay at one or more stages in the set. This risk is known as "settlement risk". Alice's patents describe using a computer to keep track of the transactions between the parties. If the computer determines that a party does not have sufficient funds to pay their obligations to the other side, then the transaction is blocked. The relevant patents are #5,970,479, #6,912,510, #7,149,720, and #7,725,375. Litigation started in 2007, eventually winding its way up to the Supreme Court.

Ruling

Writing for a unanimous court, Justice Thomas begins with a brief description of what the patents claimed. There are effectively three different types of claims made: "(1) the foregoing method for exchanging obligations (the method claims), (2) a computer system configured to carry out the method for exchanging obligations (the system claims), and (3) a computer-readable medium containing program code for performing the method of exchanging obligations (the media claims)" (page 3 of the ruling). Thomas goes on to describe the history of the litigation in this case, which was covered in our April article.

Thomas begins the rationale for the court's ruling by quoting §101 of the Patent Act: "Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title." He notes that the Supreme Court has held for a long time—most recently in its ruling last year in Myriad—that the text of §101 means that there are limitations on what can be patented, namely: "Laws of nature, natural phenomena, and abstract ideas" (Myriad, quoted on page 5 of the Alice ruling). However, since every invention to some extent incorporates these patent-ineligible components, the fact that an invention relies in part on an abstract idea does not automatically render the whole invention patent-ineligible.

The ruling then goes on to cite the court's recent ruling in Mayo, which established a test to determine which inventions that incorporate abstract ideas are patent-eligible: "First, we determine whether the claims at issue are directed to one of those patent-ineligible concepts" (page 7). If it is so directed, then the court looks at "the elements of each claim both individually and 'as an ordered combination' to determine whether the additional elements 'transform the nature of the claim' into a patent-eligible application" (page 7). This is what Thomas refers to as "a search for an 'inventive concept'" (page 7).

The court then applies this "Mayo test" to Alice's patents. Beginning with the first step of the test, Thomas notes that these patents do incorporate, to a strong extent, an abstract concept, as "these claims are drawn to the abstract idea of intermediated settlement" (page 7). Thomas cites previous Supreme Court case law, emphasizing its ruling in Bilski (throwing out a patent on financial risk hedging), as illustrating examples of other patent-ineligible "inventions" that simply boil down to abstract ideas. Turning directly to Alice's patents, Thomas notes that intermediated settlement is an old financial idea: "Like the risk hedging in Bilski, the concept of intermediated settlement is 'a fundamental economic practice long prevalent in our system of commerce'" (page 9).

Thomas then applies the second step: looking at what else is in the patent claims, individually and in combination, to see if there's anything more to Alice's "invention". The method claims, which describe how the financial obligations will be exchanged, don't pass the court's test because they "merely require generic computer implementation" (page 10). In what might be the most important part of the ruling for determining where the Supreme Court draws the line for "computer-implemented inventions", Thomas is careful to stress that while some inventions involving computers may be patent-eligible, he notes that the mere fact that a computer is used as part of an "invention" is not on its own sufficient to turn an abstract idea into something eligible for a patent (pages 13-14):

The remainder of the patents, which are the system and media claims, didn't hold up either. With regard to the system claims, Alice had claimed that there was a particular computer hardware configuration it used to implement the "invention". When the court looked at that configuration, it didn't find anything more than the components of a generic general-purpose computer. Since Alice had stated in an earlier brief that if its method claims fail, so do its media claims, the court threw out the media claims as well. Having demonstrated the court's rationale for invalidating Alice's patents, Thomas concludes the ruling by upholding the Court of Appeals for the Federal Circuit's decision to throw out the patents.

Justice Sotomayor also gave a one-paragraph opinion concurring with the court, which was joined by Justice Ginsburg and Justice Breyer. In that opinion, Sotomayor notes that the three of them would completely throw out business methods as unpatentable.

Reactions

The reaction by individuals and organizations with a professional and/or political interest in US patent law has been strong and polarized. Gene Quinn, a pro-software-patent lawyer and blogger on ipwatchdog.com, was rather unhappy with the decision, depicting it as "intellectually bankrupt". He noted that this ruling will invalidate many types of software patents: "On first read I don’t see how any software patent claims written as method or systems claims can survive challenge." That's a strong assertion, but it doesn't really hold up. For instance, if such a software patent claim was really so novel that it couldn't be boiled down to implementing an abstract concept on a generic general-purpose computer, it might indeed stand up to litigation.

In a press release, the Free Software Foundation (FSF), unsurprisingly, expressed delight at the ruling, but was not completely satisfied. The FSF noted in the release that it continues to seek a clear and total ban on software patents through legislative change.

In an opinion article for SCOTUSblog, former Director of the US Patent and Trademark Office David Kappos lauds the decision, as he finds it tacitly endorses the patentability of software: "This week’s decision reaffirms that from the point of view of the patent system, software languages are no different from other vernaculars – they are a medium of expression that can be used to capture and convey ideas." Referencing Diehr, an earlier Supreme Court case upholding a patent on a machine for curing rubber that included a computer, Kappos emphasizes how the court's Mayo test draws a line based on inventiveness: "the difference [between patentable and unpatentable software] is the presence or absence of a definitive invention versus abstraction. Diehr’s new and useful process for curing rubber was held to be innately patentable — the fact that it happened to be manifest in a software language was tributary."

I found all three of those reactions to hold merit. The court's clear statement that a mere incorporation of a general-purpose computer is insufficient for an "invention" to be patentable will, as Quinn put it, "render many hundreds of thousands of software patents completely useless". However, the FSF and Kappos both pick up on the subtleties of the decision: the ruling does not outright abolish software patents, and even explicitly recognizes that certain computer-implemented "inventions" remain patentable.

While those working in the free and open source software world, which has been threatened and restricted by software patents, should celebrate, the ruling in Alice is not an outright victory for software patent abolitionists. There will likely be a flurry of cases challenging software patents, which will better define the boundary the court has set in this case. However, only legislative change, such as by adding language to the patent statute similar to that proposed by Richard Stallman ("developing, distributing, or running a program on generally used computing hardware does not constitute patent infringement") will lead to abolition.

Comments (81 posted)

Ascend seeks to include underaddressed populations in FOSS

Mozilla has rolled out a mentorship and education program called the Ascend Project that is designed to reach out to populations that are typically under-represented in open source development. But Ascend differs from existing outreach efforts like Google Summer of Code (GSoC) and GNOME's Outreach Program for Women (OPW) in several respects—including who it targets and how the mentorship and instruction are delivered. Ascend has already opened the invitation for its first round of participants, who will attend a six-week, full-time training course in Portland, Oregon in September.

Lukas Blakk publicly announced the launch of the initiative in March. Noticing how many "developer boot camps" were popping up, Blakk said, she had the idea to:

Blakk had attended an open-source training program while at Seneca College, but one of the core concepts behind Ascend is to make similar training accessible to people who are not in college or who, for other reasons, cannot afford to retrain for a new job. Consequently, the program was envisioned from the outset to provide a daily honorarium to attendees to lessen the impact of missing work, as well as a laptop to keep upon completing the course, and amenities like complementary meals, transit passes, and childcare services.

Mozilla's management approved the plan in December 2013, and the team set out to plan the pilot program. The initial course will be held at Mozilla's offices in Portland; a second round is tentatively planned for early 2015 in New Orleans. The pilot round will be limited to 20 participants; according to a May 30 post on the project site, applications will be accepted through June 30. Subsequently, the project team will work through several steps to narrow down the field to the final 20.

The course will be full-time instruction, five days a week, for six weeks, with the goal being to eventually have students "getting to committed code in production". Blakk noted in the original announcement that there will be a certain level of technical competence expected of attendees at the beginning, such as the ability to complete a free online course in JavaScript development, and that applicants will be asked to supply essays and other application materials that establish their interest and problem-solving ability.

So far the details of the curriculum have not been posted, either on the project site or in its GitHub repository. But the About page indicates that the goal is to address general-purpose FOSS project practices, such as "IRC, bug trackers, code review, version control, creating & committing patches" rather than (for example) sticking to a Mozilla-oriented curriculum that covered web development. The project is currently looking for volunteers in the Portland area who can serve as in-class helpers or as "drop-in" volunteers to help participants on a less formal basis.

The outreach landscape

One might ask how Ascend fits into the larger picture of developer-training programs (including GSoC and OPW). In a June 20 blog post, Blakk expanded further on how Ascend is intended to differ from these other outreach efforts—saying that many of them target school-age children or teenagers, but that "the REAL problem to solve is how to get adult women (and other underrepresented people) re-trained, supported and encouraged to take on roles in technology NOW."

Indeed, the biggest training programs in the FOSS arena these days do tend to aim for students who have yet to enter the workforce. GSoC is the largest, and it is an outreach opportunity that focuses exclusively on college students, while Google's related Code-in program targets high-school students. OPW is open to post-college-age women, although it, too, is structured around a more-or-less semester-length internship of three months, during which the participant is expected to work full time. Ascend's six-week course may still require attendees to rearrange their work schedule—and six weeks is certainly a lengthy leave of absence from most jobs—but it is ostensibly easier to manage than twelve weeks.

Consequently, Ascend is already appealing to a different segment of potential new FOSS contributors by focusing on finding participants who cannot pursue college computer science studies. The fact that it encourages applications from people in several distinct groups of under-represented communities (ethnic minorities and the LGBTQ community) is also atypical. The software industry as whole, after all, is often noted for how it skews toward the Caucasian male demographic.

That said, Ascend cannot necessarily expect to be overwhelmed by students unless it finds ways to advertise and promote its courses outside of the avenues dominated by those who are already in the software industry (and FOSS in particular). Such a chicken-and-egg problem confronts FOSS in many outreach and evangelism efforts, of course, and easy solutions to them are scarce. Mozilla certainly has a global reach and wide "brand awareness," both of which should help matters.

Reaching out to underemployed individuals is a factor that Ascend does have in common with both OPW and GSoC, both of which pay stipends to their participants. In contrast, the "boot camp" model Blakk referred to in the initial announcement is composed largely of schools that charge attendees tuition and fees, rather than paying them. While that may make for a good re-training option, it essentially limits enrollment to those individuals who already have sufficient means to retrain themselves.

Ascend also differs in that it appears to be designing a rather broad curriculum, focusing on general-purpose development practices. The "boot camp" model tends to focus on a particular technology stack, while the GSoC/OPW model connects participants with individual, existing software projects. Ultimately, of course, most members of the FOSS community know that it can take quite some time and interaction with quite a few people for a newcomer to join the open-source development community in a full-time capacity. A course like Ascend's is the first, but not the only, step. With the potential to reach interested participants who are not within the mission of the other outreach efforts, though, Ascend has the opportunity to help many new people take that first step.

[Thanks to Paul Wise.]

Comments (1 posted)

Term limits for Debian technical committee members

As described in the Debian constitution, the technical committee can have up to eight members. The committee chooses its own members, subject to approval by the Debian project leader. The size of the committee has varied over time, but is usually close to the full eight members.

Anthony Towns started the discussion in May, noting that some of the members of the committee have been there for quite some time. Ian Jackson appointed himself to the committee in 1998 as the brand-new Debian constitution was being adopted. Bdale Garbee came on board in early 2001. Andreas Barth and Steve Langasek have both been members since 2006; Russ Allbery and Don Armstrong were added in 2009. Colin Watson is a relative newcomer, having joined the committee in 2011, and Keith Packard, member since late 2013, is still rather wet behind the ears. Anthony raised no complaints about the performance of any of the committee members, but did note:

There was almost no opposition to the idea of establishing some sort of term limit for technical committee members, even among the committee itself. Russ Allbery suggested that he has been considering voluntarily limiting his own term, regardless of what the project might decide to do. But the discussion on how these limits might be applied was rather less conclusive. It is not that there is disagreement over how it should be done; instead, there seems to be widespread uncertainty about the best approach to the problem.

Concerns

The reasons why term limits might make sense were perhaps best expressed by Russ:

Russ also pointed out that the "for life" nature of technical committee appointments causes the selection process for committee members to be highly cautious and conservative. Limited terms would lower the level of perceived risk in appointing a developer to the committee, possibly increasing the set of viable candidates.

Those reasons, however, do not necessarily answer the question of what the policy should be. Should, for example, technical committee members be limited to a fixed number of years on the committee? There is an immediate practical problem there: if the limit were to be set to, say, four years, six of the current members would immediately be forced out. The project seems to agree that this would be an unfortunate result; while there is value in bringing new perspectives to the committee, there is also value in maintaining a certain amount of continuity and experience there.

Various ways of fixing the problem were proposed; many of them involved assigning artificial appointment dates for the current members to avoid having them all expire at once. An alternative would be to put a cap on the number of members whose terms could expire within a given year. So, even if six members were over the adopted limit, only the two most senior members would have their terms expire immediately.

There is also the question of when a member whose term has expired can be reappointed to the committee. The technical committee is currently self-selecting; it appoints its own members, subject to approval from the project leader. One could imagine a longstanding committee that is happy to immediately reappoint members when their terms expire, defeating the purpose of the whole exercise. So there probably needs to be a mandatory down time during which previous members cannot return to the committee.

One other question has to do with how this change, if it is made, is to be enacted. The rules for the technical committee are written into the project's constitution, so a constitutional change seems like the obvious way to apply term limits. That, of course, would require a project-wide vote via the general resolution mechanism. Ian, however, suggested that a better approach might be for the committee to adopt its own term-limit rules.

The primary motivation for applying limits at that level has to do with items that are currently under consideration by the committee: it would have been awkward, for example, if a member's term had expired in the middle of the recent init system debate. If the committee enforced its own term limits, it could delay an expiration for long enough to bring a contentious issue to a close. Doing things at that level would also make it easier to experiment with different approaches, Ian said, and would allow an outgoing member to vote on their own replacement.

A concrete proposal

After thinking on the issue for a while, Anthony posted a pair of proposed resolutions, either of which could be adopted to apply term limits to the technical committee. The first of those reads like this:

Additionally, members could not be reappointed to the committee if they had been a member for more than four of the last five years. Anthony expressed some discomfort with this option, though, noting that Keith would likely become one of the senior members and be pushed out of the committee after just three years. So he also put out this alternative:

In this variant, members could be reappointed after a one-year absence from the committee. This version ensures that all members are able to serve for a full six years and also limits the (forced) turnover to two members per year. It should, thus, satisfy the goal of bringing in new members while preserving a certain amount of continuity.

Anthony's proposal has not been put forward as a general resolution at this point; indeed, responses to it have been scarce in general. Perhaps the project as a whole is slowing down for the (northern hemisphere) summer. Given the apparent overall support for the idea, though, chances are that something will happen once Debian developers return to their keyboards.

Comments (1 posted)