[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The "Evil Cookie Producer" case

On 07/03/11 08:00, Bruno Lowagie wrote:
> A library such as iText is already shipped with Debian, and different
> other projects depend on it. Other projects aren't part of the
> distribution, for instance because of their poor quality (e.g. the iText
> Toolbox which was never meant as a real product), or RUPS (a specialist
> tool aimed at a very small audience).
> Last week, I received a request from a Debian developer who wanted to
> ship an AGPL product with Debian, but he wanted me to change the
> license. I'm not a lawyer, but I've been working with (and for) a
> plethora of lawyers in the last 10 years, and I'm always eager to learn.
> So I asked an attorney (one that knows F/OSS licenses) to read the DFSG
> at my own expense (he's paid by the hour), to help me decide whether or
> not I should change the license as asked by the Debian developer.
> I received an answer from my attorney: "there's no reason to change. The
> license passes the tests." This legal advice didn't convince the Debian
> developer. In an attempt to help the Debian developer, I wrote a
> metaphor (exaggerating a bit, but the essence remains: does the freedom
> to hide a truth prevail over the freedom to get information). I had
> hoped to get arguments to help the Debian developer, but it turned out
> differently.
> Two out of the three replies tell me that the AGPL is accepted, but
> controversial. If that is the case, I'll advise the Debian developer NOT
> to ship that particular product with Debian.
> Thank you for your advice, I've learned something I didn't know before.

Hi all,

I'm the maintainer (a maintainer of Debian packages, rather than a
Debian maintainer) in question, and to be clear, what is under
discussion is software licensed under the AGPL with an additional term
which could potentially make the software non-free in the eyes of
Debian. So even though we accept the AGPL in raw form there is still
something to discuss.

The software itself is the current version of iText, which is licensed
under the AGPL with the following additional term:

"In accordance with Section 7(b) of the GNU Affero General Public
License, you must retain the producer line in every PDF that is created
or manipulated using iText."

The full license can be found at http://itextpdf.com/terms-of-use/agpl.php

I asked Bruno about this term, and he was very willing to discuss the
implications as he saw them. It's clearly slightly complicated, and I've
been trying to follow the implications in the worst-case. In reality I
personally would probably be happy to use iText in a project, but that
doesn't mean I'd be happy to upload it to Debian where everything needs
to remain free in the Debian sense.

It's my belief that this term could be interpreted to read that I must
not remove the producer line added by iText, which affects what follow
on processing I can do to that pdf, unless of course follow on
processing actually counts as creating a new pdf, which is of course a

My reasoning goes that if I write some software which uses iText to
produce a pdf, then if I use some other piece of software to modify that
pdf then I have potentially broken the license, since the producer line
may have been changed to reflect the name of this second piece of software.

The point is less problematic for an end user of a web app - if I write
a web app that uses iText to produce them a pdf then they haven't
entered into the AGPL with this extra term, and so they are free to do
what they like. But what about an end user who has also written some
software using iText - since they are bound by this term, then they're
no longer free to do as they wish with this PDF. Or an end user of
standalone software running on their computer?

I don't want to mis-represent what Bruno has said, so hopefully he'll
chime in and expand further if I get anything wrong here. I think the
following paragraph from Bruno sums up his viewpoint:

"The AGPL and the extra term ensure the consumer's RIGHT to know
that the PDF was produced by iText. Denying this right is IMO
exactly the abuse of Free Software the AGPL wants to avoid."

Writing this email I do now wonder if the problem is solely how far this
term appears like it could apply. If the term clearly only applied to
software which uses iText to produce or modify a PDF then I think my
issues disappear. So maybe something along the lines of:

"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."

This would make it clear that the when writing software using iText (the
covered work) you must retain the producer line, but would leave you
open to do what you want with the PDF afterwards, since you would no
longer be using a "covered work" to do the manipulation etc.

I'll think more about this later.

Andrew Ross

Reply to: