Rahul Sundaram wrote: > Bernard Johnson wrote: > >> Thank you for the clarification. The only problem I see, if I >> understand you, is that the mp3 codec is sole-sourced to Fluendo. I >> understand that Fluendo is the only vendor to providing a legal >> alternative today, but we should have the ability to allow multiple >> vendors at that step. > > We do it this way because > > * Fleundo is the company that employs many (most?) of the gstreamer > developers that provides us with a Free multimedia framework. This is > one way of acknowledging their efforts. For the record, I am not against this at all... but * Hewlett Packard is the company that employs many of the hplip developers that provide the free hplip software. This software supports 1100+ printer models. > * It is a gratis solution and a commonly requested feature. The hplip software is GPL and not intentionally feature-limited in any way. One must assume that if you want to print to your HP printer, it would be a commonly requested feature given the market penetration of HP. (It was important enough to include at FC-4 anyway) > * If we provide redirects it is just a additional step over making it a > click through option which is more usable. Like you said there really > isn't any choice of vendors to provide the same feature and providing a > theoretical level playing feature for a gratis component does not appear > to important as opposed to the usability advantage at this point. There are no vendors that provide the same level of functionality as the hplip software. > If there are other vendors in the future we can reconsider what we need > to do. The hooks for codec buddy are already in upstream gstreamer, > nothing is hard coded and we can change this very easily. Today, we do not allow the hp-toolbox to have an icon on the menu. Now, I do not disagree with the direction taken with CodecBuddy (this I stated in my original email). I very much disagree with lack of impartiality between vendors who are both supporting Linux. Given that the original argument against the hp-toolbox menu item was because it was advertising, the Fluendo agreement goes /far/ beyond that. I should also point that that the "advertising" HP gets has no directly -tied revenue (ie. it doesn't not direct anyone to a website to purchase anything). At the same time, Fluendo will directly profit from the CodecBuddy tie-in. And please, before anyone goes down the "but I don't like the HP software" rant road, get a reality check. Show me software that can be used to get the same functionality. We told HP that we wanted Linux support, and not only did they give us printing support, they supported the whole MIO ball of wax. As far as I understand it, they are also paying for the continued development of the software AND support in the newsgroups. Compare that to Broadcom(wireless)/Nvidia/ATI who we also asked to support Linux. Two companies gave us blobs and said "trust us, it's great software!", while another said "get bent"[1] and the only reason we have support at all today with this vendor is because someone reverse engineered the chip and developed the ability to load a firmware blob. All the "free software zealots" say to vote with your pocketbook. I did. I bought a $1000 SOHO printer BECAUSE THEY HAD LINUX SUPPORT. And not just a blob, real GPL software. Now I hear total bogus arguments like "it's advertising" [but don't look at these other things that are advertising as well that we will let slide] or "yeah, it's free but it's not good enough"[2][3]. This is exactly the attitude that will cause Linux to not get any support by vendors. The fact of the matter is that it takes vendor support to make Fedora/RedHat anything other than a toy operating system for many uses. At many junctures, we have to make conscious trade offs between idealogical beliefs and functionality. That trade off may be a little recognition of the hard work that someone / some company put into the software, and I say that's great, give it to them. But to actually go out of your way to make it harder for the end-user it beyond comprehension. There are already multiple bugs filed on this issue, and I would have filed one too had I not looked at the spec file. It's not like Linux doesn't have enough hurdles (potential patent pitfalls, trademark issues[4], brand recognition, user-base fragmentation, etc), let's not create more problems just for the fun of it. [1] That wasn't the real response, but since they are ignoring the issue, it's clear that they don't care. [2] Where "good enough" seems to be based on idealism and by people who don't even use the software. [3] I can consistently break the bcm43xx stack, but you don't see me screaming that it sucks and we should disable it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233729 [4] See my response in this thread regarding potential bluetooth problems. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
