Image via Wikipedia
License compliance is a major and costly issue for proprietary software, but the license involved in that case is an End User License Agreement (EULA), not a source license delivering extensive liberties. When we compare like-for-like, we discover open source software has no such issues. End-users do not need to have a license management server, do not need to hold audits, do not need to fear BSA raids.
Of the many attributes of software freedom that could move to front-of-mind, it strikes me that the minimal license compliance burdens for open source software are actually a comparative strength and having them presented as a feature by commercial interests in various contexts applies a “frame” that serves only the detractors of software freedom. No wonder proprietary vendors want to divert our attention! Open source is so much easier!
On Frames
I owe American progressive scholar George Lakoff for the insight about framing. As he explains in detail in “Metaphors We Live By” and in more accessible (if politically-oriented) terms in “Don’t Think Of An Elephant“, the words and concepts we use about things are a powerful tool for shaping our understanding of them. The choice of terms used to speak about a subject can be used to convey an outlook and evaluation of the subject more powerfully than we might imagine. Thus the constant repetition of “tax and spend” to describe the politics of a political party, even if used without accusation (“they are not as prone to raising taxes as you might think, and their spending is largely under control”) defines the criteria by which the party is judged as their propensity to raise taxes, whereas the real area where comparison is due may actually lay elsewhere.
By careful selection of the set of terminology and concepts used to talk about ones opponents – the “frame” placed around them – it’s possible to completely distract an audience from the real issues and actual benefits, as the victim of the frame will spend all their time arguing against the frame (and thus reinforcing it as their defining issue) rather than speaking about their strengths.
Open Source Compliance Is A Marginal Issue
Do we need to worry about license compliance? Obviously respecting authors and obeying the law are important, but for most of us the answer is probably “no”, there are bigger things to worry about. Open source software comes with a set of liberties commonly called “the four freedoms“. My summary of them is that any software under an open source license may be used, studied, modified and distributed for any purpose, as long as the license is obeyed.I believe all the benefits of open source are the first and second derivatives of these freedoms.
- As a user of the software, there are no conditions of any kind set on your use; you are free to use it for any purpose. There is no compliance requirement. Pause and reflect on that for a moment. Open source does not place a compliance burden on the end user, does not mandate acceptance of an end-user license agreement, does not subject you to para-police action from the BSA. That is a significant advantage, and there’s no wonder that proprietary vendors want to hide it from you and make you think open source licensing is somehow complex, burdensome or risky. If all you want to do is use the software – which is all you are allowed to do with proprietary software as the other three freedoms are entirely absent – then open source software carries significantly less risk.
- If you move beyond use of the software and study the source code, there is also no compliance burden. There is no risk associated with using the knowledge you gain for other purposes. You do not become “tainted” in some way, and there is no need to create a “clean room” environment when you build related software using that knowledge.
- If you move beyond studying the code and actually modify it, there is no compliance burden. You are free to use the modified version in any way you wish, both personally and within your business. There is no need to account for your use, no need to send your improvements somewhere else, no requirement that you participate in the community. Of course, if you don’t you won’t get all the benefits associated from joining the community, but all the same the choice remains yours.
- If you move beyond modifying the code and decide to distribute your modified version, that is the point at which there may be compliance issues with the open source license. You only need to check you are passing on the same rights to others as you received with the original code.Even then, not all open source licenses place any significant responsibilities on you. Licenses like the Apache, BSD, MIT and X11 licenses are extremely easy to comply with and licenses like the CDDL and the Mozilla license involve negligible housekeeping if you are participating in an open source community – simply committing code back to the community repository is likely to be enough. Only strong copyleft licenses like the GPL family need an audit process, and even there it’s no more burdensome for most of us than the sort of tracking we would do anyway in our version control system.
There are issues that companies who are shipping open source code as a part of products need to keep in mind, but in my view they are no more complex and burdensome than the issues arising from shipping proprietary software. It’s important to make sure you know you have the necessary rights to everything you ship, and when you ship code made from proprietary elements you naturally do so. Only sloppy developers fail to do this, and the Linux Foundation’s programme is a fine cure for that sloppiness.
Software Freedom Is Not About Licenses
The result of making it seem otherwise is that the more subtle opponents of open source are able to raise Fears about compliance, attaching Uncertainties soluble only via extra costs that aren’t really applicable to the majority of uses and thus seeding Doubts that the bother is really worth it. This has all the classic hallmarks of FUD, spinning the weakness of proprietary software and its BSA-mediated enforcement heavies and by implication tarring open source with it. We should reject the frame
Ultimately, software freedom is not about licenses; they are merely a part of the mechanics. It is about the liberty to use, study, modify and distribute software, and we are free to use that liberty as little or as much as we want without interference. Allowing ourselves to be distracted from the liberty which is the course of all of the benefits individuals and business gain from open source is a mistake. Don’t let the forces of proprietary software do it to you. Reject the frame and revel in your liberty!
This essay is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
While you are not compelled to do so, the author would welcome notification of derivatives, especially translations which will be gladly posted here. If your intended use is commercial, please do ask for permission as it is usually granted; it is withheld because of past abuses.
Wild Webmink 
I agree that there’s complexity in commercial licenses and that in many ways open source licenses are simpler. The difficulty is that whereas companies typically have (often large) purchasing organizations set up to help make sure developers aren’t being “sloppy,” most don’t even have policies in place to guide those developers’ use of open source.
The LF’s Open Compliance Program(me) is a great source of guidelines, best practices and training (much of it free…as in free beer). Also, there are other consultants (e.g. Olliance Group) that advise clients in this domain and (as the OCP prescribes) tools for automating and minimizing overhead.
You’re missing the point though. If all that is happening is that the software is being used, and not redistributed, /there is no compliance action of any kind needed/ – no EULA, no tracking, no license registration, nothing. Introducing the complexities associated with developers creating new works is completely irrelevant to 99% of people and need never be mentioned.
I realise that’s not the message Black Duck want propagated, but I am tired of people transferring the complexities of the world of development (which are just the same if proprietary software is being used) into the world of use.
Agreed, Simon. If someone is just using a FOSS program as is, they don’t have to think about license compliance. Black Duck (and, yes, I work for Black Duck) doesn’t really target such end users, so your message is in no way inconsistent with ours.
Our value is for development organizations who modify open source (the beauty of open source being that you can do that) not just use it (your 3rd and 4th use cases). Clearly licensing is the big issue for organizations that distribute, but we also find that enterprise IT groups developing apps for their own use want to make sure they are following license obligations. The GPL obligation, for example, that says modify away, but put notice of changes in modified files.
Certainly, though, licensing is not the top issue for enterprise IT groups. They are much more concerned with supportability, internal standardization, security, etc. So, compliance is important, but compliance with company policies, not license obligations. Again, the old style supply chain that funneled through a central purchasing organization was helpful in managing such compliance, but the wonderful ease of FOSS procurement brings with a governance challenge that requires new approaches.