CV Lizenz und Möglichkeiten

[vlamers]

Hallo,

ich sehe das Ähnlich.
Solange die Basis OpenSource bleibt ist alles i.O.
Die bisherigen funktionen sollten erhalten bleiben.

Schwierig wird es, wenn die gekauften Plugins/Designs nicht mehr weiter aktualisiert werden und die dann nach einigen Updates nicht mehr oder nicht mehr richtig funktionieren.
Das denke ich mal ist sehr schwierig festzulegen bzw. zu Handhaben.


Gruß Volker

[Chris M.]

In diesem Konzext mag es interessant sein, wer überhaupt Autor ist.
Wenn ich mir per "git shortlog -sne" die Namen anzeigen lasse (+ etwas manuelles zusammenfassen) komme ich auf:

   546  Christian Mayer <ChristianMayer@users.noreply.github.com>
   279  hausl <hausl@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
   143  peuter <peuter@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
    80  j-n-k <j-n-k@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
    69  netzkind <netzkind@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
    43  netsrac69 <netsrac69@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
    41  makki1 <Makki1@users.noreply.github.com>
    25  vlamers <vlamers@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
    16  netfritz <netfritz@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     9  mclb <mclb@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     9  panzaeron <panzaeron@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     6  chris_ace <chris_ace@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     5  daviid5 <daviid5@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     5  hannesloehr <hannesloehr@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     5  jensgulow1 <jensgulow1@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     5  swiss1 <swiss1@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     4  mrremy <mrremy@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     4  pelnet <pelnet@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     3  jumi2006 <jumi2006@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     2  bubo08 <bubo08@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     2  christian523 <christian523@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>
     1  cschleiffer <cschleiffer@b3ce15a5-05c3-4bc8-b6eb-98bdc3a999cb>

[Chris M.]

Und die Diskussion wie sich die GPL in dem Umfeld einer Web-Applikation verhält ist auch nicht neu (hätte mich auch gewundert).

Vgl. z.B.: WordPress, themes, and derivative works [LWN.net]

Wobei man dort beachten muss, dass WordPress eine Server-Anwendung ist und folglich das wichtigste auf dem Server per PHP funktioniert - und bei uns fast alles per JavaScript auf dem Client.

Für WordPress kommt verschärfend hinzu, dass die klar definieren, dass für die ein Plugin und ein Theme abgeleitete Werke sind:

Part of this license outlines requirements for derivative works, such as plugins or themes. Derivatives of WordPress code inherit the GPL license. Drupal, which has the same GPL license as WordPress, has an excellent page on licensing as it applies to themes and modules (their word for plugins).
There is some legal grey area regarding what is considered a derivative work, but we feel strongly that plugins and themes are derivative work and thus inherit the GPL license.

Und das dort verlinkte Drupal sagt:

7: If I write a module or theme, do I have to license it under the GPL?

Yes. Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later. You are not required to distribute them at all, however. (See question 8 below.)
However, when distributing your own Drupal-based work, it is important to keep in mind what the GPL applies to. The GPL on code applies to code that interacts with that code, but not to data. That is, Drupal's PHP code is under the GPL, and so all PHP code that interacts with it must also be under the GPL or GPL compatible. Images, JavaScript, and Flash files that PHP sends to the browser are not affected by the GPL because they are data. However, Drupal's JavaScript, including the copy of jQuery that is included with Drupal, is itself under the GPL as well, so any Javascript that interacts with Drupal's JavaScript in the browser must also be under the GPL or a GPL compatible license.
When distributing your own module or theme, therefore, the GPL applies to any pieces that directly interact with parts of Drupal that are under the GPL. Images and Flash files you create yourself are not affected. However, if you make a new image based off of an image that is provided by Drupal under the GPL, then that image must also be under the GPL.
If you commit that module or theme to a Drupal Git repository, however, then all parts of it must be under the GPL version 2 or later, and you must provide the source code. That means the editable form of all files, as described above.

Mal davon abgesehen, dass das eher dem amerikanischen Rechtsraum zuzuordnen ist (gut, wir wollen international sein, d.h. es gelten bei uns "alle", auch wenn das juristisch vermutlich so wiederum nicht darstellbar ist) und außerdem vermutlich egal ist, was ein Projekt als "abgeleitetes Werk" definiert (das muss entweder das Gesetz und/oder der Richter machen...) - bestärkt mich das in meiner Auffassung:

• Ein Design/Theme sollte in seinen CSS und Medien (Bild)-Dateien eine eigene Lizenz wählen können, da das ja nur als Daten durchgereicht wird
• Bei einer JavaScript-Datei die mit dem Design kommt wird's schwieriger, das Grau dunkler - aber noch lange nicht schwarz
• Ein Plugin unter Nicht-GPL ist deutlich problematischer, da dort mit dem Code intensiv interagiert wird. Schwarz würde ich es auch noch nicht sehen - aber schon extrem dunkel

Fazit:
Das ganze ist ein Graubereich und folglich wäre eine Klarstellung der Autoren sicher für alle besser.


Jetzt müssen wir uns nur noch final überlegen was wir wollen (und wie wir diese Meinung bestimmen. Und diese Meinung dann in eine Klarstellung packen. Und ob dieser Meinung jeder Autor (vgl. Posting oben) zustimmen muss oder nicht, da das ja schließlich alles Grau ist...)

[mfd]

Jetzt müssen wir uns nur noch final überlegen was wir wollen (und wie wir diese Meinung bestimmen. Und diese Meinung dann in eine Klarstellung packen. Und ob dieser Meinung jeder Autor (vgl. Posting oben) zustimmen muss oder nicht, da das ja schließlich alles Grau ist...)

Ich fände wie weiter oben schon angedeutet eine Umfrage nicht schlecht.
Zumindest um zu bestimmen wo man sich befindet, in welche Richtung die Tendenz geht usw. ...

[hannes loehr]

von mir aus kann es gerne Plugins und Designs jenseits der GPL geben. Das tut der CV ja nicht weh, solange es bei einer fairen und gemeinschaftlichen Zusammenarbeit bleibt.

Guten Abend,

ich habe auch nichts gegen kommerzielle Designs/Plugins einzuwenden. Wenn sich dann jemand ein Modul kauft, ist es die persönliche Entscheidung, das Risiko einer künftigen Inkompatibilität einzugehen.

Gruß
Hannes

[makki]

Meine 5ct: Alles andere als GPL ist inakzeptabel.

1. Die GPL erlaubt ja durchaus auch eine kommerzielle Nutzung. Das verstehen nur manche Menschen nicht (oder wollen es nicht verstehen).
Es gäbe keinen einzigen am Markt befindlichen Wlan/DSL-Router ohne GPL.. Hallo? Alle eure Fritzboxen laufen deswegen überhaupt.
Da läuft überall Linux, nur das es manche halt versuchen zu kaschieren oder zu verleugnen - hilft aber nix.
Aufm HS, EibPC, WireGate etc.pp. läuft im Kern 90% eine GPL-Software, die es verdient, das ihren Lizenzbedingungen entsprochen wird (und dies auch übrigends rechtswirksam einfordern kann/könnte)

2. Es ist nahezu unmöglich - das ist meinerseits (persönlich) im Design so ganz bewusst gewollt!! - an der GPL vorbei da was proprietäres zu stricken.
Is nich! Wollte ich nie, will ich auch zukünftig nicht.

Makki

P.S.: das gilt nicht für z.B. Icons, auch wenn ich das nicht gut fände, wären hier andere (als CC) Lizenzmodelle denkbar

[jolt]

Wenn Plugins GPL3 Only sind, dann würde das bedeuten, dass man in den Plugins (wie auch in der CV selbst) nur mit der GPL kompatible Libraries verwenden kann, richtig? Das würde die Frage nach einer alternativen Diagram Library abkürzen

Siehe hier: https://knx-user-forum.de/forum/supp...573#post877573

[makki]

Nun, das müsste ein Sach- & Fachkundiger Jurist beantworten (was niemand je öffentlich tun würde, der bei Sinnen ist..)
Was man jedoch sagen kann, mit GPL ist man erstmal auf der sicheren Seite.

Makki

[mfd]

P.S.: das gilt nicht für z.B. Icons, auch wenn ich das nicht gut fände, wären hier andere (als CC) Lizenzmodelle denkbar

Mit den von mir gelieferten Icons dürften mit CC BY-SA 3.0 dem Ideal doch recht nahe kommen...

[STSC]

Der Jung Smart Visu Server verwendet openHAB mit CometVisu. Wie ist das eigentlich lizenztechnisch mit CometVisu? Ist das nur ein Theme, das sie herum bauen oder können die auch die Sourcen anpassen?

[Chris M.]

Meine Interpretation als juristischer Laie:

Die CV ist mit der GPL lizenziert. Die verlangt, dass Änderungen auch unter der GPL stehen müssen - und dass man den Quellcode von Änderungen den Kunden zugänglich machen muss.

Dies ist, was die CV angeht, trivial gegeben, da man einfach im Web-Browser schauen und ggf. wegspeichern kann, was übertragen wird. (Schöner wäre natürlich, wenn auf der Homepage ein Paket zum runterladen steht - das ist aber IMHO keine Anforderung der GPL, nur eine von vielen gelebte Praxis)

Spannender ist die Frage, wie der Status des Designs und der Config-Erzeugung ist.
Die Config-Erzeugung erbt von der CV keinerlei Lizenz, genau so wenig eine in einem GPL lizenzierten Editor erstellte Datei unter der GPL stehen muss.
Das Design ist als Punkt deutlich mehr im Graubereich, da es davon abhängt, wie es erzeugt wurde. Ein bestehendes so lange abgeändert bis es passt? Oder im Clean Room ganz neu und unabhängig?

Für mich ist das Design aber nur eine Interpretation von der Ausgabe der CV. Eine Interpretation die nicht mal Rückwirkung auf den Code hat und erst auf dem Client im Browser passiert. Genau so wie ein (hier: nicht GPL lizenzierter) Editor nicht unter die GPL fällt, nur weil GPL Code angezeigt wird und mit eigenem Syntax-Highlighting "interpretiert" wird. Oder wenn ich mit Microsoft Visual C ein GPL Programm compiliere fällt ja auch nicht Visual C unter die GPL.

=> Für mich ist die Lizenz eingehalten. Auch wenn Sourcen geändert sein sollten.
(Letzteres sollte man - auch schon im Eigeninteresse bzgl. Wartbarkeit - natürlich immer dem Projekt zurück spielen. Hier ist noch kein Code angekommen, entweder weil es noch nichts gibt oder es eben noch nicht commited wurde)