GPL and open source license amibiguities

January 5, 2008

I think I’ve written on this before, but this recent story on Slashdot just brings it all up again, so I’ll write again.  I currently deal with these sorts of questions for a living, and I have to say it doesn’t generally get any easier as time goes on.

McAffee indicates that some of its products rely on GPL software, and because this of ambiguities in the license, and the fact that it’s not been tested in court, may cause product problems down the line.  It’s a perfectly reasonable statement to make, yet many responding on Slashdot kept repeating that “there’s nothing ambiguous” about the GPL.  Not sure how wrong these people can be, but they are.

GPL v2 states:

“You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program…”

The first question is ‘how strict should this be interpreted?’.  It sounds unambiguous above - *any* modification would form a ‘work based on the Program’, right?  If I load a file, my editor changes tabs to spaces, or changes carriage returns automatically, then I save it, would that count?  I’ve modified the program, right?

Then later:

“If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. … In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.“

So, if I create a ’separate’ program and distribute it, but my installation routine compiles them in to one executable, am I safe?  As the license also states:

“it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.”

So, they’re concerned about distribution.  If my installer combines the ’separate’ work with GPL code after distribution, I should be OK, right?  I doubt anyone would agree with that, because it seems like too much of a violation of the spirit of the GPL.  But of course, there’s no ambiguities, right?

Another issue with GPL (well, open source license in particular) that I’ve faced recently is the question of origin of code.  Just because there’s code in a file that states that it’s under GPL doesn’t make it so.  This is probably the biggest ambiguity that developers and companies face.  I’ve found a number of things with GPL license and copyright notices in them which simply *aren’t* copyrightable by the person in question.  Likely people just run a script and add their boilerplate code to the top of every file in their project, but just slapping a copyright and GPL notice on something doesn’t make it correct.  Unless of course the original author granted permission to the second author to license it under those terms - in other words, if the original author dual-licensed the code.

But how do you determine that?  That is a cumbersome research process that can sometimes take days or weeks.  Sometimes it can’t be done for whatever reason, but companies still, in my view, need to make the effort and document that effort.

Another big area of ambiguity is applying a license to something that doesn’t make much sense.  GPLv2 and LGPLv2 were based on ideas from the late 80s and early 90s view of software development.  LGPL, in particular, has many references to ‘linking’.  What does ‘linking’ mean with respect to PHP scripts, for example?  Static vs dynamic linking - does that mean copy/paste of code vs include()ing the file?  Possibly, but there’s been no guidance from the FSF or GNU people as to how these concepts should apply to a whole range of current software arenas, yet people continue to blindly slap the de facto copyleft license on their code without understanding the full implications.

I do see the situation as getting better in the next few years, with more experienced developers becoming more cognizant of the issues, if only because of lawsuits and stories like the McAffee one above coming to ‘mainstream’ news sources (if Slashdot is mainstream!).

However, there’s years and years of old code out there that people will continue to use, which is clouded with ambiguities and confusion about how it can or can’t be used, and in many cases, uncertainty of its origins.  This will continue to cause problems, but as more people consider licensing issues at the start of development projects, rather than after the fact, these issues will hopefully just become a footnote in the history of software development.

Posted in Development, Law, Software, opensource