= phenomenon =
This is about a change in Firefox. Upon first startup, Firefox automatically downloads Cisco's OpenH264 video codec in binary form, and puts the ELF DSO into the user's Firefox profile.
The package bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1155499
= background analysis =
I see three problems with that:
The binary was not built on Fedora infrastructure, which is against packaging policy.
Cisco's binary license agreement requires that the license is presented to the user, but it is not included in the Licensing Information or End User Rights that come with Firefox. It is linked from the Add-Ons Manager, but not from about:plugins.
Cisco's license does not seem to allow commercial use (“uses in which it [receives] remuneration”), which is a restriction on use and incompatible with Fedora's licensing guidelines.
The package maintainer asked me to file a ticket with Fesco. I assume he disagrees with my analysis.
= implementation recommendation =
I think we need some other solution which is not an implicit software download. For Flash, Firefox prompts the user explicitly before downloading it. Unfortunately, this does not work (which is not a Fedora-specific bug), so I don't know if there is a clear indicator to the user that they are installing software which does not conform to the Fedora packaging guidelines. But if the Flash approach is acceptable in principle, this could be a solution for OpenH264 as well.
I'm not sure how useful OpenH264 is on its own because it's just a video codec, and I suspect that most H.264 uses will come with audio streams which use codecs not part of Fedora and not downloaded by Firefox.
= OpenH264 license text =
Cisco provides this program under the terms of the BSD license.
Additionally, this binary is licensed under Cisco’s AVC/H.264 Patent Portfolio License from MPEG LA, at no cost to you, provided that the requirements and conditions shown below in the AVC/H.264 Patent Portfolio sections are met.
As with all AVC/H.264 codecs, you may also obtain your own patent license from MPEG LA or from the individual patent owners, or proceed at your own risk. Your rights from Cisco under the BSD license are not affected by this choice.
For more information on the OpenH264 binary licensing, please see the OpenH264 FAQ found at http://www.openh264.org/faq.html#binary
A corresponding source code to this binary program is available under the same BSD terms, which can be found at http://www.openh264.org
Copyright © 2014 Cisco Systems, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The binary form of this Software is distributed by Cisco under the AVC/H.264 Patent Portfolio License from MPEG LA, and is subject to the following requirements, which may or may not be applicable to your use of this software:
THIS PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE FOR THE PERSONAL USE OF A CONSUMER OR OTHER USES IN WHICH IT DOES NOT RECEIVE REMUNERATION TO (i) ENCODE VIDEO IN COMPLIANCE WITH THE AVC STANDARD (“AVC VIDEO”) AND/OR (ii) DECODE AVC VIDEO THAT WAS ENCODED BY A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS OBTAINED FROM A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO. NO LICENSE IS GRANTED OR SHALL BE IMPLIED FOR ANY OTHER USE. ADDITIONAL INFORMATION MAY BE OBTAINED FROM MPEG LA, L.L.C. SEE HTTP://WWW.MPEGLA.COM
Accordingly, please be advised that content providers and broadcasters using AVC/H.264 in their service may be required to obtain a separate use license from MPEG LA, referred to as "(b) sublicenses" in the SUMMARY OF AVC/H.264 LICENSE TERMS from MPEG LA found at http://www.openh264.org/mpegla
In addition, the Cisco-provided binary of this Software is licensed under Cisco's license from MPEG LA only if the following conditions are met:
The Cisco-provided binary is separately downloaded to an end user’s device, and not integrated into or combined with third party software prior to being downloaded to the end user’s device;
The end user must have the ability to control (e.g., to enable, disable, or re-enable) the use of the Cisco-provided binary;
Third party software, in the location where end users can control the use of the Cisco-provided binary, must display the following text:
"OpenH264 Video Codec provided by Cisco Systems, Inc."
Any third-party software that makes use of the Cisco-provided binary must reproduce all of the above text, as well as this last condition, in the EULA and/or in another location where licensing information is to be presented to the end user.
v1.0
}}}
The older ticket is #1192.
And while bug1155499 says that the earlier discussion was “without any result", there was
#info Regarding the earlier discussion on OpenH264, if Fedora community members have a project in Fedora that is intending to use OpenH264 in some way, please talk to FESCo before integrating code to use it.
What are our options here?
It's possible to disable the automatic download by pre-loading the user profile with non-working update URLs. (There might be a cleaner option, but changing the URLs will definitely work.) See the “gmp-” properties in this file: firefox-33.0/mozilla-release/browser/app/profile/firefox.js
firefox-33.0/mozilla-release/browser/app/profile/firefox.js
It is unclear if disabling or changing this functionality is possible while still retaining the original Mozilla branding.
In recent discussion about theming, Firefox developers reached out to us and expressed interest in being flexible. The branding restrictions are really intended to stop bad actors. Despite the decision to do this in a way that may be different from what Fedora chooses, I think we're all basically on the same side here and I'm optimistic that we can find something that works.
Can someone please volunteer to talk to the Mozilla folks about removing this auto-download, possibly in the manner described in https://fedorahosted.org/fesco/ticket/1359#comment:4
We seem to have not done anything here. ;(
It would be very nice to have this fixed before f21 final.
I'll ask in bug if they would be willing to disable this autodownload.
I'm not FESCo, but I'd argue that this is a f21 release blocker, in that it clearly violates the Packaging Guideline that requires all software be built from source. If Firefox is just going to auto-download a binary on startup, it's functionally equivalent to if it shipped it.
I agree with spot here.
As far as I know, the codec is only usable for WebRTC video chat streaming. While that is useful, it isn't as popular as simple HD videos streams. I believe the audio side of the streams aren't covered either. So patching this out for now does not seem like a huge loss of functionality even ignoring the legal side of things.
Going forward, we should likely start a conversation with both Fedora Legal and the Fedora Council to see if there is anything we can do for cases like this.
From the bug, they can disable the autodownload at any time.
I've asked if there is a way to do so where users could still manually initiate a download/install or where loading something that needs it could ask the user to download/install.
Replying to [comment:11 jwboyer]:
As far as I know, the codec is only usable for WebRTC video chat streaming. While that is >useful, it isn't as popular as simple HD videos streams. I believe the audio side of the >streams aren't covered either. So patching this out for now does not seem like a huge loss >of functionality even ignoring the legal side of things.
Actually Audio is covered as the agreed audio codec for WebRTC is Opus from Xiph.org. So if we disable this we go from a fully working WebRTC implementation to a broken one.
ok, so further discussion on bug has clarified some things for me at least. ;)
Proposal: 1. ask firefox maintainers to disable automatic download of this plugin in fedora asap.
Replying to [comment:8 spot]:
I don't think that this makes any sense not only do we usually not block the release for "violations of the package guidelines" but in that case the change is already in F20 (Firefox gets updated in all branches). So while we have to resolve this I disagree that it should block the release. The only thing that this gains us is to put pressure on the Firefox maintainers ... but this shouldn't be the way we deal with things.
I don't propose we add an exception for this, but I do want to recognize that this is a somewhat unique binary-software situation, as the source code is available under a BSD license (https://github.com/cisco/openh264) and [http://andreasgal.com/2014/10/14/openh264-now-in-firefox/ Mozilla says]:
Mozilla and Cisco have established a process by which the binary is verified as having been built from the publicly available source, thereby enhancing the transparency and trustworthiness of the system.
Do we have details of that verification, and is it something we can also do?
In any case, I don't think the situation is directly comparable to the Flash player and am sympathetic to making the process pain-free for users who want to make this choice. On the other hand, I do think that a choice should be involved.
I would personally consider this issue resolved if the user was prompted before this download occurred, something like:
Thanks to a partnership with Cisco, Mozilla is able to offer H264 support via a pre-built binary addon to Firefox. Click here to learn more. [DOWNLOAD] [SKIP]
Replying to [comment:17 spot]:
I would personally consider this issue resolved if the user was prompted before this download occurred, something like: Thanks to a partnership with Cisco, Mozilla is able to offer H264 support via a pre-built binary addon to Firefox. Click here to learn more. [DOWNLOAD] [SKIP]
+1
My understanding (althought I don't want to speak for firefox maintainers) is that they would be fine with such a solution, provided the code for it was written and accepted upstream. There is no such code currently, nor I think do they have desire to write such.
Can we find someone who does want to implement that?
Replying to [comment:16 mattdm]:
Mozilla and Cisco have established a process by which the binary is verified as having been built from the publicly available source, thereby enhancing the transparency and trustworthiness of the system. Do we have details of that verification, and is it something we can also do?
And would it be a reasonable substitute for fulfilling the “built from source” requirement?
My opinion: No, it is not. I don't want to open that sort of a loophole, where the vendor says it is trustworthy, so we don't have to build it from source.
This was discussed at todays meeting:
Forgot to leave this open. :(
Hello,[[BR]]
I know my opinion doesn't carry much weight, but I'm also interested in this and I thought I could contribute from a user standpoint. I don't like -much less trust- closed source stuff and I hate myself whenever I am forced to install something like adobe flash, or binary drivers for any reason whatsoever.[[BR]]
Now the problem with OpenH264 isn't that it's closed source, rather than we trust somebody else to vet, compile, package and distribute it. What if that was done in-house and on first run or when a user came across a scenario that would require the plugin, they were offered to install an rpm from Fedora? I'm not that technically versed, but having seen Canonical's (and others') modifications, it would seem feasible. We could have ''media.gmp-gmpopenh264.provider.enabled'' set to false (there seem to be a couple more relevant options in Aurora) and maybe write a Fedora-specific Firefox add-on to detect the need for the plugin which could also allow them to disable/enable it at will.
Replying to [comment:24 alexpl]:
Hello,[[BR]] I know my opinion doesn't carry much weight, but I'm also interested in this and I thought I could contribute from a user standpoint. I don't like -much less trust- closed source stuff and I hate myself whenever I am forced to install something like adobe flash, or binary drivers for any reason whatsoever.[[BR]] Now the problem with OpenH264 isn't that it's closed source, rather than we trust somebody else to vet, compile, package and distribute it. What if that was done in-house and on first run or when a user came across a scenario that would require the plugin, they were offered to install an rpm from Fedora? I'm not that technically versed, but having seen Canonical's (and others') modifications, it would seem feasible. We could have ''media.gmp-gmpopenh264.provider.enabled'' set to false (there seem to be a couple more relevant options in Aurora) and maybe write a Fedora-specific Firefox add-on to detect the need for the plugin which could also allow them to disable/enable it at will.
We discussed this in the meeting. Our current understanding is that if Fedora were to build it from source, it would negate the license fee that Cisco has paid already making it an unlicensed use of the codec. That is not acceptable for Fedora either.
I am in talks with Cisco about making the H264 codec available for RHEL and Fedora as a GStreamer plugin packaged as an RPM. The way this would work is that we will work with Cisco to create needed scripts and infrastructure on their servers to take their source tarballs, automatically submit them into our build infrastructure to create the rpms and then host those rpms on the Cisco servers where GNOME Software will know to look for them.
This would ensure that we are covered by their licensing and and at the same time we will control the actual build. If we are lucky we can even use the GStreamer plugin with Firefox so that we can grab the code only once, but if that doesn't work we can look into doing a similar setup for Firefox that we are looking at for the GStreamer plugin.
So it'd be a) open source b) built in our build infrastructure from that source, but c) distributed from cisco servers because of the patent licensing issue?
Correct
The automatic download/install is disabled now, packages submitted as update.
This topic will be discussed at FESCo meeting on Wednesday 2014-11-19 on 18:00 UTC.
AGREED: Close the ticket and ask interested parties to work with legal on more user friendly solution (+7, -0, 0:0)
Interested parties :), please work with Fedora Legal on more user friendly solution if possible.
FYI: initial page for manual download info:
https://fedoraproject.org/wiki/OpenH264
Replying to [comment:27 mattdm]:
one way I see improving the situation is to build it at Fedora, download from cisco and compare fingerprints.
Nevertheless I am still strongly in favor of asking the user to download it and wondering if it should not be installed in a system directory instead of user profile.
Also this plugin is of no particular importance for me anyway and if it was me getting rid of it is preferable over spending valuable resources trying to resolve it.
See also issue #2015,
Login to comment on this ticket.