Re: GLib plans for the next cycle


On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller <t i m 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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]