Why the GPL licensing cops are the good guys

The Software Freedom Conservancy (SFC) — a nonprofit project hosting the Samba and BusyBox projects — has announced a new initiative to engage in enforcement of the Gnu General Public License and related free software licenses. The move arises following a controversy earlier in the year when it seemed that a former developer of BusyBox — a command-line interface used in embedded devices — was working on ToyBox, a non-GPL-licensed clone of the project. This concerned GPL enforcement activists because BusyBox is a popular entry point to wider GPL enforcement by the SFC on embedded devices.

The news brings together several SFC projects, including Samba, BusyBox, Evergreen, Inkscape, Mercurial, Sugar Labs, and Wine, all of which explicitly permit the conservancy to pursue violators of the GPL. SFC is also launching a new project to gather copyright holders in the Linux kernel who are keen to see legal pursuit of GPL violators. Called the GPL Compliance Project for Linux Developers, it brings together seven Linux kernel contributors, including the well-known Matthew Garrett.

[ Also on InfoWorld: Blogger Simon Phipps expounds on the inherent evil of software patents. | Track the latest trends in open source with InfoWorld’s Technology: Open Source newsletter. ]

With these projects joining the effort — especially the Linux kernel copyright holders — SFC now has copyright standing even in cases that do not involve BusyBox.

No concern for enterprise users

Although this news may sound worrying to enterprise open source deployers, it’s unlikely to result in any change. You are several orders of magnitude more likely to be raided by your proprietary suppliers, in the form of the Business Software Alliance, than to ever hear from SFC, let alone face any action. License compliance is a major and costly issue for proprietary software, but the case concerns an end-user license agreement (EULA), not a source license. Open source licenses deliver extensive liberties to developers and place no burden on users. Indeed, as Kuhn comments:

… most free software users never actually have to deal with the details of compliance. Requirements of most copyleft licenses like GPL generally trigger on distribution of the software — particularly distribution of binaries. Because most users simply receive distribution of binaries and run them locally on their own computer, rarely do they face complex issues of compliance. As the GPLv2 says, “The act of running the program is not restricted.”

When you compare like for like, you see that open source software has minimal compliance issues. Users of open source are always free to employ the software for any purpose without further permission. They do not need to have a license management server, hold audits, or fear BSA raids. Of the many attributes of software freedom that could move to front of mind, it strikes me that the story on license-compliance burdens for open source software shows a key strength, regardless of what proprietary vendors — or companies whose business models predate the open source movement — may want you to think.

The SFC’s real target: Electronics makers

If enterprise users can essentially ignore this news, who is the target of the SFC’s actions? Its approach is well documented, but its targets are harder to identify. Kuhn’s presentation on the subject makes clear that SFC’s main target is hardware manufacturers — typically those creating low-cost consumer and business electronics. Always keen to shave the last few cents from their bill of materials, these manufacturers tend to procure their firmware from low-cost suppliers that have in turn delivered open source software without passing on its licensing terms. It can come as a surprise to the hardware manufacturer to discover a violation of the license terms.

Open source communities rely on those that benefit from their software to contribute improvements to the code. Although some communities, such as the Apache Software Foundation, can lean on market forces to encourage contributions, groups that pick copyleft licensing — which requires the source to distributed software to be made available as a condition of the license — believe contribution must be mandated.

When a manufacturer chooses — or is led to choose by lack of information — to distribute such software without passing on the source, the community faces a real loss.

The Software Freedom Conservancy does a valuable job in this area. Its action has provided manufacturers with an education on the subject of compliance, and it has created an environment where best practices are observed by them. Almost every intervention results in the vendor’s compliance; only one of its cases has gone the distance, out of about 100 interventions per year, Kuhn says.

Debunking the false controversy

Why is there controversy? In short, self-interest — on the part of the proprietary vendor community.

Remember: As a user of open source software, there are no conditions of any kind set on your use; you are free to work with 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 user, does not mandate acceptance of an end-user license agreement, and does not subject you to para-police action from the BSA. That is a significant advantage, and there’s no wonder proprietary vendors want to hide it from you and make you think open source licensing is somehow complex, burdensome, or risky.

But it’s not:

• If all you want to do is use the software — which is all you are allowed to do with proprietary software — and 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 want, both personally and in your business. There is no need to account for your use, no need to send your improvements somewhere else, and no requirement that you participate in the community. Of course, if you don’t do these things, you won’t get all the benefits associated from joining the community. All the same, the choice remains yours.
• If you move beyond modifying the code and decide to distribute the software, there may be compliance issues with the open source license. But you only need to verify that you are passing on the same rights to others as you received with the original code.

Even then, not all open source licenses place significant responsibilities on you. Licenses like the Apache, BSD, MIT, and X11 licenses are extremely easy to comply with, and 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 it’s no more burdensome for most of us than the sort of tracking we do anyway in our version control system.

Should enterprise software users worry about open source license compliance? Obviously, respecting authors and obeying the law are important, but for most of us the answer is no. While the Software Freedom Conservancy is serving us all by keeping electronics manufacturers honest, the rest of us can use open source as a way to relax about license compliance rather than worry about it.

This article, “Why the GPL licensing cops are the good guys,” was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.