[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-21 6:21:37
[Download RAW message or body]

On Sat, Aug 19, 2000 at 09:31:52PM -0500, Kevin Forge 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.

The package exists.  I still question why the people responsible don't
upload it.  Or could it be that uploading it would quickly deflate the
argument that there's some deep seeded hostility in the Debian
organization and some urge to screw KDE any way we can?

Of course, I won't pretend there isn't animosity toward KDE with at least
a few people in the project.  KDE has taken great pains to piss off anyone
who dared disagree with them and still does.  I still believe this is
because KDE would rather see itself destroyed than admit they ripped
people's code without permission.  I have yet to see an admission that
kghostscript has a licensing problem.  It must have implicit permission to
link Qt because ... well, because it does!  And KDE can't make it explicit
because .. well, because they don't need to since it's implicit.

The fact that KDE does not own Copyright to ghostscript and has no legal
basis to claim they have any permission other than that explicitly set out
in the GPL doesn't matter.  I am supposed to take them at their word that
there are no licensing problems in KDE despite this blatant and obvious
example of just how much of a lie that is!  No, I've trusted KDE and taken
them at their word too many times.  KDE has no intention of doing anything
about any of this and never will unless someone manages to slap them with
a lawsuit for damages (which is kinda difficult to do with free software
since there can't really be any damages to claim..)  So we're back where
we started.  KDE has done nothing but try to tell us what they believe
will or at least should quiet all dissent.  Problem is, it's a pretty
obvious lie.


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

I know how to use the C lib, I just don't want to jump through those kinds
of hoops in my C++ code.  gtkmm is pretty bad even now and wxgtk has some
serious limitations because it provides a very bare API because of the
other wx* targets.  So really it would just be an attempt to do gtkmm
properly.


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

You know, I'm actually not sure.

I think so, but there might be some other points I'm not immediately aware
of offhand that might make it ineffective unless you initiated a fork or
something.  I believe M$ has a sourceless version of Perl for example
which the GPL would forbid but the Artistic license would allow as long as
they didn't do something like release perl 7.0 or something.  And the
exclusive disjunction seems to allow them to get away with doing it.


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

It seems acceptable to distribute the thing according to one set of terms
or the other and list both sets of terms for other people.  I must admit
though that you have caused me to seriously question how that all works
and I doubt I'll be recommending it to anybody until I find some solid
answers.

-- 
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 is now known as SirKewLDooD
*** Mercury kicked SirKewlDooD from #quakeforge (*WHACK*)
[Ed: (you'd have to have been there)]

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