Open source ensures developers already have permission to innovate and don’t need to ask first.
If you want your code to be open source, it needs an OSI-approved copyright license. Code with no license to the copyright isn’t open source. But project success needs more than just an OSI-approved license — it needs “permission in advance” for every developer and deployer.
That may sound basic (and obvious for OSI’s president to say), but a surprising number of people disagree. I’ve frequently heard three misunderstandings expressed from across the open source “political” spectrum. Each is dangerous in its own way; together they are a threat to open source.
The Essential License
Let’s take a look at each misinterpretation.
- All software should be public domain. Every restriction is wrong. Adding a license is a restriction. This view has come from developers who regard the expectation of a license as legalistic interference. They would rather their code was “public domain.” Some realize that public domain does not make matters clear enough for developers outside the United States, where the concept is different or nonexistent. For them, falling back to using the BSD license is the least-worst solution and anything more is an imposition.
- Anyone who can stop software being open is wrong. This license doesn’t stop proprietary use, so it’s bad. This view has come from developers who believe all code that starts out open source should always remain open source, regardless of how it’s being used. They see licenses that allow others to take open source code and make it hidden and proprietary as wrong, and prefer licenses that require republication of source code. As such, they reject any licenses that aren’t strongly reciprocal.
- When it’s code that makes things, the result can’t be copyrighted. Adding a license is overreach. This view arose in a conversation between lawyers talking about 3D printing. They saw applying a copyright license to source code used by a printer as a claim of ownership. As one correspondent wrote to me: “Chutzpah! We shouldn’t overreach with copyright claims and put licenses on everything in sight.”
All of these statements come from looking through the wrong end of the telescope. In open source, we “put licenses on everything in sight” not because we want to claim ownership but rather to give permission in advance. When the day arrives that someone becomes concerned about the existence of a copyright claim, there will already be a positive response. We go to great efforts to do so, though some regard it as obstructive bureaucracy.
Many would prefer to simply say their code is “public domain,” but the concept is not recognized worldwide. That leaves doubts about sufficient permission-in-advance for some collaborators. We take these steps to guarantee the freedom to innovate without seeking permission first.
Seen through the lens of “granting permission in advance,” the distance between the BSD license at one extreme and the GPL at the other does not seem so large. Both seek to set unknown future innovators and collaborators free to innovate by granting permission to use and change the code any way they want — to everyone. Neither is seeking to claim ownership or restrict use according to their worldview, even if those worldviews differ on the nature of causality. I’m happy to respect their ideological differences and celebrate their shared intent to grant permission in advance.
All OSI-approved licenses grant permission to deploy code for any purpose without restriction, as well as to read, study, and improve the code and to pass it on to others. All those permissions are given in advance; no OSI-approved license withholds them. That’s what OSI’s work of the last 15 years has delivered — a guarantee that “the four freedoms” are embodied in approved licenses so that you can simply go ahead and use the code if you see one.
Practitioners of other disciplines related to open source — open hardware, 3D printing, and so on — take a similar approach. They apply copyright licenses to their designs not necessarily to assert claims of copyright ownership or to limit the actions of any party, but so that their downstream collaborators are freed from concerns about the legality of their actions. Open source licensing is not about forcing others into your worldview; it’s about giving permission in advance to others to create the greatest freedom to innovate. Applying an open source license is a work-around to counter the expected greed of others.
Those over-reaching are not the developers who want to remove barriers to collaboration — it’s those whose expected behavior is to claim maximum rights in all cases. In the case of open hardware and the Internet of Things, it seems rash to claim certainty about the ineligibility of copyright where the “object code” is hardware. The lack of involvement of humans in the generation of the source files is a leap, one I’d expect corporate counsel to be able to challenge in court — silicon fabricators copyright the source files to their chip designs, for example.
Yes, a whole industry revolves around pursuing conformance breaches and using copyright law to suck money out of victims. But applying an open source license does far more to fix that than either leaving the license off (otherwise known as “reserving all rights”) or using a proprietary license (the notorious EULA).
Society depends on a rich and deep commons of reusable culture, technology, and ideas. Innovation is rarely creatio ex nihilo but rather, as Newton is supposed to have commented, the act of “standing on the shoulders of giants.” Innovators see new ways with old ideas; they envisage solutions to old problems framed by existing craft. Even the greatest of art exists framed in the context of its contemporaries and predecessors.
If we place the commons off-limits, by doing so we also ban most innovation and art and put the brakes on progress. If we want to see innovation in the emerging, meshed society, applying copyright licenses to source files is a necessary prophylactic, not a land-grab. Granting permission in advance so innovators can work their magic freely is grace, not chutzpah.
Permission in advance goes beyond just the rights to copyrights and patents granted in an OSI-approved license. Here’s a model I use in my consulting engagements to help clients work through their proposals for new open source community activities. Evaluating a project’s licensing, patent, and community management strategy should begin with the question: How confident are community members that they have permission in advance to do what they need to succeed?
1. Am I granted copyright permission? An OSI-approved license guarantees this; does it apply to all your code? If there are portions of your code that remain proprietary, a community is not truly free to form around the code. Developers wanting to enhance or even deploy that portion of the code do not have permission in advance, so probably won’t want to join you.
2. Am I free to use my chosen business model? Copyleft licenses may limit certain business models, but issues arising from them aren’t usually directly to do with their copyleft terms. Communities use the GPL very effectively where the playing field is level — the Linux kernel and the GNOME community both come to mind. More problematic is the use of strong copyleft license like the AGPL in conditions where the “project owner” is not subject to the terms of the license for trading. In these circumstances, one community member is free to engage in proprietary strategies while everyone else can only offer support or add-on businesses because any platform value-add would have to be donated to the business of that one community member.
3. Am I unlikely to suffer patent attack? It can never be prevented, but patent grants like the ones in modern open source licenses — plus corporate pledges and nonaggression alliances like OIN and LOTN — can all help. Communities with no patent grants to protect people can feel like the Wild West, with the concern anyone could show up with weapons any time you’re successful.
4. Am I free to compete with other community members? Community rules that prohibit — explicitly or tacitly — competition with the sponsor reduce freedom. That includes any attempt at field-of-use restrictions — which are banned in OSI-approved licenses but still show up in governance rules — such as “not for mobile use” or “can’t be used for military purposes.”
5. Am I free to contribute my improvements? Copyright assignments get in the way, as does any mandatory agreement that will require legal review. I contribute back to reduce my maintenance and refactoring burden so that it’s not only philanthropy. It’s reasonable for a community to expect me to demonstrate competence before giving me commit rights, asking me to channel my work through others initially. It’s much less reasonable to insist I have to assign ownership of my work to a “project owner.” That chills participation, both by forcing me to effectively pay to participate and by forcing me to get legal advice first.
6. Am I treated as a development peer? Changes that are conducted in private, then “thrown over the wall” to the community rob potential collaborators of the confidence they have space to innovate. Why would you invest in significant new work, only to find the “project owner” rendering all your work moot with a bolt-from-the-blue code update? When the only way to be sure you’ve permission to innovate is to enter into a bilateral agreement with one company, you’re being treated as a client or partner and not as a community peer.
7. Am I inclusive of all people and skills? How do you license your documentation? Can I contribute to it? What about your user support community? Can I join in both to get and to give help? Do you have policies to discourage harassment of people who don’t seem to fit into your community norms? If people need to ask for any of those, that’s a lack of permission in advance as well.
Using the lens of “permission in advance” turns out to be an easy and useful tool for diagnosing your community governance. The seven points here aren’t the only concerns; which do you use for your own purposes? I would be interested to hear what tests others apply to community and project governance to determine whether there is truly freedom to collaborate.
(Parts of this were published in InfoWorld on November 7, 2014 and January 21, 2015)