Hi, On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller <t....@zen.co.uk> wrote: > You tell people not to worry. But many people clearly do seem to worry.
Well, why don't these many people post a rational response to my points? I have not seen a rebuttal to http://mail.gnome.org/archives/gtk-devel-list/2009-April/msg00008.html If it's a legitimate concern then someone specific will turn up and make a rational argument that's responsive to the points I made. As far as I'm concerned, libdbus's license situation is the same as that of glib itself, because it's effectively the same as LGPL. And guess what - the same bankrupt company that contributed to libdbus contributed to glib and gtk, too. Plus hundreds of other people. libdbus at least has relicense permission for every bit of code except the codefactory bits. If someone wants to do something productive, it would be great to add to dbus/COPYING a note that all new code, and almost all existing code, is MIT/X11. So if we do solve the codefactory code through rewriting some files, the rest is all already relicensed. Otherwise it isn't clear what license new patches are going in under. My only question here is whether there were any missing relicense responses other than the codefactory one. > It seems to me that by making GLib, the cornerstone of our platform, > depend on libdbus, we'd be creating a fair bit of uncertainty Only because people have a whisper campaign about how there's some unclear problem, when they (afaict) are just wrong. I don't see a reason we should care about how "some people" have some unspecified, unexplained (and as best I can figure, flat wrong) worries; and these "some people" are not turning up. If someone shows up and actually makes a convincing argument, that's different. Even if there's a problem, which one sounds easier: * replace the parts of libdbus that CodeFactory wrote (which are really not that large.) * reimplement the entirety of libdbus and dbus-daemon and port everything using them I would advocate lazy-replacing the codefactory code at the point that it is clearly a practical issue. Which will be never. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list