18 April 2010

May software patenting and open source go together?

In this post published in a Sydney based IP firm's IP blog, the author(s) speculate(s) whether it makes sense to consider patenting of open source software, which would of course require a certain degree of mental liberty to overcome the common view that patenting totally contradicts to the idea of open source and is, at best, only an option for big business.

The idea is that the underlying rationale of patent protection and open source is to publish the invention/source code to be used and further developed by others. However, while open source can be freely used within the provisions of an open source license, a patented software-related invention may only be used if a patent license (or cross-license) is obtained that usually is liable to pay license fees. From that point of view, the two models for "explointig" software appear fairly similar, since the world's patent databases may be seen as large free-access prior art libraries, even though an invention disclosed in a patent and an open source library provide very different levels of detail and opportunities to use the disclosed knowledge.   

However, when considering the aspect that a patent owner has a monopoly, while the open source programmer contributes his developments to the community, the two models appear rather far apart. If the latter perspective is adopted, it doesn't help very much that patents only grant monopolies for a limited period of time (20 years from the patent filing date), since software life cycles usually are much shorter than a patent's lifetime.

At this point, the authors suggest that the open source community should consider patenting their developments for three reasons:
  1. A group of open source collaborators could secure a patent and grant a royalty-free licences to (only?) the open source community in much the same way as open source software is licensed. This would secure the invention for public use and prevent other parties from patenting that invention and exclusively exploiting it for commercial gain.
  2. A patent would secure the open source community the right to freely use the invention subject to the terms of the licence, which may comprise a provision according to which any modifications, enhancements or improvements are owned by the (open source) patent owner in order to retain all enhancements for public use.
  3. Open source patented innovations reside on patent databases and thus form part of the same public record, which makes the public record more comprehensive and useful to the community at large.
This argumentation, is base on the finding that such kinds of "open source patents" and subsequent zero licensing (to the community) would provide the legal certainty that no one else can obtain a patent for exactly that subject-matter and thus usage under the freely available zero license is not threatenend by patent infringement suits as it is today. Such a "run-with-the-pack" strategy according to which you apply for patents to be protected yourself from patents is in fact a legitmate strategy, whose further advantage (besides legal certainty) over the intrinsic open source disclosure strategy may be the official prior art search and examination, e.g. during the international phase of PCT proceedings or the like.

As open source today is a successful business model (see e.g. Novell, RedHat, Oracle) and not so much (only) an attitude of software developers that refrain from considering legal aspects of their work, the money needed for such a defensive patent strategy may exist (even without the chance to earn substantial license fees). In fact, some well known names in the open source market have plenty of experiences with patents (e.g. IBM, Novell and others). But there remains a risk that the community, whose contribution is needed for any successful open source business, will turn against an open source firm that is sympathising to patents, as Novell had to experience (see e.g. the Boycott Novell blog).

The authors of the referenced post see two main issues to be solved within the suggested open source patent framework, namely ensuring novelty of open source projects in the legal sense of the term as well as patent costs. One might add further important issues, e.g. that patent examiners should have the required expertise and ability to properly search and examine software patents and that sufficient prior art has to be available in the patent databases for conducting meaningful searches in that particular field. The latter two issue have not been overly pronounced some years ago but both are rapidly improving.

Novelty: To be patentable, a subject-matter has to be novel, i.e. not being publicly disclosed in any form before the filig (priority) date of the respective patent application, which appears hard to be achieved in an tedious collaborate open source development process.

One option may be that countries such as Australia, Canada, Japan, the USA and others have a grace period of six or twelve months from the first public disclosure of an invention by the inventor (depending on the country) whithin which inventors may still apply for a patent without drawbacks as to the required novelty. Apart from the fact that this is not an option in Europe where a patent grace period is unknown, six or twelve months may seldomly be sufficient to bring an open source project to a stable patent-worthy state.

Another option may be that collaborators sign an NDA before any detail of the project is provided and before they can contribute. An open source development process under such an NDA regime may e.g. comprise the below-sketched two-stage process (suggested by the authors and somewhat extended here), comprising an initial (conceptual) patent drafting stage in which a patent specification is drafted as a project agenda, e.g. as (part of) a software requirements specification that specifies the functional and usability requirements, and a subsequent (technical) software development stage in which the defined requirements are implemented. This process may e.g. look like this: 
  1.  The project coordinators (inventors?) provide a rather global view of the invention onto a site, which would have to be reasonably course to not endanger later patenting (e.g. comprising only the principle goals to be achieved);
  2. Contributors sign an NDA and make submissions to substantiate the published high level view and by this build a pool of invention-related material;
  3. The invention-related material is then structured in a joint drafting process (directed by the coordinators and, if required, supported by an adequately skilled patent attorney) leading to a colaborately drafted patent specification which may serve as some sort of project agenda (ideally the patent application is filed at this point - e.g. as a provisional application);
  4. Interested developers could subsequently join the community for helping to implement the invention as specified in the patent specification (in case the patent application has been already filed, the interested developers may consult the application before joining the community);
  5. The coordinators and associated community can accept new contributors if they show skills that are helpful to the project;
  6. The contributions would be logged against each contributor so as to determine if they are making a technical or inventive contributions;
  7. At an adaquate (preferably early) point of the development process, a set of patent claims is drafted (supported by a patent attorney, if required) based on the specification and the state of the developing process, such that the patent application can be filed to obtain preliminary protection. 
Costs: According to the author's conception, setting up a community of particular skills in order to draft the patent specification would reduce the costs for patent attorneys, due to contributions of the community in an open source manner. If the patent is commercially successful (e.g. by donation), any funds received can be made available to the contributors/inventors, or the community to promote further open source patent opportunities or as contribution for payment of official fees according to the various jurisdictions.

Conclusion: The authors see their sketched approach as an open source solution to promote access and availability to the excellent resources available both in the community and in the patent offices around the world.

However, even though the approach sounds interesting and may have a certain potential for utilise the best of both worlds in a software development process, it currently resides on a rather theoretical level, especially with respect to the patent specification process, the role of patent attorneys and the idea to collect fees for commercial uses and granting a free license for open source developers, whatever the differences between theses two groups may be today. Also a fairly strong opposition of anti-patent campaigners is to be expected if this or a similar appoach schould be implemented for a concrete project one day.

Especially, if an open source community really should decide to secure patent rights for their project, they should better consult a patent attorney or other legal advisor and not solely rely on community contributions (except some members are at least experienced patent practitioners) when it comes to legal issues with respect to worldwide patent procesution, licensing, infringement or the like.