Welcome Guest | Sign In
LinuxInsider.com

Licenses, Libraries, Laws and Loopholes

Licenses, Libraries, Laws and Loopholes

What's the point of GPLv2 libraries? What's the purpose of libraries associated with licenses anyway? Do they provide useful guidance or impose annoying restrictions? Who wants to puzzle out the legalese of licenses and their appurtenances when working with code and systems that are supposed to be open?

By Katherine Noyes
08/20/09 4:00 AM PT

It's been a relatively quiet few days on the Linux blogs, but that didn't stop geeks from taking time out last Sunday to wish Debian a happy birthday.

Yes, it was exactly 16 years ago on the 16th that Ian Murdock announced the imminent arrival of what he called the "Debian Linux Release."

Happy Birthday, Debian, and many thanks to Heise Online for calling attention to the happy event!

'What's to Stop Me?'

There were several other low-key discussions on the Linux blogs in recent days, but perhaps none so widely discussed as the one that arose from a question posted on Slashdot recently.

Specifically, "GPLv2 libraries -- is there a point?" was the query put out there by blogger PiSkyHi in a post last week.

"I understand that if I build an application that links with a library that is licensed under GPLv2, I must also make my application GPL2; I can see that value in this for an application," PiSkyHi wrote. "But for a library, what's to stop me separating my program into a GPLv2-compliant client app that talks to the rest of my (choose my own license) application?"

'Umm... Nothing?'

Responses on Slashdot were all over the board.

"Umm... nothing?" answered Phroggy, for example. "If you're writing your application from scratch without using anybody else's libraries, you're free to release it under whatever license you like, even if it happens to talk to a GPL'd client plugin thingie, and even if you wrote that GPL'd client plugin thingie around somebody else's GPL'd library.

"Why do you imagine that somehow there's a problem here?" Phroggy wondered.

'RMS and the Community'

Then again: "RMS and others (the community) possibly are there to stop you," warned mysidia. "If/when they find out, they might point to your software as an example of bad practice, or put you in the 'GPL Violations hall of shame,' or some such."

Alternatively: "This is exactly why the LGPL was created," chimed in ianare. "Or sometimes you will have a GPL lib with the linking or classpath exception. You will find most libs are licensed under these or even more permissive terms.

"Therefore, if the lib in question is explicitly licensed under normal GPL, it's the author's wish that any apps that use it must be GPL compatible. I think it's only fair to follow the author's wish," ianare concluded.

Word of the FSF

Adding the voice of the FSF, dowlingw reproduced the group's official response to a similar question involving dual-licensed GPL/LPGL "glue" connectors:

"If the LGPLed library dynamically calls the GPLed library, then it is the FSF's position that the LGPLed library is a derivative of the GPLed library, and thus the work as a whole may only be distributed under the GPL," dowlingw said the FSF wrote. "Please see this section of the FAQ: http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper."

Coincidentally, it seems, a similar topic came up at DaniWeb this week when Ken Hess asked, "Do open source software licenses have a purpose?"

A 'Fine Piece of Nonsense'

Citing the GPL, LGPL, APL and other licenses, "as soon as you slap a license on something, you can no longer call it open," Hess concluded. "Putting a restriction on something that you're allowing unrestricted access and use to is just silly."

Bloggers weren't shy about responding to Hess's assertions on DaniWeb before the topic got picked up on LXer, where the reception was -- let's just say -- even cooler.

To wit: "Does anyone have a greasemonkey script to hide all stories on LXer written by lazy uninformed authors such as the one who wrote this fine piece of nonsense?" was the reaction of tbuitenh, for example.

With such widely varying opinions on the matter, Linux Girl felt bound to exercise her right to investigate further.

'This Gets Rather Strange'

"The question of when a library's license is relevant to the main program's license is a very complex question which courts have not yet had much of an opportunity to answer," Chris Travers, a Slashdot blogger who works on the LedgerSMB project, told LinuxInsider.

For those with the time and inclination to read up on the matter, Travers suggested two lawyer-authored articles ( here and here) for more.

"A major part of the problem is that copyright protects literary and artistic expression, not functionally required elements," Travers explained. "This gets rather strange as applied to computer software."

Derivative Works

For example: Microsoft can't use its copyright of the system libraries of Windows to control who can write software for that operating system, Travers pointed out.

"However, if one creates alternate map files for a video game, the resulting audiovisual display might be a derivative work of the original video game," he noted. "This would be the same thing even if the files' information was dynamically served from a distant network server to the game, so no linking would be involved."

Similarly, "it is hard to see how nVidia's closed-source drivers would constitute a 'derivative work' of the Linux kernel under U.S. copyright law -- despite RMS's speculations to the contrary," Travers asserted, and "it is hard to see how copyright law by itself would allow a software vendor to prohibit libraries which link two systems together under incompatible licenses."

Static linking also presents specific issues here, he added, "but those may depend on the specific mechanism the linker uses to create the executable and so might not be applicable to the concept as a whole.

"The question is when, under copyright law, static linking creates a 'collected' or 'compiled' work and when it creates a 'derivative' work, and functional elements don't count in that analysis," he said.

'A Waste of Time'

"GPL2 libraries are a waste of time," Montreal consultant and Slashdot blogger Gerhard Mack told LinuxInsider. "The whole point of a library is code reuse -- why would you want to limit yourself to just other GPL code?"

The problem with the GPL is that "RMS just keeps pushing the limit," Slashdot blogger hairyfeet added. "Just look at how Linus refuses to license under GPLv3; he thinks that RMS has become too business-unfriendly, and he is right."

The fact is that "businesses are scared of GPL -- and rightly so, considering how RMS added language to GPLv3 to specifically target a single company," hairyfeet asserted, citing Stallman's "anti-TiVo clause."

"This is why you see articles on 'how to avoid GPL infection,' because many in the RMS camp believe GPL should be based on process separation, which means if ANY GPL code is in your product you have to release the whole thing as GPL," hairyfeet told LinuxInsider. "That just ain't gonna fly."

Until the exact boundaries of the GPLv2 and v3 are worked out, "more and more businesses will go the MSFT and Apple route and use BSD, or just buy proprietary," he predicted.

'Use It or Not'

The bottom line is that "folks who do not like the GPL can use it or not," blogger Robert Pogson told LinuxInsider. "They are better off using it so they do not have to re-invent the wheel every time they code."

Creating a library and releasing it under GPLv2 or any other license "is at the creator's prerogative, unless he or she is merely modifying or deriving the code from already-GPL stuff, in which case there is a requirement to release under the same license," Pogson added.

Ultimately, "I believe most coders like the GPL because it allows them to get on with what they do best and let experts deal with the legalese," Pogson concluded. "Linus stated that choosing GPL was one of his best decisions because it ensured wide participation in the project. Amen."


Facebook Twitter LinkedIn Google+ RSS