ffmpeg: binaries no longer distributable, due to rav1e; openssl11 now in play

[mascguy (Christopher Nielsen)]

With the addition of dependency rav1e, ffmpeg +gpl2 is no longer distributable:

$ ../macports-infra/jobs/port_binary_distributable.tcl -v ffmpeg
"ffmpeg" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl11"

Meanwhile rav1e has no lib/runtime deps, and a non-conflicting BSD license:

$ port info rav1e
rav1e @0.5.1_1 (multimedia)

Description:          the fastest and safest AV1 encoder
Homepage:             https://github.com/xiph/rav1e

Build Dependencies:   cargo-c, nasm, rust, cargo
Platforms:            darwin
License:              BSD

Ultimately openssl11 appears to be coming from rust and cargo, which both have lib deps on it. But should that license be propagated to downstream ports that build with them?

[mascguy (Christopher Nielsen)]

rav1e is also distributable, which makes this even more interesting:

$ ../macports-infra/jobs/port_binary_distributable.tcl -v rav1e
"rav1e" is distributable

[i0ntempest]

That's a *really* far connection from openssl11 to ffmpeg... I doubt it would really affect anything. But that said I don't know a lot about licenses, better ask the experts.

[Christopher Nielsen <mascguy@…>]

In 0778750ef43db61b5b5bf961601d64c66040cafd/macports-ports (master):

ffmpeg/ffmpeg-devel: add license_noconflict for openssl11
See: #65462

[mascguy (Christopher Nielsen)]

While this is now fixed, leaving ticket open for further discussion: Want to be sure there's consensus from @jmroot and others.

[jmroot (Joshua Root)]

The license_noconflict belongs in rav1e if it doesn't use rust in a way that creates a derivative work. (And it should be license_noconflict rust, as that's the direct dependency.) Language runtimes can be tricky though. GCC for example has an extra license exception for its runtime components so that everything compiled with it isn't automatically GPLv3: ​https://gcc.gnu.org/onlinedocs/gcc-12.1.0/libstdc++/manual/manual/license.html

I don't know what the situation is with rust. Alternatively, if rust doesn't create a derivative work with openssl11, that could be specified, though that seems unlikely.

[mascguy (Christopher Nielsen)]

Replying to jmroot:

I don't know what the situation is with rust. Alternatively, if rust doesn't create a derivative work with openssl11, that could be specified, though that seems unlikely.

It's my understanding that software built by rust, isn't inherently a derivative work of openssl11. Rather, that would only be the case if the component depends on a crate that binds to (or includes code from) the latter, such as ​https://crates.io/crates/openssl.

Based on a quick review of the portfile for rav1e - as well as the build log, to verify what crates are being downloaded - I don't see (?) such a dependency.

I'm not 100% certain on all of the above, though.

Marcus/Chris/Herby, your folks' thoughts?

[mascguy (Christopher Nielsen)]

It looks like cargo and rust can migrate to openssl3, which may help:

​https://github.com/macports/macports-ports/pull/15288

[jmroot (Joshua Root)]

Great, better outcome all round.