= phenomenon =
The IETF is discussing whether to make a video codec mandatory in their WebRTC standard. The two contenders are the unencumbered VP8 and patent encumbered H.264.
Background can be found in the first port to this thread: https://lists.fedoraproject.org/pipermail/devel/2013-November/191153.html
In the advisory board thread, Spot noted that Fedora will not be able to ship any code that directly implements H.264 since H.264 is patented and we do not have a license to ship source implementing it (let alone ship source code implementing it that others could then modify). However, he leaves open the question as to whether we could ship software that downloaded the freely available binary implementation that CISCO states that it will provide, stating that that's a FESCo decision:
https://lists.fedoraproject.org/pipermail/advisory-board/2013-November/012261.html
He does note that codeina would seem to be a precedent in this case and in the end we did not ship that in its default form (directly allowing the user to the fluendo site to get the codecs).
= recommendation =
Discuss and vote on the following at the meeting:
Proposal: Have a fesco member email the ietf list to say that 1) As a distribution that cares about software freedom we cannot ship within Fedora anything that is not modifiable and re-distributable by our users. Therefore we cannot ship software that directly contains OpenH264. 2) Precedent for Fedora would be to not ship software that downloads patent encumbered codecs either. If we continue to follow that precedent, software that downloads Openh264 at runtime to implement webrtc would need to be modified and users would need to perform the download step manually.
This email would need to be sent ASAP after the fesco meeting as their meeting is at Thursday the 7th at 13:00 pacific (approximately one day after ours).
Mailing list info: https://www.ietf.org/mailman/listinfo/rtcweb
So, in regards to breaking any auto-downloading code in Firefox - we already have Mozilla's plugin-finder service, which would download binary plugins. It does not always work in Fedora, but, to the best of my knowledge, we're not breaking it intentionally and by policy.
I want to note that we do have some games that facilitate downloading of non-free assests (for example uqm). Assets aren't the same as code, but it looks like there is a precedent for making it easy to install stuff that can't be in Fedora. Presumably there will be some way for people to install OpenH264 if they want it. Presumably we wouldn't let firefox silently install OpenH264 (without user interaction). Narrowing things down, where the line is between those extremes would probably be better. I haven't seen much in the way of details on how exactly it is anticipated this will work in Firefox. It has been stated there will be a preference to prevent the install, but by default it will be allowed. I haven't seen anything about whether a license is presented to the user, whether the user gets to OK the install, or whether the install is per user or system wide.
So, rewording Toshio's initial proposal slightly, to handle the obvious points:
...
Fedora is a distribution that cares about software freedom and our users freedom. Firstly, we cannot ship binary-only prebuilt software within Fedora. This rules out inclusion of OpenH264 binaries direct from Cisco, or other providers. Secondly, we cannot ship software built from source that is not free for any use, freely distributable, and free from patent restrictions. Therefore, Fedora is similarly unable to ship rebuilt OpenH264 code.
Is this wording acceptable? CCing spot as fedora-legal rep.
We can then haggle over how we may or may not handle user-initiated installation on an individual system, but the question of whether Fedora can ship it directly is clear.
Wording is fine.
Replying to [ticket:1192 toshio]:
So, let me just suggest some ideas: (While I don't have hard data,) I believe that many Fedora installations in fact do contain either non-free or (US-)patent-encumbered software; so insisting that avoiding both is somehow critically important, or silently implying to IETF that when it's not distributed by Fedora then our users won't install it or something functionally equivalent from other sources, and won't be interoperable, is somewhat disingenuous. The real-world effect of the efforts to keep standards patent-unencumbered "for interoperability" has frequently resulted in ''less'' real-world interoperability (by creating a minority that insists on not following the majority's standards without giving the majority much reason to switch, at least judged by ''their'' evaluation criteria). * In the meanwhile, the incumbent standards are incumbent to a significant extent because the "non-commercial-use-only" patent licenses have widely been violated, making the insistence on a patent-clean alternative particularly ironic.
Finally, 2) refers to a precedent that, per fedora-devel, seems to have been made on purely technical, not principal, basis (users wanted a MP3 implementation but wanted a ''different'' MP3 implementation); I haven't yet researched if that's true, but if it is, I'd be unwilling to vote for a similarly technical FESCo resolution if it were to be presented to IETF as an interoperability objection (because it wouldn't be an interoperability problem) or a principled objection (because the authority for these is with the Board).
I like notting's proposal and I agree that point2 from the original proposal is problematic. Perhaps something like this in addition to notting's proposal:
"""
Fedora would be much happier with a non-patent encumbered codec in the standard as it would relieve us of the burden of caring for a codec implementation that we cannot fix if it is buggy on our platform, let us ship improved or more efficient versions of the codec if that is asked for, and relieve us of the burden of making sure all implementors of the standard were using a proper technique to retrieve the patent-encumbered portion from the internet so that we weren't shipping non-free code.
The full proposal would then be:
Full text we voted on:
Acceptance of an insufficiently-free license of the OpenH264 codec would mean that open-source vendors are not able to implement it on their own terms. They must rely on the implementation provided by a third party (Cisco) and create workarounds to have the user download their implementation after installation, increasing the burden on open-source users. This creates an unequal environment for open-source vendors.
We agreed to the full text that pjones posted in comment:9 with a vote of (+1:7, 0:0, -1:0)
Statement sent:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09546.html
I'll close this ticket for now. If there's followup questions I'll reopen it with details.
We also passed this related proposal at the meeting:
This is just codifying that we'd cross the bridge of deciding what to do about software that wants to download the pre-built codec from cisco when and if we had to cross that bridge.
Login to comment on this ticket.