For what it is worth, I reached out to Mozilla, and this was the explanation received from Chris Blizzard:

It sounds like we're still finding issues with our fuzzers from time to time and there are
still changes coming to the library. So we're going to keep it close for a while yet.

An interesting note on this: I think we're finally to the point with libvorbis, etc, where we
can start to think about using system libs. We've needed specific versions of those libraries
for a long time because of bugs in the code. So my suggestion here is that we wait for a
while and let the library shake out for a bit. After all, it's pretty new on the scene.

Not what you wanted, but there are real reasons for it.

Basically, it seems clear that Mozilla isn't going to back down on this. At this point, I'm starting to seriously question whether the value of the trademark is worth the limitations that its use is placing on the copyright license terms.

Then I think we should create an exception for it until they allow using the system's libvpx.

I hope they fix the text relocs in libxul.so though in bug : https://bugzilla.mozilla.org/show_bug.cgi?id=595112 ( might be off-topic in here, sorry )

Note, the vorbis bundling that blizzard refers to is noted in this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=517856

This ticket seems like a knee-jerk reaction - Mozilla is trying to do the right thing, but the project is large and these things take time. I'm +1 to granting them an exception while they sort this stuff out.

Mozilla is doing the wrong thing, especially considering their ridiculous rationale (security fixes). We want to be able to issue ONE security update for a libvpx security issue, not two. The only way to do this is to build xulrunner against the system libvpx.

We have a strict policy against bundled libraries, we need to enforce it. I really don't see why xulrunner should get to do its own thing.

(FWIW, IMHO, the bundled libpng fork is also unacceptable.)

Adding to 2010-10-05 meeting agenda.

Please don't forget this issue affects F15/rawhide only right now.

Replying to [comment:8 stransky]:

Please don't forget this issue affects F15/rawhide only right now.

Note that there is the larger issue of xulrunner bundling other system libraries which affects the version currently in all releases. The libraries should be decided on one-by-one as the circumstances surrounding each will be different. However, it's up to fesco whether to have a separate ticket for each.

Reading through the justifications, I have to agree with spot that I'm against granting an exception for the libvpx library. Especially, the upstream position that it's more secure to bundle is incorrect for a Linux distribution. We're just duplicating effort (from some of the complaints duplicating them badly) by having bundled libraries. What we need here is for the mozilla package maintainers to be working closely with the packagers of the libraries that mozilla upstream is bundling. As mozilla adds security fixes and critical bugfixes to the bundled libraries, we need to be adding those fixes to the system library packages so that all of the programs using the library in our distribution benefit.

I have some questions for the firefox maintainers:

• Is it expected that this would be unbundled before f15 releases? Or do you have any idea on timeframe? (ie, would the bundling only need to occur in rawhide).

• If we added all the firefox maintainers to commit acls for libvpx, couldn't those changes happen in our vpx package instead of bundled?

There's an underlying assumption in that statement that all changes in the bundled library would be upstream-palatable, ABI-maintaining, etc. if we were to put them in the system libvpx. I'm not sure we can unilaterally make this assumption.

In any case, this is just 'good system development practices' being the opposite of 'good application development practices'. Once both the system and applications get to a certain size I do wonder what we gain from a hardline stance here, as we're explicitly asking local maintainers to do things that are bad practice for the upstream application.

Could we just use the mozilla copy of libvpx as our system lib ?

Discussion led to two proposals, but we don't really have quorum in the meeting, so:

Proposal 1: Mozilla should be exempted from the FPC bundling policy

(obviously within reason - bundling glibc would be a no-no...)

Proposal 2: Mozilla should be granted an exception in order to bundle libvpx

Could people vote on these?

proposal1: -1 from me. We should at least look at exceptions.

proposal2: +0.5. I am ok with this, but it makes me uneasy that they don't care about our concerns or are willing to work with us on it. I'd also love to see a plan for unbundling: ie, what has to happen before they would be willing to do so.

At the 2010-10-12 meeting fesco voted to grant a exception for the libvpx bundling for now. No broad exception is allowed.

Please do try and unbundle?