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 Open Source Ecology project is a great example of this resilient commons based approach that is strictly open source in its approach. Their values statement encapsulates this:
“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.
Pragmatic Conclusions
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.
thanks for some interesting perspectives. Though I do have 3 points of disagreement:
1. Linux is a terrible example if you’re trying to suggest that profit-maximising corporations do not contribute to the commons.
The Linux kernel is built by corporations and recieves billions of dollars in corporate investment. It is an extremely well-funded project built by employees of Red Hat, IBM, Google, Samsung, Microsoft, and others. The high quality of the linux kernel is of also huge benefit to the entire F/LOSS ecosystem and the GNU project. Presenting Linux as a little community project of commons hackers which is being taken advantage of by external corporations is ridiculous. I don’t deny that the freeloader problem exists in some corners of the commons, but please find a better example when making your case.
2. At least in theory, if patent law works as it is supposed to, having published designs online with a verifiable history of development shows ‘prior art’ and should certainly invalidate any later-filed patent from a third party. I didn’t follow the Makerbot case though so I can’t say if this always works in practise. (as with many of these things, I assume that those with the biggest legal fund will win… which is not necessarily an endorsement of your suggestion for commons projects to seek patents – you need money to defend them)
3. I admire the general goal of strengthening the commons and eliminating freeloaders, though I’m very critical of the practical implementation of any CopyFair license.
For example, what happens if an organisation’s status changes? how do you define military use? how do individuals fit in? how do you effectively police the license? Who makes the decision if a case ‘could go either way’? If it is the project initiator who does so, how do CopyFair-licensed projects with different initiators combine in downstream derivative works? It’s also important to remember that CopyFair-licensed projects are incompatible with existing copyleft commons, i.e. I can’t both share alike under copyleft and share alike under CopyFair, so they can’t be combined).
One huge benefit of existing copyleft licensing is that it is relatively easy to use and understand, without having to investigate and verify a particular person or organisation. There are just two factors which in most cases are simply verifiable: (attribution? check. sharealike? check.)
Licensing based on the person/organisation/field of use massively increases the bureaucratic overhead for the project initiator. It also puts up further hurdles (having to ask for permission in most cases), increases legal ‘grey area’ and discourages collaboration on a project, because of uncertainty over whether someone may qualify, or whether they will still qualify in the future.
So at this stage, I don’t think that a CopyFair approach can succeed alone. My personal approach to ensuring a commons-biased licensing strategy would be a form of triple licensing:
1. project available under copyleft (GPL, CC-BY-SA, CERN OHL) to ensure the growth of the commons and instant, permissionless access.
2. fee-based licensing for specific uses where an organisation/corporation cannot/does not want to sharealike
3. fee-waived licensing for non-profits/coops where they cannot/do not want to sharealike.