Closed viccie30 closed 1 year ago
We are OK with any open and free licenses compatible with Fedora (https://docs.fedoraproject.org/en-US/legal/allowed-licenses/). At the moment we do not use the spec from the rpm directory, we use our own downstream spec (https://src.fedoraproject.org/rpms/openfec/blob/rawhide/f/openfec.spec), because OpenSUSE is a bit different.
Maybe both specs could be merged together, but it's not our prio at the moment. We also don't need our spec to be upstream - it's changed quite often depending on the new features proposed into Fedora. In Fedora the specs are usually licensed by the MIT license (https://fedoraproject.org/wiki/Licensing:Main#License_of_Fedora_SPEC_Files), but in fact they can be licensed by any compatible Fedora license (https://docs.fedoraproject.org/en-US/legal/allowed-licenses/) if the license is mentioned explicitly in the spec.
Their website says:
CeCCIL-C is the main licence, for most of the OpenFEC library source code.
It says "code", but I'd assume that actually this is the license for documentation / tests / examples as well. I think you could write to their mailing list or directly to Vincent Roca to his email at inria.fr. He answered to my questions on the mailing list some time ago.
Also waiting for an answer from @twojstaryzdomu. I think for simplicity we could use the same license (CeCCIL-C) for deb and rpm stuff too? I'm personally is OK with any license.
The other files come from the original distribution at openfec.org and it does not look like that website has seen any activity in the last years.
Yep. IIRC they're working on a different types of codecs (sliding window) and on a new library, that is not open-sourced so far.
Alternatively, they can also be deleted without impacting the functionality of the library itself.
Well it's not super-nice to remove documentations and tools, but if this is the only way then OK. I suggest to wait for clarifications for some time, and if there is no response, feel free to send PR or ask me to do it.
We are OK with any open and free licenses compatible with Fedora (https://docs.fedoraproject.org/en-US/legal/allowed-licenses/). At the moment we do not use the spec from the rpm directory, we use our own downstream spec (https://src.fedoraproject.org/rpms/openfec/blob/rawhide/f/openfec.spec), because OpenSUSE is a bit different.
Maybe both specs could be merged together, but it's not our prio at the moment. We also don't need our spec to be upstream - it's changed quite often depending on the new features proposed into Fedora. In Fedora the specs are usually licensed by the MIT license (https://fedoraproject.org/wiki/Licensing:Main#License_of_Fedora_SPEC_Files), but in fact they can be licensed by any compatible Fedora license (https://docs.fedoraproject.org/en-US/legal/allowed-licenses/) if the license is mentioned explicitly in the spec.
Thanks for the quick response, @yarda. I will describe the license as MIT for Debian then.
Hello Vincent,
First of all I want to thank you and the other developers at INRIA for developing openfec. I am trying to package openfec for Debian, using a fork from https://github.com/roc-streaming/openfec as a basis.
Debian requires that the copyright and license of every source file is clear. Most of the files in the openfec distribution are clearly labeled, but a few are not.
Specifically all files in the doc/ and perf_eval/ subdirectories and the files tools/descr_stats_v1.2/descr_stats_doc.html and tools/descr_stats_v1.2/sigma2.gif lack licensing information.
Could you clarify the copyright and license situation for these files?
Merci d'avance and kind regards, -- Victor Westerhuis @.***>
Well it's not super-nice to remove documentations and tools, but if this is the only way then OK. I suggest to wait for clarifications for some time, and if there is no response, feel free to send PR or ask me to do it.
Also we could modify github action to remove those files from sources and create source tarball without those files. And attach this archive as release asset.
Also we could modify github action to remove those files from sources and create source tarball without those files. And attach this archive as release asset.
That is a possibility, but that's also something I can do downstream in Debian if you prefer to keep the source tarballs complete.
Handling it in downstream would be perfect, if it wouldn't complicate things for you.
@viccie30 just curious: did you have a reply?
Unfortunately not. I have been busy otherwise, so I haven't followed up any further. I'll see if I can get in touch with INRIA in some other way.
I found another email address for Vincent Roca, so resent the following email:
Hello Vincent,
First of all I want to thank you and the other developers at INRIA for developing openfec. I am trying to package openfec for Debian, using a fork from https://github.com/roc-streaming/openfec as a basis.
Debian requires that the copyright and license of every source file is clear. Most of the files in the openfec distribution are clearly labeled, but a few are not.
Specifically all files in the doc/ and perf_eval/ subdirectories and the files tools/descr_stats_v1.2/descr_stats_doc.html and tools/descr_stats_v1.2/sigma2.gif lack licensing information.
Could you clarify the copyright and license situation for these files?
Merci d'avance. -- Groet, Regards,
Victor Westerhuis
Unfortunately, I still have no response. If and when openfec is packaged for Debian, I will strip the offending files in the packaging.
Got it.
Since there is nothing we can do on our side, I'm closing this. However feel free to reopen if I'm missing something.
There are quite a few files in the repository without clear licenses and copyright notices. Debian requires that software in its archives follows its guidelines. The issues I have specifically noted in the code:
For the recently added files in pc/ and rpm/, perhaps @twojstaryzdomu and @yarda can clarify what license they want this code to be under.
The other files come from the original distribution at openfec.org and it does not look like that website has seen any activity in the last years. Perhaps it would be possible to ask for clarification via e-mail? Alternatively, they can also be deleted without impacting the functionality of the library itself.