License compliance is not a problem for open source users

No readers like this yet.
FOSS?

Opensource.com

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. Open source is so much easier!

But it's easy to forget that.  The New York Times recently featured the activities of the GPL enforcement community. While there's a part of me that's pleased there are people doing this, I'm concerned that their well-intentioned actions - and those elsewhere, such as the Linux Foundation's compliance programme - are the focus of public understanding about open source software. 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 applies a "frame" that serves only the detractors of software freedom.

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 not a user 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 (or the original), 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!

[First published in ComputerWorld UK]

Tags
Simon Phipps (smiling)
Computer industry and open source veteran Simon Phipps started Public Software, a European host for open source projects, and volunteers as President at OSI and a director at The Document Foundation. His posts are sponsored by Patreon patrons - become one if you'd like to see more!

3 Comments

<p>
In the propietary case, you might be able to convince the copyright holder to give you a special license to (re)use part of their stuff in yours (at least if you pay enough), with open source licenses this usually isn't even an option. So Linux can't take parts of OpenSolaris and viceversa, mixing OpenSSL with other stuff is dodgy, ...
<p>
Take a look at David A. Wheeler's <a href="http://www.dwheeler.com/essays/gpl-compatible.html">essay</a> on the matter for a thorough discussion.

I, for one, would love to use open source libs, and the like in some of the software products we build. Unfortunately, GPL/LGPL licensing leaves the corporations that wish to use these modules/libs at considerable risk for lawsuit on copyright infringement, open-ended definitions of the word "contribute", and I don't think any of us want to be the first to test the laws, and licensing agreements in the courts. I believe that adoption of open source, while the arguments are strong for consistency and cross-pollination of code, could still be improved if some of these issues were addressed.

Missed your comment originally, sorry.

I don't think the risks you face are any different to the risks of using proprietary libraries; both have contract terms that need managing in shipped products. At Sun, we used a workflow system for all copyrighted materials entering the company so that we could track and fulfil our responsibilities in anything we shipped. Treating GPL software as in some way toxic is a natural first reaction to the unfamiliar, but allowing it to persist is simply a mistake; manage the risk, don't let the risk manage you.

That's even assuming there's a risk, of course. It's not clear if you work for a company selling software; if you do, there's definitely a risk to manage, but f the software products you create are for use by your own company or for deployment as a web service, the distribution trigger isn't pulled on the GPL and there's essentially no risk to manage.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.