gst-plugins-bad: disable faac by default because it's unfree

[lucabrunox]

A lot of packages are not built in hydra due to gst-plugins-bad
being unfree. Make faac dependency optional.

[lucabrunox]

I tried adding faacSupport = true to nixos package overrides, but I'm still unsure on how to check whether it was built with faac or not. Help appreciated in determining whether this change is correct or not.

[bluescreen303]

gst-plugins-bad are supposed to be lower-quality plugins.
The ones with flaky licensing/patent issues is gst-plugins-ugly.
As far as I know, the license for gst-plugins-bad is LGPL2+ no matter what plugins you enable/disable.

I think there is an issue that wants to create some onlyFree config setting for people who don't want any unfree/patented pkgs. There's no desire to enable that by default.

[lucabrunox]

The problem is that with faac enabled, this long packages are not built, and thus they are not evaluated and are not in the cache (am I wrong?): http://hydra.nixos.org/jobset/nixos/trunk-combined#tabs-errors
We're throwing away the CI for all those packages.

[vcunat]

The patent issue was discussed with freetype #2020 (comment). It seems that @edolstra is fine with distributing patented stuff (as the servers are in EU, where SW patents can't apply). Still, I think we should reflect such things somehow in meta, because e.g. US users might mind about patents.

For similar reasons, I would tend to remove patented stuff from default dependency trees. I don't know if currently the packages depending on gst-plugins-bad can work well without it -- in that case it might be cleaner to drop the dependency by default, otherwise it makes better sense to have a default version without patent risks.

[lucabrunox]

It's not only whether patents can be shipped by default or not. Does nixos want to be a libre by default os or not? As a free software user, I'd like to have sane free defaults. The fact that @bluescreen303 says "there's no desire", that's subjective, yet has to be decided as project goal.
If it turns out that any software depends on faac, it can override faacSupport. I don't think any package particularly depends on faac, it can be viewed more of a plugin, so in my opinion it's not a critical change. We made more invasive changes (like gsettings schemas :P).
I underline again the fact that ffmpeg does not support faac by default, and that it breaks CI for many packages.

[bluescreen303]

The problem with these types of settings (faacSupport) is that overriding them leads to lots of local rebuilds. In case of gstreamer this means all of kde and libreoffice will be custom-built locally every time some dependency changes. Of course people can choose to not to override and just use the default as a (kde/libreoffice)dependency and use some deep override trick to build their mediaplayer/video-editor with a copy of gstreamer that does enable faacSupport. Of course having multiple copies around is a bit silly.

I want to stress once more that gst-plugins-bad is licensed LGPL2+, which is a libre license.
Your conditional license change therefore is somewhat odd.

I do agree on having a project-wide goal regarding liberties, licenses and patents. My comment was related to recalling the recent freetype discussion that mentioned "we don't care about patents by default. people who do should have an easy toggle though". Of course licenses are something different, so we should ask @edolstra what he thinks. Personally, I would draw the line with licenses that don't allow redistribution. libreOnly would be a nice option to have, but probably not as a default.

[lucabrunox]

Isn't it already like that because there's no cache on the servers? Since gst-plugins-bad is not built, other packages are not built by hydra, so no cache. That was exactly my point.

[bluescreen303]

gst-plugins-bad is not in release.nix
I'm no expert on hydra, but I believe stuff only gets built if it's in there (or something depending on it).
Perhaps someone can clarify?

I do not think that the fact that faac is in buildInputs will prevent it from building.
You can for example use an unfree tool to build a free package. Of course if that tool sticks around in the closure at runtime, that can be a problem, but that would only be visible/knowable when the build finishes. I cannot find that hydra ever even attempted to build gst-plugins-bad, so I'm pretty sure licenses/dependencies don't have anything to do with it in this case.

[lucabrunox]

It didn't even attempt, because it is an evaluation error: http://hydra.nixos.org/jobset/nixos/trunk-combined#tabs-errors

[bluescreen303]

that doesn't look nice indeed.

Anyway, it seems there is some decision to remove unfree stuff by default.
#2134 (comment)
Although that discussion was started because of non-redistributable struff, not unfree in general.

Can you take out the conditional license change? I don't think that's correct.
I'll merge the rest after that.

[vcunat]

In any case, we can mark the patented stuff as "unfree-redistributable" ATM, which is IMO correct and doesn't prevent Hydra from building it.

[bluescreen303]

Not sure if faac has a patent issue. It's just a somewhat restricted license (but redistributable).

[lucabrunox]

Updated, just in case.

[vcunat]

@bluescreen303: patent problems come from the mpeg4 format stuff, see e.g. http://en.wikipedia.org/wiki/Faac#Licensing