Change license about sofatoolbox HOT 7 CLOSED

Thanks Hagen for starting this topic. I would opt for an unrestricted license that also allows companies to use the libraries without any limitation. In this case, we normally use the MIT License (MIT): https://opensource.org/licenses/MIT (or to the Apache 2.0 or BSD 3-clause as you have proposed).

from sofatoolbox.

MIT License is also absolutely fine with me and often used for such purposes.

from sofatoolbox.

Hi guys,

First, I'm not a lawyer.

Second, I don't worry:

1. EUPL is explicitly downstream compatible
   https://joinup.ec.europa.eu/software/page/eupl/eupl-compatible-open-source-licences#section-4
   to GPL v2. (GPL v3 is not explicitly in the list because it did not
   exist at that time, it most probably is, but this is not confirmed by
   case law yet).
2. EUPL is longer than MIT or BSD because it has more to say. For
   example, it says that in case of troubles, the court will the Austrian
   one. And I don't want to be sued in USA, I hope you understand. Somehow
   it is more obvious for me to use a license proven to be European than by
   an other country.
3. If in doubts: a) publish your own specific contribution under CeCILL,
   or find convenient code covered by CeCILL; b) combine with the EUPL
   component and publish the larger work under CeCILL; c) add the needed
   GPLv3 components and publish the larger work under the GPLv3. So, how
   can EUPL be the reason for not using/developing/linking our API?

Third, the statement given by GNU in the link you've sent
https://www.gnu.org/philosophy/license-list.html#EUPLdoes not seem to
be right, see here
https://joinup.ec.europa.eu/community/eupl/news/new-fsf-statements-eupl-are-step-right-direction.

Fourth, I'm not a lawyer. But I'll come back to this issue in two weeks
(most probably asking our legal department).

So long,
Piotr

mnoi wrote:

Thanks Hagen for starting this topic. I would opt for an unrestricted
license that also allows companies to use the libraries without any
limitation. In this case, we normally use the MIT License (MIT):
https://opensource.org/licenses/MIT (or to the Apache 2.0 or BSD
3-clause as you have proposed).

—
Reply to this email directly or view it on GitHub
#11 (comment).

Piotr Majdak
Psychoakustik und Experimentelle Audiologie
Institut für Schallforschung http://www.kfs.oeaw.ac.at
Österreichische Akademie der Wissenschaften http://www.oeaw.ac.at/
Wohllebengasse 12-14, 1040 Wien
Tel.: +43 1 51581-2511
Fax: +43 1 51581-2530

from sofatoolbox.

I think the problems that could hinder users to use our API with EUPL are the followings:

1. Non-industry users: no one has ever heard of EUPL before. As an open source developer you normally trust what https://www.gnu.org is stating regarding compatibility to GPL and it says it is not compatible. So, for example, we had a longer discussion what to do in our project.

2. Industry users: EUPL (like the GPL) is a copyleft license that enforces you to publish your code under the same license, what you normally don't want in the industry.

In summary: I see a lot of points that speak against EUPL, so why not change it, I see no disadvantage for us by switching to MIT or BSD license?

from sofatoolbox.

Hagen Wierstorf wrote:

I think the problems that could provide to use our API with EUPL are
the followings:

1. Non-industry users: no one has ever heard of EUPL before. As an
   open source developer you normally trust what https://www.gnu.org is
   stating regarding compatibility to GPL and it says it is not
   compatible. So, for example, we had a longer discussion what to do in
   our project.

From Wikipedia: " Its [EUPL] main goal is its focusing on being
consistent with the copyright law in the 28 Member States of the
European Union, while retaining compatibility with popular open-source
software licences such as the GNU General Public License
https://en.wikipedia.org/wiki/GNU_General_Public_License. "

2. Industry users: EUPL (like the GPL) is a copyleft license that
   enforces your to publish your code under the same license, what you
   normally don't want in the industry.

Also here, situation seems to be clear:
https://joinup.ec.europa.eu/community/eupl/news/why-eupl-not-viral-licence
Shortly: you are not enforced to publish your code under EUPL, even if
you include EUPLed code in your larger software project.

But EUPL is copyleft, and it's OK as it is. So, industry users can
dynamically link to our code for free. If they statically link or fork
our code, I appreciate receiving their changes in return for our work.

If an industrial user wants to fork our software without giving their
changes back, they should contact me. We'll think about a proprietary
commercial license.

In summary: I see a lot of points that speak against EUPL, so why not
change it, I see no disadvantage for us by switching to MIT or BSD
license?

EUPL protects us and our work and is consistent with European law.

Regards from Europe ;-),
Piotr

from sofatoolbox.

here's another suggestion: upgrade (at least) to EUPL v1.2, which is consistent with European law (@petibub) and and includes a(n additional) number of popular Open Source licenses in the, among them:

• GPL-3
• LGPL-3, and LGPL-2.1
• AGPL-3

from sofatoolbox.

Upgraded to EUPL v1.2.

from sofatoolbox.