How to risk your project and your livelihood with sloppy licensing

Recently the makers of the free-as-in-cost iPhone jailbreaking utility PwnageTooldiscovered that someone was reselling their creation — without permission, under a new name, and for profit. That’s a situation no software developer wants to be in, but the PwnageTool team was in an even tougher position because of the license under which it released its code. It didn’t have one.

What the reseller did is flat-out illegal, of course; PwnageTool is protected by its creators’ copyright, period. No one who downloads it has any right to modify or redistribute it without permission.

But a free software project could have called on a group like the Software Freedom Law Center (SFLC) for legal help. The SFLC provides pro bono legal representation and consulting to free and open source software projects, such as the recent high-profile copyright infringement lawsuits brought on behalf of the Busybox project.

In contrast, by never applying a license to its work, the only recourse left to PwnageTool team was to take matters into its own hands.

If the developers had put their licensing ducks in a row, they would have been in a far stronger position to combat the abuse. They would have had the SFLC available to help, and they would have had the entire FOSS community and its legal history on their side, instead of being alone.

Talk is expensive

Just to be clear, I am not bringing up the PwnageTool story to comment on the evils on non-free software licenses. The problem in this case is that the PwnageTool team never attached any license to its code, despite talking about it.

The April 2008 release notes for PwnageTool 1.1 say that portions of the code “will be released under the GPL,” and to look for source code on a Google Code project page “within 48 hours of this release.” It is now July, and there is still no license on any code in either location.

We can all think of examples of proprietary software companies that promised to open the source code to a particular product “soon” — only to have “soon” never arrive. If they are smart, the public relations teams that craft such empty promises avoid precise language, restricting their comments to “expressing interest” in and “willingness” toward opening the source code, or “exploring” and “pursuing” the possibilities.

The FOSS community can generally smell a con like that a mile away, so there is little real harm done.

On the other hand, a FOSS developer or project that gets careless or forgetful with licensing can harm itself or other projects — as in the 2007 debacle over Broadcom Wi-Fi driver code copied from Linux to OpenBSD.

What the PwnageTool incident reminds us is that putting off licensing decisions altogether can hurt, too. Sure, the smaller the project, the smaller the chances that leaving off the license will come back to haunt you — but the bigger the headache for each individual member of the team.

It isn’t clear yet how the PwnageTool problem will be resolved. Someone claiming to be the party behind the resale chimed in with blog comments defending and explaining the activity. But slapping a GPL “COPYING” file onto the download server today won’t help matters. Developers who have been putting off applying a license to your source code: take heed.