From: [EMAIL PROTECTED] >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 cross-link >> 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? >From http://xml.apache.org/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: -formatter -renderer Nobody has ever thought to ditch the current FOP renderers. It would be illogical. 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 productive. > 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]
