RevFE Licensing. What is it, and what does it mean?

**malcom2073** · 05-25-2009, 07:19 PM

These are not native c++ compiled dll's, they are .net dll's, and the issue is a GPL program loading closed source libraries not the other way around.

Regardless, I believe that LGPLing the interface class required to link .net plugins should solve the issue.

**NSFW** · 05-25-2009, 11:19 PM

Originally Posted by malcom2073

For what it's worth NSFW: you should read the license. You can't link non-gpl compatible (iGuidance API would definitely not be gpl compatible) in a GPL program.

But, I give up.

http://www.mp3car.com/vbulletin/carp...nder-lgpl.html

Happy?

I've read it a number of times, and have released software under it. The GPL prevents derivative works from being released as closed source. iGuidance is not a derivative work, it is iNav's original work. It would not violate the terms of the license for a third party to create a derivative from your work which calls into iNav's original work.

I'm happy either way, actually. I just wanted to clear up what I believe to be a misconception.

**malcom2073** · 05-25-2009, 11:29 PM

I'll stick to what the official GPL FAQ says regardless.

**NSFW** · 05-25-2009, 11:45 PM

Originally Posted by rodweb

When I created a closed source application which was dependent on a GPL library, that is the path I took. Nothing was modifed or linked to and I could distribute the GPL application provided I included the license with it and made the source code of the GPL component available on request or via the web. The closed software still ran if the GPL DLL component was missing, just it did not do anything useful.

Based on that description, it sounds like your software is a derivative work of the GPL'd work you mentioned, and thus you are not complying with the terms with which that software was licensed to you.

LoadLibrary vs static linking makes no difference.

If people think they can avoid the GPL by using function pointers, they
are WRONG. And they have always been wrong.

- Linus Torvalds

See also: http://www.gnu.org/licenses/gpl-faq....FUseGPLPlugins

**NSFW** · 05-25-2009, 11:48 PM

Originally Posted by malcom2073

I'll stick to what the official GPL FAQ says regardless.

Since you're clearly a fan of open source software (I am too, FWIW!), I'm guessing you've heard of Lawrence Rosen by now... if not, his bio is at the of this article (click me), which includes the following quote:

3) Derivative works are not going to encompass plugins and device drivers that are designed to be linked from off-the-shelf, unmodified, programs. If a GPL-covered program is designed to accept separately designed plugin programs, you don't create a derivative work by merely running such a plugin under it, even if you have to look at the source code to learn how.

I added the bold-face since it seems like it could be a determining factor here.

**malcom2073** · 05-26-2009, 12:01 AM

There is a very interesting point made in the comments to that article:

Suppose someone writes a library that implements a standard API - for which commercial versions already exist - and he GPL's it. Both libraries are dynamically linkable.

Now, I write an application that uses that standard API. Are you telling me

that if I link my binary against the GPL'ed library - then my application must be GPL'ed - but if I link it against the commercial version, it doesn't?

Bear in mind that the resulting binary will be bit-for-bit identical in those two cases.

Suppose - you are right - and I link against the commercial one - and distribute my application (without the library code). Now someone runs my application (without my knowledge) against the GPL'ed code. Is my application *now* caught in the GPL trap? What if I didn't even know the GPL'ed version of the library existed? What if it didn't even exist when I wrote my application?

If dynamic linking fell legally under the GPL, we could force Microsoft to release the entire source code to WORD - by simply writing a GPL'ed plug-compatible DLL that matched one of the DLL's that WORD links to!

I think that this pretty much states what you're saying. Plugins created for my program cannot be enforced to be GPL purely because my program is capable of loading them. The releasing of InterfaceClasses under LGPL I believe clears up the last legal issue reguarding plugins, and that is the fact that they must link that in order to gain access to the interface. You can't copyright a method of operation, so if someone were to write a version of InterfaceClasses themselves that did the same thing but was not the same code GPL would not apply anyway.

Bottom line: InterfaceClasses is LGPL. Plugin developers can write software, and reference InterfaceClasses to talk to CarPal WITHOUT releasing their source code at all.

**NSFW** · 05-26-2009, 01:23 AM

Originally Posted by malcom2073

Bottom line: InterfaceClasses is LGPL. Plugin developers can write software, and reference InterfaceClasses to talk to CarPal WITHOUT releasing their source code at all.

And that clears everything up nicely.

However I'm compelled to point out that the author of that comment misunderstands something pretty fundamental about the GPL: it's a license, not a contract. There is no "GPL trap" as the commenter puts it. The GPL cannot force someone to give away their source. Not even if they distribute something that contains GPLed code. The only thing it can force someone to do is stop distributing derivative works.

**malcom2073** · 05-27-2009, 06:52 AM

I have to disagree with that. You cannot use gpl code without following gpl. That is kinda the point of gpl. If someone were to use snippets of CarPal in a non gpl program it would be a copyright violation and a violation of gpl.

**NSFW** · 05-28-2009, 12:13 AM

Originally Posted by malcom2073

You cannot use gpl code without following gpl. That is kinda the point of gpl.

It is more accurate to say that you cannot distribute GPL code without following the terms of the GPL. You actually can use it all you want, it's when you distribute the code (derivative works, especially) that you need to follow the terms.

If someone were to use snippets of CarPal in a non gpl program it would be a copyright violation and a violation of gpl.

If you distribute snippets of CarPal, it would be a violation. Imagine if you hadn't LGPLed your plugin library, and someone created a clean-room clone of it. (That might be impractical due to the way your code is structured - I haven't looked - but I hope you see what I'm getting at.) They could use their clone to create and distribute closed-source plugins. Since they are only distributing their own code, the GPL does not come into play.

The commenter was talking about the reverse, though. Suppose you write a GPL'ed plugin for Ride Runner. This does not obligate the owner of Ride Runner to GPL their code. That's the (bogus) "GPL trap" the commenter was imagining.

**Tidder** · 05-28-2009, 03:16 AM

Now it seems you're just arguing semantics. Sure you can use the code in private, but how would anyone ever know? It's when they put their works out in public that these are discovered. I'm positive malcom2073 knew this when he made that statement.