iText de facto nicht mehr verwendbar

[Guybrush Threepwood]

Hi,
ich habe bislang immer in kleinen Projekten (vieles davon Closed Source Freeware) iText zur Erstellung von Berichten verwendet. Auch viele andere Open-Source-Reporting-Enginges setzen auf iText, unter anderem BIRT in Eclipse oder auch Jasper-Reports. Bis Dezember letzten Jahren war iText unter LGPL und MPL verfügbar, wurde dann aber auf AGPL umgestellt (GPL mit einigen spezifischen Erweiterungen). Das geschah, nachdem die Bibliothek fast 10 Jahre unter einer permisiven Lizenz verfügbar war. Da ich die Bib sehr gut finde dachte ich mir, eine kommerzielle Lizenz zu erwerben und habe an die "Sales"-Abteilung geschrieben. Es geht wohlgemerkt um kleine Desktop-Applikationen mit einer geringen Marge. Die Antwort der sales-Abteilung:

You would purchase iText OEM license subscription if you plan to embed iText into your application which is distributed to your customers.


iText Commercial OEM Desktop licensing
· Annual payment for right to distribute based on sales volume
· No additional royalties beyond subscription payment
· Support included (annual incidents based on volume)
· IP protection
· Requires quarterly reporting of quantities distributed unless choosing unlimited option (50,001+)
· Licenses are not for internal use, for redistribution only
· Custom pricing available for unique situations
· Perpetual licenses installed under previous years contracts can be upgraded to latest release of software @ 20% annual maintenance charge on that year's contract price
· Upgrade between levels allowed during the year @ 20% charge

Subscription Price _________ Distribution Rights _____ Effective Price/Copy _______ Support Incidents
$3,000 ______________ up to 250 desktops/year ________ $12.00 _____________ 1
$5,000 ______________ 251-500 desktops/year ________ $10.00 ______________ 2

Das geht dann so weiter und wird günstiger, je mehr man kauft, muss aber die verkauften Programmzahlen quartalsweise melden. In meinem Fall liegen die Kosten bei einem Vielfachen dessen, was an Ressourcen für die Implementation zur Verfügung steht.

Ich finde das wirklich heavy. Es war natürlich sehr nett, dass man iText bisher so leicht verwenden konnte und die Entwickler dürfen natürlich auch Geld verdienen und eine tolle Bib ist es allemal. Auch kann man bei iText 2.1.7 bleiben oder - falls möglich - die eigene Software unter AGPL publizieren. Alles in allem finde ich das Verhalten von Lowagie und Kollegen aber sehr fragwürdig. Sie zwingen die ganzen anderen Projekte in die AGPL und verlangen für closed source (ob Freeware oder nicht) Preise, die sich nur die Industrie leisten kann.

Ciao,
Guybrush

 

[Wildcard]

Wie wäre es denn mit ODFDom? OpenDocument ist sowieso viel cooler als PDF
The ODF Toolkit Project

 

[Guybrush Threepwood]

Herzlichen Dank! Das ist ein guter Tipp Das einzige, was mir dann noch fehlt ist die Möglichkeit, die ODF programmintern (ohne eine vorausgesetzte OpenOffice-Installation) anzuzeigen. Gibt es hierfür Möglichkeiten? Beispielsweise einzelne Seiten als Image zu rendern?

 

[Wildcard]

Ich weiß nicht genau ob es einen Java OpenDocument Viewer gibt. Hast du für deine Anwendung eine Art Installer? Biete doch OpenOffice Portable als optionale Komponente im Installer an.
Wenn das ausgewählt wird kannst du mit der OOo Office Bean direkt OpenOffice in deiner Applikation embedden.

 

[Matthias73]

Ich habe hier mal ein paar Alternativen zusammengestellt

Java PDF-Libraries

 

[ChristophMach]

ich habe ebenfalls nachgefragt bei iText bezüglich einer Server Lizenz.
Untenstehend die Preisinformation, die ich bekommen habe.

Für kleine Unternehmen ist das kaum attraktiv.
Bin nun auf Version 4.2.0 zurückgegangen.

Download hier zum Beispiel: https://github.com/ymasory/iText-4.2.0

Price US$ Description/Quantity (Production Environment) Support Incidents (*)

$2,000 Each for quantities between 1 and 4 per purchase order 1 per license
$1,800 Each for quantities between 5 and 9 per purchase order 1 per license
$1,700 Each for quantities between 10 and 29 per purchase order 1 per license
$1,600 Each for quantities between 30 and 99 per purchase order 1 per license
$30,000 Unlimited use (no server/VM count) on one named application 10
$100,000 Unlimited use for one enterprise Unlimited

 

[bronks]

Mal angenommen, ich bin ein Kaufhaus und verwende das iText mit AGPL.

Im Intranet existiert eine App, die eine PDF-Datei erzeugt. Die App soll nur von Angestellten des Kaufhauses verwendet wird. Klar das geht OK, denn der Benutzer ist das Kaufhaus.

Ein Angestellter läßt einen Kunden, Vertreter oder sonst einen externen an den Computer, damit sich dieser eine PDF selbst erzeugt. Damit wird der Externe zum Benutzer und kann den Quellcode der App anfordern und einklagen. Ist das so?

 

[Guybrush Threepwood]

Ja. Eigentlich beeinhaltet die AGPL jeden Fall, wo ein generiertes Dokument auch über das Netz verteilt wird, sollte somit deshalb eigentlich sogar für das Intranet gelten (nur merkt es dann keiner) und es gilt auch dafür, wenn ein generiertes PDF nach außen gegeben wird. Es muss also niemand externes das System nutzen, es reicht das erzeugte PDF-Dokument.

 

[Empire Phoenix]

Es gibt bei GPL -soweit ich weiß- eine halbe ausnahme(weiß nicht in wieweit agpl das mag)
Erstell eine eigenständige konsolenanwendung die du unter AGPL mit quellcode ect stellst,
diese wird jetzt von dem Server per bash aufgerufen. Ist aber auchn weder die wahre Lösung noch schön aus programmierer sicht)

 

[bronks]

Ja. Eigentlich beeinhaltet die AGPL jeden Fall, wo ein generiertes Dokument auch über das Netz verteilt wird, sollte somit deshalb eigentlich sogar für das Intranet gelten (nur merkt es dann keiner) und es gilt auch dafür, wenn ein generiertes PDF nach außen gegeben wird. Es muss also niemand externes das System nutzen, es reicht das erzeugte PDF-Dokument.

Nehmen wir an, daß die Erzeugte PDF-Datei auf Papier ausgedruckt wird und das Haus verläßt. Das dürfte eigentlich das gleiche sein, wie eine PDF-Datei, welche übers Netz verteilt wird?

 

[Guybrush Threepwood]

Im Grunde müsste das streng genommen so sein. In einer ausgedruckten PDF-Datei lässt sich allerdings nicht mehr nachweisen, womit diese erstellt wurde. Nach Aussagen von Lowagie lassen sich aber die digitalen PDF-Dokumente eindeutig identifizieren.

 

[...ButAlive]

Weiß eigentlich jemand, ob pdfbox von Apache schon eine ernstzunehmende Alternative zu IText ist?

 

[bronks]

... Ist aber auchn weder die wahre Lösung noch schön aus programmierer sicht)

Das vor allem.

Im Grunde müsste das streng genommen so sein. In einer ausgedruckten PDF-Datei lässt sich allerdings nicht mehr nachweisen, womit diese erstellt wurde. Nach Aussagen von Lowagie lassen sich aber die digitalen PDF-Dokumente eindeutig identifizieren.

Ich bin jetzt nicht auf iText fixiert, denn es gibt ja Alternativen. Auf diesen Thread bin ich gekommen, weil ich wegen iText#, wozu es kaum eine brauchbare und bezahlbare Alternative gibt, mit der AGPL konfrontiert wurde.

Die Freiheit der Software kann man mit der AGPL eigentlich in die Tonne treten, da genaugenommen nichteinmal für Demozwecke brauchbar. Da wird dann z.B. bei einem Autohersteller ein Kommissionierbeleg mit einem selbstgestrickten Kommissioniersystem erstellt, welches wegen z.B. iText unter AGPL gestellt werden muß. Jeder Käufer eines Autos hat damit das Recht, die Quellcode des Kommisioniersystems, die Quellcode der Software des im Auto verbauten Steuergerätes und letzendlich auch noch die Zeichnungen, Pläne, Prüfberichte ... ... des Autos zu erhalten.

 

[bronks]

Weiß eigentlich jemand, ob pdfbox von Apache schon eine ernstzunehmende Alternative zu IText ist?

Zum Erstellen von PDF-Dokumenten: fop.apache.org

 

[Guybrush Threepwood]

Das vor allem.


Ich bin jetzt nicht auf iText fixiert, denn es gibt ja Alternativen. Auf diesen Thread bin ich gekommen, weil ich wegen iText#, wozu es kaum eine brauchbare und bezahlbare Alternative gibt, mit der AGPL konfrontiert wurde.

Die Freiheit der Software kann man mit der AGPL eigentlich in die Tonne treten, da genaugenommen nichteinmal für Demozwecke brauchbar. Da wird dann z.B. bei einem Autohersteller ein Kommissionierbeleg mit einem selbstgestrickten Kommissioniersystem erstellt, welches wegen z.B. iText unter AGPL gestellt werden muß. Jeder Käufer eines Autos hat damit das Recht, die Quellcode des Kommisioniersystems, die Quellcode der Software des im Auto verbauten Steuergerätes und letzendlich auch noch die Zeichnungen, Pläne, Prüfberichte ... ... des Autos zu erhalten.

Ja, aber die Version 2.1.7 oder 4.2 ist nach wie vor (und vermutlich auch noch auf Jahre) eine sehr gute Möglichkeit, sofern man nicht irgendwelche völlig speziellen PDF-Eigenschaften benötigt. Insofern ist es nicht ganz so schlimm. Ab Version 5 gibt es beispielsweise besser Möglichkeiten zum Verbinden von Zellen in Tabellen usw. Mit ein paar Tricks bekommt man das auch bei den früheren Versionen gut hin. Alternativ könnte man OpenOffice einbinden (wenn man die 200 MB fürs Deployment nicht scheut). Das ist schließlich ein XML-Format (in Zip), was man im Prinzip gut bearbeiten kann. Hier gäbe es dann auch die Möglichkeit, ganz andere Formate auszuspucken.

 

[bronks]

Ja, aber die Version 2.1.7 oder 4.2 ist nach wie vor (und vermutlich auch noch auf Jahre) eine sehr gute Möglichkeit, sofern man nicht irgendwelche völlig speziellen PDF-Eigenschaften benötigt. Insofern ist es nicht ganz so schlimm. ...

Genau in diesem Zusammenhang ist es nicht schlimm und iText 2.1.7 nutze ich auch schon in ein paar Projekten.

Mein Unverständnis geht in Richtung der FSF, welche eine Lizenz für "nur anschaun" bzw. "Heim und Hobby" geschaffen hat. Mit der Förderung von freier Software hat das nichts mehr gemeinsam. Die GPL ist schön und gut, denn ich baue für jemanden ein Programm und übergebe es mit dem kompletten Workspace an den Benutzer und dabei ist es mir absolut egal, was dieser mit der Software anstellt, denn ich habe meine Pflichten bzgl. der GPL erfüllt.

Ich bin in der Zwickmühle, daß ein Kunde bereits einen PDF-Vewurschtler für viel Geld gekauft hat, welcher auf .NET basiert und wirklich super ist. Dieser Kunde wird sicher kein Geld dafür ausgeben, weil ein Bronks, als Javafrickler, genau den o.g. teuer gekauften PDF-Verwurschtler nicht verwenden möchte. Ich muß einen freien PDF-Verwurschtler finden, der genau die Sachen macht, welche ich brauche oder ich verwende den den PDF-Verwurschtler vom Kunden und .NET, womit ein weiteres freies Projekt wieder gestorben ist, was eigentlich nicht im Sinne der FSF liegen dürfte.