Murphy's Law: Open-Source Licensing Brings Headaches, Confusion

Posted 07/09/2009 at 4:45pm | by David Murphy

9

Comments

Print

Open-source licensing can be a tricky beast. But it's not just aspiring software developers that need be concerned about the nuances of OSS licensing (or freeware licensing, for that matter). If you offer up apps on a CD or a Web site for others to grab, you're just as impacted by the parameters of licensing as anyone else. If you're just a downloader who's thinking, "why me? I just install cool programs," it behooves you to understand the differences between legitimate and illegal distribution models for the programs you fancy. While you, yourself, cannot be held accountable for another's licensing violation when you go to download software, you shouldn't encourage their efforts either. Playing by the rules is the only way to keep the spirit of open source alive.

That doesn't make it any less easy for you to understand the rules. And there are certainly number of them. There are licensing restrictions for what you can make available to others. There are restrictions on the kinds of files or code you need to package alongside applications you're distributing (be it on a CD to a friend or on your personal home page). There are restrictions on your ability to modify the software and retain elements of its original trademarks, and there are restrictions on what you can charge to deliver the software to others. There are a lot of restrictions--far more than what I could ever cover in a single column. And they aren't always as clearly defined as one would hope.

The GNU General Public License (GPL), for example, allows you to make whatever modifications to a program you want without additional reservations, provided you keep the changes to yourself. The license most concerns itself with distribution of the software. If you choose to make your modified work available to a friend, a group of fans, or the Internet as a whole, you have to package your derivative work along with the requisite license and source code. But even that's a can of worms in itself.

Is it enough to pack the complete source code along with your program's binaries? Yes. That's actually the preferred method of satisfying your licensing requirements. You can also link to a third-party site that hosts the applicable source-code for you--if you're passing along a binary as part of a software distribution package, for example--but you have to make sure that said site is both easily found via the program and that it is able to host the relevant source code for as long as you're distributing the binary.

As always, the necessity of packaging source code along with a program varies depending on the licensing scheme. OpenOffice.org's LGPL v3 allows you to just link back to main OpenOffice.org site--it's as easy as that. Other licenses like the Berkeley Source Distribution (BSD) have no source code requirement. Unlike the GPL, which prohibits the inclusion of licensed open-source code into closed-source projects, projects based on a BSD license can be passed around, modified, and locked into programs without requiring the source code to be released in any fashion. Mozilla's MPL license requires that modifications of its applicable code-as opposed to new files you've created using your own code--be documented and the source code for the work be made available to the public for no less than 12 months.

Without getting into too much detail (for fear of writng a book instead of a column), this is a great example of the gap between strong and weak copyleft provisions. In a nutshell, copyleft--an obvious play on the word "copyright"--signifies a license's ability to force derivative works to use the same license when released. The GPL would be the strong copyleft example, whereas the free-ranging, do-whatever-you-want BSD license would fall in the latter category.

Of course, even if you were to follow all the parameters of whatever license it is that you're bound by as a developer or user, you could still run afoul of a company's legal rights by passing along a modified binary of the program without approval. Mozilla's Firefox browser represents the perfect scenario here. Suppose you found an awesome extension that you wanted to pack into a version of Firefox that you later decided to release on the Web or give to your friends. Technically, you would not be allowed to call the release Mozilla Firefox without approval, nor could you use the company's logos in the software itself.

Think about it. Any variation you make to Firefox--be it one as large as changing the default bookmarks to one as small as repackaging the installation file into a new archive--would be seen as an implicit endorsement by the company were you to use its Mozilla or Firefox trademarks in reference to the project. Were you to rename your creation AwesomeBrowser and strip the accompanying logos from the program, you'd be in the clear (assuming you fulfilled the other terms of the MPL).

Confusing? You betcha. But integrity in the open-source and freeware world leads to software development and community involvement in a manner that's consistent and fair for all involved. Without standards, the very nature of open-source would fold into one giant mush of "it's free, do whatever." And that's not what anybody wants, nor would its presumed benefits trickle down to you, the user, in a positive fashion. By helping developers enforce the rules of their software, you do your part in making sure that everyone, regardless of background, has the same ability to create and improve as anybody else. That's a good thing.

As for how you can best stay afloat in these multi-license waters, well. Read the licenses. Understand the licenses. Ask questions, search for FAQs, troll message boards. As the oft-repeated phrase goes, know your rights. And more importantly, know if you're accidentally violating someone else's.

David Murphy (@ Acererak) is a technology journalist and former Maximum PC editor. He writes weekly columns about the wide world of open-source and roundups of awesome, freebie software. Shoot him a message via Twitter, especially if you have an awesome app or game you're dying to recommend!

[image credit: http://www.gnu.org/software/software.html]