That doesn't answer my question: why is there only non-free software in it? Note, please, that the Fluendo plugin as shipped by Fluendo is _also_ non-free (non-redistributable) since it contained patent rights.
Free software would be the non-patent-mentioning MIT-licensed plugin or the ffmpeg/mad decoders as found in gst-ffmpeg or gst-plugins-something.
26 March 2007 at 13:20
Anonymous said...
It would be useful if the codec buddy could download the Free solutions (like -ffmpeg or plugins-ugly/bad) from gstreamer repositories. Or at least offer them as an option.
It explains what you complain about. No, we can't put pointers to gst-ffmpeg or gst-plugins-bad in Fedora. People who know won't be seeing this dialogue anyway.
I did read CodecBuddy. The main problem that I have with it is - again - that it promotes and advantages non-free software.
Now, you're going to ask: what else can we do? And it's really fairly simple. For one, you could offer free solutions such as gst-ffmpeg if the user has added universe (ubuntu) or rawhide (fedora) to his repositories. This way, you're not litigable, because you didn't do that. However, by doing that, the user accepted his responsibility and CodecBuddy can now offer the superior (merely by being ~) free solutions.
I would argue that the user would actually have to explicitely enable the closed-source, non-free, proprietary repositories before CodecBuddy would show them, but I can sort of feel that I'm fighting against the wind here. I hope you agree that - regardless of what Fedora does - GNOME (and thus the totem shipped as part of ~) should definitely go that way.
And now don't tell me I didn't read CodecBuddy, please comment on what I say instead. I don't do this for crying out loud, I would like to see discussion on this subject.
26 March 2007 at 22:22
Anonymous said...
I second rbultje's comment entirely. I can understand if you don't feel Fedora can take the risk of pointing to ffmpeg, but:
1) If the user explicitly enabled a repository that has ffmpeg, and just hasn't installed ffmpeg, I see nothing wrong with telling them they could just install the packages they've already got available.
2) Similarly, if the user runs a distribution that ships ffmpeg in their default repositories, please support their using it.
27 March 2007 at 03:46
Anonymous said...
Unless you're hardcoding the solutions into the software there is no need for explicit references to ffmpeg. SUrely the software could send some query to the gstreamer server for "CodecFor:xxxxx" where xxx is the filetype (mpeg2layer3, wmv, aac, etc) and the server sends back a list of packages with explanations like:
Ogg: Free, open and patent free.
in the case of say mp3
MP3(ffmpeg): Free, opensource patent encumbered (not suitable in countries with software patents [click here for more] MP3(fluendo):Non-free, closed source, legally licensed in all countries [click here to purchase]
Legally I see no difference in this behaviour (installing ffmpeg via this method) than using the graphical yum tool to install livna packages.
You could even have a config on codec manager that had the following tick boxes: *Show free and open codecs *Show free but encumbered codecs [link to more info] *Show pay-for-use for codecs
You could have the first default to TRUE and the second two would be up to the distributor.
There is a great deal of responsibility for gstreamer. If major distributions are switching to the gstreamer backend then gstreamer have to make sure that while they provide codecs for use in the US they do not force US law on everyone. Forcing people to use a poorer sound system in a non-polished/non-major distribution (as I expect in time gstreamer will be number one in all main linux distros) is not offering real choice.
27 March 2007 at 08:12
Anonymous said...
Re: not hardcoding ffmpeg, I agree. I simply used it as an example. In general, the process should look exactly as you suggest: obtain a list of codecs with various qualifications.
27 March 2007 at 16:45
Comment deleted
This comment has been removed by a blog administrator.
17 July 2007 at 08:22
Comment deleted
This comment has been removed by a blog administrator.
2 August 2007 at 19:11
Ronald, that'd be because there's a bug in the code, and the free Fluendo MP3 plugin would be what shows up as the default in this dialogue. As Brian mentioned, the Codec Buddy page explains what this is about.
And the dialogue only shows what you need to download at first, I just changed the view so it looked a bit less empty.
"OMGKYHO!"
9 Comments -
That doesn't answer my question: why is there only non-free software in it? Note, please, that the Fluendo plugin as shipped by Fluendo is _also_ non-free (non-redistributable) since it contained patent rights.
Free software would be the non-patent-mentioning MIT-licensed plugin or the ffmpeg/mad decoders as found in gst-ffmpeg or gst-plugins-something.
26 March 2007 at 13:20
It would be useful if the codec buddy could download the Free solutions (like -ffmpeg or plugins-ugly/bad) from gstreamer repositories. Or at least offer them as an option.
26 March 2007 at 15:27
Ronald, again, you didn't read CodecBuddy
It explains what you complain about. No, we can't put pointers to gst-ffmpeg or gst-plugins-bad in Fedora. People who know won't be seeing this dialogue anyway.
26 March 2007 at 19:48
I did read CodecBuddy. The main problem that I have with it is - again - that it promotes and advantages non-free software.
Now, you're going to ask: what else can we do? And it's really fairly simple. For one, you could offer free solutions such as gst-ffmpeg if the user has added universe (ubuntu) or rawhide (fedora) to his repositories. This way, you're not litigable, because you didn't do that. However, by doing that, the user accepted his responsibility and CodecBuddy can now offer the superior (merely by being ~) free solutions.
I would argue that the user would actually have to explicitely enable the closed-source, non-free, proprietary repositories before CodecBuddy would show them, but I can sort of feel that I'm fighting against the wind here. I hope you agree that - regardless of what Fedora does - GNOME (and thus the totem shipped as part of ~) should definitely go that way.
And now don't tell me I didn't read CodecBuddy, please comment on what I say instead. I don't do this for crying out loud, I would like to see discussion on this subject.
26 March 2007 at 22:22
I second rbultje's comment entirely. I can understand if you don't feel Fedora can take the risk of pointing to ffmpeg, but:
1) If the user explicitly enabled a repository that has ffmpeg, and just hasn't installed ffmpeg, I see nothing wrong with telling them they could just install the packages they've already got available.
2) Similarly, if the user runs a distribution that ships ffmpeg in their default repositories, please support their using it.
27 March 2007 at 03:46
Unless you're hardcoding the solutions into the software there is no need for explicit references to ffmpeg. SUrely the software could send some query to the gstreamer server for "CodecFor:xxxxx" where xxx is the filetype (mpeg2layer3, wmv, aac, etc) and the server sends back a list of packages with explanations like:
Ogg: Free, open and patent free.
in the case of say mp3
MP3(ffmpeg): Free, opensource patent encumbered (not suitable in countries with software patents [click here for more]
MP3(fluendo):Non-free, closed source, legally licensed in all countries [click here to purchase]
Legally I see no difference in this behaviour (installing ffmpeg via this method) than using the graphical yum tool to install livna packages.
You could even have a config on codec manager that had the following tick boxes:
*Show free and open codecs
*Show free but encumbered codecs [link to more info]
*Show pay-for-use for codecs
You could have the first default to TRUE and the second two would be up to the distributor.
There is a great deal of responsibility for gstreamer. If major distributions are switching to the gstreamer backend then gstreamer have to make sure that while they provide codecs for use in the US they do not force US law on everyone. Forcing people to use a poorer sound system in a non-polished/non-major distribution (as I expect in time gstreamer will be number one in all main linux distros) is not offering real choice.
27 March 2007 at 08:12
Re: not hardcoding ffmpeg, I agree. I simply used it as an example. In general, the process should look exactly as you suggest: obtain a list of codecs with various qualifications.
27 March 2007 at 16:45
This comment has been removed by a blog administrator.
17 July 2007 at 08:22
This comment has been removed by a blog administrator.
2 August 2007 at 19:11