GNOME Bugzilla – Bug 513612
gst-props should be LGPL or have GPL exception
Last modified: 2015-01-20 13:50:25 UTC
gnome-sound-recorder is a GPL program that allows you to record files, but also play them back. Therefore you can use gnome-sound-recorder to play files in formats like MP3. Normally the GPL doesn't allow GPL programs to link in library plugins that contain IP, like the MP3 GStreamer plugin. Totem has a GPL exception that allows the usage of such plugins. Refer here: http://svn.gnome.org/viewvc/totem/trunk/license_change?revision=4301&view=markup Would it be possible for gnome-sound-recorder to also have such an exception added so it can be distributed on systems with GStreamer plugins that contain IP like the MP3 plugin?
Also, gnome-media's shared-library bits for the profiles probably need relicensing as well.
ok, I put the 2.24 milestone. Bastien, how did you relicense totem? You look at all the headers/copyright holders of the GPL files and send them a mail? I'll add some people to the CC list of this bug to discuss it.
Iain, Jan, Leif, Johan, Tim, Thomas, raise your hands please :)
NO! Muhahahahaha, oh all right then, relicense away (assuming everyone else agrees)
Fine for me. (which is unsure bugzilla is the proper medium to do a license survey)
No problem here.
(In reply to comment #2) > ok, I put the 2.24 milestone. > > Bastien, how did you relicense totem? You look at all the headers/copyright > holders of the GPL files and send them a mail? I'll add some people to the CC > list of this bug to discuss it. FYI, I think you're missing a _lot_ of contributors here. You need to check the ChangeLogs for every non-trivial code submission. So Bugzilla probably isn't the best place to do this...
(In reply to comment #7) > (In reply to comment #2) > FYI, I think you're missing a _lot_ of contributors here. You need to check the > ChangeLogs for every non-trivial code submission. So Bugzilla probably isn't > the best place to do this... > Contributors are also copyright holders? If they are not in the copyright, do they need to be contacted? How many people did you contact for totem? How? I don't know how to proceed: I think Bugzilla is better than personal mails or ml, there is a trace :). Do you have a better idea?
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #2) > > FYI, I think you're missing a _lot_ of contributors here. You need to check the > > ChangeLogs for every non-trivial code submission. So Bugzilla probably isn't > > the best place to do this... > > > > Contributors are also copyright holders? Yes. > If they are not in the copyright, do > they need to be contacted? Yes. > How many people did you contact for totem? How? None, Christian did it, but I did the work for the relicensing of the gedit/ephy/etc. plugin system for use in Totem and Rhythmbox and contacted about 25 people. Remember it's only non-trivial contributors (one-line fixes don't really count...). > I don't know how to proceed: I think Bugzilla is better than personal mails or > ml, there is a trace :). Do you have a better idea? Use personal mail, and save all the files in an mbox and attach it here...
(In reply to comment #9) > (In reply to comment #8) > > > > Contributors are also copyright holders? > > Yes. > > Use personal mail, and save all the files in an mbox and attach it here... > Ok, I'll do that.
I just reviewed the gnome-media code. It seems like there is some mix of licenses in this code. The top-level COPYING file says "GPL". However, some components of gnome-media are "LGPL". The following is some detail from looking at the licenses in the c/header files of each sub-component. The following parts of the module seems to be under the "GNU Library General Public License version 2, or (at your option) any later version" - gnome-sound-record (grecord) - profiles - gst-mixer (though misc.c is missing a license header) - profiles - vu-meter While these parts of the code seem to be under the GPL: - cddb-slave - gstreamer-properties This code has no license in the c/header files, so I assume it defaults to GPL since the top-level COPYING file says GPL. Not sure. - gnome-cd My understanding is that there is no problem with LGPL code linking against GStreamer. Correct me if I am wrong, but I do not think we need to worry about relicensing any of the code that is already under the LGPL. Further, we only need to worry about relicensing code that links against GStreamer (and thus possible GStreamer plugins which may contain non-free IP). Looking at the code, the following components use GStreamer: profiles, grecord, gst-mixer, gnome-cd, and gstreamer-properties. In other words, I think we only have issues with gstreamer-properties and gnome-cd. Going Forward ------------- It might be nice to work towards making the entire gnome-media library more clearly LGPL. This is more appropriate, I think, for library code and code that links in GStreamer. - gstreamer-properties looks like the only component which is GPL, used by most distros, and which links in GStreamer. I think this may be the only component we really need to address. Note there isn't a lot of code to gstreamer-properties. It might be feasible for someone to just rewrite it if we find relicensing is difficult. - There has been talk about removing gnome-cd from the module, and it is now disabled by default. In light of this licensing issue, I think it might make more sense to just remove it from gnome-media rather than worry about relicensing it. It could move into a separate module, rather than clutter up an otherwise LGPL module with GPL code. - The only other GPL code in the module is cddb-slave. I do not think the cddb-slave code is linked into any programs that also use GStreamer. Is this correct? If so, then there is not a strong need to relicense this code to LGPL. However, if we are going to the trouble to relicense gstreamer-properties, then it might make sense to work towards relicensing this code as well, so the entire module could be under the same LGPL license. Or we could consider moving it into a separate module. Thoughts? Does this make sense?
Yes. Also, gst-props is only by Thomas with some additions by me and Jan, so permission from ys three is sufficient. I'm OK, so is Jan it seems, so you only need Thomas.
Created attachment 108004 [details] Stats of .c files committers, for the whole gnome-media
Created attachment 108005 [details] stats over the .c files of gst-props
Created attachment 108007 [details] stats of the .c files in gst-props
cddb-slave and gnome-cd don't need to be LGPL, or GPL+exception. Gstreamer-properties should definitely have the exception though.
gnome-cd does use GStreamer. So, if it doesn't have an exception then you can't distribute it with GStreamer plugins that contain IP. Perhaps you mean that since gnome-cd is now disabled by default, it isn't really so important. This is true. However, the problem does exist for gnome-cd for any distros who want to ship with it. In short, it would be nice if gnome-cd could also be relicensed, but not a high priority since most distros don't ship it. I agree cddb-slave doesn't need to be LGPL, unless there is a desire to make the entire module under the same license.
(In reply to comment #17) > gnome-cd does use GStreamer. So, if it doesn't have an exception then you > can't > distribute it with GStreamer plugins that contain IP. How so? That would mean that every GPL program you ship with GNOME would need to be relicensed as well, no? gnome-cd only uses components that are LGPL/GPL (such as cdparanoia), so the only case in which you'd need the relicensing would be for a proprietary output medium.
Agree with Bastien. An application which is not able to access any non-GPL compatible plugins would not be affected by any licensing conflict with for instance a proprietary GStreamer plugin.
Oh, so you are saying that although gnome-cd uses GStreamer, it does not use any non-GPL compatible plugins. So, since it doesn't actually use such code, there is no need to worry about GPL licensing issues for it. One problem with gnome-cd being GPL is that it is limited in terms of how it can be enhanced. If gnome-cd were to have a future, it might be a good idea to add CD ripping features to it so it is more competitive with other programs like sound-juicer. You obviously couldn't support ripping CD's to mp3 format with a GPL program, for example. However, it seems gnome-cd is dying anyway, so I am not sure it's worth spending time making changes to it. I just wanted to highlight that making gnome-cd GPL wouldn't necessarily be completely pointless. I'm a little confused by Bastien's statement that "This would mean that every GPL program you ship with GNOME would need to be relicensed as well, no?" In response, I don't think so. Only those programs that use in GStreamer in a way that can make use of non-GPL compatible plugins. As has been stated above, making gstreamer-properties LGPL is, I think, higher priority and more critical.
Sorry, I meant to say that "making gnome-cd LGPL wouldn't necessarily be completely pointless"
I'd say that there's still a little fuzzy ground in the argument about applications-only-using-non-proprietary plugins. It's still technically possible (if the GST_REGISTRY_FORKING=no env var is set, or the home-dir is read-only, or some other scenarios) that the plugin scanning code will load plugins into the same address space, which would technically violate the GPL. It's pretty fuzzy ground though - none of the *features* of the GPL code would be exercised (probably), but the code would be loaded. However, it's also unlikely to happen - the default registry loading method is to do it all in a forked background process, which insulates the app under the terms of the GPL anyway.
Running is not illegal. Shipping the combination is illegal.
(In reply to comment #23) > Running is not illegal. > > Shipping the combination is illegal. > Is that a reply to my comment? Assuming it is: You're correct, of course - it's distribution of combined works with incompatible licenses that's problematic, but it's how they *run* together which defines whether or not they're combined works. The part that's fuzzy to me is probably not fuzzy to a lawyer familiar with the GPL/LGPL: whether the fact that gnome-cd (GPL) can accidentally load a proprietary plugin via registry rescanning changes solely for cataloguing the available features of the plugin changes the distribution situation from mere-aggregation to combined-work status. I *think* it does, even though *usually* plugin loading is done in a forked sub-process (which is allowed under the GPL). The solution lies in either re-licensing-with-exception, or ensuring that the code avoids the situation by *always* forking to rescan plugins (ie, changing GStreamer).
On the other hand judges tend to approach things with an aim of being rational and reasonable in how to interpret a contract/the law. So in context of playing hobbyist lawyers here one should probably be extremely unlucky to find a judge who would decide that a due to this registry generation, a distribution making company would have violated the license of gnome-cd-player. So maybe we should just let these extremely hypothetical issues lie until a gnome-cd-player developer complains and ask that gnome-cd-player is removed from distro xyz due to feeling his copyright is being violated.
We should focus on gst-props and get it relicensed to LGPL or to include the GPL exception, since most distros actually ship this program. It would be best, I think, to simply relicense it to avoid further concern or worry in this area. Also, it doesn't seem that gst-props has many authors, so getting permission to relicense shouldn't be too difficult, I think. ----- Regarding gnome-cd, I was only trying to highlight that relicensing gnome-cd might have some merit. As I said, it might add value if it could be enhanced to support CD ripping. Adding this sort of feature could run into IP problems since many people like to rip to formats like MP3. That said, I agree that we should ignore gnome-cd for now. It seems to be dying anyway. Most distros aren't even shipping it because it isn't useful. To be honest, it might make sense to move gnome-cd out of gnome-media and into a separate module for those people who want to continue using this legacy code. Let's shelve the gnome-cd discussion until we get gst-props licensing resolved. Does this seem reasonable?
I note that the COPYING file in gnome-media specifies the module is under GPL. Shouldn't this be updated to reflect that different subparts of gnome-media are LGPL and others are GPL?
Any update? It sounds like relicensing gst-props is something we are close to doing. I think this would be a real nice step in fixing the overall GNOME media licensing story.
(In reply to comment #16) > cddb-slave and gnome-cd don't need to be LGPL, or GPL+exception. > Gstreamer-properties should definitely have the exception though. May I ask why gstreamer-properties needs to be relicensed or have the exception clause? What am I missing here?
Like other programs which use GStreamer, it is not possible to distribute a GPL'ed program that links in a non-GPL compatible GStreamer plugin. It would be nice if GNOME supported GStreamer in a way that allowed people to distribute popular non-free plugins (such as MP3, MPEG-2, MPEG-4) if they have license to do so. Note that gst-props has "Test" buttons that you can use to test various sinks and sources, or a pipeline that the user can specify. Since it is fairly easy to specify a pipeline that contains a non-GPL plugin, it is not appropriate to distribute gst-props with non-GPL compatible plugins. Furthermore, it would possibly be useful if people could write non-GPL compatible sink/source plugins (which they could test in the gst-props GUI) if they want or need to make GStreamer work with some proprietary audio/video device, for example. In other words, adding such an exception makes GStreamer in GNOME more flexible and makes it more friendly for audio/video device manufacturers to integrate with GNOME. Also note that even if gst-props doesn't use any non-GPL compatible, it is debatable whether the registry process which happens every time you run a GStreamer-enabled program and loads all plugins (including non-GPL compatible ones) should mean that all GStreamer programs that are distributed with a non-GPL compatible program should have such an exception or be under LGPL or other license which allows non-GPL compatible plugins. For the avoidance of doubt, it's better to simply relicense with an exception I think. Especially for a program like this which is intended to be a basic GStreamer configuraiton program that all distros should ship.
While I don't mind relicensing gst-props and the registry argument is nominally relevant please do not argue with things like 'Since it is fairly easy to specify a pipeline that contains a non-GPL plugin, it is not appropriate to distribute gst-props with non-GPL compatible plugins.' That argumentation starts coming close to saying that since open source applications can be so easily changed then any since GPL application can be changed to use non-free software shipped with a distribution they should be treated as if they are linked and thus violates the GPL.
I did not mean to suggest that changing gst-props is necessary to link in a non-GPL compatible plugins. If you pick "Custom" for sink/source, then the gst-props program provides an entry field where users can enter arbitrary pipelines. It seems the expectation is that if I have my own sink/source I can test it via gst-properties program by entering the pipeline of my desire. There is not any need to change the source code, recompile, or anything to easily specify a pipeline that might include a non-free plugin. Especially when you consider that it is possible for end-users to create (or want to create) non-free sink/source plugns. It just seems sensible to make gstreamer-properties have a GPL exception or be LGPL since it is the tool you use to configure your default sink/source plugin, and (in the future) some distros may want to distribute non-free default sink/source plugins.
gnome-media has been obsolete since the release of GNOME 3, nearly 4 years ago. Furthermore, the gnome-sound-recorder program in gnome-media has been replaced by the stand-alone, rewritten, gnome-sound-recorder program which has a different interface. This relicensing should not be necessary anymore.
Gone but not forgotten!