Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

By your definition of open source, I know of no compiled application that's fully open source. If you want to change it, you're going to need to fork it. If that's not intrinsic to source code in principle, it is in practice.

As to the H264 situation - how is using closed source and patented implementations better than using open-source but patented implementations?

I don't think anybody is happy with H264; but blaming mozilla is counterproductive. They clearly aren't calling the shots on this; and they tried their utmost to prevent it from happening by supporting numerous unencumbered alternatives. However, companies such as Apple and Microsoft refused to participate, and web developers chose to support H264 over the free alternatives. And lets be honest - there's no free alternative with comparable quality. And realizing that, mozilla supports the very interesting https://xiph.org/daala/ - but that's clearly far from ready.

What else could they have done to avoid H264 dominance? Failing to implement it would simply have hastened firefoxes decline, as despite FF's onetime significant market share, sites never adopted H264 alternatives to any large extent.

If you want to blame somebody, blame webdevs for that (but again... it's not like there was a good alternative).



> By your definition of open source, I know of no compiled application that's fully open source. If you want to change it, you're going to need to fork it. If that's not intrinsic to source code in principle, it is in practice.

By far most open source software, when built without changes, will produce a fully working binary that does not grab and run binary blobs at runtime. All that software would meet my criteria for acceptance.

> As to the H264 situation - how is using closed source and patented implementations better than using open-source but patented implementations?

If the work is deferred to the OS, it's not mozilla's problem. It is then up to the user to choose a platform with the desired codecs, which may be open or closed. People on platforms that already contain and expose closed-source codecs are unlikely to be concerned about these issues.

The rest of your comment, I agree with. I know mozilla fought hard to get a free codec included in the standard. That was very good, I'm certainly not trying to demonise mozilla here.

My problem here is only with the technical solution implemented after that fight was lost. And I worry about the precedent being set that mozilla is okay with the browser downloading and running precompiled binaries from the internet at runtime, without an explicit request from the user with a big, scary warning. That's mozilla's prerogative, they decide to go with the larger market and I totally understand that. It doesn't make it any less sad to watch, though.


>By far most open source software, when built without changes, will produce a fully working binary that does not grab and run binary blobs at runtime. All that software would meet my criteria for acceptance.

Huh? We're not talking about whether the main part of firefox is open source. We're talking about whether the H264 plugin is open source.

Look at firefox as your apt-get and the H264 plugin as something that you can either download a compiled binary of or compile yourself.

Is the only objection that it does it at 'runtime'? If you consider first boot part of the install process then that problem solves itself.

I really don't understand what the problem is.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: