incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: License implications of build-time or test-time dependencies?
Date Sun, 23 Oct 2011 19:28:20 GMT
This announcement may be pertinent to the questions about Qt dependencies:
<http://devworks.thinkdigit.com/Features/Qt-Project-launches-Qt-now-under-open_7799.html>.

The Qt Project is taking some interesting directions,
<http://www.qt-project.org/>.  It is a structured meritocracy, with a Chief 
Maintainer and Elected Maintainers.

I haven't accessed the Qt Project version of iCLA, but the explanation for it
is rather interesting at <http://qt-project.org/legal.html>.

Key take-aways:

 1. With regard to the parts of Qt that must be statically bound into code,
there is a BSD-like license.

 2. The explanation of the Contribution Agreement is a tribute to the virality
of the ASF approach, as well as I can tell.

 3. The Qt Project is mostly LGPL 2.1 and they seem reluctant to have LGPL 3
contributions, although the iCLA lumps all GNU License Terms together.

 4. They use Gerrit.  One cool aspect is that to submit code, there is an iCLA
solicitation that can't be passed until executed.  They use JIRA accounts as
the identification mechanism.

 5. Digging around in the iCLA, I see that easily-accepted third-party
contributions are required to be LGPL 2.1 compatible as defined at
<http://www.gnu.org/>.  The Various Licenses page there do not indicate that
ALv2 is so compatible, with a point made that GPL3 is the point of
compatibility,
<http://www.gnu.org/licenses/license-list.html#SoftwareLicenses>.

 6. Apart from a little care in parsing a warranty in section 3.3 of the
actual License Grants (section 3), the terms appear quite similar to those of
the Apache iCLA.  In this case, the grant of license is to Nokia. There are
other terms that may be of concern and I offer no opinion on the acceptability
of the Qt iCLA by anyone.

That's about enough for Sunday reading.


 - Dennis E. Hamilton
   tools for document interoperability,  <http://nfoWorks.org/>
   dennis.hamilton@acm.org  gsm: +1-206-779-9430  @orcmid



-----Original Message-----
From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com]
Sent: Friday, October 21, 2011 10:58
To: ooo-dev@incubator.apache.org
Subject: Re: License implications of build-time or test-time dependencies?

On Thu, Oct 20, 2011 at 9:37 PM, Rob Weir <robweir@apache.org> wrote:
> On Thu, Oct 20, 2011 at 4:07 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>> On Thu, Oct 20, 2011 at 12:08 PM, Pedro Giffuni <pfg@apache.org> wrote:
>>> Hmm ...
>>> We have discussed some of the things that must be replaced but we have not
>>> drawn a roadmap about it beyond the initial migration list. I think we
>>> will have to open BZ issues for those.
>>>
>>> The gtk/qt issue is rather critcal: I do not think there is previous
>>> history among Apache projects depending on them but if we cannot consider
>>> those "system provided" libraries it would be a serious setback to an
>>> early Apache release.
>>
>> I would support allowing C/C++ code to link to gtk and/or qt, provided
>> we don't distribute gtk or qt themselves.  Both are LGPL.  The LGPL is
>> clear for languages like C, C++.
>>
>
> Clear in what sense?  Dynamic linking and such?

Before Version 3, the meaning of the LGPL - when applied to many
dynamic and interpreted languages -  was sufficiently debatable to
pose a definite legal risk. It would be surprising but not
unreasonable for a court to rule that the license was strong (not
weak) copyleft for some languages.

Robert

Mime
View raw message