As mentioned here.
Jibri relies on various proprietary/patent-encumbered codecs, notably Ffmpeg. As these are only runtime dependecies & users can install them via RPMFusion this shouldn't be an issue.
However, before building we need to make sure that the build doesn't pull in any problematic code.
Regarding third-party licenses of dependencies that are pulled in during build:
Here is a report, generated by adding the license-maven-plugin to the pom xml and invoking it by running
mvn license:third-party-report
<img alt="third-party-report.html" src="/jitsi-rpm/issue/raw/files/034e6f473a252e68bee38a7ae39da8b984363d5e79e3188f7aa1fb653d749413-third-party-report.html" />
In the report, some licenses could not be found. Of those, a search at mvnrepository.com displays the following Licenses:
org.igniterealtime.* Apache org.jitsi.* various: Apache/LGPL/GPL/MIT/EPL net.jcip.* Public Domain dom4j BSD
The various Requires: directives in the spec file don't pose a problem, because those are not pulled in at build time.
Conclusion: Should be no problem to build on Copr
BTW: These dependencies are installed, if ffmpeg is installed from rpmfusion:
ffmpeg.x86_64 4.3.1-16.fc33 @rpmfusion-free-updates ffmpeg-libs.x86_64 4.3.1-16.fc33 @rpmfusion-free-updates libavdevice.x86_64 4.3.1-16.fc33 @rpmfusion-free-updates opencore-amr.x86_64 0.1.5-11.fc33 @rpmfusion-free vo-amrwbenc.x86_64 0.1.3-13.fc33 @rpmfusion-free x264-libs.x86_64 0.160-2.20200702gitcde9a93.fc33 @rpmfusion-free x265-libs.x86_64 3.4-3.fc33 @rpmfusion-free xvidcore.x86_64 1.3.7-4.fc33 @rpmfusion-free
No packages from rpmfusion-nonfree repositories required.
Hey, thanks for investigating. I agree, this looks OK. I've merged your PR & will release a new jibri package later today.
Metadata Update from @lcts: - Issue status updated to: Closed (was: Open)
Unfortunately, testing here reveals: This is still WIP. So, a release is currently not necessary. There will be more PRs with fixes.
Log in to comment on this ticket.