How Not To Violate The GPL: An Easy Guide - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Government // Enterprise Architecture
Commentary
8/25/2008
12:27 PM
Serdar Yegulalp
Serdar Yegulalp
Commentary
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

How Not To Violate The GPL: An Easy Guide

It's never nice to know that you've been violating the GPL in some form. Far better, instead, to know how to not violate the GPL in the first place -- which is the premise behind the Software Freedom Law Center's new guide to same, "A Practical Guide to GPL Compliance".

It's never nice to know that you've been violating the GPL in some form. Far better, instead, to know how to not violate the GPL in the first place -- which is the premise behind the Software Freedom Law Center's new guide to same, "A Practical Guide to GPL Compliance".

The guide (available as HTML, PDF or PostScript) tackles the subject of GPL compliance from several fronts -- best practices to employ within your organization when using GPLed software; how to create a GPL-compliant distribution; and what to do if someone does come a-knockin' with word that you've tripped up. (One, don't panic; two, communication will go a long way.)

One piece of advice I haven't seen communicated very often, and something I agree with completely: avoid a "build guru":

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. Avoid relying on a "build guru", a single developer who is the only one who knows how to produce your final product.

As I see it, this is as bad as trusting any set of internal IT operations to one person who doesn't document his work and leaves you with a terrible mess to clean up if/when he leaves.

These types of guides are documentation -- but instead of documenting how to use a particular program, they're documenting the operations of the culture of open source. That culture's got a reputation for being insular and difficult, and the more guides we have like this (a la Lonely Planet: Open Source, maybe?) the easier that territory will be for the rest of us to enter.

The hard part about this documentation is that someone has to actually sit down and write it. Documentation has always been one of those jobs that everyone needs to have done, but few actually stick their necks out to do it. And even if you do, there's no guarantee you'll end up with anything coherent or useful. It's an area where a lot of work remains to be done -- not just in terms of writing such material, but fostering environments and attracting talent for writing it. A piece of documentation is good, but to have a system where good documentation can be produced reliably and consistently is even better.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Slideshows
Data Science: How the Pandemic Has Affected 10 Popular Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  9/9/2020
Commentary
The Growing Security Priority for DevOps and Cloud Migration
Joao-Pierre S. Ruth, Senior Writer,  9/3/2020
Commentary
Dark Side of AI: How to Make Artificial Intelligence Trustworthy
Guest Commentary, Guest Commentary,  9/15/2020
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
IT Automation Transforms Network Management
In this special report we will examine the layers of automation and orchestration in IT operations, and how they can provide high availability and greater scale for modern applications and business demands.
Slideshows
Flash Poll