New package licensing question
Hello, I would like to submit a new package to Factory later but unfortunately the licensing is not fitting cleanly with the packaging rules. The package in question is this: https://build.opensuse.org/package/show/home:LKucharczyk/mac The license is described here: https://www.monkeysaudio.com/license.html It says "Monkey's Audio source can be included in GPL and open-source software, although Monkey's Audio itself will not be subjected to external licensing requirements or other viral source restrictions." Does that mean the package cannot be included in openSUSE? If it can, what should I use as a value for "License" in the spec file? I've tried "custom" but that just spits out a warning with all the possible values ("custom" not being one of them). -- Lukas Kucharczyk — Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 — Karlín, Czech Republic Email: lukas.kucharczyk@suse.com - Office telephone: +420 284 084 000
Hello Lukáš, Am Donnerstag, 6. Oktober 2022, 10:47:14 CEST schrieb Lukáš Kucharczyk:
I would like to submit a new package to Factory later but unfortunately the licensing is not fitting cleanly with the packaging rules. The package in question is this: https://build.opensuse.org/package/show/home:LKucharczyk/mac The license is described here: https://www.monkeysaudio.com/license.html
It says "Monkey's Audio source can be included in GPL and open-source software, although Monkey's Audio itself will not be subjected to external licensing requirements or other viral source restrictions."
considering that I'm not a lawyer - if it can be included in GPL-based software it has to fit GPL license. Although the next sentence say 'we are not doing any licenssing'
Does that mean the package cannot be included in openSUSE? If it can, what should I use as a value for "License" in the spec file? I've tried "custom" but that just spits out a warning with all the possible values ("custom" not being one of them).
openSUSE follows https://spdx.org/licenses/ At the bottom of https://www.monkeysaudio.com/license.html is an email for questions regarding the licensing - maybe you get in touch with them and ask to clarify with regard to spdx? Plan B would be to ask a SUSE lawyer for advise.... HTH Axel
On Donnerstag, 6. Oktober 2022 11:08:28 CEST Axel Braun wrote:
Hello Lukáš,
Am Donnerstag, 6. Oktober 2022, 10:47:14 CEST schrieb Lukáš Kucharczyk:
I would like to submit a new package to Factory later but unfortunately the licensing is not fitting cleanly with the packaging rules. The package in question is this: https://build.opensuse.org/package/show/home:LKucharczyk/mac The license is described here: https://www.monkeysaudio.com/license.html
It says "Monkey's Audio source can be included in GPL and open-source software, although Monkey's Audio itself will not be subjected to external licensing requirements or other viral source restrictions."
considering that I'm not a lawyer - if it can be included in GPL-based software it has to fit GPL license. Although the next sentence say 'we are not doing any licenssing'
Unfortunately, the license is not very clear. Lets start with the other requirements, (1.), (3.) and (4.): (1): "The Monkey's Audio SDK and source code can be freely used to add APE format playback, encoding, or tagging support to any product, free or commercial." No usage restrictions - "any product, free or commercial". As long as the last part is read as a non-exclusive list, and the first part is the actual requirement (e.g. also includes academic use), this is compatible with the GPL. (3): "Any source code, ideas, or libraries used must be plainly acknowledged in the software using the code." - complies with the allowed "Additional Terms", preservation of legal notices, in the GPL. (4): "Although the software has been tested thoroughly, the author is in no way responsible for damages due to bugs or misuse." - complies with "Disclaimer of Warranty" and "Limitation of Liability" paragraphs of the GPL. So this leaves requirement (2.) cited in the original message. I can see only one interpretation which is non-self-contradicting: Monkey's Audio is permissively licensed. When it is linked with GPLed components, it becomes part of a larger works, and thus also MACs source must be distributed alongside all other sources. Monkey's Audio sources become subject of the GPL requirements *in this context*. This does not affect the license terms of Monkey's Audio source distributed otherwise. Why they haven't chosen the MIT or one of the BSD licenses totally eludes me. If you only need a Monkey's Audio decoder, you may be better of with the implementation in FFmpeg. If you want lossless audio compression, you are definitely better of with FLAC. Kind regards, Stefan
On 06. 10. 22 15:03, Stefan Brüns wrote:
On Donnerstag, 6. Oktober 2022 11:08:28 CEST Axel Braun wrote:
Hello Lukáš,
Am Donnerstag, 6. Oktober 2022, 10:47:14 CEST schrieb Lukáš Kucharczyk:
I would like to submit a new package to Factory later but unfortunately the licensing is not fitting cleanly with the packaging rules. The package in question is this: https://build.opensuse.org/package/show/home:LKucharczyk/mac The license is described here: https://www.monkeysaudio.com/license.html
It says "Monkey's Audio source can be included in GPL and open-source software, although Monkey's Audio itself will not be subjected to external licensing requirements or other viral source restrictions."
considering that I'm not a lawyer - if it can be included in GPL-based software it has to fit GPL license. Although the next sentence say 'we are not doing any licenssing'
Unfortunately, the license is not very clear.
Lets start with the other requirements, (1.), (3.) and (4.):
(1): "The Monkey's Audio SDK and source code can be freely used to add APE format playback, encoding, or tagging support to any product, free or commercial."
No usage restrictions - "any product, free or commercial". As long as the last part is read as a non-exclusive list, and the first part is the actual requirement (e.g. also includes academic use), this is compatible with the GPL.
(3): "Any source code, ideas, or libraries used must be plainly acknowledged in the software using the code." - complies with the allowed "Additional Terms", preservation of legal notices, in the GPL.
(4): "Although the software has been tested thoroughly, the author is in no way responsible for damages due to bugs or misuse." - complies with "Disclaimer of Warranty" and "Limitation of Liability" paragraphs of the GPL.
So this leaves requirement (2.) cited in the original message. I can see only one interpretation which is non-self-contradicting:
Monkey's Audio is permissively licensed. When it is linked with GPLed components, it becomes part of a larger works, and thus also MACs source must be distributed alongside all other sources. Monkey's Audio sources become subject of the GPL requirements *in this context*. This does not affect the license terms of Monkey's Audio source distributed otherwise.
Why they haven't chosen the MIT or one of the BSD licenses totally eludes me.
Thank you for the elaboration, I now understand the situation a bit better!
If you only need a Monkey's Audio decoder, you may be better of with the implementation in FFmpeg.
It's required by http://shnutils.freeshell.org/shntool/ which unfortunately only supports the "mac" for APE support and hasn't been updated since 2009.
If you want lossless audio compression, you are definitely better of with FLAC.
Yep, it's my codec of choice nowadays! However I had some older APE files that I needed to convert... and here we are :)
Kind regards,
Stefan
On Freitag, 7. Oktober 2022 11:57:56 CEST Lukas Kucharczyk wrote:
On 06. 10. 22 15:03, Stefan Brüns wrote:
If you only need a Monkey's Audio decoder, you may be better of with the implementation in FFmpeg.
It's required by http://shnutils.freeshell.org/shntool/ which unfortunately only supports the "mac" for APE support and hasn't been updated since 2009.
Do you need only decoding, or also encoding? For decoding, you can replace the "mac" command with an equivalent ffmpeg call (untested): $> export ST_APE_DEC='ffmpeg -i %f -acodec wav -' $> shntool ... See http://shnutils.freeshell.org/shntool/support/doc/shntool.txt Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On 07. 10. 22 15:51, Stefan Brüns wrote:
On Freitag, 7. Oktober 2022 11:57:56 CEST Lukas Kucharczyk wrote:
On 06. 10. 22 15:03, Stefan Brüns wrote:
If you only need a Monkey's Audio decoder, you may be better of with the implementation in FFmpeg.
It's required by http://shnutils.freeshell.org/shntool/ which unfortunately only supports the "mac" for APE support and hasn't been updated since 2009.
Do you need only decoding, or also encoding?
For decoding, you can replace the "mac" command with an equivalent ffmpeg call (untested):
$> export ST_APE_DEC='ffmpeg -i %f -acodec wav -' $> shntool ...
See http://shnutils.freeshell.org/shntool/support/doc/shntool.txt
Thanks, nice find! This is definitely enough for my use case. I should read the manual more carefully!
Kind regards,
Stefan
On 06.10.22 10:47, Lukáš Kucharczyk wrote:
Hello,
I would like to submit a new package to Factory later but unfortunately the licensing is not fitting cleanly with the packaging rules. The package in question is this: https://build.opensuse.org/package/show/home:LKucharczyk/mac The license is described here: https://www.monkeysaudio.com/license.html
It says "Monkey's Audio source can be included in GPL and open-source software, although Monkey's Audio itself will not be subjected to external licensing requirements or other viral source restrictions."
Does that mean the package cannot be included in openSUSE? If it can, what should I use as a value for "License" in the spec file? I've tried "custom" but that just spits out a warning with all the possible values ("custom" not being one of them).
This is unfortunately a custom license that first needs an entry in SPDX - and upstream authors should really stop doing that. Because the nature of the license is very generic and fits the open source definition so it can be included in openSUSE. Use SUSE-Permissive in your spec file please. Greetings, Stephan
participants (5)
-
Axel Braun -
Lukas Kucharczyk -
Lukáš Kucharczyk
-
Stefan Brüns -
Stephan Kulow