QPL (was Re: C++ ... )
Alan Cox writes...
> KDE standardising needs to follow Qt getting a stable API (maybe Qt3 does
> this). What do Troll tech think
Well we had hoped to talk to them about it before going any further. We
know they are pretty sick of dealing with license issues (as is everyone
I'm sure). In the minutes from the last lsb-futures confcall,
http://freestandards.org/pipermail/lsb-futures/2002-April/000429.html
I got assigned writing up the situation which I haven't gotten to yet :(
We are still in the process of deciding/discovering/documenting what the
LSB's license criteria are. So far the LSB has not included any libraries
that require anything of developers using them. Matt Wilson recently
phrased this as "a no-strings-attached development environment". For
example there are no GPL'd libraries in the the LSB. With the GPL its
clear because developers who use a GPL'd library have to use the GPL.
The QPL is less clear because it depends on the case.
My understanding is that if you use QPL'd software to develop
- an open source product: then you must permit (section 6)
- use without charge
- re-distribution of original and modified versions
- upon request, a copy of non-public software to the original author
- a propriatary product that uses libqt: then you need to pay developer
license fees.
Please correct me if I'm wrong.
So does this violate the "no-strings-attached" rule? Unlike the GPL it
_is_ possible to create propriatary versions but at a cost. Where do we
draw the line?
As others have pointed out, nothing prevents developers from using things
not in the lsb, they just have to link statically or deliver the DSO
themselves. So the question is what criteria does a candiate need to meet
for us to standardize and promote it?
--
Matt Taggart Linux Development Lab
taggart@fc.hp.com HP Linux Systems Operation
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: