>Nicola Ken Barozzi wrote:
>> Given the licences, nobody is prohibited to cross-collaborate. iText
>> developers can send patches to FOP and viceversa, and be [VOTE]d as usual
>> when the time is right.
>> FOP can distribute iText jar as it's MPL, and both projects would
>> in a clear way.
> Advance warning: I didn't follow possible discussions
> on the iText list regarding this issue.
> IF the integration FOP-iText is done in a way where PDF
> output via iText is not just an option but a replacement
> for the existing PDF output - or even for the other renderers,
> too, then I'd say this step contradicts the intention
> though not the letters of the Apache license.

This is a strong opinoin. Remember that the Apache license is a *license*,
not the community. Apache values the community, and the license is there to
help the community.

> Why? If FOP - under Apache license - can no longer be
> used for essential purposes without using an additional
> component (iText) under MPL or LGPL, then in effect FOP
> is no longer Apache licensed, though technically
> speaking it still is.

? This boils down to a question: what is FOP?

FOP is the world's first print formatter driven by
XSL formatting objects and the world's first
*output independent* formatter.

Currently FOP is not totally output indipendent, in the sense that it
doesn't even output without going through a FOP renderer.

The goals of the Apache XML FOP Project are to deliver an XSL FO->PDF
formatter that is compliant to at least the Basic conformance level
described in the W3C Recommendation from 15 October 2001, and that complies
with the 11 March 1999 Portable Document Format Specification (Version 1.3)
from Adobe Systems.

FOP is currently two things:

Nobody has ever thought to ditch the current FOP renderers. It would be
The proposal is to focus on the formatting part, that is somethind that no
other project does AFAIK, and make the rendering accessible to other
projects, like iText, jFor and POI. Fop renderers would be just another
possibility, and now there are no alternatives I see for PCL, for example.

This way different working groups could focus indipendently on different
parts. Separation of concerns can help keep working groups more focused and

> This would reduce the usefulness of
> FOP for a (unknown, agreed) number of users while
> enhancing the usefulness for others
> (not license-concerned users).

I fail to see how this reduces usefulness.

> My personal favourite would be a FOP renderer
>  implementation that makes use of iText. Then,
> time could tell whether there are enough people
> interested in keeping Apache-licensed PDF output
> alive.

Basically, this is the idea :-)

I remember that iText has already proposed to be put in the FOP codebase,
thus gaining Apache license.
But several reasons advise us to be cautious and defer it for now.
It's not codebases that would merge, but communities, and we have to avoid
stalling while in the process.

> If the decision goes toward a full replacement,
> I'd say that at least all existing FOP committers and
> possibly the major contributors to FOP should agree
> to this step as it - in one respect - decreases the
> value of their work so far.

IMO, it's the opposite.
This can give FOP another opportunity, not make it go back.

Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to