[legal] libYARP_math is released as LGPL but it should be GPL

[drdanz]

GSL is licensed as GPL. This means that the YARP_math library should be released as GPL.

All the other components that optionally use the YARP_math library (priority_carrier, logger, manager) and all the iCub modules that use the YARP_math library should probably be GPL.

Finally, since linking the init library is linking to the math library, it should be GSL, and therefore almost everything in YARP and iCub should be GPL

[paulfitz]

The default build of yarp has been LGPL, with optional libraries and plugins that can cause it to be GPL. From the README:

Certain optional parts of YARP have dependencies that have more
requirements than the LGPL:
 + libYARP_math uses the GNU Scientific Library, under the GPL.

From the COPYING file:

All files used in the default YARP build are compatible with the
LGPL.  Optional modules may require use of YARP under the GPL,
rather than the LGPL.

We could communicate this better, but the status of GSL has been known and is the reason YARP_math is not built by default, and everything else is set up to compile without it.

[drdanz]

It's not very clear, and also all the files in the YARP_math library are LGPL, even though they use GSL directly and therefore there is no way they can be LGPL...

[paulfitz]

We hold copyright on all files in YARP_math. Assuming no copyrighted text from the GSL is used in the YARP_math text, I don't see that there's any constraint at all on what license we offer that text under. People can certainly copy that text and pass it on without ever falling under the terms of the GSL's license, whose force rests on copyright of the GSL's source code.

Of course, to actually use the library, you need the GSL, and whoever passes you a copy of the GSL or passes you a binary with GSL stuff in it had better be following the terms of GSL's license, since GSL copyrighted source code was involved somewhere along the line.

In general your overall license to use yarp could become arbitrarily restrictive as options/plugins get enabled. I feel like this is reasonably well understood and that it is fairly common to have optional dependencies that have licensing implications.

I could be totally wrong about all of this however.

It would be in any case totally reasonable to switch the license text on YARP_math files to be GPL since there's no way to use those files without the GSL. However, if we also need to make everything else GPL, that would be an argument for pushing libYARP_math out of YARP. Last time we looked at this, we definitely wanted someone to be able to compile enough stuff to interoperate with yarp-using programs without needing to GPL their own code.

@lornat75 @giorgiometta any thoughts?

[paulfitz]

@drdanz in your opinion what needs to happen in order to resolve this?

[drdanz]

Hire a lawyer :) To be honest, I have no idea... And by the way, also the readline library is GPL...

[lornat75]

@paulfitz: sorry for replying late but I must have missed this. It is an optional component and I would agree with you.

I am not an expert though and I need to check more carefully or ask advice.

If we have to change license I would modify libYARP_math instead to use eigen. for other reasons it already proved to be a better choice.

[drdanz]

@lornat75 Maybe it is a stupid question, but if we need to change it to use eigen instead of gsl, why do we need it at all? Wouldn't it be easier to convert everything to eigen and remove libYARP_math?

[pattacini]

Have I read correctly? Removing libYARP_math? Stop joking :)

[drdanz]

I think that to simplify everything we should just have a CMake switch to choose YARP license between GPL and LGPL, instead of switches like CREATE_LIB_MATH that do not expose this issue.

• If GPL is selected, CMake will search for GSL and Readline and will create libYARP_math and the tools will be built with readline support if the libraries are available. Binary releases are released as GPL. Using/redistributing files taken from such a release require a GPL compatible license.
• If LGPL is selected, then libYARP_math will not be generated and all tools will be created without readline support. Binary releases (if any) are LGPL and therefore can be linked/redistributed, etc. with proprietary stuff.

It would be nice to have a dual-licensed release (i.e. if you use YARP_math you are forced to be compatible with GPL otherwise if you use other YARP libraries you can use any license compatible with LGPL), but unfortunately I don't think is possible... for example libYARP_OS optionally uses Readline, therefore if you distribute this version, the library is GPL. Moreover there are the libYARP_init issues. Therefore I believe that the only solution is to distribute 2 different installers.

About file licensing (from what I understand from the GPL license and the GPL FAQs):

• Files that cannot be built without GPL must be GPL.
• Files that don't use any GPL library can be LGPL.
• I don't know about files that can optionally use some GPL library, but I think that

#ifdef WITH_READLINE
  // This part must be released under the ``GPL``
#else
  // This part could technically be released under the ``LGPL``
#endif

Therefore I believe that these files could be dual-licensed, adding some extra comment to the header.

[lornat75]

We can clearly print in cmake a warning about the type of license and change the license on the binary distributions. Distributing two different versions of the binaries is too complicated.

Do we have alternatives for readline?

For GSL I think we should consider changing the implementation using eigen.

[paulfitz]

On the readline issue, we could easily move its use out of YARP_OS and into the yarp program where it belongs. The current organization makes no sense.

[paulfitz]

big +1 for a GPL/LGPL flag in cmake

[drdanz]

Would it be legal, in order to release just one binary that can be both GPL and LGPL, if we opened readline using dlopen and eventually use it?

[drdanz]

@lornat75 Yet another serious licensing issue. I found out that yarpview-qt uses QCustomPlot, that is GPL, this means that the yarpscope-qt plugin should be GPL, but instead it is LGPLv2.1

I don't know if the executable that loads the plugin is supposed to be GPL as well or not, but I think it is.

An option for the future could be to switch to Qt Charts or Qt Data Visualization that according to this announcement by Lars Knoll are going to be released as LGPL starting with Qt 5.7, but it will be a long time before all our supported releases will include it...

[lornat75]

what about yarpscope-qt?

[lornat75]

In any case, these are executables they can have GPL license. What matters more is the libraries. I think we have to change the license on the binaries and add a flag in cmake as suggested above by Paul.

[drdanz]

what about yarpscope-qt?

I'm not sure... it opens a plugin that is (supposed to be) GPL through a QML file (that I have no idea about the license that is supposed to have) that is handled by a library that is LGPL (Qt5).

I have no idea but my opinion is that it something like this:

       ?              LGPL          ?                   (GPL)                  GPL
       |               |            |                     |                     |
yarpscope-qt   ----   Qt5   ---- QML File   ----  QtYARPScopePlugin  ----  QCustomPlot
           \-main only----------/

I think this is a borderline case, see GPL faqs.

[drdanz]

896 and #892 were merged, I think the big issues are now solved, but we still need to check and fix all the headers of all the files, and we need to remove the CREATE_LIB_MATH_USING_GSL flag and get rid of GSL completely from YARP_math

[traversaro]

IANAL, but I think this issue is already solved if CREATE_LIB_MATH_USING_GSL is set to OFF.

[drdanz]

GSL is no longer used or linked anywhere in YARP, except for the YARP_gsl compatibility library. I think we can close this now.