In recent years, new projects have been much more aware of the role of the license in enabling community formation and function. The result has been a trend toward liberal licenses such as the Apache License or the BSD/MIT licenses, thereby eliminating perceived barriers to participation for corporate contributors. OpenStack, for example, uses liberal licensing.
Yet even projects that use the liberal BSD Unix license have at times railed against corporations who use their work without contribution, suggesting there's a role for copyleft, too. Most communities are offended when a profitable consumer of their work is all take and no give. This sense of justice will likely push the needle that has swung full-scale from GPL to BSD back to the middle ground, best represented by the recently revised Mozilla Public License, MPLv2.
MPLv2 is explicitly compatible with the GPL, and it contains no clauses that prevent mingling with liberal licenses, aligning it with the sensibilities of most of today's open source communities. It does include a weak copyleft requirement that changes to files managed by the project must be published, but it allows developers complete freedom to use the compiled binaries any way they want, including mixing them with non-open-source code to create proprietary products.
3. The specter of software patents
The legal system is having an increasing effect on today's open source movement in the form of software patents, a stark contrast from 15 years ago.
A form of social contract between inventors and society, patents exchange a temporary monopoly of a practical invention for the publication of that invention so that the public at large -- "the commons" -- can benefit from it.
Patents protect implementations of ideas, not ideas themselves. But over time, clever drafting by legal experts has pushed the envelope for what can be patented, and in the software industry, a loophole that allows ideas to be associated with a physical object and thus rendered patentable has yet to be addressed by legislators. While software can only formally be protected by copyright, verbal constructs attaching software or algorithms to general-purpose computers have allowed patents on software to increasingly be granted.
Worse, software patents make no allowance for the reality that, unlike the creation of physical objects, two programmers in two unconnected places may in fact devise the same method to solve the same problem without copying one another. Thus, for proprietary and open source software alike, patents represent a threat. At any time, a well-resourced corporation wishing to chill competition can challenge another entity of any size. There's really nothing an individual developer can do to be protected from software patents, although Debian provides worthwhile advice.
Counterclaims can sometimes protect an organization from a patent aggressor, but an increasing number of patent aggressors are entities that make patent threats to force licensing. Against such companies, there is no recourse for countersuits, as the aggressor has no products that might infringe patents in your own portfolio. Consequently, the best defenses for developers have become:
- Building patent pools to defend against corporate aggressors
- Buying portfolios to take patents out of circulation
- Building tools to establish prior art and engage in defensive publication
- Proactively litigating and securing cross-licensing from competitors