The largest forces in technology today – consumer-facing companies like Google and Facebook, business-facing companies like Salesforce, now even first-gen tech corporations like Microsoft and IBM – all increasingly depend on open source software. That means collaborative inter-company development of the software components and infrastructure technology these enterprises use for their business success. It’s enabled by the safe space created when they use their IP in a new way – to ensure an environment for collaboration where the four essential freedoms of software are guaranteed.
They use open source licenses to handle the copyrights and patents, community governance to handle trademarks and other patents and public benefit entities to protect everyone from everyone else. Each participant in the collaboration works at their own expense in order to achieve a shared outcome that benefits all, including themselves. When they create an enhancement, fix a defect, participate in a design, they are not “working for free” or “donating their work” so much as they are “participating in co-development”. It’s a new way to leverage IP for greater benefit than can be achieved directly monetising its scarcity.
The safe collaboration space depends fundamentally on equality of participation and transparency of behaviour within the safe space. Organisations like Apache, OpenStack, Cloud Foundry and many others go to great lengths to ensure transparency and equality, and have rules that exclude the possibility of participation by those who attempt to breach either. Seen in the context of a safe collaboration space, standards-essential patents (SEPs) are obviously a problem, and a FRAND licensing regime is obviously an anti-pattern for dealing with them:
- SEPs are a problem because they create an implied threat that means every participant fears the future actions of the patent holder(s) as well as their potential future owners. Possessing a monopoly makes them inherently unequal. Moreover, the power it gives them perpetuates and magnifies that inequality, allowing them to exert influence even without contribution, something anathemic to open source communities.
- Mandating FRAND is an anti-pattern since it guarantees that the patent holder will need private relationships with community participants. There will be no transparency either in the relationship or in the behaviour it consequently generates in the community. This undermines trust, since commits will be made or withheld on the basis of the private relationship and portions of the collaboratively-maintained software will be forced to be proprietary rather than shared, reducing the scope of the innovation and the quality that would otherwise arise from collaboration to magnify and perfect it.
As a result, existing technology collaborations eschew SEPs, apply licensing terms that severely discourage patent aggression and disadvantage those who attempt it. Far from being a sacrifice, this use of IP is arguably the dynamo of the technology industry, allowing startups and established corporations alike to rapidly climb upon the shoulders of earlier giants and deliver innovation. Web servers, smartphones, business automation, cloud computing and the sharing economy – to name just a few examples – all arise from the use of open source software and would probably never have happened without it.
Mutually Assured Control
But that’s not the case in markets where collaboration happens at the level of specifications and de jure standards rather than code and de facto standards, such as the telecommunications industry. Decades of comfort with SEPs and FRAND terms have resulted in a heavy investment in patents licensed in such a way that they create mutually-assured control. Telecommunications standards are so heavily encumbered with SEPs that patent pools and cross-licensing have become the norm. That in turn has created a barrier to newcomers that has made the telecommunications industry a cartel of giants.
The cartels of giants of the telecom and similar industries now see their mesh of complex physical technologies coming to a lifecycle point where software dominates. The rise of apps and smart devices for the user and of software-defined and implemented infrastructure for deloyers, means that there is more and more of an incentive to move in to the computer and software technology markets. This in turn has created an impetus to adopt the working practices of the ICT industry, which notably today means collaboration over shared implementation rather than just over mutually essential specifications. As a result, they seek to introduce open source into their business.
That’s where the conflict arises. From one side of the divide come successful corporations who believe collaboration means safe spaces where startups and incumbents co-exist in mutual safety. From the other come legacy corporations who believe collaboration means creating a mesh of mutually-assured destruction that promotes progress for giants who’ve paid their dues.
These models cannot co-exist. To mandate a system where controlling patents are permitted in standards extends the effective monopoly of the legacy industries into the worlds of the Internet and ICT, to the detriment of the current competitiveness and innovation of the technology industry. On the other hand, to require that any patents in new ICT standards are de-weaponised would create a level playing field for participants while allowing everyone to collaborate using the open source methodology and the free software freedoms associated with it.
So will we create a new opportunity with policy instruments like EIF, or allow an existing industry to hobble another as the two collide? That’s the real question about FRAND terms for SEPs. Trying to force-fit FRAND into open source by mistakenly asserting it’s just a matter of compliance is sure to fail. Despite the name, FRAND is always discriminatory.