Re: [Muine] Re: Muine (!) Relicensing

[Jorn Baayen <jbaayen gnome org>]

On Mon, 2005-01-10 at 23:38 -0800, Tamara wrote:
> > > I have been thinking about (in the long-run) splitting off
> > > "MusicManager" and "MusicPlayer" (names I just made up) from Muine
> > > into separate apps which we could communicate over D-Bus and which
> > > other music-playing apps, such as RB, could also use. I asked RMS if
> > > licensing these two apps as LGPL would solve the issue.
> > 
> > I'm sorry, but argh, no. :) There is such a thing as over-engineering.
> > Muine is just a music player, nothing more. And I really, really, don't
> > want it to ever become bloatware. Why I started to write Muine is to
> > have a simple, lean player with a decent, comfortable interface, and no
> > bloat. Having a separate "music player backend" would in my opinion be
> > majorly overkill, not to mention how it would bloat the d-bus.
> 
> Splitting off "MusicManager" and "MusicPlayer" would *reduce* the size
> of Muine and make it *simpler*. It would also be a plus for Beagle as
> well as RB. I would be doing it for the reason of simplification and
> reducing bloat.

It would only take out the few hundred line Player.cs, not something I
would call a considerable reduction ..

> "MusicManager" would take the place of all the database functions,
> reading metadata, and album / cover management. "MusicPlayer" would be
> a simple front-end to GStreamer and Xine (or possibly just GStreamer).
> 
> We don't have to use D-Bus, I just used that as an example. There are
> other ways of serializing data, such as SOAP, but I think D-Bus is
> best and much easier than SOAP.

Yea, but either way, it is bloat for something that is already way
simple. I mean, basically all we need to do for GStreamer playback is to
create a 'playbin' element. Why should this 'playbin' element be
embedded in all kinds of fluff, and thereby creating regressions for all
the using apps as well? (non-instant depausing (see later in this mail)
is the first to spring to my mind)

> It wouldn't send that much data over D-Bus anyway, just status changes
> and exceptions. You wouldn't have to update it every second or
> anything like that.
> 
> "MusicManager" and "MusicPlayer" could possibly be one app to
> eliminate the confusion :-).
> 
> Also, those aren't the real names :-)
> 
> It may also be useful to have them be MediaManager and MediaPlayer if
> it wouldn't be too hard...
> 
> > The "MusicPlayer" would have to be quite sophisticated for starters,
> > because you need to support having more than one stream open at a time
> > (for instance one from muine paused, and one from your-random-other-app
> > playing, for instance). Etc.
> 
> You wouldn't need more than one stream open at a time. If the user
> wants to play two song simultaneously (e.g. mixing), then MusicPlayer
> would be not the right place to do that.
> 
> Starting playing in one app would pause it in the other. To resume,
> the app would just send the play request and the position to start
> playing at.

Yea, I know that seems possible in theory. But in practice it is very
hard or impossible to seek back to *exactly* where you left off in the
case of VBR files, and it's not exactly responsive if you have to open
and decode the file first. 

Really, as every app has their own playback requirements, it is much
better for them to talk to GStreamer in their own way. For instance, an
internet radio player will have much different requirements from a
regular player.

I've been working a little on an iradio player in the spirit of Muine,
and the thing I'm thinking of doing is sending a signal to the bus,
something like "MusicStartedPlaying". Which the other app would pick up,
and subsequently pause their stream.

> This is all just conjecture, I'm not thinking of doing this anytime
> soon. I'm still working on abstracting the classes in Muine right now.
> Since both these apps would be under LGPL (for the reason of GStreamer
> use), Muine could remain GPL.
> 
> The more code under GPL, the better.
> 
> > > Before making any licensing changes, I want to wait to see how the
> > > GStreamer community is moving. We cannot relicense without consulting
> > > *all* of the GStreamer developers from the past. It is a developers
> > > right to choose the license that their work will be distributed under.
> > 
> > GStreamer? We're of course not talking about relicensing GStreamer or
> > anything. If you meant Muine, the number of contributors to Muine isn't
> > that big, and we can easily find out from the changelog, and mail
> > everybody.
> 
> Just a typo. My point was relicensing isn't that easy. It's also not
> usually very popular. Legally, if someone doesn't reply or disagrees
> then we don't have their consent to relicense and we cannot relicense.

Well, like I said earlier, in the case of Muine it is very doable
because we have the e-mail addresses of the handfull of contributors at
hand.

> I'm not saying I will refuse to have my code relicensed but I still
> want to wait and see what happens. This is not an area we need to be
> first in.

Okay.


Jorn