CV Lizenz und Möglichkeiten

[Chris M.]

Wie im anderen Thread ab Beitrag https://knx-user-forum.de/459102-post13.html und folgende schon angesprochen, sollten wir uns über unsere Software-Lizenz klar werden.

Dazu sind ein paar Punkte wichtig:

1. Was wollen wir mit der Lizenz erreichen
2. Ist das mit der aktuellen Lizenz (GPL v3) möglich
3. ggf: was müssen wir unternehmen um da hin zu kommen.

Für mich ist klar, dass die CometVisu an sich unter der GPL stehen soll. Da will (zumindest) ich keine Änderungen (und - um das klar zu sagen - ich kenne auch niemanden, der da etwas ändern möchte!).


Grundsätzlich sehe ich aber Klärungsbedarf, wie wir zu externen Erweiterungen stehen. Also zu Dingen, die nichts an der CV ändern und einfach on top kommen.
Mir fallen da spontan genau zwei Dinge ein - Designs und Plugins.


=> Wollen wir, dass nicht GPL-Designs möglich sind?
=> Wollen wir, dass nicht GPL-Plugins möglich sind?
(Habe ich hier noch etwas vergessen?)

-----

Meine persönliche Meinung ist, dass Designs möglich sein sollten (so können Firmen die CV Bundlen und ihre CI oder hochwertige Designs als Value Added Content anbieten - die haben ein Alleinstellungsmerkmal und wir eine breitere Nutzerbasis mit professionellem 1st Level Support; ist ja ein gängiges Geschäftsmodell im OSS Umfeld). Die Interaktion mit GPL-Code ist da auch minimal bis nicht existent.
Bei Plugins bin ich mir noch nicht ganz sicher. Und hier müssten wir ziemlich sicher mit Ausnahmen zur GPL arbeiten (denen nach vorweg genommenen Diskussionen zu 3. vermutlich jeder aktuelle Autor zustimmen müsste)

Zu Punkt 2. habe ich übrigens von der FSF eine Rückmeldung zur Interpretation der GPL. Da habe ich gerade noch die Rückfrage am laufen ob ich die öffentlich teilen darf.

[JuMi2006]

=> Wollen wir, dass nicht GPL-Designs möglich sind?
=> Wollen wir, dass nicht GPL-Plugins möglich sind?

Also meine bescheidene Meinung:

Ja zu nicht GPL-Designs.
Aber der nicht GPL-Designer muss zusehen dass er mit der CV Schritt hält. Nicht dass kostenpflichtige Designs die Entwicklung ausbremsen und man Sonderlocken um ein kommerzielles Design stricken muss -> NoGo.

Jein zu nicht GPL-Plugins.
Was die Visu in Konnektivität weiterbringt sollte auch GPL sein. Wenn z.B. Enertex oder WireGate nun produktspezifische Plugins rausbringen wollen können Sie das gerne tun (die Auswahl erfolgte rein zufällig) solange es sich einfach nur um die Kommunikation mit der entsprechenden Hardware handelt. Das wäre z.B. irgendwas um plugin_info auszulesen oder eibpc Logs anzuzeigen. Wie die Hersteller dann mit Ihrer Lizenz umgehen wäre mir an der Stelle egal.
Was nicht sein sollte ist das z.B. ein SQL-plugin kostenpflichtig wird. Genauso falsch fände ich kostenpflichtige Backends. Ich hab jetzt einfach die mir am schnellsten eingefallenen Beispiele gewählt die keinen Anspruch auf Richtigkeit erheben.

Was ich damit sagen will:
Kernfeatures sollten GPL sein/bleiben. Am Beispiel von SQL wäre es ja so dass sich nicht jeder mit RRDs rumärgern will oder noch andere Datenbanken hat. Das würde den Nutzerkreis der CV erweitern, die Popularität steigern und damit sicherlich/hoffentlich weitere Entwickler anziehen. Herstellerspezifische Plugins (z.B. Sonos, Samsung o.ä.) dürfen gern nicht GPL sein sofern Sie aus dessen eigenen Hause kommen.

Gruß

[johnnychicago]

Ich hab' als reiner User natürlich überhaupt nichts zu melden. Trotzdem habe ich eine Meinung

Im Interesse der User würde ich bei Plugins oder Erweiterungen auf eine offene Lizenz drängen. Wie oft entscheidet ein Anbieter, sich vom Markt zurückzuziehen, den Laden zuzumachen oder verliert aus anderen Gründen Interesse an dem, was er zuvor verkaufte. Wenn der User dann auf den Anbieter angewiesen ist, gibt's für ihn halt keine Updates und Verbesserungen mehr. Wenn die Software offen ist, kann man sich trotzdem behelfen. Wenn nicht, hat man als Kunde die A*-Karte. Das ist mir persönlich ausreichend oft passiert, dass ich sehr gezielt versuche, ohne nicht-offene Software auszukommen.

Wenn der Hersteller eines Widget ein Plugin für die CV anbieten will, dann ist der Verkauf an den Kunden, der dem Hersteller Einkommen generiert, ja immer noch der des physikalischen Gerätes. Ob das Plugin jetzt frei oder proprietär ist, ist für den Kunden/User ja nicht relevant. Auch ein freies Plugin nutzt dem Kunden nichts, wenn er nicht das Gerät hat. Nun könnte man argumentieren, dass bei einem freien Plugin das Gerät für billig Geld nachgebaut (oder sogar kostenlos emuliert) werden könnte. Wenn dem so ist, ist es mit der Wertschöpfung des Anbieters an sich vielleicht nicht so weit her.

Was Designs angeht, kann ich gerade bei Dingen wie Firmenlogos und dergleichen nachvollziehen, dass man einem Anbieter da Raum geben muss. Aber das Design an sich stelle ich mir schwer schützbar vor: wenn ein Anbieter ein elaboriertes CSS baut und das jemandem gefällt, kann er es sich nachbauen. Ich würde mich als Anbieter auch da nicht wieder unbedingt darauf verlassen wollen, dass eben das Design Geld hereinbringt.

[fanta2k]

zu 2 kann ich dir sagen das es davon abhängt wie das plugin design aussieht, wenn zb eine defnierte API vorliegt und das plugin darüber kommuniziert und keine systemfunktionen direkt aufruft dann ist das eine grauzone, ansonsten muss ein plugin unter die gpl oder eine gpl kompatible lizenz.

wenn das plugin eine eigenständige software ist, und auch hier über klare apis kommuniziert wird, dann kann man das properitär lizenzieren.

[Chris M.]

Hier die Antwort der FSF zu meiner Frage (ist im Text enthalten):

Hello and thank you for writing in.

> I have created a GPL (v3 or later) web application that is using
> heavily JavaScript and CSS, of course.

> I wand to allow third partys (e.g. companies) to create different
> designs for this application that can be proprietary to that company.
> That design would live in it's own folder and the config can tell the
> application to use it. The design is basically starting with the set
> up DOM tree in the browser and then creating all display rules on its
> own.

> I would have guessed that this is possible with the GPLv3. (Do you
> think differently?)

> Now we want to ship a generic CSS that gives the DOM tree display a
> generic shape that each design (OSS and proprietary ones) can build on
> to reduce code duplication.
> I.e. this generic CSS would be included by the application first and
> then the proprietary design on top of it.

> => You could argue that the proprietray design becomes a derived work
> - - or not...

That would depend on the interrelationship of the different parts
involved, and may take a lot of detailed examination to determine. It
would be simpler to assume that a derivative work is being made and
proceed with providing an exception.

> => What do you think about that situation?

> Should I put a clarification to the copyright notice to allow this use?
> Or would it help to give this generic CSS a LGPL licence?

First, you need to make clear to the recipient of the software, the
license under which they may extend the CSS, Javascript and HTML you've
provided in your template (for lack of the better word) code. You can
achieve this by carving out a narrow exception to the GPL (you can use
the Javascript exception in the FAQ mentioned as a basis for such an
exception text, if you wish, or any other effective language).

Licensing under a lax license may not suffice to permit the kind of use
you have in mind since the work, as a whole, still would have to be
distributed under the terms of the GNU GPL.

Second, since CSS, Javascript and HTML are all sent (distributed) to the
client, you need to make clear to people who will then be interacting
with the system over a network that some portions of it may not be under
a free software license. This may or may not be an issue depending on
how you've organized your project and what expectations people have when
interacting with a third-party installation of your software (for
example, people who recognize that they are interacting with a Wordpress
or Drupal install may assume that the Javascript, CSS, etc. being sent
to their browser is under a free software license).

Finally, when you provide such an exception you will have to make
certain that third-party code you use in your project which is licensed
under the terms of the GPL, for which you are not the copyright
holder/s, is not being transitively contaminated by proprietary code via
the exception.

I hope this answer is of help.

--
I am not a lawyer, the above is not legal advice

Regards, Yoni Rabkin

[Fry]

Leicht off-topic, aber im Kontext:

Nicht-freie Software im Rahmen der Haussteuerung einsetzen ist so ziemlich das kurzsichtigste, was ich mir als Hausbauer vorstellen kann. Ein Haus lebt 50-100 Jahre, und "professionelle" Software?

(Ich lach mich kaputt, wenn Leute hier stolz Visu-Plattformen auf Windows-Basis vorstellen. Ist denen nicht klar, dass ihr Kram eines Tages mal kaputt gehen könnte und auf dann aktueller Hardware gar nicht mehr installierbar ist?)

Bei mir kommt in der Hauselektronik NUR Linux, CV, Wiregate zum Einsatz. Und beim Wiregate mache ich seit >1 Jahr kein Update mehr. (Sehr wohl aber Backups). Warum auch, läuft ja alles.

Einzige bittere Ausnahme ist die ETS. Da nutze ich Version 4 und habe ebenfalls vor, nicht den Versionen hinterherzulaufen. Aber die Abhängigkeit von einer proprietären KNX-Konfiguratoinssoftware, die noch dazu unter Windows läuft (und damit eines Tages einen Upgradezwang bringen wird) ist schon ein stark negativer Aspekt einer KNX-Installation.
Ich würde mich sehr freuen, wenn es eines Tages eine freie Alternative zur ETS gäbe, oder die KNX Association sich (klugerweise) entschließen würde, eine (von mir aus ältere) Version der ETS unter die GPL zu stellen. Ansonsten bleibt mir nur übrig, das Vertrauen (haha) zu haben, dass die ETS auch in 30-40 Jahren auf dann aktueller Hardware noch existieren und meinen (dann uralten) Kram supporten wird. Die Chance schätze ich angesichts der hohen Zahl von Installationen bei KNX/ETS höher ein als bei EnOcean, ZigBee, Z-Wave usw. Nur am Rande: KNX-Geräte, die proprietäre Plugins für die ETS verlangen, sind selbstverständlich ein absolutes No-Go für mich.

Summa summarum: ich stimme ChrisM zu in seiner Einschätzung, was man erlauben sollte und was nicht. Aber ich selbst würde proprietäre Software in einer Hausinstallation meiden, wenn es irgendwie geht. Auch unter Verzicht auf schöne Features.

VG, Fry

[NetFritz]

Hallo

Ich möchte darauf hinweisen das bei Plugins wie z.B. bei Gauge auch noch ext. Programmierer beteiligt sind.
Deren Erlaubnis man auch einholen müsste wenn die CV kommerziell verwendet wird.

Gruß NetFritz

[Chris M.]

Ich möchte darauf hinweisen das bei Plugins wie z.B. bei Gauge auch noch ext. Programmierer beteiligt sind.
Deren Erlaubnis man auch einholen müsste wenn die CV kommerziell verwendet wird.

Guter Hinweis - aber nur halb richtig.

Eine kommerzielle Verwendung der CV ist selbstverständlich schon jetzt möglich - das erlaubt die GPL problemlos.

Wenn eine Änderung der CV Lizenz anstehen würde, dann müssten die externen Programme geprüft werden, ob diese damit kompatibel sind. Falls nicht, dass muss deren Einverständnis geholt werden - oder diese aus der CV entfernt werden.

Praktisch gesehen sind die meisten externen Abhängigkeiten eher unter liberaleren Lizenzen als die GPL.

Und als Kern-Abhängigkeit gibt es nur JQuery - und das steht unter der MIT Lizenz.

Bei den anderen Abhängigkeiten habe ich aktuell nicht nachgesehen. Die stecken aber eigentlich nur in den Plugins (wie Gauge), d.h. im Zweifel könnte dann eben nur das eine oder andere Plugin nicht verwendet (und natürlich auch nicht distributiert) werden.

[StefanW]

Wie oft entscheidet ein Anbieter, sich vom Markt zurückzuziehen, den Laden zuzumachen oder verliert aus anderen Gründen Interesse an dem, was er zuvor verkaufte.

Genau das gleiche kann auch bei Open Source Produkten passieren. Nicht immer findet sich ein neuer Maintainer oder es macht jemand einen Fork. Ich denke, dass weniger als 0,1 % aller Nutzer in der Lage wären, selbst Änderungen vorzunehmen und neu zu kompilieren. Man muss dann jemand kennen, der sich der Sache annimmt. Die Möglichkeit ist da, das ist unbestritten und eine Stärke von OSS.

Auch ein freies Plugin nutzt dem Kunden nichts, wenn er nicht das Gerät hat. .... für billig Geld nachgebaut... Wenn dem so ist, ist es mit der Wertschöpfung des Anbieters an sich vielleicht nicht so weit her.

Richtig, so ist unsere Situation.

Sowohl das WireGate 1 Multifunktionsgateway als auch die IP-Extender basieren auf gängiger Hardware die für jeden verfügbar ist.
Deswegen haben wir am Ende den IP-Extender auch einstellen müssen, weil dieser sehr oft kopiert und nicht mehr gekauft wurde.

Solange etwas kopierbar ist, wird es auch kopiert. Wenn ich keine Querfinanzierung aus anderen Bereichen habe und die Entwicklung von den Einnahmen betreiben muss, kann ich weder kostenlose Kopien hinnehmen noch dass man die eigene Entwicklung ebenfalls unter eine Copyleft-Lizenz stellen muss.

Natürlich hätte ich die Freiheit, z.B. eine komplett eigene Visu unter propriäterer Lizenz entwickeln zu lassen (wie es alle anderen kommerziellen Produkte tun). Das wäre aber für den Endbenutzer deutlich teurer als wenn er evt. nur eine Extension bezahlen müsste (sofern gewünscht).

Die Entscheidung wie das mit kommerziellen Anteilen / Erweiterungen bei der CV laufen soll, liegt bei den Autoren (zu denen wir auch gehören) und bei den Usern (ohne deren Akzeptanz ein Projekt nicht erfolgreich ist).

Damit wir uns nicht Missverstehen: Wir würden es absolut verstehen, wenn sich die Mehrzahl gegen kommerzielle Zusatzmodule aussprecht. Freiheit ist viel Wert. Nicht jeder braucht jedes neue Feature. Dann entwickeln wir eben was anderes / eigenes.


lg

Stefan

[johnnychicago]

Genau das gleiche kann auch bei Open Source Produkten passieren. Nicht immer findet sich ein neuer Maintainer oder es macht jemand einen Fork. Ich denke, dass weniger als 0,1 % aller Nutzer in der Lage wären, selbst Änderungen vorzunehmen und neu zu kompilieren. Man muss dann jemand kennen, der sich der Sache annimmt. Die Möglichkeit ist da, das ist unbestritten und eine Stärke von OSS.

Die Situation ist bei OSS halt schon genau umgekehrt: wenn ich auf einen einzigen Anbieter bauen muss, kann der alleine mich hängen lassen. Wenn ich eine Community habe, dann müssen schon alle wegfallen, damit nichts mehr geht.

Originally Posted by johnnychicago
Auch ein freies Plugin nutzt dem Kunden nichts, wenn er nicht das Gerät hat. .... für billig Geld nachgebaut... Wenn dem so ist, ist es mit der Wertschöpfung des Anbieters an sich vielleicht nicht so weit her.

Richtig, so ist unsere Situation.

Es ist mit Eurer Wertschöpfung nicht so weit her?

Da bin ich anderer Meinung

Ich hab' zumindest ein Wiregate gekauft, obwohl ich durchaus in der Lage wäre, ein Communitygate zu bauen, und die Hardware rumliegen hatte.

Sowohl das WireGate 1 Multifunktionsgateway als auch die IP-Extender basieren auf gängiger Hardware die für jeden verfügbar ist.
Deswegen haben wir am Ende den IP-Extender auch einstellen müssen, weil dieser sehr oft kopiert und nicht mehr gekauft wurde.

Nun habe ich keine Ahnung, was der IP-Extender ist/war, damals war ich wohl noch nicht wirklich dabi.

Und Du hast natürlich einen Einblick in Deine Kundenstruktur und Deine installierte Basis, der uns hier völlig abgeht. Wir können da nur raten.

Solange etwas kopierbar ist, wird es auch kopiert. Wenn ich keine Querfinanzierung aus anderen Bereichen habe und die Entwicklung von den Einnahmen betreiben muss, kann ich weder kostenlose Kopien hinnehmen noch dass man die eigene Entwicklung ebenfalls unter eine Copyleft-Lizenz stellen muss.

Und worin genau siehst Du eine Querfinanzierung? In dem ganzen restlichen 1-wire-Ökosystem, das von Wiregate bedient wird? Ich hätte jetzt eher eingeschätzt, dass das Wiregate an sich die Motivation ist, für Tausende Euros Sensoren zu beschaffen, und dass es sich alleine nicht mal unbedingt tragen muss.

Ich tu mir schwer damit, dass Dir aus den paar Leuten, die ein CommunityGate betreiben, ein Schaden erwächst. Auch fände ich es überraschend, wenn Integratoren und Planer Raspberries und ähnliches einsetzten, um 300 EUR für das Wiregate zu sparen.

Wenn die Situation jetzt aber die ist, dass sowohl Wiregate als auch Sensoren nichts abwerfen... naja, dann ist es halt schon blöd.

Natürlich hätte ich die Freiheit, z.B. eine komplett eigene Visu unter propriäterer Lizenz entwickeln zu lassen (wie es alle anderen kommerziellen Produkte tun). Das wäre aber für den Endbenutzer deutlich teurer als wenn er evt. nur eine Extension bezahlen müsste (sofern gewünscht).

Und vor allem: ist es für Deinen Endnutzer relevant, ob das Produkt unter einer Opensource-Lizenz steht, oder nicht?

Ich bin da jetzt vielleicht nicht räpresentativ, aber ich lege keinen gesteigerten Wert darauf, dass mein System zwar nicht frei kopierbar, dafür aber soviel teurer ist.

Die Entscheidung wie das mit kommerziellen Anteilen / Erweiterungen bei der CV laufen soll, liegt bei den Autoren (zu denen wir auch gehören) und bei den Usern (ohne deren Akzeptanz ein Projekt nicht erfolgreich ist).

Damit wir uns nicht Missverstehen: Wir würden es absolut verstehen, wenn sich die Mehrzahl gegen kommerzielle Zusatzmodule aussprecht. Freiheit ist viel Wert. Nicht jeder braucht jedes neue Feature. Dann entwickeln wir eben was anderes / eigenes.

Ich bin überrascht: das Produkt Wiregate, für das die Kaufentscheidung vermutlich in den meisten Fällen nicht vom Endbenutzer kommt, sondern von einem Systemintegrator, machst Du teurer, indem Du eine existierende Software nachprogrammierst. Für den Systemintegrator muss das ja dann entsprechende Vorteile haben, damit er das teurere Produkt querfinanziert bzw innerhalb seines Projektes verkauft.

Ich bin in einem komplett anderen Bereich tätig und hab' wirklich keine Ahnung von Deinem Business, aber das... wundert mich

[Chris M.]

Genau das gleiche kann auch bei Open Source Produkten passieren. Nicht immer findet sich ein neuer Maintainer oder es macht jemand einen Fork. Ich denke, dass weniger als 0,1 % aller Nutzer in der Lage wären, selbst Änderungen vorzunehmen und neu zu kompilieren. Man muss dann jemand kennen, der sich der Sache annimmt. Die Möglichkeit ist da, das ist unbestritten und eine Stärke von OSS.

Das ist genau der Punkt. Bei OSS habe ich die Chance - bei Closed Source nicht.

Ob man diese Chance nutzen kann oder will ist davon natürlich unabhängig.

[mfd]

Ich schließe mich der Meinung von Fry an:
bei einer Hausinstallation die auf viele Jahre angelegt ist möchte ich möglichst auf freie Softwarekomponenten setzen. Deshalb bewußt die Entscheidung fürs Wiregate und dessen "Ökosystem".

Ich sehe die Gefahr, falls es zu einer Aufspaltung der CV in freie/nicht freie Bestandteile kommen sollte, dass das für die Weiterentwicklung insgesamt nachteilig sein könnte.
Schließlich hat eine Visualisierungslösung wie die CV (bis dato) einen IMHO sehr überschaubaren Entwicklerkreis. Falls sich dieser zusätzlich in verschiedene "Lager" aufspalten oder zerfallen würde wäre das sowohl für die Community als auch für potenziell kommerziell Interessierte alles andere als günstig.

Ich habe bisher immer gern den Icon-Anteil zur CV beigesteuert und möchte das auch weiterhin tun, solange ich das "Produkt CometVisu" guten Gewissens bei mir einsetzen kann.

Vielleicht wäre eine Umfrage zu diesem Themengebiet mal ganz aufschlussreich:
- Wie viele Nautzer hat die CV?
- Warum nutzen sie die CV?
- Wie viele Entwickler sind aktiv beteiligt?
- Wie stehen die Nutzer/Entwickler gegenüber freier/nicht freier Software?
- Welche Wünsche haben die Nutzer der CV?
- ...

[Chris M.]

Ich sehe die Gefahr, falls es zu einer Aufspaltung der CV in freie/nicht freie Bestandteile kommen sollte, dass das für die Weiterentwicklung insgesamt nachteilig sein könnte.
Schließlich hat eine Visualisierungslösung wie die CV (bis dato) einen IMHO sehr überschaubaren Entwicklerkreis. Falls sich dieser zusätzlich in verschiedene "Lager" aufspalten oder zerfallen würde wäre das sowohl für die Community als auch für potenziell kommerziell Interessierte alles andere als günstig.

Ich weiß nicht, wo die Befürchtung herkommt dass die CV aufgespaltet wird. Die GPL ist und bleibt GPL - da ändert sich nichts.

Es geht hier nur darum, ob (und wenn ja, unter welchen Bedingungen) Erweiterungen unter anderer Lizenz möglich sein sollen.

Für alles andere als Erweiterungen - wie etwa alle Weiterentwicklungen - ist die GPL sehr eindeutig. Auch das wird unter der GPL verfügbar sein.

Bei einer Erweiterung muss man ja auch noch trennen zwischen direkt eingebautem (muss auch unter der GPL verfügbar sein), "angeflaschten" wie einem Plugin (müsste man im Detail klären, nach aktueller Lizenz ziemlich sicher auch GPL-Zwang) oder einer "losen" Erweiterung wie einem Design (müsste man auch noch klären, gut möglich dass eine Virulenz der GPL nicht greift).

Wenn wir Plugins freigeben würden, dann wäre die Echtzeitkommunikation mit dem Backend weiterhin per GPL geschützt. Das ist ein Level auf den ein Plugin nicht wirklich zugreifen kann (und falls es sich doch einen entsprechenden Zugang erzwingt dann ist ziemlich sicher die Grenze erreicht dass es sich um ein abgeleitetes Werk handelt). Was ein Plugin aber kann, ist einen parallelen Kommunikationspfad zu öffnen (wie z.B. Diagram mit der RRD macht). Wenn so etwas (etwas neues natürlich! Diagram bleibt natürlich GPL) nicht frei verfügbar wäre, würde das keinen Einfluss auf bestehendes haben. Es wäre dann halt einfach nicht verfügbar. Und jeder OSS Entwickler könnte natürlich jederzeit eine entsprechende Funktion selber implementieren.
Da ein Plugin aber viele Möglichkeiten hat, bin ich mir nicht sicher ob ich dem eine andere Lizenz ermöglichen möchte.

Ein Design ist da deutlich anders, das legt "nur" fest, wie ein konkreter DOM-Tree dargestellt wird. Das ist quasi One-Way.
Man könnte die CV eigentlich wie einen Compiler auffassen der eine User-Config (in beliebiger Lizenz) in einen DOM-Tree übersetzt. Und anschließend kommen noch ein paar CSS Regeln dazu die das hübsch darstellen.
=> Müssen diese CSS Regeln nun GPL sein?
Das ist die entscheidende Frage (zumindest für Designs).

Für andere Erweiterungen als Plugins oder Designs fehlt mir momentan die Kreativität. Könnte es da noch etwas geben?
(OK, außer einer neuen Structure. Aber das ist ein anderes Thema. Und da bin ich mir sicher, dass die unter der GPL stehen müsste)

[mivola]

Ich kenne mich mit dem ganzen Lizenzkram leider viel zu wenig aus um hier irgendetwas detailliertes beitragen zu können. Ich sehe es eher aus der Sicht eines ambitionierten Endanwenders: ich möchte, dass die CV an sich weiter frei, kostenlos & OpenSource bleibt, d.h. ich kann & darf (wenn ich könnte und wöllte) Änderungen vornehmen. Zur CV zähle ich die momentan verfügbaren Designs (v.a. Metal) und Plugins.

Sollte es in Zukunft hochwertige (kostenpflichtige, closed-source) Plugins und/oder Designs unter anderen Lizenzen geben, würde das mMn der CV nur gut tun. Dem Endanwender muss dann natürlich aber auch klar sein, dass der Support dann nicht primär über dieses Forum sondern über den Hersteller laufen kann. Was ich nicht wollen würde, wäre eine (zu große) Abhängigkeit der CV (und deren Entwickler) von einem Hersteller - mit der Gefahr die CV zu sehr nach den Wünschen dieses Herstellers anzupassen.

VG
Micha

[dombn]

Da du per Mail um eine Meinung gebeten hattest, auch wenn ich mich nicht als Mit-Autor zähle (-n kann). IMHO hatte war ich bisher leider nicht dazu gekommen in nennenswertem Umfang mitzuhelfen und zu comitten.

Ich bin da recht leidenschaftslos: 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.