[64studio-devel] [64 Studio] #152: Drop terminatorx package from base install, remove dummy libmad

[Free Ekanayaka]

|--==> Daniel James writes:

  DJ> Hi Free,
  >>For these reasons I still think that the libmad dummy package is a
  >>good compromise

  DJ> In that case, there's a couple of things we need to do:

  DJ> 1. Change the package description of our dummy libmad to make it clear
  DJ> that this is a non-functional version due to software patent
  DJ> enforcement, and that users should replace it with a real libmad
  DJ> package from Debian if they wish to have MP3 support in dependent
  DJ> applications.

Done.

  DJ> 2. Always version the package so that if people have a Debian apt
  DJ> source, the version in Etch won't be replaced by our package. I think
  DJ> this is OK at the moment, we have 0.15.1b-1.64studio2 and Etch has
  DJ> 0.15.1b-2.1

Yes, the trick is to have the debian version greater than ours, so
that if the user installs, it won't be replaced again by our package
when upgrading.

  >>As for now I've fixed the libmad dummy package version included in the
  >>last 1.3.0 release, it now behaves better and both terminatorx and
  >>alsaplayer will just think that an empty MP3 file was selected.

  DJ> Thanks, terminatorX isn't freaking out any more :-)

  >>We should probably state clearly in a very visible place that we are
  >>supporting MP3 playback only via gstreamer, and include some
  >>instructions on how to get the libmad0 package from Debian as well.

  DJ> I agree, especially in light of:

  DJ> http://www.pcpro.co.uk/news/112099/judge-approves-microsoft-mp3-patent-damages.html

  DJ> It's not likely that these patent pirates will go after small free
  DJ> software companies, but unfortunately we can't rule out the
  DJ> possibility that they might. Even defending against an ultimately
  DJ> unsustainable patent claim costs a great deal of time and money.

True enough.. :/

  >>Generally speaking it could be a good idea to write a page (and
  >>perhaps some ready-made script) indicating users what do they have to
  >>do in order to get "unofficial" support for technologies that we can't
  >>officially support, like ffmpeg, MP3, VST, etc.. I don't know if this
  >>would be legally and morally acceptable, but it would probably make
  >>the difference for many users that do actually need those things, and
  >>can't use 64 Studio without them.

  DJ> That would be useful for users, but I'm reluctant to turn too much
  DJ> spotlight on the sites that do provide these packages, in case it
  DJ> helps the patent lawyers track them down - it's a difficult situation.

This is also true, however this kind of easydebian or or easy64studio
script would just automagically download components from "somewhere",
without shouting out "hey I'm using Marillat's repo!".

Anyway if we wanted to offer such a script it would be better to not
use third-party repos directly, as we don't have control over them and
they might break from time to time.

  DJ> One solution for MP3 would be to create a drop-in replacement for
  DJ> libmad that uses Gstreamer with Fluendo's licenced plugin. I don't
  DJ> know how it would compare performance-wise.

  DJ> VST is a different case from MPEG codecs, because the VST headers are
  DJ> legally available as a free download from Steinberg; they're just not
  DJ> GPL compatible.

What do you thing about trying to contact Steinberg and ask them to
allow re-distribution of those headers? That would make possible to
build and distribute a fst package.

Ciao,

Free