- labels: --> LGPL
- assigned_to: Bogdan Cristea
Some time ago I used IT++ for academic calculations. In the meantime I used only MATLAB, with some IT++-based Mex-functions. I'm still looking for the best math library in future projects. The most relevant disadvantages of IT++ are the lack of thread-safety and the GPL license.
I cannot publish all my algorithms I have develop for research contracts. However, I'm absolutely willing to contribute basic building blocks and extensions on a library such as IT++. I think most of the researchers are in the same situation.
But at the moment, only people can work with IT++ that are allowed to publish EVERYTHING they develop using the basic math of IT++ (hobbyists, students and researchers with liberal contracts). It's not a bad thing, but you exclude many professional and industrial researchers that have to keep some algorithms confidential by contract. Most of them have something to share and something to keep confidential. Of course, some industrial users could also just use IT++ without contributing anything back. But is this really a loss, if it's otherwise becoming a quasi-standard for signal processing blocks? I know many people that are unhappy with MATLAB and would like to to more in C++.
I think the LGPL would suit best for a library with basic math functions like IT++. It's a bit like with the GCC. The compiler itself is GPL, it will always be free software. But you are allowed to compile confidential algorithms, too. The more IT++ is used in application programs, the more contributions it receives to extend the library itself. At the moment, you have to publish all your source, even if just a few vectors and matrices are used from IT++.
With IT++ the situation is even more critical than with other more application-specific GPL/LGPL libraries. Because math (vector and matrix classes) between IT++, uBLAS on Boost/C++, GSL etc. is not compatible. This is very elementary. I would like to choose one basic math library, that my programs and algorithms are portable. It would be a mess to mix very different vector or matrix classes. C and C++ would never be successful, if elementary data types like double and string would force all programs to be GPL.
If IT++ stays with the GPL, I would probably switch to another math library. For example:
is licensed as LGPL, also based on LAPACK, MKL or ACML, with similar basic math. It might be an option. Or even using uBLAS C++/Boost standardized vector and matrix classes. I'm really looking for somthing as a "standard", that I don't have to rework algorithms every time I'm using a different math library. Armadillo could be a good base for signal processing extensions.
I know this issue has been discussed before. It's difficult to ask every author for permission. But as there are only a few core developers, it seems realistic. Maybe leaving out some functions in a LGPL-Library, for later reimplementation. I was very surprised how OpenStreetMap survived the license change. Not every contributor agreed, but in the end the map did not end with white empty areas. They systematically marked the elements that have to be recreated. Apparently not much was missing after the license change. The data size was even bigger a few months after the change.
There is a big risk that IT++ will become less popular as a C++ based MATLAB-replacement if it stays with the GPL.
p.s. the LGPL would be necessary if you want to distribute your program and link with non-GPL-compatible software such as ACML, MKL or MATLAB (IT++ Mex-Function). GPL "infects" every single piece of linked software and forces it to be compatible. Thinking of Mex-functions, they coudn't be just called as a functions but had to be implemented as a separate service program, communicating with sockets or pipes. This is insane. LGPL means, all modifications, improvements, bugfixes, additional functionaltiy of the library itself has to be LGPL again. It only gives the freedom to integrate IT++ with other software, like Mex-Funktions, some confidential application programs or linking together with other commercial libraries. So, in my opinion the LGPL is the best license for this kind of library.
Hi
I have just received an e-mail from someone interested in using IT++ algorithms in a project that requires a non GPL license. I think this decision should be made by all developers involved into IT++ and it is important for the future of this project. Please let me know your opinion.
Below is the e-mail I received:
Dear Mr. Cristea,
I am working on a project, in which we currently use part of the IT++ library. If we keep the library code there, it would however impose a GPL license on our complete codebase. We are currently using only the Multilateration class.
Would you consider releasing the library (or at least this specific class) code under GPL with linking exception (https://en.wikipedia.org/wiki/GPL_linking_exception), which would allow us to use your code as a library linked with our code, so that we wouldn't have to release all our codes under GPL?
Kind regards,
Martin Zidek
Hi Bogdan
I am OK if license is changed if you feel it would be benefitial for the library. Thank you for your hard work maintaining this software.
Andy.
Maybe you cannot reach every developer to ask for permission. Maybe even some disagree.
A solution could be: split the library into two parts, create a core library with LGPL. The core math operations are most critical, see comments above. And then a second GPL library part could build upon the core functions, i.e. some more application-specific routines, multilateration, special modulations etc. So from the start you don't loose any functionality. Later, non-LGPL functions could be ported or re-implemented for the LGPL-part. Mixing GPL with LGPL is legal.
Anyway, I think it would be a good structure to modularize between core math functions (complex, vector, matrix math) and higher signal processing functions. For some mex-functions I used only math from IT++, didn't need the rest. IT++ has a really elegant implementation of complex vector and matrix math.
And yes, I think it's important for the future of IT++. Most researchers in the field work with MATLAB, so GPL would be forbidden to interface with (Mex Interface between C++ and Matlab). GPL Octave also has the Mex interface. You can write C++/IT++ functions that are compatible with both Matlab and Octave. But Octave lacks the just-in-time-compiler, profiler, debugger etc., so often it's not a comfortable/productive replacement for Matlab. With LGPL you could freely exchange Octave and Matlab. With GPL IT++ you have to decide: starting with IT++/Mex/Octave means you are not allowed to use it in MATLAB any more. I ran into those conflict situations quite often. My solution: try to avoid IT++/C++ and do everything in MATLAB. It's a pity that currently you don't really have the freedom to choose.
I am a current ardent user of IT++ library for my research.
This post is so timely and relevant that it could save me from a lot of pain.
Basically I have been involved in a good amount of research using IT++ and now I want to integrate those components with MATLAB.
Can someone kindly answer: Am I allowed to develop a MATLAB library using IT++ code running using mex interface for my own purposes / commercial purposes? How different would it be if IT++ becomes LGPL?
p.s.: I think it's OK to violate GPL in your house for your private enjoyment. But if you publish it, e.g. as university thesis, or deliver within a research contract, you have to respect the GPL. This is a typical szenario, using IT++ Mex functions within a MATLAB analysis enviromnent (IT++ has no graphical plotting functions and very few data analysis functions).
The GPL forbids to link with GPL-incompatible parts. Embedding IT++/Mex functions into MATLAB means dynamic linking of a function, so it's not allowed for IT++. Alternatives would be standalone IT++ applications, called via exec or unix/network sockets.
With LGPL you can do this. It guarantees the open-source of IT++ itself, but allows for linking with non-GPL stuff. In my opinion the better choice for opensource libraries.
Log in to post a comment.