Linux kernel devs, Samba join GPL compliance effort

Software Freedom Conservancy expands roster of compliance seekers

By  

GPL enforcement within the free software community has just stepped up its game.

Software Freedom Conservancy (SFC) has announced a coordinated effort among several of its member projects to ensure compliance with their Free Software licenses.

SFC is a non-profit umbrella organization that provides support and administrative services to its members. It has also made the service of GPL enforcement available to member projects, but to date, only the BusyBox project has really availed itself. But that's about to change, as one of SFC's more well-known projects, Samba, will also enable SFC to engage in compliance efforts on its behalf.

Up until now, Samba has been taking care of GPL compliance itself, usually led by Samba Team member, Simo Sorce. According to the press announcement: "Samba is delighted to help Simo by appointing Conservancy officially in charge of these efforts, and to gain the benefit of Conservancy's wealth of knowledge and expertise in achieving license compliance in a friendly and collaborative way."

It's not just Samba coming on board: the Evergreen, Inkscape, Mercurial, Sugar Labs, and Wine projects have all requested SFC handle any compliance issues for their projects if they come up.

Another key development from SFC today is the formation of an entirely new project, the GPL Compliance Project for Linux Developers, which enables independent Linux kernel developers who own copyright for the code they have contributed to the Linux kernel under the GPLv2 to let SFC work on compliance issues on their collective behalf.

Seven copyright holders have formally asked SFC to engage in compliance efforts for their copyrights in the Linux kernel, including one very vocal proponent, Matthew Garrett.

This should come as no surprise, since Garrett has long advocated GPL compliance enforcement, and was involved last Winter in a public argument with former BusyBox developer Rob Landley, who is a key developer on the ToyBox project, which is working to re-create a non-GPLed version of the BusyBox tools for embedded Linux.

In a statement today, Garrett said: "For some time, many Linux kernel copyright holders have offered our moral support to the BusyBox enforcement efforts through Conservancy, but didn't have the ability to formalize that support. I'm glad to put my copyrights forward for this new initiative, and welcome any Linux kernel copyright holders who wish to join us to reach out to Conservancy via compliance@sfconservancy.org."

GPL enforcement is a surprisingly touchy subject within the free software community. While many developers agree that compliance enforcement is needed, there is a vocal subset of developers who argue that enforcement should not be carried so far that there's a risk of developers simply refusing to use the code in question. Nor do they feel that the primary rationale for enforcement--the release of code that will foster new projects just by the code's general availability--has never really come to pass.

Bradley Kuhn, the executive director of SFC, has been hinting around at this new push towards expanded GPL enforcement for some time. Back in February, Kuhn foreshadowed the inclusion of more projects joining SFC's GPL enforcement process.

"I think the community needs other projects to stand with us to enforce the GPL, and I'm working on coordinating that. BusyBox has become a 'poster child'--unfairly--because for the last few years, BusyBox was the only project actively enforcing the GPL," Kuhn said in a post on the BusyBox mailing list.

It is not entirely clear how many, if any, compliance issues will come out of the GPL Compliance Project for Linux Developers. Even as he was arguing against the creation of the ToyBox project in February, Garrett also admitted the reason why he had not raised compliance issues for any of the Linux kernel code he has contributed over the years.

"Most of the past work I've done is in bits of the kernel that are rarely present in infringing devices, and most of my recent work is owned by my employer rather than me," Garrett commented on his blog.

Indeed, since many of the Linux kernel developers are employed by corporations (save for the Fellows that are salaried by the Linux Foundation and unpaid volunteers), one has to wonder: will there be any participant in SFC's new compliance program who will be able to call for GPL enforcement?

It has been theorized that this is only part of the reason there isn't more GPL enforcement of the Linux kernel. The other may be social, as developers would just rather not bother with enforcing compliance. Better, they may argue, to just let the violation go and get on with developing better code.

If the SFC will be able to act on the behalf of the Linux kernel developers who up until now were simply not willing to make the effort, it is possible that we will see more than just BusyBox getting GPL compliance enforcement.

But what will more GPL enforcement mean? The admittedly cynical part of me expects to see a lot more arguments for more permissive license adoption (such as BSD or Apache Software License) as opposed to restrictive GPL-family licensing. I'm sure someone will see today's development as "proof" that the GPL is a legal land mine just waiting to explode within a given organization.

Nothing could be further from the truth, really. The GPL is no more arduous a license than any other as far as compliance goes. But try telling that to the opponents of Linux and other GPLed technology.

Read more of Brian Proffitt's Zettatag and Open for Discussion blogs and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness