License question

[Christoph Schulz]

Hi,

I'm currently evaluating C++ graph drawing libraries for a spare time project. I want to write a QML plug in around, lets say OGDF (note: Qt/QML is LGPLed). So the question is: which license do I have to put an QGDF C++ QML plug-in under, if I want to link statically against OGDF, for convenience. All outgoing interfaces will be QML/JavaScript, thus GPL shouldn't inherit here, right?
I don't have a problem with publishing an OGDF QML plug-in under GPL. What I can't do is GPL my whole application as it uses EPL+CPL libraries, as they're both GPL incompatible. Any advice on how to get this right?

Regards,
Christoph

[Carsten Gutwenger]

Hi Christoph,

since you can use LGPLed code in project under GPL, you can simply put your OGDF C++ QML plug-in under GPL. The EPLed library thing is a bit more complicated due to incompatibility of EPL and GPL. However, if you have two clearly separated modules and the plug-in is not an essential component of the whole program, it should be possible to have the plug-in under GPL and the program under EPL (I am not a lawyer, this is just my opinion; at least we wouldn't mind if you do so).

Carsten

[Christoph Schulz]

Hi,
 

However, if you have two clearly separated modules and the plug-in is not an essential component of the whole program, it should be possible to have the plug-in under GPL and the program under EPL (I am not a lawyer, this is just my opinion; at least we wouldn't mind if you do so).

My application is centered around programming and working with drawn graphs is an important activity (editing purely on text level is possible, but very annoying). The AST and other graphs are clearly separated from drawn graph(s). So what's the definition of "essential"? Very fishy (basically you're telling me to risk violating/replacing OGDF, because you wouldn't mind - sounds fair, but not as assuring as I hoped).

After reading through walls of text about issues with GPLed libraries I've got to ask this question: why not switch over to LGPL? That'll solve a lot of legal issues and still force people to collaborate - it's meant to be used after all, right?

Regards,

Christoph

[Carsten Gutwenger]

Hi Christoph,

regarding all the different licenses for free software and their incompatibilities, it's merely impossible to choose one that fits for everything.

When GPL is a problem for combining software under different licenses, we give so called link exceptions, where we allow to link a program against OGDF and other libraries under licenses incompatible with the GPL. We do this for COIN projects (EPL), ABACUS (LGPL) and Tulip (LGPL). We can also give you an explicit link exception for your software, so you will have no license issues (e.g., you can make your plug-in LGPL or EPL, and we give you a link exception for the plugin, then you can combine the plugin with the EPL libraries in your program.

Would that be an option for you?

Regards,

Carsten

[Christoph Schulz]

Hi,

Your proposal sounds fair and thus I gave it shot today (qml-ogdf). Here is my initial attempt for terms:

Licensed under the GNU Lesser General Public License Version 2 or Version 3.

Note: OGDF is usually licensed under the GNU General Public License Version 2 or Version 3. They kindly grand an exception compile OGDF into this software and distribute it under weaker terms to prevent you from having legal issues when using this plug-in.

Am I good to go with that?

Regards,
Christoph

[Carsten Gutwenger]

Yes, sounds good. I will add the link exception to our license terms.

Best regards,

Carsten

[Christoph Schulz]

Hi,

Am Samstag, 23. März 2013 13:51:13 UTC+1 schrieb Carsten Gutwenger:

Yes, sounds good. I will add the link exception to our license terms.

Thanks. Some basic information and license terms on my side are live now.

Regards,
Christoph

[Carsten Gutwenger]

I added the exception on our license web page.

2013/3/23 Christoph Schulz <schu...@gmail.com>

Regards,
Christoph

--
You received this message because you are subscribed to the Google Groups "ogdf" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ogdf+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Piyoosh Mukhija]

Hi Carsten,

I'm interested in using the QML OGDF plugin created by Christoph. However, for performance reasons, it'd be good to povide node and edge data to his wrapper classes from C++ instead of directly from QML/Javascript.

Now, the LGPL exception allows me to link to his library, but it adds a constraint that the QML plugin directory should be in my link paths. Generally QML plugins are loaded dynamically and need not be in compile-time link paths. I'm thinking to split his library into a plugin component (runtime-loadable library with only a plugin class that registers the types in QML environment) and a compile-time linkable component (a library ontaining all the types allowing me to populate data structures from my c++ application). Would your exception still be valid for this update? If not, can you add an exception for such a fork? If agreeable, I can then create such a project under LGPL.

Thanks,

Piyoosh

On Tuesday, March 26, 2013 at 9:14:45 AM UTC-4, Carsten Gutwenger wrote:

I added the exception on our license web page.

2013/3/23 Christoph Schulz <schu...@gmail.com>

Hi,

Am Samstag, 23. März 2013 13:51:13 UTC+1 schrieb Carsten Gutwenger:

Yes, sounds good. I will add the link exception to our license terms.

Thanks. Some basic information and license terms on my side are live now.

Regards,
Christoph

--
You received this message because you are subscribed to the Google Groups "ogdf" group.

To unsubscribe from this group and stop receiving emails from it, send an email to og...@googlegroups.com.