Yes, agreed.

Let's start the relicensing fun with Bastien and Ronald.  Do you agree?

Fine by me. gnome-media's shared-library bits for the profiles probably need relicensing as well. Brian, could you file a bug?

I only contributed the volume slider and some CD playback bits, right? The volume slider was always LGPL (and isn't that in Gtk+ nowadays?), so that's OK.

For the CD playback, I need to look at that patch and make sure I didn't do any straight copy-pastes from someone else. If not, it's OK with me. Make sure that whatever CD playback element I use is in fact LGPL also, hardcoding it to a GPL element would sort of defeat the whole purpose, because (by hardcoding it) you "include" GPL code (i.e. your code is not independent) and thus the runtime would probably be GPL (${IANAL}).

See bug 513612 for gnome-media relicising.

Right, it would defeat the purpose to use a GPL CDDA plugin, like cdparanoia or libcdio.  Unfortunately these are the only CDDA plugins in GStreamer at the moment.

Artem and I at Sun wrote a LGPL CDDA plugin that only uses ioctls and seems to work well enough on Solaris.  Nobody complained about loss of quality or anything when we switched from using libcdio.  Refer to bug 413705.  Perhaps a LGPL option should be included in gst-plugins-good as well, as suggested in that bug report?

The key thing is that it needs to not rely on GPL-only CDDA API. There's several ways to do that, but key is that the API is generic, LGPL, ideally there's a LGPL implementation (like yours) and there's no hardcoding of GPL parts.

GSt has plugin categories and such that can assist you in that, and the API is obvious enough, imo. The amount of code needing a patch in s-j is very minor (and since you have the LGPL impl, it seems like you're pretty much there already).

Any update on whether sound-juicer can be relicensed?

By the way, I understand that the Mozilla Songbird project is planning to add CD playback and ripping support.  They also use GStreamer, and they have a totem-like extension in their licensing already.

I suspect that if sound-juicer cannot figure out how to relicense, that on Solaris we will drop sound-juicer support and switch to using Songbird.  If sound-juicer is able to relicense, I think we would probably ship both.

Some contributors have not replied to my mails, I'll ping again.

Any update?

I'm fine with this.

I'm fine with relicensing any contributions I have in sound-juicer (though I'm not aware of any, really)

No problem with relicensing from me.

I agree on the licensing change

Fine with me.

Ok as well if I made significant contributions to s-j

No problem from me too.

Fine with me (also with regard to the gedit-message-area widget)

Any update on when the code could be relicensed or who still needs to provide approval?  It would be good to get this issue addressed.  sound-juicer is the only remaining GStreamer-based program that is commonly installed with GNOME that does not have this issue fixed yet.

List is here:
http://live.gnome.org/SoundJuicerRelicense

Fine with me.

Fine by me.  Thanks!

I agree on the licensing change (also with regard to the gedit-message-area widget)

paolo, talking about gedit-message-area, I was toying with the idea of adding a message area widget to gtk and basing it on that code. Would you be open to lgpl ?

Matthias: sure, feel free to relicense it to LGPL

Fine with me too.

Fine by me. The only recollection I have was to provided a fix to one of GUI :)

That's fine for me, I don't even remember what code I could write :)

Fine by me.

I agree on the licensing change

Fine by me.  I personally don't like the exception approach instead of using something like the LGPL, but I approve of your decision regardless.

Fine by me.

Fine to me.

I agree to relicensing of my (minor) contributions.

Fine with me.

I agree.

I agree.

Fine by me.

I also agree.

Agree

I agree.

Fine by me.

I'm fine with adding the same grant as totem in sound-juicer.

Fine with me as well, though my contributions were limited to small bugfixes IIRC.

I agree.

Fine by me.

While relicensing a Free application so that non-Free code can be used seems to be a step backward to me, my contribution is minor enough such that I don't want to block the effort. So I guess that's a "yes" from me.

I don't quite understand what sound-juicer needs that would require a non-Free plugin though... but that may be quite offtopic here.

Ka-Hing, just for the record, the main reason why relicensing sound-juicer with t
this exception is a good thing for many users would be that sound-juicer could be 
shipped with non-free audio codecs.

For example, MP3 audio or AAC are examples of non-free audio formats.  Some users 
may like to rip files from CD to these formats.  However, such support cannot be 
distributed with sound-juicer without this license exception.  Enhancing sound-
juicer so it has such a license exception gives distros the ability to distribute 
sound-juicer with such non-free media support if they desire (and if, of course, 
they also pay any associated licensing fees).

The licensing exception doesn't change the code from being GPL.  It is still
under the GPL after the license exception is added.  The exception just adds
a clarification that distribution with non-free GStreamer codecs is acceptable 
and not a violation of sound-juicer's license.

Note that the other major GStreamer-based media programs in GNOME (rhythmbox, 
totem, and songbird) all have similar license exceptions as proposed here.

Brian, please retract your "However, such support cannot be distributed with sound-juicer without this license exception.", this is not true. The "free"-ness of mp3 as a (patented) format can be questioned, but GPL implementations of mp3/aac (e.g. faac/lame), whether legally distributable or not, can be used with a plain GPL sound-juicer, there is nothing wrong with that.

Apologies if I caused any confusion or spread any FUD in my last posting.

As you say, the example of MP3 may not be a good one since, as you say, there is
some that debate whether it is a free format or not.  Regardless, having the
exception avoids any need to worry about such debate, and also ensures that
people can distribute sound-juicer with any non-free codecs they might desire.

I never intended to suggest that end users cannot build and use whatever GStreamer plugins they wish.  As you say, users can do this if they want.
I only intended to suggest that distributing sound-juicer with non-free media plugins can cause complications.  As you say, it is only an issue with distribution, not with using.  Also, since IP laws vary from country-to-country,
the distribution issues may not be problems in some places or for some users.

Also, I'm not a lawyer, so my opinions shouldn't be considered to have any real authority.  My main interest in seeing this issue addressed is simply to make 
sure that sound-juicer uses the same licensing that has already been approved for
other GStreamer-based media players, so that things are more consistent.

Fine with me.

I agree to the change.

I am not sure I agree with the way the issue is presented/framed; particularly the analogy between playback applications and encoding applications, but more generally the - as it seems to me - either conflation or confusion of multiple somewhat different issues. Or whether I'd want sound-juicer to be used in connection with proprietary encoders if it was 'my' application.

However, since my contributions to sound-juicer have been insignificant at best, I'm fine with the relicensing.

I think there are only 4 people who haven't yet given a positive response: 
Ed Catmur, Stefan Röllin, Christian Persch, and Juan F. Giménez Silva.

- Ed Catmur is only recognized in the ChangeLog for bug #172781.  By my reading
  of this bug report, he did not provide any code.  He seemed to just offer some 
  advice in the bug report, thus the Thanks.
- Stefan Rollin is associated with only bug #440400, and he only provided a
  1-line fix to avoid a crasher.
- Juan F. Giménez Silva is associated with only bug #522909 which added %y
  support to src/sj-extracting.c.  Not a major feature, and one we could perhaps
  consider ripping out if it isn't too important.
- Christian Persch seems the only outstanding person who has contributed more
  significant code changes.

Note, I have send two emails to all these people asking them to respond with 
their feedback, and no response yet.  One in early February and the second a few 
days ago.

I'm sorry for the late response, while I know my "contribution" *sigh* was rather unsignificant, I must have missed the email as I never thought my opinion would matter on such an important decision.

I agree with the proposal.

Fine for me.

(Sorry for the late reply - didn't remember that I contributed to sound-juicer.)

Presumably more people have been contributing to S-J since this list was created?

The current developers should add the exception to all the code except that belonging to the last two people, so that the problem doesn't get any worse when new people contribute.

Then, have another go at contacting Christian Persch. I wouldn't worry about Ed Catmur.

You are so close; don't falter now! :-)

Gerv
(who did the Mozilla relicensing!)

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/sound-juicer/-/issues/80.