From

Thank you

Sorry

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.

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.