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

List:       kde-licensing
Subject:    Re: QT Designer _NOT_ under QPL.
From:       Kevin Forge <forge () myrealbox ! com>
Date:       2000-08-20 2:31:52
[Download RAW message or body]

Joseph Carter wrote:
> 
> 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.

Because I don't use Debian.  nothing against it, I just prefer 
Mandrake and on occasion Slackware.  My point was that none of the 
existing Debian developers cared enough to do it and that point stands.

Evidence suggests that if I go in and do this, I will be running against
the grain as soon as I join up.  Why board a boat just to rock it ?
It makes much better sense to board the boat that is going your way
and help paddle.
 
> 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.

This is the 3rd ( at least ) attempt at such a wrapper I have herd of.
What I herd is that in the end using a C++ wrapper on a C lib ( at least
the others that exist ) is going to be harder than learning and using 
the C lib directly.
 
> > 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?

So this means I can take a dual licensed app.  Remove one of the 
licenses and make it single licensed for people who get it from me ?

> 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.

That's a little different.  A distributor can decide not to allow 
closed apps linking to the version of an LGPLed lib he ships. 
The LGPL specifically allows this relicensing.  I honestly don't
know how this works for dual licensing when neither license 
allows relicensing and both demand that all future version still 
be under the same license.  

Yes.  That confusion isn't specific to KDE and QT.  It applies
to Mozilla too.  I mean, when it's dual will AOL still be able 
to do a closed version like the MPL allows but not the GPL ?
Effectively removing the GPL license from the code ?

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