I pointed yesterday to an interesting comment about contributor agreements attached to a report about Michael Meeks speech a LPC. Another comment to the same article by Meeks himself casts light on another, much more serious issue for open source communities; bilateral agreements.
An open source community depends on multilateral agreements - where everyone is able to know anything about the community. This is key to understanding open source licenses, for example. While lawyers are used to treating licenses as bilateral instruments - capturing the truce between two parties - open source licenses are inherently multilateral in their effect and are best understood that way. They are the agreed boundary conditions of the community, its constitution, and treating them as if they were bilateral agreements is the most common beginner mistake for legal-minded folks new to open source.
Communities depend on transparency and equality. Anything that causes community members to engage in actions related to the community that are bilateral will likely be a problem. So some examples:
- Implementing a standard that is covered by patents may mean that some community participants are bound by the terms of licenses for those patents. Bruce Perens speculates that this is the case for Red Hat and JBoss, for example. Perens comments:
But it’s important to note that Red Hat, as defendant, would have had to agree to seal this case knowing its legal partners in the development of JBoss, the open-source community, would be forever kept in the dark regarding whether their own licenses were being violated.
- In order to obtain a non-open source licence to some code (perhaps out of concern for the consequences of a copleft licence like the GPL), it is entirely possible that the customer of the aggregated copyright holder may have to accept terms that prevent them from exercising their rights under the open source licence without breaching the bilateral agreement. Meeks comments:
As soon as a company steps away from a transparent, open Free Software license - the proprietary license will almost certainly have "non-fork" provisions - such that these guys are bound to the other side of whatever fork you do. So - sure, of course you always have the right to fork: but the effectiveness of doing that on your own is going to be small, and you may find you have a set of stake-holders that agree with your direction; but simply cannot help you due to their proprietary license agreement.
This is my top reason for fighting in standards bodies to ensure that there is no scope for participants in the creation of standards to offer patent licences under RAND terms. When RAND terms are permitted, it indicates the standards group includes participants in the standards process who require the right to hold in reserve the option of controlling the relationship with the end user or with selected implementers.
In particular, the lack of any set terms up front (ex ante in the jargon) means participants are permitted to introduce different terms for different implementers depending on the competitive and market context. This scope for additional restrictions and for variability dependent on the field of use is what makes any form of RAND a red flag to open source developers. Only full patent non-assert commitments should be tolerated in future software standards. India is heading the right way but there's still a long way to go for most of Europe.
Open-by-rule open source communities depend on multilaterality - equal rights, transparent actions and meritocratic governance - for their success. Now that we seem to be moving into the era of open-by-rule communities, we can expect to see bilateral behaviours being prohibited by those rules. It can't happen too soon.