SFLC releases GPL compliance guide

Advanced Corda CenterView™ Data Visualization for the BusinessObjects™ Intelligence Platform Corda Technologies presents a white paper on pervasive BI. The BusinessObjects business in...

From Mobile to SOA: A Guide for Optimized Application Deployment Customer need has driven the emergence of multiple computing tiers. Today’s application d...

e-Kit: Web Application Security Is your network secure? What about your web applications. If IT security is your top p...

Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...

By Alex Handy

August 28, 2008 — Thanks to the people behind BusyBox, the GPL has a lot more teeth than was once thought. To complement litigation against GPL violators, the Software Freedom Law Center has released in late August a set of guidelines called "A Practical Guide to GPL Compliance."

According to the compliance guide, “GPL violations are often caused or compounded by a failure to adopt sound practices for the incorporation of GPL’d components into a company’s internal development environment. We suggest companies establish such practices before building a product based on GPL’d software.”

The guide goes on to state that many companies focus too heavily on the copyleft aspects of the GPL, those being the portions of the license that address freedom of use and distribution from a purely monetary and rights standpoint. Thus, many corporate users of the GPL recognize it only as a license that turns software into a free legally unencumbered building block.

Unfortunately, it is not this portion of the license that tends to get people into trouble, states the guide. “In our experience with GPL enforcement,” write the SFLC's Bradley M. Kuhn, Karen M. Sandler and Aaron Williamson, the guide's authors, “few redistributors’ compliance challenges relate directly to the copyleft provisions; this is doubly true for most embedders. Instead, the distributions of GPL’d systems that we encounter typically consist of a full operating system including components under the GPL (e.g., Linux, BusyBox) and components under the LGPL (e.g., the GNU C Library). Sometimes, these programs have been patched or slightly improved by direct modification of their sources, resulting unequivocally in a derivative work.”

And derivative works must be resubmitted into the open-source community, under the terms of the GPL. This is the fundamental “infectious” aspect of the GPL that made it so controversial in its early years.

“Alongside these programs,” the guide said, “companies often distribute fully independent, proprietary programs, developed from scratch, which are designed to run on the FOSS operating system but do not combine with, link to, modify, or otherwise derive from the GPL’d components. In the latter case, where the work is unquestionably a separate work of creative expression, no derivative work has been created.”

Yet despite the clear-cut nature of such a scenario, many companies aren't sure where the line between “must redistribute” and “wholly owned and proprietary” is.

To rectify this situation, the SFLC advises development teams to pay close attention to changes and releases of their software. In many cases, writes the SFLC, engineering teams are unable to track the contents of a binary back to its origins, and thus they lose track of where GPL software is being used in a project.

This type of problem can occur when the actual building of a project is left in the hands of a single individual, says the guide.

“Too many software projects rely on only one or a very few team members who know how to build and assemble the final released product. Such knowledge centralization not only creates engineering redundancy issues, but it also endangers GPL compliance, which requires you to provide build scripts.”

The Practical Guide to GPL Compliance is available online for free in both HTML and PDF forms at www.softwarefreedom.org/resources/2008/compliance-guide.html.

Related Search Term(s): open source, SFLC

Share this link: http://www.sdtimes.com/link/32772

EMAIL THIS ARTICLE

SEND FEEDBACK