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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/legal
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
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.
[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).
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
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
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@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@lists.fedoraproject.org first."