Nicola Ken Barozzi wrote:
> > 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.
Yes, I agree to all of this (including the "strong opinion"). Still, I think
you underrate the importance of the license. In marketing terms: what is it
that makes Apache and GNU a "brand", while SourceFourge is not widely seen
as a brand. I think it's the license.
If I take something from the Apache projects, I know - because of the Apache
license - that I can do most everything with it as long as I mention the
origin in an appropriate way. This makes its very simple to use Apache
projects in commercial projects in medium-size and large companies. Basically
it boils down to this: If I want to use open-source components in a customer
project, I can use Apache-licensed stuff with no problems. MPL, LGPL and GPL
licensed components give me so many headaches when used in commercial customer
projects that I no longer even try to use them (with the exception of
internal-use-only projects). I just want to design and implement software, not
fuss with legal departments, you know... 8-)
Warning: Strong opinion follows
The Apache project just would not be the same if it adopted the MPL, LGPL or GPL.
Also, a number of contributors would quit in that case. If this is true, the
Apache license is still a *license* but not *only a license*. In a sense, the
license defines what persons the community consists of.
Philosopical issues aside, if the integration/collaboration is planned as you
say, then most points of my original mail become moot. Remember, my mail started
with an uppercase IF. The discussion here on fop-dev showed that it was NOT
clear that PDF via iText would only be an option, not a replacement.
And one more thing - I recite your citation:
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.
From this, it's clear that as soon as FOP no longer outputs PDF by itself, but
using a non-Apache-licensed component, then it not longer fulfills the original
goal. This may be good: it makes a lot of sense to separate formatter
and renderer if the abstraction layer is done well (this won't be an easy task,
I'm pretty sure of that).
Technically, it's very tempting to do what you propose. In fact, technically,
I'm all for it. Let's just be aware that the license problem is not only a
There is a real reason why there are different types of licenses.
And as for this:
> > 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.
If n persons are using FOP now and some of these can no longer
use FOP because a part of FOP they need has a license they can't use, then
I'd say this reduces FOPs usefulness for these "some" persons, despite being
more useful to others.
Arnd Bei▀ner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
- Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (w... arnd . beissner
- Re: [PROPOSAL] FOP+iText = FOP-NG -next generatio... Nicola Ken Barozzi
- Re: [PROPOSAL] FOP+iText = FOP-NG -next generatio... arnd . beissner
- Re: [PROPOSAL] FOP+iText = FOP-NG -next gener... Nicola Ken Barozzi
- RE: [PROPOSAL] FOP+iText = FOP-NG -next gener... Matthias Fischer