Tine20 Support & Vermietung

[5kyy]

Morgen,
hier hab ich auch gleich eine neue Frage. Darf man eigentlich Tine20 auf einem eigenen Server Installieren und an Kunden vermieten? Wegen den ActiveSync Sachen ist klar da muss man aufpassen aber rein vom rechtlichen Aspekt her?
z.B. habe ich einen standard Webmailer installiert, welcher automatisch bei einem Paket dabei ist. Wenn nun der Kunde z.B. etwas mehr Komfort haben möchte, darf ich ihm dann Tine20 auch anbieten als Alternative?
Entschuldigt wenn das eine dumme Frage ist, aber eine ähnliche hab ich nicht gefunden und beim ersten "überfliegen" der Lizenzen bei der Installation bin ich auch nicht gleich fündig geworden.
MfG
5ky

[nelius]

Das kannst du gerne machen. Nur wenn du etwas an Tine 2.0 veränderst, musst du diese Änderungen wieder veröffentlichen!

Evtl. würdest du dich gerne mit einem Second-Level support absichern, dann nehm einfach mal Kontakt mit tine20.com auf. Wenn du selbst keine Lust auf das Hosting hast, kannst du da auch wg. reseller optionen nachfragen.

[5kyy]

Heißt das, egal was ich wie ändere bin ich VERPFLICHTET dies auch zu veröffentlichen?

Das heißt, ich darf jetzt hergehen, auf meinem Server Tine installieren und dies zum Vermieten anbieten?
Ich darf aber keine eigenen Erweiterungen dann ausschließlich auf Installationen auf MEINEM Server anbieten?

Glaub ich hab da was falsch verstanden? Mit vTiger, XT-Commerce etc. wurde es ja auch so gemacht oder? Dass Unternehmen hergingen und Ihre eigenen z.B. Templates bzw. PDF-Generatoren gemacht haben, welche eben dann nur bei Ihren Paketen vorhanden sind?

Nicht dass ich nicht bereit bin zu Teilen, aber da ich ein Nebengeschäft habe, muss ich natürlich sehr wohl sehen, dass sich meine investierte Zeit auch irgendwo wieder hereinspielt.

Hab zwar grob die GNU Lizenzen schonmal angepackt aber so einfach zum Durchsteigen find ichs ned. Vermutlich fehlt auch mehr das Interesse an solch rechtlichen Dingen. Da Code ich lieber paar Zeilen.

[nelius]

Wir verwenden die AGPL. Diese regelt genau den Fall mit den Anpassungen.

Wenn du Anpassungen machst, musst du diese veröffentlichen, egal ob es nur auf deinem Server läuft oder ob du Software verteilen willst. Wenn du dass nicht machen willst, kannst du dich aber von der AGPL "freikaufen" und den Code unter einer Lizenz bekommen in der du die Änderungen nicht veröffentlichen musst. -> www.tine20.com

So sind eigentlich auch die GPL Lizenzen gedacht. Da man im Web die Software nicht verteilt, sondern auf seinem Server nur zum nutzten anbietet, kann man bei vielen Projekten diese 'Grauzone' nutzten und die Software verändern ohnen die Änderungen zu veröffentlichen. Die AGPL klärt das aber eindeutig!

[made]

Hab auch noch ein paar Fragen:

Wenn du Anpassungen machst, musst du diese veröffentlichen, egal ob es nur auf deinem Server läuft oder ob du Software verteilen willst.

1. Bezieht sich "Anpassungen machen" auch auf selbst geschriebene (neue) Module ohne Änderung am bereits bestehenden Code? Müssen neue Module auch unter AGPL veröffentlicht werden, oder dürfen die unter einer anderen Lizenz laufen?

2. Kannst Du mal eine Hausnummer nennen wo man dann preislich so in etwa liegt, wenn man sich bei Euch von AGPL "freikaufen" möchte?

3. Wenn man sich "freikauft", wie sieht das dann mit den Lizenzen der anderen Komponenten die Ihr nutzt aus (z.B. ExtJS). Muß man dafür dann auch eine kommerzielle Lizenz erwerben?

Hintergrund:
Ich überlege Tine als Codebasis für eigene, nicht Open-Source-Module zu verwenden (der Kunde würde das nicht wollen).

[lab@nohl]

Hallo made,

ich bin nicht von den Tine 2.0 Entwicklern (Rechteinhabern), kann also nichts zum konkreten Einzelfall sagen. Ich bemerke nur immer mal wieder Missverständnisse in Bezug auf OSS, deshalb noch meine Anmerkungen.

1. Bezieht sich "Anpassungen machen" auch auf selbst geschriebene (neue) Module ohne Änderung am bereits bestehenden Code? Müssen neue Module auch unter AGPL veröffentlicht werden, oder dürfen die unter einer anderen Lizenz laufen?

Inwieweit ein "verbundenes" oder "abgeleitetes" Werk vorliegt, ist in der Praxis meist schwer zu bestimmen. Die meisten gehen auf Nummer sicher und gehen im Zweifel davon aus. Interessant sind solche Modelle, wie die Mozilla Licence, die letztlich auf geänderte Dateien abstellen. Dazu gehört aber die AGPL definitiv nicht. GEFÜHLT würde ich sagen, mit php im Rahmen von Frameworks (hier Zend) ist keinerlei Kombination möglich, ohne dass die AGPL für alles weiter gilt (also echt "viral").

Hintergrund:
Ich überlege Tine als Codebasis für eigene, nicht Open-Source-Module zu verwenden (der Kunde würde das nicht wollen).

Ich weiß nicht, wie konkret du das einsetzen willst. Aber die Verpflichtung nach (A)GPL bedeutet nicht, ein eigenes Projekt auf zu machen. Man muss den Code auch nicht Jedermann, sondern nur dem Empfänger des Kompilats (GPL) bzw. dem Nutzer (AGPL) zur Verfügung stellen.

Wenn du mithin ein Modul schreibst, das nur von dem Auftraggeber und seinen Angestellten genutzt wird, hast du die Bedingungen letztlich eingehalten. Javascript bekommt jeder und php ist ja auch Quellcode. Was du nicht verhindern kannst ist, dass der Auftraggeber das weitergibt.

So traurig es ist, es sind genügend Konstellationen denkbar, in welchen das Arbeitsergebnis NICHT an das Projekt zurück fließt. Allerdings ist sowas grundsätzlich nicht zu warten. Insofern sollten die Kernbestandteile auf jeden Fall upstream kommen, alles Andere ist fahrlässig, meinst du nicht?

3. Wenn man sich "freikauft", wie sieht das dann mit den Lizenzen der anderen Komponenten die Ihr nutzt aus (z.B. ExtJS). Muß man dafür dann auch eine kommerzielle Lizenz erwerben?

OSS ist ziemlich simpel, wenn man selbst OSS schreibt. Die Mischung ist extrem einzelfallabhängig. Deine Überlegung mit dem extJS hätte ich bspw. übersehen

[made]

Danke erstmal für den ausführlichen Reply. Ein paar Dinge sind mir klarer geworden
Das Hauptproblem mit der AGPL sehe ich in meinem konkreten Fall darin, dass mein Auftraggeben die Software nicht hausintern einsetzt (mit seinen Angestellten damit arbeitet), sondern die Software für die End-Kunden des Auftraggebers gedacht ist und es natürlich auch darum geht, der Konkurrenz ein Stück weit voraus zu sein. Aus unternehmerischer Sicht wird's hier wohl schwierig mit der AGPL. Und vor ich falsch verstanden werde: OS ist eine feine Sache, das Pojekt soll profitieren von Erweiterungen und Modifikationen, keine Frage, aber es ist schwer diese Denke in jeden Kopf zu bekommen und für manche ist es eben ein no-go

[lab@nohl]

Ja, diese Konstellation ist die Daseinsberechtigung der AGPL... Sonst hätte es die GPL auch getan Ich bin da sehr undogmatisch, soll dein Auftraggeber dich halt für eine Doppelschöpfung bezahlen.

Ganz Allgemein: In Sachen Innovationsvorsprung ist OSS witzig. Weil einerseits kann man sehr viel schneller am Markt sein, andererseits kann aber die Konkurrenz sehr viel schneller gleichziehen. Ergo: Man könnte behaupten, OSS ist Innovation.