Patents and Open Source Are Not Always Like Water and Oil:
“Patents have long served to enable innovation while assuring the complete disclosure of inventions and a reasonable return to inventors”. While RAND (Reasonable And Non-Discriminatory) licensing requirements, which provide equal and fair access to IP for use in both open and closed standards, has significant support from governments and industry, there exist some within the OSS (Open Source Software) community who wish to abolish RAND licensing all together. In the first of two featured articles, Stacy Baird outlined both the motivations and consequences of this desire.

The OSS Roadmap to a Minefield of Patents:
“Standards bodies are a microcosm of the marketplace: alternative ideas compete for inclusion in a draft” with organizations offering a wide range of approaches towards IPR technology, ranging from allowing to disallowing its inclusion or alternatively falling somewhere in between. In the second featured article, OASIS’s James Bryce Clark reported that “demands for royalties are becoming rarer” particularly during the recent boom in internet technology such as cloud computing which increasingly depends upon interoperability and transparency, in contrast to traditionally closed telecommunications networks.

FOSS (Business), Standards, and Intellectual Property Rights:
There is ongoing discussion covering how FOSS can be used in scalable business and what business models support using FOSS. For instance: “how one makes money when one gives the product away for free”. Stephen Walli argued that the nature of any tension between FOSS and standards is in their relationship and concluded that a well-run FOSS project should have the same level of IPR policy considerations in place as an SDO.

Betwixt and Between: Open source software and RAND standards development patent policies:
Regarding the tension between OSS and RAND, George T Willingmyre posed the questions: “What is the problem? Is this actually a “problem” or a matter of differing goals?” and “what is the lesson?” Arguing that rather than being a conflict between the Open Source definition and RAND, the tension instead comes from certain patent licensing restrictions which are included in some Open Source licenses and RAND. He concluded that the world’s policy makers should take heed when contemplating any decisions regarding Open Source policy affecting standard setting.

The Intersection of Royalty-generating Standards and OSS:
“All open source licenses are not created equal – hard line licenses, like the GPL, place more restrictions on users and thus create tensions with RAND/FRAND that don’t otherwise exist”, argued Daniel Garcia-Schwartz and Anne Layne-Farrar in their co-authored response to the featured articles. Counter to OSS ideals of “Information wants to be free”, the more restrictive the OSS license, regarding IPR inclusion, the less that information flow is possible. These licenses not only limit the pool of information from where OSS reliant firms can draw, but also delay standard implementation due to uncertainty.

Shaping the Debate – Are Some of the Tensions Created by “RAND-OSS” or by “RAND-GPL”?:
Many open source advocates reinforce the belief that RAND is incompatible with open source licenses with phases tending towards too strongly a worded, argued Jay Kesan. But the patent grant in an OSS license does not necessarily result in a royalty-free grant of all patents the distributor holds that read on a certain code, which is important to for maintaining a vibrant ICT sector.

An Open Source Approach to Policymaking?:
As global competition and the convergence of new technologies continues to increases, issues related to standards and standard development is “becoming a growing focus of policymakers who are struggling to keep up with the pace of change”. Helen Disney commented upon the discussion between proponents of open and proprietary-based standards and some of the misconceptions regarding the obstruction of innovation. She argued policymakers should neither “idolize nor demonize” business models based upon either OSS, RAND, etc and should take a more collaborative approach towards the most open, competitive ICT marketplace possible.

Open Standards and Open source – Maturity and beyond:
In many regards Open Source is maturing, claimed Ajit Jaokar citing the recent Talkstandards debate, which focused upon the evaluation a specific Open source licensing options rather than simply the OSS/IPR dichotomy, as part of a continued evolution of the discussion regarding Open Standards and Open Source. Arguing that “Open source licenses are not incompatible with IPR” and that the “Demands for royalties are increasingly depending on the domain” he outlined a series of implications stemming from this maturity.

Standing at the Intersection of RAND and OSS:
While on the surface it may seem a simple debate between RAND and “Open Source” regarding patent royalties, claimed Steve Mutkoski, “neither RAND nor OSS are singular or uniform concepts capable of such a simple comparison”. Outlined a number of ways in which the dozens of OSS licenses currently in use uniquely treat the inclusion of patents, Mukoski described the situation as a “complex legal discussion”.

Standards and Open Source Software:
“Is there an inherent tension between the FRAND … and the imperatives of Open Source software development? In one word, no” argued Timothy Simcoe. Nothing prevents a firm contributing technology to an open standard under a FRAND licensing agreement for free, via a non-assertion covenant or setting the maximum royalty rate to zero during ex-ante disclosure. Simcoe cites the potential holdup possibility as the key priority for policy consideration, in particular the improvement of IP policy (greater transparency, reduced vagueness such as “reasonable” royalty rates, etc).

Many participants in the open-source community are implementing standards and licensing patents where necessary to create highly successful, innovative products, so why would others be calling for abolition of RAND licensing?

The answer lies in licenses: not the patent licenses, but certain open source software licenses.

Simply put, there are different flavors of OSS license. Some, such as the BSD and Apache licenses, allow OSS developers to design software that plays well with others. These licenses allow OSS developers to include software (any software, not just software that implements standards) that may require the developer to pay royalties. So if you are an OSS developer and you choose to use, for example, a BSD license, the question “can I use the standard in my OSS?” is invariably answered “yes.”

However, other open source licenses, specifically GPL licenses, are intended to ensure no IP royalties flow from not only the underlying OSS, but any add-ons to, or components of the underlying OSS code, including any standards implemented in the software.

So if you are an OSS developer who decides the GPL is the best license for your software, then yes, there is a problem. It’s a problem written by the authors of the GPL licenses who seek to exclude any patents from GPL licensed software – not a problem created by the patent license or the standards setting body that adopted RAND as the right approach to licensing of patents embodied in a standard. Patrick Durusau describes this well in “Self-Inflicted Discrimination and GPL.”

Many OSS developers, like commercial software developers, license these patents with royalties based on unit sales (so called “per unit” royalties). But this metric is proscribed by the GPL; so alternative valuations such as lump sum or royalties based on revenues can be substituted to enable OSS developers to use a standard in a way compatible with the GPL. In fact, according to an analysis of the Redhat/Firestar settlement not even OSS developers using GPL 3.0, the most stridently anti-patent OSS license, are entirely foreclosed from licensing such patents on terms that include some form of royalty.

So what is the best public policy?

Patents and RAND licensing stimulate innovation, remunerate inventors and enable interoperability, even interoperability for highly successful OSS. When the situation warrants, the market gets creative in working out reasonable royalties on GPL-licensed software. As Hellström, Kramler and Bulst of the European Commission Antitrust unit recently wrote in Holding Standardization to a Competition Law Standard (Concurrences Review, February 2010): “As competition law should be business model neutral, there should be no preference for open source based models over other models. From a competition law perspective royalty free access to IPR is not necessarily required.” It makes no sense to abandon patents and RAND licensing, fundamental aspects of standards-setting, to accommodate one type of open source software license.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

Standards bodies are a microcosm of the marketplace: alternative ideas compete for inclusion in a draft. Some organizations permit royalty-bearing work to be included in a standard; some don’t; and some (like ours) permit each standards project to select a set of terms. In OASIS’ experience, the overwhelming majority of member-initiated projects choose a royalty-free approach, and so only accept contributions that do not come with royalty claims.

Demands for royalties are becoming rarer, in our own domain. Structured data standards that bear royalties have grown less acceptable to the marketplace, during this last decade of widely-distributed, Internet-driven information transactions. Proprietary and royalty-bearing methods have a wholly completely legitimate place in computing and ICT. But they are less likely to be embraced for use in globally-networked open systems that depend on user elaboration. In a multi-modal, constantly-growing open network, unlike a closed telecomm network (for example), participants add themselves spontaneously, and often modify shared data constructs. In such a system, to test each new participant and data exchange against whether proper rights are in place — perhaps many times a second, in the case of some networks — would pose obvious scalability challenges.

That may be why, in our field, standards panels often seek workarounds for proposed methods that have restrictive licenses. Whether to do so is, itself, the decision of the participants. The benefit of a transparent, stable process is that all contributors may participate, and conduct an open debate about what kind of terms ought to be required for a given project. We believe that this leads to better disclosure and better results.

In free and open source software work, like open standards, there are some established venues that operate under clear and known terms. The Open Source Initiative, the Free Software Foundation and the Apache Software Foundation are obvious examples; each with a transparent governance structure and a track record of stability. Many open standards consortia benefit greatly from those “FOSS” software development communities. As a practical matter, we see these two spheres interact constantly. Many FRAND standards have open source implementation projects which pose no license compatibility problems. See, for example Softwarefreedom.

A number of more informal models also have emerged. Not all of them have binding assurances for openness or re-usability in place. Ad hoc projects are created, to pool cooperative effort for a project, and may even be called “open-source” or “open-standards” work; but often these collaborations have no participation rules, or license or permission practices, to give assurance to the end-user. Increasingly, we see governments carefully distinguishing between such ad hoc efforts, and established stable processes, in their purchasing requirements and policy development.

Patent and copyright regimes do not always deal in certainties, even at their best. Some of the legal devices used in the above environments are relatively untested. One only needs to look at the Rambus cases in the US, to see swings in the interpretations that regulators and courts apply to the duties of participants in collaborative projects (e.g. 2006 case and 2008 case). A clear definition of the enforceable meaning of “fair” or “reasonable”, when the terms of proposed licenses are challenged, sometimes seems beyond a court’s reach. Also, issues around whether one may, or ought to, apply patent protections to software, generally, under the laws of various nations, is so well known an issue this year as to require no citations.

One recent response to these uncertainties, in our community, has been an increased use of waiver forms that may make licensure diligence, and perhaps enforcement details, obsolete. Standards participants may issue a statement that supports a standard — regardless of assertions about the state of their rights — by simply disclaiming any right to demand a license for a conforming implementation. See, for example, the model “Non-Assertion Covenant” . It’s likely that developer and user marketplaces will continue to seek agile and creative solutions, or work-arounds, to the traditional high-cost methodologies involved in parsing and threading through often poorly-mapped patent minefields.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

FOSS and Business

A business creates a marketplace and manages products through a pipeline. FOSS adds interesting new tools to the product development and customer engagement toolkit, but FOSS doesn’t fundamentally change the nature of the business. The easiest way of thinking about this may be to recognize that companies sell products (and services) to customers, while FOSS projects develop software collaboratively in community. This doesn’t mean that companies don’t mix with communities, nor that products can’t related to projects, but these are separate things with different engagement processes.

Companies may use software from external FOSS projects as part of the business offering, or they may publish components from their product space under FOSS licenses, and further they may develop communities of users and/or developers. There are well-understood ways for managing each process: i.) developing product channels, ii.) licensing FOSS projects, and iii.) developing technology user/developer communities. Successful companies understand that these are separate functions and how to manage each process to support the other two.

FOSS and Standards

The nature of any tension between FOSS and standards is in their relationship.

A. If there is only ever one true FOSS implementation, does there need to be a standard that would encourage multiple implementations? Probably not, and no standard should be created. Nothing is lost in the economy. People are collaborating on the implementation and not a specification for multiple people to implement differently. This tension can be seen in the lack of debate around the Perl language for a standard, but is interesting as people debate a Ruby language standard.

B. If the FOSS project acts as the reference model for a standard’s creation for which there will be multiple implementations, then is the FOSS project committed to maintaining the conformance to the standard specification once it is finished (e.g. OASIS and ODF out of the OpenOffice.org project). This would certainly aid the standard at promulgating faster if the FOSS licensing allows more people to adopt the FOSS project as a component of their products and services.

C. If the standard’s conformance criteria requires multiple genetically different implementations (e.g. the IETF), then one or more of them could certainly be FOSS licensed projects. This would again likely encourage the standard’s spread faster.

Standards and Business

Standardization does have an impact on business models. I’m an enormous fan of Christensen economic models. When a vendor begins to over deliver on functionality in products, and customers can no longer absorb the changes (or want to pay for them), the technology space is ripe for standardization. The standard can provide a reference model for a particular set of solutions to the problem and businesses (new and old) are in a position to offer new solutions to customers with the standard at their core. These new business offerings often have very different margins to the original vendor’s solution. New solutions with new margins create new business models.

IPR Tensions

The tension between standards and IPR is whether or not the IP licensing is [F]RAND or not. IPR and standards clash because they exist to support different functions within the marketplace. Standards exist to enable and encourage multiple implementations of the specification. IPR exist to protect a single idea’s expression or implementation. Every standards development organization (SDO) must deal with the reality of patents in the marketplace (regardless of whether SDO participants are the IPR holders). SDO create IPR policies to make the licensing situation as clear as possible for participants and potential future implementers. Ideally, no SDO wants to create standards with built-in taxes, but the reality is that there may be patent licensing to manage. Letting participants know the licensing landscape in the development process as early as possible is the goal.

The tension between FOSS and IPR is whether or not the IP licensing is [F]RAND and royalty-free. When FOSS projects implement standards, it’s no different to tackling any other endeavor with respect to patents, i.e. the FOSS project needs to be sensitive to the patent landscape. With respect to FOSS project participants, well-run projects fall back on a similar process to the SDO by creating some form of IPR policy. This policy is embedded in the project’s license choice/design, its contribution agreement process, or both. IP rights holders that participate in FOSS projects need to be as sensitive to how they manage those rights with respect to the FOSS project as if they were to participate in SDO, but the bar is higher because the expectation in a FOSS project’s IPR policy is that any patent licensing is royalty-free as well as [F]RAND.

A well-run FOSS project should take steps to ensure they have the same level of IPR policy considerations in place as SDO. As with the business world, the FOSS project needs any IPR to implement and distribute the standard implementation. FOSS projects suffer the same problem of patents outside their participants’ control.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

On the one hand we are speaking of the numerous and varied licensing conditions that have evolved around the sharing of “Open source software” defined as:

“… computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software.” (Source Wikipedia)

And on the other hand we speak of “RAND standards development patent policies” that provide for “Reasonable and Non-Discriminatory” (RAND)  (see e.g. Abanet.org) licensing terms and conditions (including possible royalties) that might comprise a license covered by an assurance of a license from the holder of an essential patent to a particular standard.

This is to remove from our discussion the term “open standard” which can be confused with, but is distinctly different than either of the previous. We shall leave discussion what is an “open standard” for another day.

What is the problem? Some in the OSS community contend they are disadvantaged by RAND standards development patent polices where patent owners are allowed to seek reasonable royalties (and/or other reasonable terms and conditions) in licensing patents that are essential to practice the standard. They observe that OSS may be foreclosed from inclusion in standards employing RAND patent policies due to several elements generally understood to define OSS (Source Wikipedia):

“… 1. Free Redistribution

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.”

and

“… 3. Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.”

A generalization is just that, and all generalizations are suspect.

Nevertheless one such recent generalization about OSS which brought to me a smile, this by Gene Quinn:

“But too many open source regimes are like the Borg of Star Trek fame, or a little like the Mafia. Once you are a member you simply cannot get out. With too many open source regimes once you join and take then anything that you produce must be free to be taken by other members of the consortium. It really is akin to a patent deal with the devil, and ignores human tendencies” (Source IPWatchdog.com)

I believe Quinn is observing whatever improvements might be made and contributed will be difficult if not impossible to monetize as Intellectual Property and that this contrasts with human nature to desire rewards for individual efforts.

Another important generalization is that there are important distinctions among OSS licenses. Not all open source licenses are necessarily in conflict or incompatible with RAND patent licensing (including royalties). Rather than being a conflict between the Open Source definition and RAND, the tension instead comes from certain patent licensing restrictions which are included in some Open Source licenses and RAND.

Välimäki and Oksanen observe*:

“… popular open source have a built-in termination mechanism that does not allow the development of software that requires any kind of royalty payments for third party patents. In more technical wording, GPL and LGPL are incompatible with patent royalties: if there is a patent for some software invention and that patent is not licensed for free to everyone forever, it is not possible to develop free software for that invention.”

They continue however:

“To be precise, not all open source licenses have such patent clauses. For instance the popular BSD license lacks one.”

Is this about a problem or a matter of differing goals? Distinctions exist between the goals of OSS and standards. A goal of OSS generally is that of permitting users to study, change, and improve the software. A goal of standards generally is about creating compatible or interoperable implementations and NOT about permitting multiple and varied changes. Andy Updegrove stated this succinctly in assessing a “non-assert” patent pledge concerning a standard:

“The pledge only relates to “compliant” implementations, which does run afoul of the open source right to change anything. From a standards point of view, that serves a purpose, as it furthers the spread of interoperable implementations, which is what standards are all about. That works well from that perspective, but may leave some open source advocates less happy.” (Source Consortiuminfo.org)

Carrying forward the notion that OSS actually describes a diversity of licenses, others here correctly opined: “all open source licenses are not created equal. “ There are upwards of 75 OSI “approved” open source licenses in use today (however dozens other non-approved licenses, see Opensource.org). It is all in the details; how well the current Oracle – Google patent dispute illustrates this point! In its complaint, filed August 12 2010 (see Scribd.com) with the U.S. District Court for the Northern District of California, Oracle said Google’s Android operating system software consists of Java applications and other technology. As such, it infringes on one or more parts of seven different patents. When Oracle purchased Sun Microsystems in 2009, it acquired Java.

“Sun, though it amassed thousands of patents, was one of the biggest backers of freely sharing programming technologies. Though Sun cut licensing deals to sell Java, it offered free versions under what the industry calls open-source licenses.” (Clark and Tuna on Wall Street Journal)

Some have questioned how could Oracle now seek to enforce its patents in Java (as it has with respect to Google) and at the same time support organizations with strong positions that such commonly used standards as Java should be available without any royalties?

“However, Oracle’s patent infringement suit against Google is also an aggression against the notion of open standards. Java should be an open standard, and according to Oracle-backed organizations such as the OFE and ECIS, such standards would have to be made available on a royalty-free basis.**” (Source Fosspatents.com)

Why should it come as a surprise that businesses strive to maximize their potential value? In standards setting the term for this behavior is, “enlightened self interest”. Exactly how Oracle makes its Google case is a matter for the attorneys and juries; however, the answer may lie in the concept of multilicensing:

“The practice of distributing software under two or more different sets of terms and conditions. This may mean multiple different licenses or sets of licenses. … When software is multi-licensed, recipients can choose which terms they want to use or distribute the software under.” (Source Wikipedia)

These snippets from Why Has Oracle Sued Google? from the “land down under” indicates there may be details within Sun’s original commitments that make these commitments consistent with the current Oracle litigation.

“This appears to be the story of a clever strategy by Sun/Oracle to monetise intellectual assets (patents, copyrights, and other intellectual capital embodied in the Java platform) through open-source licensing … This strategy gives Oracle the best of both worlds: freely available development platforms to encourage widespread adoption and standardisation; and commercial licensing in the most lucrative (high volume) market segments”

What is the lesson? This could be about a real problem when advocates from one side promote government intervention to their advantage and to the disadvantage of the other when a balanced analysis leads to a different conclusion. Should policy makers try to influence the conditions for different development and business models through standardization policy?

The global voluntary consensus standards community has a long and generally successful experience with the application of RAND standards development patent policies. The earliest such text from the predecessor to the current 2010 patent policy (see ANSI) of the American National Standards Institute was nearly 80 years ago in 1932:

“That as a general proposition patented designs or methods should not be incorporated in standards. However each case should be considered on its merits, and if a patentee be willing to grant such rights as will avoid monopolistic tendencies, favorable consideration to the inclusion of such patented designs in a standards might be given.” (Source GTW Associates)

The notion that any “RAND standards development patent policy” discriminates against certain OSS is not a matter of “discrimination” in the text of such a RAND standards development patent policy. It is a matter that some self-created elements in some of the OSS licenses make it impossible for the software subject to those licenses to meet at the same time the RAND standards development patent policies that have existed for decades.

Regulators and policy makers around the world face complex questions when contemplating government actions and rules affecting standards setting or use. Now with appeals in the US for “open government” it may seem at this time of government budget deficits that standards based on OSS or that royalty free licensing policies at SSOs merit attractive consideration. The Government of India recently proposed Draft Policy on Open Standards for e-Governance including such text as, “… the patent claims necessary to implement the Identified Standard shall be available on a Royalty-Free basis for the life time of the Standard.“

Regulators and policy makers around the world take heed. Such government actions are not as simple as they might at first appear. There are many factors bearing on the choice by a standards developer of its patent policy. Standards Developing Organizations balance many and often conflicting interests and needs of their members and users of their standards in making this choice. In some cases the market corrects such mistakes that SDOs may make in this regard (resulting in the standard failing to gain acceptance or market share) and the standard or standards developer becomes irrelevant.

Government policy makers contemplating actions to alter the rules affecting standards setting should use extreme caution and they should treat as circumspect claims by participants that open source software is disadvantaged by the RAND regime, long employed across a multitude of standards development organizations.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

*Mikko Välimäki and Ville Oksanen, “Patents on Compatibility Standards and Open Source – Do Patent Law Exeptions and Royalty-Free Requirements Make Sense?”, Sept 25 at http://www.law.ed.ac.uk/ahrc/script-ed/vol2-3/valimaki.asp.

** Here is use of the term “open standard” to define presumably a standard where patents are exluded or available royalty-free but where there is ample room for misunderstandings.

This article is co-authored by Anne Layne-Farrar and Daniel Garcia-Swartz (bio Here)

As fellow commenter Stacy Baird notes in his contribution to today’s discussion, all open source licenses are not created equal – hard line licenses, like the GPL, place more restrictions on users and thus create tensions with RAND/FRAND that don’t otherwise exist. Indeed, open source and IPR protected software frequently coexist quite peaceably.

While proponents of OSS famously said some time ago, “Information wants to be free”, restrictive OSS licenses unfortunately have the opposite effect. In fact, the more restrictive the OSS license, the less information flow is possible. It is difficult to measure the cost paid for the road not taken, but it is likely non-trivial.

The potential negative effect for firms that rely on OSS with highly restrictive licenses derives from the self-imposed reduction of choice. When organizations rely on the GPL or other similarly restrictive licenses for a specific product, they are precluded from incorporating into that product software that involves royalty payments. The pool of innovation from which they can draw is therefore limited. This reduction in choice is not a problem only if we assume that all software involving royalties is inferior, less innovative, and less relevant than readily available OSS software free of all IPR payments. The moment that we admit that some proprietary software may offer solutions not otherwise available, or available only in a less efficient or lower quality form, then we must also admit that a price is indeed paid by restricting the pool of contributions from which an OSS program can draw.

But the effects are surely more wide spread than that. In particular, it is our experience that many firms that rely on IPR protection shun standard setting organizations with open source leanings. Here the issue is not that existing software solutions protected by IPR are being precluded from inclusion in open source products, but rather that software solutions are not developed at all because the firms that would develop them are leery of OSS entanglements. This second effect exacerbates the first.

A related third effect in the form of uncertainty will emerge in at least some instances. To see the price that uncertainty over IPR and OSS can impose, consider Google’s recent announcement of an “open and free” video format, VP8, “with the goal of creating a standard that anyone can use without paying royalties.”*   The controversy began almost immediately after Google’s announcement. Specifically, MPEG LA announced that it was already working on creating a patent pool with patents that read on the VP8 standard. As the technology underlying VP8 is allegedly not owned by Google and thus is not under Google’s control, neither is the standard’s royalty-free status. Despite any reassurances that Google may make, risk averse firms appear to be avoiding the standard until its status is clarified – the opposite effect that Google was striving for.

The bottom line seems clear: tension between IPRs and OSS is bound to impose some economic costs. Most likely, the presence of strict OSS licenses in a standard setting context will result in reduced innovation and less consumer choice. When uncertainty is thrown into the mix, the cost can include delayed adoption of a standard. These effects appear to be greater the greater the reliance on more restrictive licenses, like the GPL, as opposed to more accommodating ones, like the BSD.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

* See “Google’s New Open Source Standard May Never Be Free”", Technology Review, May 26, 2010

It is incumbent that scholars and policymakers understand the meaning of numerous open source licenses that are currently in use as opposed to thinking of OSS licenses as a monolithic and homogenous concept. The scope of the debate should be reshaped into a discussion of how a subset of OSS licenses, perhaps the GPL family of licenses, may or may not conflict with RAND-based licensing. In fact, there are a significant number of examples and approaches in open source licensing that create no tension with RAND-based standards licensing.

The OSI’s Open Source Definition is a set of criteria used to judge whether a particular code license can be certified (by OSI) as an “Open Source” license. There is no reason why a RAND patent license would need to be certified by OSI so the application of the OSI principles in this situation is misplaced. OSI’s definition merely states that an OSS license may not require the recipients of the code to pay the code distributor a royalty. It does not prohibit the code distributor from taking a patent license from a third party and paying per unit royalties on the copies of code that it distributes under an OSS license. Indeed, there are clearly OSI approved licenses that do allow such third-party patent licenses. The key question is whether the operative OSS license (OSI certified or otherwise) contains a requirement or limitation that prohibits the code distributor from taking such a patent license.

There are currently over 50 open source licenses in use. Because each OSS license is somewhat unique, a claim that all OSS licenses are impacted unfavorably by a RAND-based standards license would require a careful review of some key clauses in each OSS license with specific identification of the RAND term that is in conflict with a term of an identified OSS license. Only after this review is conducted, can we say decide whether there is a tension between a RAND-based license and any specific OSS license. The fact that there may be some tension between a RAND-based license and one OSS license does not imply that this will be true for other OSS licenses.

Therefore, we need to create a license taxonomy or license attribute analysis that we can use to better understand the interplay between OSS licenses and RAND-based licenses in the standards-setting arena. The key components of this taxonomy are license grants, conditions, or restrictions and a group of other related provisions.

Fundamentally, an open source license is about making computer source code available for modification and redistribution by recipients including those who are downstream from the recipients. A key component of an OSS license is therefore the license grant clauses that enable recipients to make use of the source code. There may be patent grants which may relate to claims that read on some or all of the code received from the distributor under the license. A significant point to understand about the patent grant in an OSS license is that the grant does not necessarily result in a royalty-free grant of all patents that the distributor holds that read on the code.

Such an understanding is vital to maintaining a vibrant ICT sector where there is significant licensing of both proprietary and open source software in standards development and in other scenarios, and towards the continued development of a robust ICT sector where a plethora of different business models are allowed to flourish.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

On the positive side, the understanding of open source principles and ways of working has motivated us all to be more transparent, more open to creative partnerships and to place a premium on innovation as a public good.

Yet while it is perfectly fair to argue that open source does lead to greater innovation in software, it is not fair to say that open source is the only way in which innovation takes place in this field.

In fact, there is a great likelihood that those innovations in software that require substantial time and resources to reach the market, would still depend on good “old-fashioned” proprietary models, a.k.a intellectual property rights (IPRs).

Simply put, IPRs allow innovators to recoup the rewards of taking risks and often investing vast sums of money in creating products and services that would never come to market without the associated R&D efforts that were put behind them. Attempting to circumvent that process – even for the most laudable of reasons such as increasing interoperability – starts to weaken and undermine the IP system which has grown up precisely to protect this important principle.

Nonetheless, a heated debate exists between proponents of open and proprietary-based standards. In this debate, “open” is often equated with “free” and “proprietary” is seen as being synonymous with so-called “closed” efforts. One argument is that because open source efforts allow anyone to access standards at no cost, they promote more competition and better innovation than proprietary-based efforts. Furthermore, because IPR-based standards offer access at a price, they are sometimes considered to be barriers to competition and innovation, and as such, closed standards. Crucially, a distinction is not always made between proprietary standards that are not publicly accessible and those that are accessible for a fee.

In fact, proprietary-based and “closed” standards (i.e. not publicly accessible) are not necessarily synonymous. Neither are open standards and those that are free. Rather, many standards involving IPRs are publicly accessible at a reasonable, transparent and non-discriminatory price – hence, they are open. Many patent pools, like MPEG LA and the Open Patent Alliance for the field of WiMAX technology (4G wireless technology) are a good example of this. And many standards typically considered to be open (i.e. which do not involve conventional licensing structures) are still based on an IP model of some form.

For instance, “defensive patent pools” work similarly to SDOs in that they aggregate a set of standards for public use with the intent that users can implement the standards without facing litigation; however, in the case of “defensive patent pools” member companies pay an annual fee to access all the standards. In the case of RPX, members can access over 1,000 standards for a fee that is considerably less than purchasing each individual license, but the IPR regime of the rights owners is still protected. Google’s Android technology is not IPR-free either. It is available to users under an Apache License, under which copyright is still preserved and while vendors may access the technology for free, they can add proprietary extensions without making them open to the open source community. Thus, a variety of hybrid models have come to exist.

With global competition and the convergence of new technologies only set to increase in the 21st century, the issue of standards and standard development is becoming a growing focus of policymakers who are struggling to keep up with the pace of change. Indeed, policymakers may even benefit from taking a more collaborative approach to forming policy in this area, allowing for more direct inputs online from a wider range of stakeholders in order to reach a consensus on what works.

However, ultimately public policy should neither idolise nor demonise a particular business model – be it based on IPRs or on open source – but should instead allow for the most open, competitive ICT marketplace possible. For those who truly believe in creativity, open collaboration and fair competition, let us try to set the rules of the game in a way that does not exclude either proprietary or open efforts and let human ingenuity solve the rest.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

In many ways, our forum topic this month addresses that issue. Stacy says: The answer lies in licenses: not the patent licenses, but certain open source software licenses. James says: Demands for royalties are becoming rarer, in our own domain.

My thoughts specifically to these two comments are as below. I also extend this discussion with implications for the future.

1) Open source licenses are not incompatible with IPR: Open source licenses are admittedly complex but they come down to one basic principle. (No, it is not about ‘free’ or ‘paid’). Essentially, Open source licenses come down to the ability to modify and distribute derivative code. The two positions are: Either you have to contribute back any modifications to the original code and redistribute the modifications as per the original license (copyleft) OR you can ‘keep’ and distribute the modifications and add any conditions (IPR, payments etc) to the modifications as long as you indicate the original license of the code and do not violate anyone else’s IPR. The two best known examples of the two perspectives for Open source licenses are GPL v 3 (copyleft) and Apache.

The Apache License, does not require modified versions of the software to be distributed using the same license. In every licensed file, any original copyright, patent, trademark, and attribution notices in redistributed code must be preserved (excluding notices that do not pertain to any part of the derivative works); and, in every licensed file changed, a notification must be added stating that changes have been made to that file.

This means there is no conflict between the Apache license and IPR, patents, payments etc.

2) Demands for royalties increasing depending on domain: In the domain I work with (mobility, convergence, sensor networks etc), we do see increasing (and not less) IPR issues. Mobile technology always had to deal with IPR right across the stack (network, device, services etc). My point is: When it comes to hardware and firmware integration (SW-HW interface), IPR has always played a role and it is getting more significant as the entire mobility sector gains in significance. Many of the royalty free arguments arise from the ‘software only’ domain. This may not be valid going forward especially as implementations become more complex and they span software and hardware with blurring boundaries (see below).

Implications:

As Open source matures, here are some of the implications as I see them: (there are many more but I choose three for brevity and focus)

1) Transparency is the key – not Open/Closed

2) Community engagement and trust

3) Blurring the lines between software and hardware

TRANSPARENCY IS THE KEY – NOT OPEN/CLOSED: Today, the biggest challenge for Open source is not the business model or IPR, (the Apache license certainly provides that) but that of trust and transparency. Most people today recognize the difference between Governance models vs. development models. I can explain this simply as: The leverage of control for open source is not who can change the code but rather whose changes will be accepted into the core product. Take the example of Android. The development model is open sourced (anyone can see the code and change it) but the Governance model is (ultimately) managed by Google i.e. if developer A and developer B both modify a specific code segment, the governance model (Google) decides which changes are to be included in the core product. This can be perceived as a barrier depending on the trust, transparency and engagement of the provider. Certainly, the traction gained by Android demonstrates that there is a degree of Trust in Google and indeed benefits for the licensees.

However, staying with Android, last week saw something much more complex i.e. the lawsuit between Oracle and Google over Android. The crux of this lawsuit arises from Sun’s original Java supposedly ‘open source’ terms and is explained by David Vellante via Gigaom which I summarise as follows:

In the license there is a “Classpath Exception” which is a crucial provision that allows developers to link their code to Java without the need to fall under a GPL license—meaning developers can make their own licensing terms and not be bound by GPL. Sun only included the Classpath Exception for the core Java platform – it’s not included the mobile edition.

This meant that it was really neither open nor closed source but rather a lack of transparency on the part of Sun which Oracle is attempting to monetize post its acquisition of Sun. Which brings us to the second point: Why would anyone want to ‘open source’ in the first place?

COMMUNITY ENGAGEMENT AND TRUST: Open source, by definition, needs engagement with the community (specifically with developer communities). Community engagement can occur at many levels. Many successful products have developer programs and the product itself is not open sourced.

Historically, this has worked well for many products. There are two commercial reasons for ‘open sourcing’ a product.

a) Extending the product along unpredictable directions: The first is to extend the product along unpredictable directions. This is the benevolent reason for open sourcing a product. Your product becomes a platform. Others can add value to the product by adding features. This works because the rate of change of products is now too fast. It means that the community ‘morphs’ the product in directions which you (as product owner) could never have anticipated. This could gain you competitive advantage because you gain an early market lead by allowing the community to shape your product in a direction that is beneficial to the community itself(who are often the users/customers of your product)

b) Getting traction for a challenger product: This is often the hidden reason for open sourcing a product. The real reason for open source is to get developer traction for a ‘challenger’ product. Would a Java community develop if Sun launched a proprietary software language? Who would buy license it from (what was mainly) a hardware/server company? So, Java had to ‘appear’ to be open sourced to get community traction.

It is interesting to see the love/hate relationship between open source product owners and the community. Sun clearly misled the community on how ‘open’ its source really was. Following the Oracle lawsuit, Google has suddenly developed a love for the open source Java community, which it had hitherto ignored in favour of its own Android community. Oracle, which has never open sourced its products, has a developer program but no record of any serious engagement with the Open source community. The ASF (Apache software foundation) represents the open source community in the minds of people but does not seem to have any real say in this game (which is between big corporations like Oracle and Google)

BLURRING THE LINES BETWEEN SOFTWARE AND HARDWARE: I said before that the boundaries between hardware and software are being blurred. In future, this will get more interesting when we get into the realms of Open source hardware. Today, one of the hottest products in the open source community comes from a university in Italy – Arduino. A trailer for a documentary for Arduino got 75,000 views in one day. Arduino comes from a university setting. It does not have the baggage from other corporate open source products with hidden agendas. Yet, developers can create commercial products from Arduino because it supports the LGPL license. The hardware is also completely hackable i.e. open and modifiable. This indicates to me that the boundaries are going to get a lot more complex and blurred both for HW/SW but also the management of IPR will be more complex

This is a much longer post that I originally thought and I could add much more but I will stop now.

Based on the above, my only conclusion is: We are going to see a lot more complexity, variety and increasing maturity when it comes to Open source and IPR.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

There are dozens of OSS licenses in use and each one is unique in the way it treats patents. But one thing is clear- it cannot be said as a general matter that open source licenses are incompatible with patents. For instance, a number of what some people might call “commercial style” open source licenses (such as the Apache 2.0 or Eclipse Public License) distinguish between those patents the distributor must license (roughly any of its patents that read on the part of the code it modified or contributed to) and those that it need not provide (patents that read on other unmodified portions of the code) in connection with distribution of the code. It’s clear that distributors of OSS licensed code aren’t thereby giving away all of their patents, even with respect to the broad functionality in that code. This analysis suggests that, at least among this category of OSS license, there is not an inherent tension between OSS and patents.

Aside from what a particular OSS license might require a distributor of the code to do with respect to patents it owns that read on the code, there is an even more important question to ask: How does a particular OSS license treat third party patents to which the distributor has taken a license? I’ve often heard the refrain “Open Source prohibits third party patent licenses with per unit royalties” as the underlying justification for the claim that RAND (which is after all a type of third party patent license) and OSS are in conflict. While it may be true that the very definition of “Open Source” precludes the distributor from collecting a royalty from recipients of the code, there is nothing in the Open Source Definition which precludes the distributor from taking a third party patent license (including one that has a per unit royalty).

The Open Source Definition is in essence a least common denominator for OSS, so there is nothing that would prevent the author of an OSS license from including a term that limited or outright prohibited the distributor from taking patent licenses from third parties. Few OSS licenses do this though, so for the vast majority of OSS licenses, there are no restrictions on the terms of patent licenses (including those negotiated in the patent context) that the distributor might take from a third party. I’d be remiss if I didn’t mention that the GPL family of licenses does include some restrictions on the types of third party patent licenses that a distributor of GPL code can take, but it’s not clear to me that the GPL would prohibit any kind of royalty associated with the economic activity of the distributor (e.g., fixed fee or based on product revenues as opposed to per unit).

This is a complex legal discussion and even experienced intellectual property and licensing lawyers can easily lose the thread. But there are important policy questions that we need to consider as we work through this set of issues. I’ve highlighted just a few of these that I hope might be the basis for continued discussion:

• Are RAND and OSS so in conflict that one really needs to yield to the other, or is this instead just a matter of finding solutions for a set of edge cases?
• Would one model support the full level of innovation that we currently have? Or are we better off in a world where we let multiple business models and innovation regimes battle it out?
• Are there issues beyond a per unit royalty term, such as restricting licenses to only “compliant” implementations or prohibiting sublicensing?
• Aside from royalties, don’t these other terms facilitate important objectives of the standards system (i.e., urging implementers to be compliant with the specification) and how do we balance those objectives into the debate?
• RAND typically covers only essential claims, but we know that there are a wide range of non-essential patents that implementers want to get access to as well (for so-called freedom to innovate). Can we contemplate changes to RAND (under which essential terms are licensed) without regard to the licensing practices for non-essential claims?
• Shouldn’t we distinguish between the implementer who can show that a particular RAND term is in tension with obligations imposed on him by a particular OSS license

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/