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.
_______________________________________________
legal mailing list
legal@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/legal
