Hi, On Thu, Apr 2, 2009 at 7:05 PM, Ryan Lortie <de...@desrt.ca> wrote: > - How does it fit with gobject-introspection? > - Do we need code generation?
I'm on the same page with you here, but I think the fix is to split the object mapping from the other pieces (as outlined in my long manifesto previously). Then go ahead and get the other pieces stable and usable, and give the various object mapping ideas and codebases some more time to settle. > - What of the license issues? > GLib is LGPL. libdbus-1 is not. The recent attempt to relicense > libdbus-1 failed spectacularly due to copyright in a large chunk of it > having been acquired by a bank (or something?) when CodeFactory AB > folded. Just for the record, my comment on this has always been that the license issues were not earth-shattering to begin with, and the relicensing was just throwing a bone to people who cared. Not sure "large chunk" is super accurate, either. As a practical matter this topic is highly overblown. Nobody has yet explained (to my satisfaction anyway) how the libdbus license has an issue the LGPL does not have. Perhaps we should get Luis or SFLC on the case, but I'm not sure it's worth their time. http://log.ometer.com/2007-07.html#17.2 3 points here. 1. AFL+GPL is the same as LGPL+GPL in the case people are complaining about. LGPL is a dual-license - the part that's the LGPL itself, OR you can choose GPL. The part that's the LGPL itself is not GPL-compatible - it's a totally different license. That's why it gives you the choice of GPL instead. libdbus is the same way, but it's choice of AFL (much less restrictive than LGPL) or GPL. Remember, when you link a GPL program to an LGPL library you are using the library under GPL. Same if you link a GPL program to dbus. The difference between dbus and an LGPL library arises only if your program is *not* GPL. You have to choose whether you want LGPL or GPL when using GTK, and AFL or GPL when using libdbus. You can't say your program is using both choices. You have to choose. If a program is GPL+Exception, I don't think you can choose GPL for an LGPL library. You have to use the LGPL terms. This means, however, that your program must, in its exception, allow linking to the LGPL library. It could also allow linking to an AFL library, if so. If your exception doesn't allow this, then your program's GPL terms require that the library be distributed under GPL... but if the library is GPL, you can't have the exception. So GPL+exception is not compatible with an LGPL library unless the exception includes LGPL libraries. 2. It's unclear that the AFL2.1 is GPL-incompatible. GPLv2 is hard to understand on this topic, so it's hard to know. GPLv3 may be clearer. But as generally understood, if you distributed libdbus under either GPL version, you'd be licensing your patents under GPL. All AFL2.1 requires is that if you sue *with respect to libdbus* claiming libdbus infringes your patents, you can't distribute libdbus. But distributing libdbus under GPL requires you not to sue with respect to libdbus. So in practice, there is no situation AFL adds further restrictions over GPL. The GPL already prevents you from suing for infringement claiming that libdbus infringes your patents, *while distributing libdbus yourself*, because distributing libdbus yourself necessarily licenses your patents. There is no way, under either GPL or AFL, to distribute libdbus while simultaneously suing users of libdbus saying libdbus infringes your patents. The licenses agree on this. As does LGPL for that matter. So the situation where 1) AFL keeps you from doing something and 2) GPL allowed you to do that same thing, does not ever exist. As a result, I don't think there's a "further restriction." To me "further restriction" means "prevents something the GPL allowed me to do" and the AFL does not do so. AFL is pretty much an MIT/X11 license and an extremely liberal and toothless patent clause (compared to the GPL's patent requirements). 3. There's no practical issue, even if there's a theoretical one (which I don't think there is) _Even_ if I'm wrong on the theory (IANAL), the case where it even _matters_ is that some non-software company who owns the assets of a small business (codefactory) that went bankrupt years ago, somehow opens a musty old file, cross-references it with open source forums on the Internet, realizes they could disrupt the distribution of something called "Rhythmbox," goes to lots of legal time and expense to do so... and then we either rewrite the Anders-written code in libdbus, or add an exception to the GPL in Rhythmbox, or relicense Rhythmbox to GPLv3, or some other solution, and we solve the problem. There are many things to worry about in life, but this is not one of them. btw, I believe we were going to add a notice to COPYING in libdbus to the effect of "all new code is also MIT/X11, and most code is MIT/X11, but a few bits are GPL/AFL" so that new contributions are MIT/X11 and we don't have to redo the relicensing mass email if we ever solve the codefactory code. It doesn't look like this has been done, however. Havoc >From the LGPL, why it's OK to link a GPL app to an LGPL library: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list