10:11 p.m.
Hi,
There was a question last year about a license change in itext from
LGPL to an AGPL variant [1].
At the time, no Fedora packages needed the new itext and the
discussion ended without reaching a conclusion.
During this time period, apparently Debian also raised the same issue,
and they took a step further to discuss this with the itext
developers. Eventually, the itext developers made a change in their
AGPL license. In particular, the phrase
..."you must retain the producer line" has been changed into "a
covered work must retain the producer line" in the latest iText
release. [2]
This change satisfied the Debian maintainers and they packaged itext5.
Now the question is the same: is this AGPL license [3] allowed in
Fedora?
Thanks,
Orcan
[1] http://lists.fedoraproject.org/pipermail/legal/2010-August/001352.html
[2] http://sourceforge.net/mailarchive/message.php?msg_id=27574906
[3] http://itextpdf.com/terms-of-use/agpl.php
10:24 p.m.
On Wed, Jun 01, 2011 at 11:11:46PM -0400, Orcan Ogetbil wrote:
Hi,
There was a question last year about a license change in itext from
LGPL to an AGPL variant [1].
At the time, no Fedora packages needed the new itext and the
discussion ended without reaching a conclusion.
During this time period, apparently Debian also raised the same issue,
and they took a step further to discuss this with the itext
developers. Eventually, the itext developers made a change in their
AGPL license. In particular, the phrase
..."you must retain the producer line" has been changed into "a
covered work must retain the producer line" in the latest iText
release. [2]
This change satisfied the Debian maintainers and they packaged itext5.
Now the question is the same: is this AGPL license [3] allowed in
Fedora?
No. This does not correct the problem.
- RF
[1] http://lists.fedoraproject.org/pipermail/legal/2010-August/001352.html
[2] http://sourceforge.net/mailarchive/message.php?msg_id=27574906
[3] http://itextpdf.com/terms-of-use/agpl.php
_______________________________________________
legal mailing list
legal(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/legal
--
Richard E. Fontana
Open Source Licensing and Patent Counsel
Red Hat, Inc.
10:28 p.m.
On Wed, Jun 1, 2011 at 11:24 PM, Richard Fontana wrote:
On Wed, Jun 01, 2011 at 11:11:46PM -0400, Orcan Ogetbil wrote:
> Hi,
> There was a question last year about a license change in itext from
> LGPL to an AGPL variant [1].
>
> At the time, no Fedora packages needed the new itext and the
> discussion ended without reaching a conclusion.
>
> During this time period, apparently Debian also raised the same issue,
> and they took a step further to discuss this with the itext
> developers. Eventually, the itext developers made a change in their
> AGPL license. In particular, the phrase
>
> ..."you must retain the producer line" has been changed into "a
> covered work must retain the producer line" in the latest iText
> release. [2]
>
> This change satisfied the Debian maintainers and they packaged itext5.
> Now the question is the same: is this AGPL license [3] allowed in
> Fedora?
No. This does not correct the problem.
Thanks,
Could you be a little more specific? What part makes the license
non-free? What suggestions should we propose to the developers?
Orcan
11:45 p.m.
On Wed, Jun 01, 2011 at 11:28:47PM -0400, Orcan Ogetbil wrote:
On Wed, Jun 1, 2011 at 11:24 PM, Richard Fontana wrote:
> On Wed, Jun 01, 2011 at 11:11:46PM -0400, Orcan Ogetbil wrote:
>> Hi,
>> There was a question last year about a license change in itext from
>> LGPL to an AGPL variant [1].
>>
>> At the time, no Fedora packages needed the new itext and the
>> discussion ended without reaching a conclusion.
>>
>> During this time period, apparently Debian also raised the same issue,
>> and they took a step further to discuss this with the itext
>> developers. Eventually, the itext developers made a change in their
>> AGPL license. In particular, the phrase
>>
>> ..."you must retain the producer line" has been changed into "a
>> covered work must retain the producer line" in the latest iText
>> release. [2]
>>
>> This change satisfied the Debian maintainers and they packaged itext5.
>> Now the question is the same: is this AGPL license [3] allowed in
>> Fedora?
>
> No. This does not correct the problem.
>
Thanks,
Could you be a little more specific? What part makes the license
non-free? What suggestions should we propose to the developers?
I will attempt to be more specific. This will be a bit long.
AGPLv3, like GPLv2 and GPLv3, prohibits distributors from imposing
"further restrictions" on downstream recipients. Certain kinds of
additional terms have customarily not been treated as "further
restrictions". GPLv3/AGPLv3 attempts, in section 7, to partially
codify (and to some degree expand on) this tradition by enumerating
certain categories of additional conditions that do not trigger the
"no further restrictions rule".
It is well understood in GPL culture that the original licensor of a
program is not bound by the "no further restrictions"
rule. Nevertheless, the use of a GPL-family license along with a
non-customary additional restriction violates GPL licensing norms, and
arguably creates fatal confusion for downstream distributors.
As I understand it, iText has a single author; at any rate we can
assume for simplicity that this is so. Thus he is the original
licensor.
Producer Line Restriction
-------------------------
If I understand the information you have provided correctly, the new
form of the additional restriction here appears to be:
In accordance with Section 7(b) of the GNU Affero General Public
License, a covered work must retain the producer line in every PDF
that is created or manipulated using iText.
I don't think this is substantively different from the earlier
version, but let's ignore the earlier version. This kind of additional
restriction is not authorized by 7(b). AGPLv3 7(b) authorizes
additional terms governing "material you add to a covered work" that:
Requir[e] preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it....
Let's assume that the "producer line" is some kind of brief author
attribution. What 7(b) is talking about is retention of author
attributions in *source code* of a covered work, or (within limits) in
user interface legal information displays for an interactive
program. It does not authorize requirements to retain functionality
that produces an author attribution in *output*. Moreover, there is
nothing I am aware of in GPLv2 tradition that suggests that similar
terms were ever considered GPL-compatible.
Note that (A)GPLv3 section 7, in recognition of the special problem of
original licensors imposing noncustomary (particularly nonfree)
additional terms, authorizes licensees to remove such terms from the
work ("If the Program as you received it, or any part of it, contains
a notice stating that it is governed by this License along with a term
that is a further restriction, you may remove that term").
I know from working with Tom Callaway that Fedora has a policy of not
packaging software under standard GNU licenses where the original
licensor has imposed a noncustomary additional restriction, *even if
that restriction is otherwise free*. (The one glaring exception to
this is the license of Liberation Fonts; consider that license
grandfathered in unless and until we can ever get that license
changed.)
I also know from working with Tom Callaway that the theoretical
solution of using the section 7 permission to remove additional
restrictions is not one that Fedora generally wishes to use, perhaps
as a matter of policy. I would add that, speaking for Red Hat as
distributor, we do not wish to use that permission in this instance.
Therefore, we need not reach the question of whether this additional
restriction is, in isolation, free or nonfree. It still makes the
software incompatible with Fedora legal policies.
Commercial Freedoms in Doubt
----------------------------
The "producer line" requirement is not the only problem here. If you look at
http://itextpdf.com/terms-of-use/agpl.php
the author says:
You can be released from the requirements of the license by
purchasing a commercial license. Buying such a license is mandatory
as soon as you develop commercial activities involving the iText
software without disclosing the source code of your own
applications. These activities include: offering paid services to
customers as an ASP, serving PDFs on the fly in a web application,
shipping iText with a closed source product.
This language is troublingly unclear. It suggests that the author may
be imposing more restrictions on particular commercial activities than
AGPLv3 authorizes. One can "develop commercial activities" (whatever
that precisely means) without triggering the requirements in AGPLv3
sections 6 and 13 to make source code available. This could even
conceivably include "offering paid services to customers as an ASP,
[or] serving PDFs on the fly in a web application" (even though one
can imagine that triggering AGPLv3 section 13 in many cases).
Moreover, AGPLv3 does not necessarily require "disclosing the source
code of your own applications" when you "ship[] iText with a closed
source product". It *might* in many cases, depending particularly on
what the author means by "your own applications".
In short, this external language raising doubt on commercial freedoms
is, at best, fatally ambiguous and unclear, and makes the license as a
whole nonfree.
Relevance of Business Model
---------------------------
We cannot ignore the apparent fact that the author is trying to make
money by selling proprietary licenses -- "You can be released from the
requirements of the license by purchasing a commercial license". There
is not necessarily anything wrong with that if done in an ethical
manner; indeed Red Hat has a product called Cygwin in which such a
business model (an ancient one inherited from the predecessor company)
is used.
Nevertheless, the existence of this business model informs our
analysis of the previous two issues. We know from certain prominent
historical cases that such business models sometimes give licensors
incentives to adopt noncustomarily restrictive interpretations of
standard copyleft licenses; that may be what we see here with respect
to issue 2. I am not sure it is as common to see such licensors
tacking on noncustomary additional restrictions on such standard
licenses, but the same incentives to engage in such conduct are
present. We are left with the troubling possibility that a distortion
of a legitimate free software license may have been chosen not in
innocence of the proper and customary use of that license, but for
purely mercenary reasons.
Solution
--------
I would suggest two solutions to the author.
1) Use the standard AGPLv3 (with the modified warranty disclaimer,
which is entirely legitimate), with no further additional terms, and
no gratuitous attempt to describe what commercial activities are
prohibited.
2) If he insists on some particular form of attribution, use 7(b) as
it was meant to be used. Require preservation of reasonable author
attributions in the source code. If iText is an interactive program (I
confess I have never had any reason to use it), implement "Appropriate
Legal Notices" that include reasonable author attributions. As of
2007, SugarCRM had done this in a way that met with the FSF's
approval. I would refer the author to the Free Software Foundation
(licensing at fsf dot org) for guidance.
--
Richard E. Fontana
Open Source Licensing and Patent Counsel
Red Hat, Inc.
10:11 a.m.
New subject: GPL and additional restrictions
[The following is my analysis, IANAL.]
On Thu, 2011-06-02 at 00:45 -0400, Richard Fontana wrote:
It is well understood in GPL culture that the original licensor of a
program is not bound by the "no further restrictions"
rule. Nevertheless, the use of a GPL-family license along with a
non-customary additional restriction violates GPL licensing norms, and
arguably creates fatal confusion for downstream distributors.
To be a little more specific, putting aside the provision of GPLv3 that
allows removal of additional restrictions (which seems a little
dangerous), there are two possible interpretations in this situation:
1. The license to distribute granted by the GPL is unusable because
distributors are unable to meet the copyleft condition that they convey
the work under the GPL. (They can only convey it under the GPL as
modified by the additional restriction.)
2. The original licensor intends to create a modified version of the GPL
in which the copyleft condition refers to the modified license. In this
case, the license may be free but it is GPL-incompatible: someone who
combined the work with a second work under the plain GPL would be unable
to convey the result under the GPL as required by the second work.
#2 is something the licensor is entitled to do. If the licensor states
this intent explicitly, I believe such a modified license should be
considered on the same basis as any other new license, and not rejected
out of hand because its construction as the GPL plus a restriction
"violates GPL licensing norms". But just listing GPL and an additional
restriction creates a great deal of confusion. I would treat this like
any other case of unclear licensing in which Fedora demands an official
clarification from upstream before accepting a package.
Let's assume that the "producer line" is some kind of
brief author
attribution. What 7(b) is talking about is retention of author
attributions in *source code* of a covered work, or (within limits) in
user interface legal information displays for an interactive
program. It does not authorize requirements to retain functionality
that produces an author attribution in *output*. Moreover, there is
nothing I am aware of in GPLv2 tradition that suggests that similar
terms were ever considered GPL-compatible.
Well, in some cases the output may be a derived work of the program.
For autoconf, it clearly is. For file transformations in general, it
depends on whether the manifestation of the program in the output
reaches the threshold of copyrightability. If the portions of the
program incorporated into the output are nonessential, one could remove
them and the output would no longer be encumbered.
(The one glaring exception to
this is the license of Liberation Fonts; consider that license
grandfathered in unless and until we can ever get that license
changed.)
What is more galling to me in that case is that the license falsely
refers to 1(b) as an exception, as if to make it seem more benign than
it is. An exception is by definition an additional permission that
distributors are allowed to remove (e.g., in order to combine the work
with a plain-GPL work).
--
Matt
10:21 a.m.
New subject: GPL and additional restrictions
On 06/02/2011 11:11 AM, Matt McCutchen wrote:
What is more galling to me in that case is that the license falsely
refers to 1(b) as an exception, as if to make it seem more benign than
it is. An exception is by definition an additional permission that
distributors are allowed to remove (e.g., in order to combine the work
with a plain-GPL work).
Yes, that license is terrible. Unfortunately, fixing it is non-trivial
for a variety of reasons that I cannot go into. :/
~tom
==
Fedora Project
11:18 a.m.
New subject: GPL and additional restrictions
On Thu, Jun 02, 2011 at 11:11:40AM -0400, Matt McCutchen wrote:
> (The one glaring exception to
> this is the license of Liberation Fonts; consider that license
> grandfathered in unless and until we can ever get that license
> changed.)
What is more galling to me in that case is that the license falsely
refers to 1(b) as an exception, as if to make it seem more benign than
it is. An exception is by definition an additional permission that
distributors are allowed to remove (e.g., in order to combine the work
with a plain-GPL work).
This license was negotiated with the supplier company before I arrived
at Red Hat. I basically agree with your criticism - the only thing I
would take issue with is the suggestion of bad intent. The Red Hat
lawyer involved in negotiating this license had absolutely no
intention of using the term "exception" in some misleading way. There
was, I believe, a lack of adequate familiarity with the longstanding
traditional use of "exception" in GPL licensing culture, with the
traditional distinction between additional permissions and additional
restrictions, and with the non-normativeness of tacking on
noncustomary additional restrictions to the GPL.
- RF
--
Richard E. Fontana
Open Source Licensing and Patent Counsel
Red Hat, Inc.
11:22 a.m.
New subject: GPL and additional restrictions
On Thu, 2011-06-02 at 12:18 -0400, Richard Fontana wrote:
On Thu, Jun 02, 2011 at 11:11:40AM -0400, Matt McCutchen wrote:
> > (The one glaring exception to
> > this is the license of Liberation Fonts; consider that license
> > grandfathered in unless and until we can ever get that license
> > changed.)
>
> What is more galling to me in that case is that the license falsely
> refers to 1(b) as an exception, as if to make it seem more benign than
> it is. An exception is by definition an additional permission that
> distributors are allowed to remove (e.g., in order to combine the work
> with a plain-GPL work).
This license was negotiated with the supplier company before I arrived
at Red Hat. I basically agree with your criticism - the only thing I
would take issue with is the suggestion of bad intent. The Red Hat
lawyer involved in negotiating this license had absolutely no
intention of using the term "exception" in some misleading way. There
was, I believe, a lack of adequate familiarity with the longstanding
traditional use of "exception" in GPL licensing culture, with the
traditional distinction between additional permissions and additional
restrictions, and with the non-normativeness of tacking on
noncustomary additional restrictions to the GPL.
I'm glad to hear that no deception was intended.
On a related note, the Licensing:Main entries for GPL versions with
exceptions currently state, "Please be sure that any exceptions are
approved by emailing them to legal(a)lists.fedoraproject.org first." But
true exceptions are never problematic, so more to the point would be,
"Please be sure that any terms described as exceptions are really
exceptions by emailing them to legal(a)lists.fedoraproject.org first."
--
Matt
4706
days inactive
4706
days old
7 comments
4 participants
participants (4)
-
Matt McCutchen -
Orcan Ogetbil -
Richard Fontana -
Tom Callaway