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

Hmm, RDS is licensed under LGPL so I could fairly easily make a plugin for it... and I need a usb radio eventually anyway. I'll definitely look into that thanks.

I'm glad to see the people are a fan of open source, was a bit worried for a little there heh.

I'm also glad to see this is going to be GPL'd. Hopefully as soon as things at work calm down I'll be able to break out my coding hat and write some stuff for you. Also, I agree with the fear of showing codes although since I had to get used to it once I started college it's not that bad and after graduation it's still not a big deal. More often than not the comments are a big help and someone may have a better idea on how to do something. Whether it be more efficient or just a breath of fresh air with new functionality. I'm going to be sad to see those plugins not go with this new frontend, but when software stays closed that only means someone will be more apt to try to make their own open sourced version. If the closed ones stay closed then hopefully they will make suitable starting blocks for other enterprising coders and I may be able to tackle them as well.

Can't wait to see how this goes. CarPal and project: CarMa are my two anticipated projects at the moment.

I agree about the whole closed plugin thing. I can only hope that some people are willing to put forth the effort to release open plugins. If all else fails I have a whole list of plugins I'm planning on writing, but I can only work so fast

Unfortunately you will find that CarPal is poorly commented at best. Perhaps one of these days I'll get around to commenting it better. Tidder is working on plugin, messaging and event system documentation so at least it'll be well documented (by someone OTHER than the main developer)

Originally Posted by malcom2073

I could change the license of CarPal, allowing me to close source it [...]

As the author of the code, you can do whatever you want with it, including selling it, even while you offer the code to the general public under the terms of Gnu's GPL. As long as the project doesn't include code contributed by other people, you always have the option of licensing it to other people (paying customers even) on whatever terms you like. The GPL is just the license that you've chosen to grant to the general public (the GP in GPL).

After you start mixing in code from other people, that gets harder. But, the beauty of the GPL is that people can collaborate on a project knowing that none of them is in a position to take advantage of the others' labor.

Also, the GPL does not necessarily prevent closed-source plugins. The GPL only prevents closed-source derivative works. If someone has already created a plugin for another FE, then the plugin is their original work, not a derivative of your work. There might be a grey area regarding plugins that include header files (from your project) that are GPLed - I'm no lawyer though.

If you want to make that sort of thing simpler, consider offering the plugin header files (or base classes, or whatever) under a less restrictive license like BSD's. Plugin developers can then mix their code with that code with no worries. End users can then mix your GPLed application with their closed-source plugin, and everybody's happy.

Originally Posted by NSFW

As the author of the code, you can do whatever you want with it, including selling it, even while you offer the code to the general public under the terms of Gnu's GPL. As long as the project doesn't include code contributed by other people, you always have the option of licensing it to other people (paying customers even) on whatever terms you like. The GPL is just the license that you've chosen to grant to the general public (the GP in GPL).

After you start mixing in code from other people, that gets harder. But, the beauty of the GPL is that people can collaborate on a project knowing that none of them is in a position to take advantage of the others' labor.

Also, the GPL does not necessarily prevent closed-source plugins. The GPL only prevents closed-source derivative works. If someone has already created a plugin for another FE, then the plugin is their original work, not a derivative of your work. There might be a grey area regarding plugins that include header files (from your project) that are GPLed - I'm no lawyer though.

If you want to make that sort of thing simpler, consider offering the plugin header files (or base classes, or whatever) under a less restrictive license like BSD's. Plugin developers can then mix their code with that code with no worries. End users can then mix your GPLed application with their closed-source plugin, and everybody's happy.

One of the reasons for going GPL was to make the plugins have to be GPL thereby making it harder for CarPal to go closed source. This would help to ensure it was always open and free.

http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins

So unless I change the license of CarPal as a whole, plugins need to be GPL or GPL compatible.

I'm pretty sure Gnu has it wrong with that FAQ. Consider this scenario:

Suppose iGuidance releases an API that allows their code to be run in-process by front end software. Suppose I then use your code to create a wrapper for iGuidance that turns it into a plugin. Since the iGuidance binary is not a derivative of your work, the GPL does not apply there. Since my wrapper depends on your header files, it is a derivative or your work, and it must be released under the terms of the GPL. The result is a partially-closed source plugin that does not violate the terms of the GPL in any way.

That said, if you don't want such "mixed-source" plugins being developed for your front end, other developers will probably be happy to respect your wishes. I certainly will.

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?

Originally Posted by NSFW

I'm pretty sure Gnu has it wrong with that FAQ. Consider this scenario:

Suppose iGuidance releases an API that allows their code to be run in-process by front end software. Suppose I then use your code to create a wrapper for iGuidance that turns it into a plugin. Since the iGuidance binary is not a derivative of your work, the GPL does not apply there. Since my wrapper depends on your header files, it is a derivative or your work, and it must be released under the terms of the GPL. The result is a partially-closed source plugin that does not violate the terms of the GPL in any way.

That said, if you don't want such "mixed-source" plugins being developed for your front end, other developers will probably be happy to respect your wishes. I certainly will.

EDIT: sorry, misread.

Interesting all this discussion about linking in other libraries. It would appear that the LGPL is required if users link to the CarPal binary libraries. However, Windows give you the opportunity to access DLL's without linking in the code via LoadLibrary().

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.

Personally, I prefer the loadlibrary approach rather than linking as nothing is broken if a DLL cannot be found and the error can be dealt with gracefully.

An interesting recent observation of mine was to see the GPL included in the documentation with a Dlink Router. I had a look, and sure enough, the source code of the GPL element was available for download from their web site so they could comply with the terms of the license.