Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging twolibraries)

2002-03-13 Thread arnd . beissner

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.

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 would reduce the usefulness of FOP for a (unknown, agreed) number of users while
enhancing the usefulness for others (not license-concerned users).

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.

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.

Arnd Beissner
--
Arnd Beißner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917


Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging twolibraries)

2002-03-14 Thread arnd . beissner

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.

FULL STOP

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
philosophical issue.

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 Beissner
--
Arnd Beißner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917