[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-licensing
Subject:    Re: QT Designer _NOT_ under QPL.
From:       Joseph Carter <knghtbrd () debian ! org>
Date:       2000-08-19 17:25:33
[Download RAW message or body]

On Fri, Aug 18, 2000 at 05:58:18AM -0400, Kevin Forge wrote:
> > The questions that will come up:  Is it legal?  Is it clear?  Is someone
> > going to actually upload the package?  Beyond that, an individual
> > developer or even a small group of them aren't going to keep it out of the
> > distribution.
> 
> Of course not.  This is what I meant when I said no debian developers 
> really wants it in anyway.  kdelibs is legal.  It's clear and it would 
> act as a steeping stone to get other kde apps in.  Why go to the trouble 
> of changing your license if your app is out because the library you 
> depend on is taboo ?  Too bad the last hurdle for the libs is so high.
> Nobody wants to upload the package.
> 
> It's not even like there is a technical hurdle to jump, like with QT
> ( edit the configure script to _not_ seek out designer )

Again, it goes back to futility factor.  IF someone goes through the
hurdles to upload kdelibs, maybe some people migh possibly make other KDE
apps uploadable (even though they've said they would never do what we've
asked and that these same people we're being asked to trust are constantly
attacking us and the foundations of our philosophy - and has no intention
to stop doing either..)  Further, the KDE DEVELOPERS WHO HAPPEN TO ALSO BE
DEBIAN DEVELOPERS don't even feel it's worth uploading kdelibs it would
seem, or it would be there by now.  Why is that?  I can tell you why.
kdelibs will gain nothing in the long run.  Hell, it won't even gain
anything in the short run and you know it.

Why package a library without the software to use it?  KDE cannot be
packaged and absolutely nobody has any belief that anybody in the KDE
project actually wants to change that since you're all too busy attacking
the GPL and trying to get by on questionable technicalities Debian has
rejected completely for the past five or six years now.

Anyone who can attach a real name to their identity and isn't known for
attacking systems and other sorts of things which would be dangerous to
the project if we gave write access to Debian's archive can pretty easily
become a developer.  Why not package it yourself if you think it'll
actually help matters any?  And don't say it's because the package would
be rejected since you know otherwise.


> > At the moment at least, there is no question.  Qt is in main and apps like
> > licq are perfectly acceptable.  And according to a discussion on irc, the
> > package will be split into just Qt and just Designer (the latter likely
> > unpackaged) before that happens because there are too many people who
> > wouldn't want to see Qt go away because of it.
> 
> I see.  So we are not consistent about applying the letter of the law
> but rather about doing what is convenient for the people and packages
> we like.  That's cool.  Too bad all those demons are leaving hell for 
> warmer climes ( like Antarctica ).

No, you don't see.  And I am quickly losing any belief that you ever will.
Non-pristine source has been determined to be better than removing Qt by
those people who have Qt-using apps.  If the Qt maintainer wishes to do
this, he's welcome to.

Unless of course the QPL's patch clause (as much as I tried to get rid of
that in the QPL, someone decided to put it back in at the last minute
after I was "done" with it) prevents that from being done  I'll let the
package maintainer figure that out, I don't really care anymore.  A
complete lack of faith in KDE to ever be willing to do anything that will
ever see KDE in Debian has simply caused me to begin working on a C++
wrapper for GTK+ that works as well any such beast can.  I'll just use
that, it's safer and has a higher degree of never having any of these
problems to deal with.  Unfortunately it's still quite primative and a lot
more work.


> > A dual-licensed (QPL or GPL, your choice (perl offers the same with the
> > Artistic and GPL licenses)) Designer would quite easily sidestep the whole
> > issue.  So would a GPL-compatible QPL v2 (and would also erase all doubt
> > as to the legality of implicit permission to link Qt regarding KDE because
> > of borrowed code since it would no longer be necessary...)  That was why I
> > was so interested in the QPL v1 and spent so much time trying to make it
> > happen.
> 
> Dual license means it's under both.  The problem here is that Designer
> *can't* be under the GPL ( "No matter how" ).  They would have to put it 
> under QPL *and* remove the GPL

Actually, it means it's under either.  Not at the same time.  Perl is
licensed such that you may choose either the Artistic license or the GPL
when determining how to distribute it.  Not that the Artistic license
actually really says anything specifically at all - but what do you expect
considering who wrote it?


> In this situation a Dual license would only help if it was applied to 
> QT itself.  putting designer under QPL & GPL dual license would still 
> require Debian to remove the GPL licensing from the version they ship.
> 
> Can you do even that ?

LGPL'd libraries are pretty much automatically dual licensed under the
LGPL and GPL (there's a clause in the LGPL which accomplishes this) and
there is no problem including both sets of terms.  But Debian would be
following the QPL's terms since the GPL's terms would not be clear when
linking to Qt itself.

-- 
Joseph Carter <knghtbrd@debian.org>               GnuPG key 1024D/DCF9DAB3
Debian GNU/Linux (http://www.debian.org/)         20F6 2261 F185 7A3E 79FC
The QuakeForge Project (http://quakeforge.net/)   44F9 8FF7 D7A3 DCF9 DAB3

<Knghtbrd> Yorick: no problem with indexed color palettes for images, as
           long as you can pick the palette
<Yorick> Obviously the people creating quake were colour-blind but that
         doesn't mean you have to be

[prev in list] [next in list] [prev in thread] [next in thread]