VATSIM Germany Forum

Zurück   VATSIM Germany Forum > VATSIM Software > swift - Open Source Pilot Client

swift - Open Source Pilot Client Open Source Pilot Client - Crossplattform, Pluginfähig, von Usern für User

Antwort
 
LinkBack Themen-Optionen Ansicht
Alt 2015-11-06, 10:42   #21 (permalink)
 
Registriert seit: 2011-05-25
Ort: München
Beiträge: 301
Danke erteilt: 16
640 Danksagungen in 111 Beiträgen erhalten
Standard

Vielen Dank für die Ausführungen - das hilft uns sehr in der Entscheidungsfindungen weil es Punkte beleuchtet an die wir vielleicht noch nicht gedacht haben.

Der Hauptgrund warum wir uns (vorerst) für die GPLv3 oder EUPL (falls die schon wer kennt) entscheiden wollen ist um erstmal maximal restriktiv zu sein. Wir - als Copyright Owner - können linken mit was wir wollen. Deine Punkte sind relevant sobald jemand versucht den Code für eigene Projekte zu nutzen. Die Frage die sich uns stellt ist, welche eigenen Projekte könnten das denn sein. Der Use Case von swift ist sehr direkt: ein pilot client for online networks. Das einzige was ich also erwarte sind Anpassungen der Netzwerk/Voice Libraries um auf das eigene Netzwerk zu kommen. Das soll explizit erlaubt werden

* entweder indem die Libraries als Exception genannt werden oder
* so wie X-Ivap es macht mit dem Satz: "those modifications have the sole purpose to integrate
the client in a proprietary network"

Die Option LGPL ist durchaus eine Möglichkeit ich bin aber nicht sicher ob das nicht dem Missbrauch Tür und Tor öffnet. Z.B. könnte dann jemand argumentieren einen völlig verbesserten und super tollen Interpolator-Algorithmus als Plugin zu linken. Damit ist man compliant mit der LGPL und hat alles perfekt umgangen. Deswegen eher GPL mit klaren exceptions die nur das erlauben was nicht in das System Pilot Client fällt oder wegen des Status Quo absolut nötig sind. Dazu gehört auch der proprietäre Netzwerk/Voice Code. Der sollte eigentlich offen sein und ich bin übrigens auch dafür das zu tun (was nur wahrscheinlich nie approved wird, von daher müssen wir in dem Fall einfach damit leben.

Ich hatte vorher vorerst erwähnt und damit zurück zum eigentlichen wichtigen Punkt: wir wissen überhaupt nicht was nach dem Release passiert. Wollen andere Netzwerke mitarbeiten, werden sich viele Leute mehr beteiligen oder andere Use Cases ergeben die eine andere Lizenz rechtfertigen? Dann kann man ja drüber reden und eine weitere Lizenz hinzufügen. Das Problem ist nur, wenn man LGPL/MIT lizensiert, dann kann man es nicht mehr rückgängig machen sobald man merkt dass es missbraucht wird - game over.
Kurz gesagt: Ich persönlich würde erstmal mit GPL anfangen und schauen was passiert. Kommen dann viele Anfragen von Leuten die damit ein Problem haben aus welchen Gründen auch immer kann man darüber nachdenken es anzupassen. Aber ich würde gerne erstmal abwarten ob und was da so kommt.

Es ist übrigens absolut nicht der Fall, dass wir uns auf GPL festgefahren haben und ich stur zu überzeugen versuche. Ich argumentiere bisher nur und sehe es als eine sehr hilfreiche Diskussion. Wenn es zwingende Gründe gibt die uns von was anderem überzeugen, sind wir absolut offen
__________________

Geändert von Roland Winklmeier (2015-11-06 um 10:50 Uhr)
Roland Winklmeier ist offline   Mit Zitat antworten
Alt 2015-11-06, 13:31   #22 (permalink)
 
Registriert seit: 2014-12-22
Ort: Berlin (EDDT)
Alter: 34
Beiträge: 775
Danke erteilt: 566
781 Danksagungen in 356 Beiträgen erhalten
Standard

Zitat:
Zitat von Roland Winklmeier Beitrag anzeigen
Das einzige was ich also erwarte sind Anpassungen der Netzwerk/Voice Libraries um auf das eigene Netzwerk zu kommen.
Die Frage ist ob das ausreicht - gerade im Simulator-Bereich ist evtl. gar nicht absehbar was da noch kommen könnte; vielleicht mag irgendeiner einen bestimmten Airliner tiefer mit swift integrieren, vielleicht wird sogar ein Simulator dran angepasst. Das ist vorher nicht absehbar und wäre ja vielleicht sogar ganz schön, wird aber durch die GPL von vornherein erschwert/verbaut. Vielleicht möchte auch jemand EuroScope an swift anpassen (da gibts ja z.B. für den FSX einen "Tower View" soweit ich das gesehen habe).

Zitat:
Die Option LGPL ist durchaus eine Möglichkeit ich bin aber nicht sicher ob das nicht dem Missbrauch Tür und Tor öffnet. Z.B. könnte dann jemand argumentieren einen völlig verbesserten und super tollen Interpolator-Algorithmus als Plugin zu linken. Damit ist man compliant mit der LGPL und hat alles perfekt umgangen.
Das ist auch GPL-compliant, es sei denn der Interpolator-Algorithmus steht unter einer GPL-inkompatiblen Lizenz. Die Frage ist eher: Warum sollte das grundsätzlich negativ sein? Der Rest bliebe doch offen unter LGPL und würde dadurch vielleicht sogar in eine für alle positive Richtung weiterentwickelt. Der Name "swift" dürfte für eine derartige Distribution bei egal welcher Lizenz nicht benutzt werden dürfen, davor schützen die Lizenzen entweder explizit oder - meines Wissens nach - die international immer ähnlich lautenden Gesetze. Sonst könnt Ihr das auch nochmal ausdrücklich in Euren Nutzungsbedingungen klarstellen. Jemand anderer dürfte also einen "NetzwerkX-Client" rausbringen, der dann in den Lizenzhinweisen, "Hilfe/Info", der Doku etc. drauf hinweist, dass swift darin steckt. Und noch irgendwas anderes. "swift" dürfte der Client als Ganzes aber nicht genannt werden.

Klar, bei LGPL könnte auch ein kommerzielles Netzwerk wie z.B. PilotEdge kommen, sagen: "swift ist viel besser als unser eigener Client", ein Plugin fürs PilotEdge-Netzwerk schreiben und dann eine eigene Client-Distribution rausbringen. Dürften sie aber auch unter GPL mit Ausnahme für proprietäre Netzwerkplugins.

Kritisch sehe ich es, diese Ausnahme nur auf Netzwerkplugins zu beschränken. Wie gesagt, man weiß nicht auf was für Ideen einige Leute vielleicht kommen. Spätere Lizenzwechsel sind möglich, aber dann müssen alle Entwickler einstimmig zustimmen (viel Glück, die nach 3-4 Jahren noch wiederzufinden) oder die Urheberrechts-Übertragung muss rechtlich sicher funktionieren (da wäre aber wieder der Anwalt etc. nötig).

Vielleicht bin ich, weil ich als Webentwickler auf Arbeit selbst viel mit Open Source zu tun hab, "positiv vorbelastet" in meiner Einstellung zu dem Thema. Aber grundsätzlich ists doch besser wenn mehr Entwickler an Euer Projekt rankommen. Man kann natürlich nur die negative Seite sehen ("Netzwerk XY schreibt nur ein Netzwerkplugin und der Rest des Codes stammt eigentlich von uns"), zugleich hat das aber auch positive Seiten (Mitarbeit/Patches von den Entwicklern von Netzwerk XY für Simulatoranbindung, Interpolation, Model Matching, ...). Software ist nie fertig und als solches sollte sie besser zur Weiterentwicklung offen stehen. Wenn Firmen sich daran beteiligen hat das noch einen anderen Vorteil: Deren Kunden sind nämlich sauer wenn was nicht funktioniert. Bedeutet: Die Firma wird sich möglichst auch um Patches kümmern, was dann allen zugute kommt.
Daniel Neugebauer ist offline   Mit Zitat antworten
Alt 2015-11-06, 15:00   #23 (permalink)
 
Registriert seit: 2011-05-25
Ort: München
Beiträge: 301
Danke erteilt: 16
640 Danksagungen in 111 Beiträgen erhalten
Standard

Zitat:
Zitat von Daniel Neugebauer Beitrag anzeigen
Das ist auch GPL-compliant, es sei denn der Interpolator-Algorithmus steht unter einer GPL-inkompatiblen Lizenz. Die Frage ist eher: Warum sollte das grundsätzlich negativ sein? Der Rest bliebe doch offen unter LGPL und würde dadurch vielleicht sogar in eine für alle positive Richtung weiterentwickelt. Der Name "swift" dürfte für eine derartige Distribution bei egal welcher Lizenz nicht benutzt werden dürfen, davor schützen die Lizenzen entweder explizit oder - meines Wissens nach - die international immer ähnlich lautenden Gesetze. Sonst könnt Ihr das auch nochmal ausdrücklich in Euren Nutzungsbedingungen klarstellen. Jemand anderer dürfte also einen "NetzwerkX-Client" rausbringen, der dann in den Lizenzhinweisen, "Hilfe/Info", der Doku etc. drauf hinweist, dass swift darin steckt. Und noch irgendwas anderes. "swift" dürfte der Client als Ganzes aber nicht genannt werden.
Das sehe ich persönlich nicht so. GPL fordert auch für dynamisch gelinkte Libraries wie Plugins die GPL Lizenz - sprich es ist nicht möglich einen Teil von swift proprietär neu zu schreiben sondern man muss es offen legen und genau das wollen wir bezwecken. Sonst tritt der Fall ein, dass Netzwerk XY einen besseren Interpolator schreibt und aber nur ihren Usern zur Verfügung stellt. Der Rest in VATSIM oder anderen Netzwerken hätte das Nachsehen. Das ist genau der Fall den ich meine mit: 90 % der Vorbeit nutzen aber dann eigene Verbesserung nur für sich behalten. Das ist unfair allen anderen gegenüber.


Zitat:
Zitat von Daniel Neugebauer Beitrag anzeigen
Kritisch sehe ich es, diese Ausnahme nur auf Netzwerkplugins zu beschränken. Wie gesagt, man weiß nicht auf was für Ideen einige Leute vielleicht kommen. Spätere Lizenzwechsel sind möglich, aber dann müssen alle Entwickler einstimmig zustimmen (viel Glück, die nach 3-4 Jahren noch wiederzufinden) oder die Urheberrechts-Übertragung muss rechtlich sicher funktionieren (da wäre aber wieder der Anwalt etc. nötig).
Genau deswegen gibt es eine CLA. Jeder der Code für swift schreibt überträgt die Rechte an die Organisation. Man muss also niemand fragen sondern es ist eine Org-Entscheidung. Wobei wir wieder beim ursprünglichen Punkt sind.

Zitat:
Zitat von Daniel Neugebauer Beitrag anzeigen
Vielleicht bin ich, weil ich als Webentwickler auf Arbeit selbst viel mit Open Source zu tun hab, "positiv vorbelastet" in meiner Einstellung zu dem Thema. Aber grundsätzlich ists doch besser wenn mehr Entwickler an Euer Projekt rankommen. Man kann natürlich nur die negative Seite sehen ("Netzwerk XY schreibt nur ein Netzwerkplugin und der Rest des Codes stammt eigentlich von uns"), zugleich hat das aber auch positive Seiten (Mitarbeit/Patches von den Entwicklern von Netzwerk XY für Simulatoranbindung, Interpolation, Model Matching, ...). Software ist nie fertig und als solches sollte sie besser zur Weiterentwicklung offen stehen. Wenn Firmen sich daran beteiligen hat das noch einen anderen Vorteil: Deren Kunden sind nämlich sauer wenn was nicht funktioniert. Bedeutet: Die Firma wird sich möglichst auch um Patches kümmern, was dann allen zugute kommt.
Absolut richtig. Das würde ich absolut befürworten und ist auch der Hauptgrund für Open Source. Verstehe mich nicht falsch, ich bin ein Verfechter von FLOSS. Ich bin nur hin und hergerissen zwischen dem Optimismus wieviele Firmen, Entwickler und Freiwillige ein riesiges Momentum entwickeln um etwas großes zu schaffen und dem Pessimismus dass am Ende doch nur das Netzwerk XY sich den Code forked, eine eigene isolierte Welt aufbaut, wenig Kooperation zeigt und letztendlich die Lizenzregeln maximal ausreizt nur um eigennützig arbeiteten zu können. Ich meine, ganz ehrlich, wenn jemand forked und sein eigenes Ding durchzieht, hat keiner von uns die Zeit regelmäßig die Patches durchzusehen und zu schauen ob was interessantes dabei ist. Das ist die schöne heile Welt des open source und mag bei größeren Projekten funktionieren aber bei uns eher nicht. Irgendwann laufen die Projekte auseinander und für einen Fork ist es der Tod. Je mehr also die User gezwu... äh überredet werden direkt upstream zu pushen umso besser ist das. Das bündelt die Resourcen und alle ziehen an einem Strang. Natürlich muss man neuem gegenüber offen sein und über den Tellerrand schauen (Stichwort andere Netzwerke), aber das sind wir.
Was passieren wird? Ich kann es nicht vorraussehen. Ich habe nur das Gefühl, mit GPL können wir erstmal abwarten was denn da so kommt und die Lizenz nochmal korrigieren. Umgekehrt geht das nicht.

Edit:
Ich finde den Artikel http://www.gnu.org/licenses/why-not-lgpl.html übrigens brilliant. Er trifft genau den Punkt. swift ist da es open source ist konkurrenzlos und kann sich erlauben die Regeln zu diktieren. Wenn jemand mitarbeiten will, ist er herzlich willkommen - das gilt auch für Firmen. Das viele Firmen inkl. Microsoft am Linux Kernel mitarbeiten hat ja auch seine Gründe. Es muss nur genug Vorteil dabei rausspringen.

Letztendlich kann keiner von uns vorraussehen was passieren wird. Von daher wäre meine Idee das ganze bis auf nach dem Release zu vertagen und zu sehen wie es bei den Usern und Entwicklern ankommt. Spricht denn Deiner Meinung nach etwas dagegen mit GPL zu starten aber offen zu kommunizieren dass man über Alternativen nachdenken kann, falls es nötig wird. Schreckt das Leute ab?
__________________

Geändert von Roland Winklmeier (2015-11-06 um 15:22 Uhr)
Roland Winklmeier ist offline   Mit Zitat antworten
Alt 2015-11-07, 13:47   #24 (permalink)
 
Registriert seit: 2014-12-22
Ort: Berlin (EDDT)
Alter: 34
Beiträge: 775
Danke erteilt: 566
781 Danksagungen in 356 Beiträgen erhalten
Standard

Zitat:
Zitat von Roland Winklmeier Beitrag anzeigen
Das sehe ich persönlich nicht so. GPL fordert auch für dynamisch gelinkte Libraries wie Plugins die GPL Lizenz - sprich es ist nicht möglich einen Teil von swift proprietär neu zu schreiben sondern man muss es offen legen und genau das wollen wir bezwecken.
Richtig, wenn der Interpolator nicht unter GPL gestellt wird. Steht er jedoch unter GPL kann der swift-Code damit trotzdem im Sinne der GPL "entführt" werden um einen Client unter anderem Namen zu veröffentlichen. Ich hatte es so verstanden, dass es Euch eher darum ginge, die Veröffentlichung von Releases projektfremder Personen zu unterbinden, das wäre aber wiederum gegen die GPL. Da hab ich Euren Wunsch dann wohl zu restriktiv aufgefasst.

Zitat:
[...] dem Pessimismus dass am Ende doch nur das Netzwerk XY sich den Code forked, eine eigene isolierte Welt aufbaut, wenig Kooperation zeigt und letztendlich die Lizenzregeln maximal ausreizt nur um eigennützig arbeiteten zu können.
Apple z.B., ich verstehe was Du meinst. Auch wenn es in diesen Situationen immer ziemlich laut kracht ist das zum Glück eher selten der Fall. Ich persönlich würde mich davon aber nicht entmutigen lassen.

Zitat:
Ich meine, ganz ehrlich, wenn jemand forked und sein eigenes Ding durchzieht, hat keiner von uns die Zeit regelmäßig die Patches durchzusehen und zu schauen ob was interessantes dabei ist. Das ist die schöne heile Welt des open source und mag bei größeren Projekten funktionieren aber bei uns eher nicht. Irgendwann laufen die Projekte auseinander und für einen Fork ist es der Tod.
Das Problem ist, dass keine FLOSS-Lizenz dagegen schützt, da es im Sinne von FLOSS ist, ganz egal welche Lizenz Du wählst. Stellt Ihr alles unter GPL3 kann immernoch jemand kommen, das ganze Projekt forken und den Fork so weit abwandeln, dass Ihr ihn nicht mehr wiedererkennt und Patches auch nicht mehr problemlos ohne enormen Zeiteinsatz zurückportieren könnt. Sowas passiert vorallem wenn ein größerer Teil der Entwickler unzufrieden mit der Entwicklung des ursprünglichen Projekts ist (Beispiele für solche Forks wären LibreOffice, LibreSSL, io.js oder MariaDB; zum Teil nicht ganz ungerechtfertigt). So ärgerlich so eine Situation dann ist, würde ich das allerdings eher als "natürliche Evolution" des Codes bzw. Projekts begreifen. Evolution deshalb, weil (sofern nicht beide Projekte an dem Zoff und der Spaltung der Community zugrunde gehen) am Ende das bessere Projekt überlebt und weiterentwickelt wird.

Zitat:
Je mehr also die User gezwu... äh überredet werden direkt upstream zu pushen umso besser ist das. Das bündelt die Resourcen und alle ziehen an einem Strang.
Soweit ich das sehe haben aus der Perspektive die Projekte mit den offensten Lizenzen und mit Hosting auf GitHub die besten Chancen, ganz einfach aufgrund der dortigen Leichtigkeit von (Entwicklungs-)Forks und Pull Requests und der Übersicht durch den Netzwerk-Graphen, der eine Übersicht über alle auf GitHub registrierten Forks darstellt. Das läuft einfach am unkompliziertesten und je unkomplizierter desto eher gelangen Patches an den Upstream.

Kleine Anmerkung für alle die hier mitlesen, sich aber mit Softwareentwicklung nicht auskennen, worüber wir hier überhaupt reden: Fork ungleich Fork. In der (verteilten) Versionskontrolle (z.B. mit Git) bezeichnet man damit einfach nur eine (noch) nicht ins Ursprungsprojekt integrierte experimentelle (nicht "serienreife") Entwicklungslinie, die aber meist nach Abschluss der Arbeit an bestimmten Features/Bugfixes mit einem Pull Request oder manuell per Patch-Übermittlung ans Ursprungsprojekt zurückgeführt wird. Wovor sich Entwickler üblicherweise fürchten ist ein "richtiger großer Fork", bei dem ein Projekt unter anderem Namen auf der Basis desselben Codes in eine völlig andere Richtung weiterentwickelt wird, die mit dem Ursprungsprojekt inkompatibel ist und sich damit nicht mehr zurückintegrieren lässt. Forks wie im letzteren Fall lassen sich allgemein formuliert mit einer Meuterei gleichsetzen, wenn die Entwickler sich mit der Projektleitung endgültig verkracht haben. Verhindern ließe sich sowas allerdings nur mit proprietären Lizenzen (auch da kann man den Quellcode offen einsehbar halten, bringt nur niemandem wirklich was). Da sowas bei allen bisherigen Clients die Entwicklung mehr oder weniger zum Erliegen gebracht hat wollten die swift-Entwickler das ja eigentlich vermeiden.

Zitat:
Was passieren wird? Ich kann es nicht vorraussehen. Ich habe nur das Gefühl, mit GPL können wir erstmal abwarten was denn da so kommt und die Lizenz nochmal korrigieren. Umgekehrt geht das nicht.

[...]

Letztendlich kann keiner von uns vorraussehen was passieren wird. Von daher wäre meine Idee das ganze bis auf nach dem Release zu vertagen und zu sehen wie es bei den Usern und Entwicklern ankommt. Spricht denn Deiner Meinung nach etwas dagegen mit GPL zu starten aber offen zu kommunizieren dass man über Alternativen nachdenken kann, falls es nötig wird. Schreckt das Leute ab?
Es besteht die Gefahr, dass das Projekt an Fahrt aufnimmt, interessierte Entwickler die Lizenz sehen und sich dann zum Teil für immer denken: Mäh, GPL3... Wenn Ihr die Lizenz dann nach 2-3 Jahren ändert, weil Ihr merkt, dass es evtl. doch ein zu übertrieben starkes Copyleft war, das Euch an mehreren Stellen an einer vernünftigen Arbeit hindert, oder wenn Ihr Euch erhofft, durch eine Öffnung mehr Entwickler an Land ziehen zu können, haben die meisten immernoch die GPL3 im Kopf, wenn sie an Euer Projekt denken. Bestes Beispiel ist Qt (benutzt Ihr ja auch), das lange Zeit nur unter GPL2+ oder kommerzieller Lizenz verfügbar war. Die Änderung auf LGPL hat relativ lange gebraucht um in allen Köpfen anzukommen und die alten Vorurteile geistern zum Teil trotzdem immernoch umher. Und das obwohl die Lizenzänderung in sämtlicher Fachpresse verkündet wurde.

Zum anderen hinterlässt es einen etwas unschönen Eindruck, schon nach für FLOSS-Verhältnisse "kurzer" Zeit (~erste 5 Jahre) zwischen Lizenzen zu wechseln und als Entwickler bleibt eine Unsicherheit wieviel Bestand diese Lizenz dann wieder hat. Nicht vergessen sollte man dabei, dass auch Lizenzwechsel ein Grund für Forks darstellen können und anhängige Addons (wie Netzwerkplugins) nicht zwingend mitziehen. Wenn z.B. ein Netzwerkplugin für IVAO ursprünglich unter GPL3 aber mit Lizenzausnahme beigesteuert würde, bliebe deren Plugin GPL3 auch nach dem Lizenzwechsel des Kernprojekts, vorausgesetzt der Code dafür steht nicht ebenfalls unter per CLA unter Eurem Copyright. Eine Gesamtdistribution würde dann aus dem IVAO-Plugin heraus wiederum mit der GPL3 "infiziert" werden, da das IVAO-Plugin ja gegen den Core gelinkt wird. Hier ergeben sich dann bei der Weitergabe der einzelnen Clientbestandteile in kompilierter Form neue Fragen und rechtliche Unsicherheiten, die nur durch den Verzicht auf einen Lizenzwechsel vermieden würden. Insofern sollte die Lizenz des Kernprojekts nach Veröffentlichung möglichst nur in Notfällen oder im Einvernehmen sämtlicher (auch externer) Entwickler noch angefasst werden.

Ich persönlich stünde auch eher auf der Seite derer, die sich normalerweise fragen, was die Lizenzwackelei soll, wenn ein Projekt innerhalb kurzer Zeit zwischen den Lizenzen wechselt - es macht einfach keinen durchdachten Eindruck, obwohl doch die Lizenz bei einer FLOSS-Veröffentlichung ein nicht unwichtiger Teil ist. Hier müsste ein Projekt dann enorm vorsichtig sein, nach Außen hin nicht lächerlich zu wirken.

Zu guter Letzt: Auch wenn viele hier der Konkurrenz eher negativ bis feindlich gegenüberstehen (mein Eindruck) würde ich ja hoffen, dass diese auch Interesse an swift zeigt und sich mit ranhängt, denn bis auf den Netzwerkcode käme ja jegliche Verbesserung an den übrigen Teilen des Clients (FS-Anbindung, Bedienoberfläche, Interpolator, ...) allen teilnehmenden Netzwerken zugute, ob sie nun VATSIM, IVAO oder sonstwie heißen. Vielleicht wäre es nicht schlecht, mit den technischen Betreuern der anderen Netzwerke bzw. der bisherigen Clients kurz Kontakt aufzunehmen und im Vorfeld zu fragen, was diese bzgl. Lizenz für einen potentiell gemeinsam nutzbaren Client denken.

Geändert von Daniel Neugebauer (2015-11-07 um 13:54 Uhr)
Daniel Neugebauer ist offline   Mit Zitat antworten
Danksagungen
Alt 2015-11-07, 16:15   #25 (permalink)
 
Benutzerbild von Klaus Basan
 
Registriert seit: 2011-01-14
Ort: Heidelberg
Beiträge: 1.424
Danke erteilt: 1.839
1.066 Danksagungen in 505 Beiträgen erhalten
Standard

Danke für Deine ausführlichen Anmerkungen Daniel. Ich denke, wir diskutieren das noch mal intern, und werden uns dann entscheiden. Die 100% beste Lösung kann ich leider auch nicht erkennen.

Hinzu kommen praktische Belange: So speichern wir unser Modellmatching in einer Datenbank, wir haben eine Testinstanz. Wenn jetzt jemand entwickeln wollte, müsste er quasi unsere Test-Infrastruktur mit nutzen. Fragwürdig wie wir das handeln (Ich will sagen, dass m.E. eine wirkliche Entwicklung nur möglich ist, wenn man auch die Test-Infrastruktur hat).

Manch andere Bereiche sind dann wiederum "übergreifend". So kann man ganz gut eine Anbindung an einen neuen Simulator (z.B. FlightGear) schreiben, damit dann alles reibungslos funktioniert, müssen dann aber auch anderer Bereiche angepasst werden.

Fazit: Am besten sind Co-Entwickler immer noch bei uns im Team aufgehoben.

Uns vorher noch mit anderen Netzwerken abzustimmen, ist eine gute Idee. Übersteigt aber m.E. momentan unsere Resourcen. Prinzipiell könnte man jemand brauchen, der sich nur um solche Belange kümmert. Es dauert eh alles schon viel zu lange.
__________________
Klaus Basan D[A|C|E]MBZ | VatGM - Flights on Google Map | swift Pilot client

Geändert von Klaus Basan (2015-11-07 um 16:23 Uhr)
Klaus Basan ist offline   Mit Zitat antworten
Danksagungen
Alt 2015-11-08, 00:59   #26 (permalink)
 
Benutzerbild von Andre Helm
 
Registriert seit: 2007-06-04
Ort: Germany, Berlin
Alter: 42
Beiträge: 2.939
Danke erteilt: 2.594
3.152 Danksagungen in 1.260 Beiträgen erhalten
Standard

Ich darf dazu raten, dass - so gut gemeint es auch sein mag - sich Nicht-Juristen dieser Diskussion nicht allzu ausschweifend hingeben sollten. Dies kann schnell mehr schaden als helfen. Weiterhin weise ich vorsichtig auf das Rechtsdienstleistungsgesetz hin, nicht um hier ärgern zu wollen, sondern die "Berater" vor Schaden zu bewahren.
__________________
Gruß André Helm
vATCo RG Berlin

Wir sind die vACC Germany!// Ich bin ein Berliner!... Schöne Grüße aus Berlin
Andre Helm ist offline   Mit Zitat antworten
Alt 2015-11-08, 01:50   #27 (permalink)
 
Registriert seit: 2014-12-22
Ort: Berlin (EDDT)
Alter: 34
Beiträge: 775
Danke erteilt: 566
781 Danksagungen in 356 Beiträgen erhalten
Standard

Ich hab ja weiter oben schon geschrieben, dass ich auch nur Laie bin und nur meine persönliche Wahrnehmung des ganzen schildern kann (falls ich überhaupt gemeint war). Da ich tagtäglich als Entwickler mit Open Source in Kontakt komme, meine ich, aus praktischer (natürlich nicht juristischer) Erfahrung für die alltägliche Anwendung in den Lizenzen insgesamt schon ganz gut drin zu stehen, als rechtliche Beratung begreife ich die Schilderung dieser persönlichen Erfahrungen & Meinungen eigentlich nicht. Wie oben schon geschrieben würde ich auf alle Fälle einen Anwalt empfehlen, wenn diese aus der praktischen Erfahrung erwachsenen Softwareentwickler-Ansichten nicht ausreichen, weil man Rechtssicherheit benötigt (von den hier anwesenden Juristen ist leider keiner auf Lizenzrecht spezialisiert, oder doch? Ein klein bischen Beratung könnte auch ich von Zeit zu Zeit mal gebrauchen. ). Das angesprochene Gesetz ist auf jeden Fall insofern richtig, als dass wir Laien die Komplexität rechtlicher Thematiken häufig gar nicht begreifen können, deshalb auch mein Rat lieber einen spezialisierten Anwalt aufzusuchen, wenn die Laienmeinungen und die eigenständige Interpretation der Lizenztexte nicht ausreichen. Die Open-Source-Lizenzen an sich sind zum Glück (meines Wissens nach) inzwischen so weit in der Praxis erprobt und zum Teil schon mehrfach juristisch überprüft worden, dass man diese an sich relativ gefahrlos auf seine eigenen Werke anwenden kann. Aber auch da gilt wieder: Lieber selbst nochmal zum Anwalt gehen bevor man irgendwas übersehen und später Probleme deswegen am Hals hat.

Wenn man sich für die Entwicklung oder Anwendung von Open Source (wie auch jeder anderen Software) entscheidet, ists leider unvermeidbar, sich neben den persönlichen auch mit den weiteren rechtlichen Aspekten ein klein wenig auseinanderzusetzen. Daher verwischt vielleicht etwas die Wahrnehmung was noch Diskussion ist und was von anderen bereits als Rechtsberatung aufgefasst werden könnte. Danke für den Hinweis, dass die bisherigen Kommentare schon grenzwertig waren, dann halte ich mich ab sofort lieber zurück. Da wir hier in einem geschlossenen Forum sind, sehe ich allerdings zum Glück ein eher geringes Risiko für irgendwelche Fehlauslegungen meiner Äußerungen. Spätestens dieser Beitrag sollte nochmal alles richtig stellen.

Geändert von Daniel Neugebauer (2015-11-08 um 02:18 Uhr)
Daniel Neugebauer ist offline   Mit Zitat antworten
Antwort

  VATSIM Germany Forum > VATSIM Software > swift - Open Source Pilot Client


Themen-Optionen
Ansicht

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an



Alle Zeitangaben in WEZ +2. Es ist jetzt 00:20 Uhr.


Powered by vBulletin® Version 3.8.4 (Deutsch)
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Template-Modifikationen durch TMS
© 2006 - 2018 vatsim-germany.org