On Patents, Open Source Design and Reciprocity
I previously blogged on open source and IP here and I wanted to revisit this in a more concise way to focus in on the limitations of open source and commons approaches in the context of patents.
The Benefits of Open Source Design
Developing a product or technology in an open source way offers advantages to society and also the development team. For the core team they have the many eyes of the community on the key development issues, a form of giant, distributed R&D department. Building a strong network of collaborators and a vibrant community which will contribute to varying degrees also acts to build a market and a brand for the core team (whether they be a company, charity or foundation). For society, commonly held knowledge resources are created which has a great value both as an educational resource and making technologies available to communities around the world. It adds resilience and sustainability to our communities by allowing technologies to be re-purposed appropriately and also more easily maintained to minimise waste.
“The end point of our practical development is Distributive Enterprise – an open, collaborative enterprise that publishes all of its strategic, business, organizational, enterprise information – so that others could learn and thereby truly accelerate innovation by annihilating all forms of competitive waste. We see this as the only way to solve wicked problems faster than they are created – a struggle worth the effort. In the age where companies spend more on patent protectionism than on research and development – we feel that unleashing the power of collaborative innovation is an idea whose time has come.”
The funding model for OS Ecology seems to be based around two main sources, crowdfunding/donations and charging for educational workshops teaching others to build and use the machines they have designed.
The Limits of Open Source Design & the Need for Reciprocity
Michel Bauwens of the P2P Foundation however emphasizes the need for reciprocity, suggesting, “the more communistic the licence, the more capitalistic the outcomes”. Making the case here that with open source projects eg. Linux, a profit maximising company can come in and make massive profits using the commons resource of the stable body of code at the centre of the Linux project.
This means that the value of the commons provided by free labour is being exploited by private companies and that they are not then obliged to give back to the commons to sustain it financially.
To this end, Dmytri Kleiner, has proposed the Peer Production License (PPL) whereby free use is granted to non-profits and coop entities, but commercial entities which make no contribution have to pay a license fee. Michel Bauwens has termed this an example of a Commons-Based Reciprocity License (CBRL), which has been further developed into Copyfair. These proposals suggest a means to create a self-sustaining commons of knowledge that accepts wider community contributions and at the same time provides for funds to enhance and grow a core team of curators for the project.
The nature of IP – Copyright and Patents Are Very Different
Importantly, however, for the discussion of the application of open source in physical designs, a CBRL/copyfair licence would be based on copyright, as with creative commons or copyleft style arrangements. Now, copyright is an automatic right in most countries, so in adopting a copyleft, copyfair or other licences you are then disposing of a recognition of ownership that you already have.
Patents, on the other hand, are territorially based and ownership is granted by the relevant state authorities following a relatively lengthy procedure with very real financial costs. This is largely incompatible with distributed open innovation particularly as secrecy (non-disclosure) must be maintained up until a patent is filed.
This means that an open source physical design could have the schematics and drawings of a design’s implementation covered by a CBRL but in terms of fundamental principles which would be patentable, the commons could not be protected in this way.
In fact, when we look around at the more popular open source design and open source hardware projects, such as the Ultimaker, the (original)Makerbot or Reprap, they are all based on expired, existing patents. They do not, in general, propose new technologies that would be patentable, though interestingly, when Makerbot was bought out by stratasys, it then filed a patent and released a range of closed-source models to the market. This eventually led to conflict with the original supportive community that had grown around the original open source Makerbot. Makerbot were accused by the community of stealing ideas and attempting to patent them, an enclosure of the commons. The community reacted with the hashtag #takerbot on social media.
Reliance on copyright and copyleft in a classic Open Source project leaves collaboratively produced product innovations in the paradox highlighted by Michel Bauwens: that the more communal the license, the more commercial interests can exploit them without contributing to sustaining the innovation process that generated them.
If an open source project were conducted in secret, however, it would not be able to leverage the network benefits of the distributed development resource of the online community and would be forced back into the standard model of investment, patent acquisition and defence.
Conversely, if a development is carried out in a truly open model with disregard for how patents work, the open community could find its work enclosed at a later date by a proprietary patent as seen with the Makerbot community.
As a practising designer and engineer I am looking to launch a technology project and I want to embed the values of open source communities in its development. In particular, I want to ensure that the technology is not used for military applications.
I have come to the conclusion that a patent is needed to establish a “property” which I can then licence at a lower fee to non-profits in a way that reflects the goals and spirit of the CBRL. The core technology will then be a basis for an open source community platform around which developments and applications grow. Any licensing fees to larger profit-maximising companies will then feed directly back into sustaining this platform. The challenge then is to reach the stage of obtaining patents in key territories without requiring external investors who do not share these goals.