NTFS-3G Merges With NTFSprogs, Plus New Version

[Nobu]

To make myself clear, it's a logical decision, based on business and legal reasons. Not a philosophical decision based on "I like this one more," or "this one is not free, so I won't use it, even if I can afford it".

[Nobu]

They can, they chose not to, making the problem philosophical, not technical and not legal.

Like I said, "being able to work around the problem does not make it philosophical; that is only the case if they have a significant group of customers who want Red Hat to pursue the work-around, yet they refuse to." Would you buy a license (which is needed only because of a new feature that you don't need) for a browser plug-in that you and almost none of your customers use, just because it fixes a security flaw? Especially considering the format's decrease in usage, I wouldn't.

In the case of Fluendo's mp3 codec, the situation is even worse, because Fluendo can't even make the fix available (from what I understand), so Red Hat's only choices are to either leave their customers vulnerable, or remove it from the supported repo. Having an obligation to their customers, the second option is the obvious choice, since their customers can always get it for themselves, if they want to put themselves at risk.

[smitty3268]

Your premise would be great if Red Hat couldn't afford to purchase licenses for said codecs. They can, they chose not to, making the problem philosophical, not technical and not legal.

That sounds more like an economic problem than a philosophical one. Their customers don't want to pay for it.

[yogi_berra]

Looks like a technical, legal problem, to me. It only becomes philosophical when you make it so, by saying that you should ignore license restrictions, which Red Hat cannot do. And, no, being able to work around the problem does not make it philosophical; that is only the case if they have a significant group of customers who want Red Hat to pursue the work-around, yet they refuse to.

Your premise would be great if Red Hat couldn't afford to purchase licenses for said codecs. They can, they chose not to, making the problem philosophical, not technical and not legal.

[Nobu]

I can't help that you do not appreciate quality sarcasm.

I would, however, point out the problem you point to as being a "technical" problem is a philosophical problem as there was nothing technically preventing Red Hat from shipping the next version of Real Player beyond a lack of willingness to do so.

Looks like a technical, legal problem, to me. It only becomes philosophical when you make it so, by saying that you should ignore license restrictions, which Red Hat cannot do. And, no, being able to work around the problem does not make it philosophical; that is only the case if they have a significant group of customers who want Red Hat to pursue the work-around, yet they refuse to.

[yogi_berra]

This isn't a theoretical or philosophical problem. One example

https://rhn.redhat.com/errata/RHSA-2008-0812.html

Your sarcasm (not thinly veiled really) is unwarranted and unnecessary in this case. . Yes, it is true that Red Hat might include licensed components in a extras repository if there is a sufficient demand for it however my point was that it will never be in the main repository and it is not possible to ignore legal and technical issues regardless of whether end users care about them.

I can't help that you do not appreciate quality sarcasm.

I would, however, point out the problem you point to as being a "technical" problem is a philosophical problem as there was nothing technically preventing Red Hat from shipping the next version of Real Player beyond a lack of willingness to do so.

[pvtcupcakes]

I find it hard to believe that Red Hat and Fluendo couldn't work out a reasonable solution to this given the amount of money that would be involved. Surely you could become a 'preferred customer' or something and work this out. But I certainly understand why it's not worth it. I can't imagine the enterprise market is clamoring for such a feature, so there's no reason for Red Hat to provide it.

I agree, who would want MP3 playback on their server? Are corporations going to blare their pirated music over the intercom using a RHEL box or something? I just really don't see a use for it.

If your server is streaming MP3s, you don't need a codec on the server to do that as you're only transmitting the MP3 file and the client machine decodes it.

It might be kind of nice if Red Hat could distribute an MP3 codec with Fedora, but enabling RPM Fusion is fine with me. And as was posted earlier, Red Hat would only have a sort of "3rd party" repo for the MP3 codec anyway. So it's either a 3rd party repo, or a 3rd party repo.

[smitty3268]

If you can't effectively modify software to integrate with the distribution properly and if you don't have the freedom to fix potential security issues, then it a serious liability to include them and vendors have to take such things into consideration for inclusion of any components. This isn't a theoretical or philosophical problem.

I find it hard to believe that Red Hat and Fluendo couldn't work out a reasonable solution to this given the amount of money that would be involved. Surely you could become a 'preferred customer' or something and work this out. But I certainly understand why it's not worth it. I can't imagine the enterprise market is clamoring for such a feature, so there's no reason for Red Hat to provide it.

[RahulSundaram]

My point had nothing whatsoever to do with FSF either. If you can't effectively modify software to integrate with the distribution properly and if you don't have the freedom to fix potential security issues, then it a serious liability to include them and vendors have to take such things into consideration for inclusion of any components. This isn't a theoretical or philosophical problem. One example

https://rhn.redhat.com/errata/RHSA-2008-0812.html

Your sarcasm (not thinly veiled really) is unwarranted and unnecessary in this case. . Yes, it is true that Red Hat might include licensed components in a extras repository if there is a sufficient demand for it however my point was that it will never be in the main repository and it is not possible to ignore legal and technical issues regardless of whether end users care about them.

[yogi_berra]

There is actually a legal/technical twist to the Fluendo MP3 codec. Even though the code is under the MIT license, the patent grant limits modifications. If you do any modification to the codecs, you lose the patent grant and the code has a potential security issue that needs to be fixed (https://core.fluendo.com/gstreamer/trac/ticket/24 ). I am unaware of whether this reason is enough to avoid including it but things are not always what they seem at first glance.

Oh sure someone at the F$F would take issue with distributing it like they currently do with Fluendo, but that wasn't my point.

The point of my thinly veiled sarcasm was that Red Hat is clearly able to afford a license to any codec they would want to distribute and could do so easily if they chose to. They don't as there is no market for mp3 or DVD playback on workstations and servers.

But if it helps you can tell your Bosses that doing so would be a good excuse to jack up subscription fees.