Wie kann man vermeiden, von einem mächtigeren Mitwirkenden in Vergessenheit geraten zu werden?

Wie kürzlich hier berichtet :

Xamarin hat Cocos2D-XNA, ein 2D / 3D-Entwicklungsframework für Spiele, entwickelt und eine plattformübergreifende Bibliothek erstellt, die in PCL-Projekte einbezogen werden kann.

Der Gründer des gegabelten Projekts sagt jedoch :

Der Zweck der MIT-Lizenz ist es, Ihre faire Verwendung zu entlasten. Um Sie nicht zu ermutigen, Software zu nehmen, benennen Sie sie als Ihre eigene um und gehen Sie dann "eine neue Richtung", wie Sie sagen.

Es ist zwar nicht illegal, aber unethisch.

Es scheint, dass die GitHub- Seite des neuen Projekts nicht einmal anzeigt, dass es sich um eine Gabelung in einer typischen GitHub-Art handelt, sondern stattdessen einen leicht entfernbaren Verlaufsabschnitt wählt (siehe unten).

Meine Fragen sind also:

1. War Xamarins Handeln und die Art und Weise, wie es getan wurde, ethisch korrekt oder nicht?
2. Ist es möglich, eine solche Situation zu vermeiden, wenn Sie ein einzelner Entwickler oder eine kleine Gruppe von Entwicklern ohne Fonds sind?

Ich hoffe, dass dies entweder eine Wiki-Frage ist oder objektive Antworten auf der Grundlage der modernen OSS-Ethik / -Philosophie.

War Xamarins Handeln und die Art und Weise, wie es getan wurde, ethisch korrekt oder nicht?

Lassen Sie uns einen Experten fragen - Die Open Source Initiative listet die MIT-Lizenz selbst mit der vollständigen Lizenzangabe auf:

Die MIT-Lizenz (MIT)

Copyright (c)

Jeder Person, die eine Kopie dieser Software und der zugehörigen Dokumentationsdateien (die "Software") erhält, wird hiermit kostenlos die Erlaubnis erteilt, mit der Software uneingeschränkt umzugehen, einschließlich der Rechte zur Nutzung, zum Kopieren, Ändern und Zusammenführen Sie können Kopien der Software unter folgenden Bedingungen veröffentlichen, verbreiten, unterlizenzieren und / oder verkaufen und Personen gestatten, denen die Software zur Verfügung gestellt wird:

Der obige Copyright-Hinweis und dieser Erlaubnishinweis sind in allen Kopien oder wesentlichen Teilen der Software enthalten.

DIE SOFTWARE WIRD OHNE JEGLICHE AUSDRÜCKLICHE ODER STILLSCHWEIGENDE GARANTIE "WIE BESEHEN" ZUR VERFÜGUNG GESTELLT, EINSCHLIESSLICH DER GARANTIEN FÜR HANDELSFÄHIGKEIT, EIGNUNG FÜR EINEN BESTIMMTEN ZWECK UND NICHTVERLETZUNG. IN KEINEM FALL HAFTEN DIE AUTOREN ODER COPYRIGHT-INHABER FÜR JEGLICHE HAFTUNGSANSPRÜCHE, SCHÄDEN ODER ANDEREN HAFTUNGSSTÄNDEN, DIE AUS, AUS ODER IN VERBINDUNG MIT DER SOFTWARE ODER DEM GEBRAUCH ODER ANDEREN HANDELSSTÄNDEN DES VERTRAGS ENTSTEHEN SOFTWARE.

Wenn eine Person oder ein Unternehmen Software / Quellcode mit einer MIT-Lizenz veröffentlicht, bedeutet dies, dass eine andere Person oder ein Unternehmen "uneingeschränkt mit der Software handeln kann". Solange der Urheberrechtsvermerk intakt bleibt, können sie so ziemlich alles tun, was sie wollen.

Dies ist einer jener Fälle, in denen Ethik und Legalität ziemlich genau gleich sind. Wenn eine Person oder Gruppe die Lizenz oder ihre Auswirkungen nicht verstanden hat, hat sie ihre Due Diligence nicht durchgeführt. Die Open Source Initiative bietet viele weitere nützliche Ressourcen, um Lizenzen wie die MIT-Variante besser zu verstehen. Schauen wir uns ein paar Klauseln ihrer Open Source Definition an:

1) Kostenlose Weiterverteilung - Die Lizenz darf keine Partei daran hindern, die Software als Bestandteil einer aggregierten Softwareverteilung zu verkaufen oder weiterzugeben, die Programme aus verschiedenen Quellen enthält. Für diesen Verkauf ist für die Lizenz keine Lizenzgebühr oder sonstige Gebühr erforderlich.

3) Abgeleitete Werke - Die Lizenz muss Änderungen und abgeleitete Werke zulassen und die Weitergabe unter denselben Bedingungen wie die Lizenz der Originalsoftware ermöglichen.

5) Keine Diskriminierung von Personen oder Gruppen - Die Lizenz darf keine Person oder Personengruppe diskriminieren.

6) Keine Diskriminierung von Einsatzgebieten - Die Lizenz darf niemanden daran hindern, das Programm in einem bestimmten Einsatzgebiet zu nutzen. Beispielsweise darf es das Programm nicht daran hindern, in einem Unternehmen oder für die genetische Forschung verwendet zu werden.

Meines Erachtens ist das alles völlig klar: Wenn man etwas als Open Source veröffentlicht, insbesondere mit der MIT-Lizenz, kann man die Software frei nehmen, ändern, verpacken und verkaufen, so lange man möchte. ' t Ihren Copyright - Hinweis entfernen und behauptet , es selbst zu sein alleinige Arbeit.

Als Autor verzichten Sie ausdrücklich auf das Recht, wählerisch und wählerisch zu sein. Sie müssen sich nicht entscheiden, wer oder was von Ihrer Software profitieren oder sie nutzen kann, und Sie müssen sich nicht entscheiden, warum sie sie verwendet. Sie geben dieses Recht ausdrücklich auf.

Die Idee ist, dass Sie zum Wohle der Allgemeinheit beitragen, indem Sie ausdrücklich auf alle gesetzlichen Rechte verzichten, die Sie haben, um die Nutzung und Änderung Ihrer Ergebnisse zu kontrollieren und einzuschränken. Wenn Microsoft Ihr FluffBall-Projekt teilen und es für 2.000 USD pro Arbeitsplatz als WindowsSpongeCake verkaufen möchte, ist dies möglich. Haben Sie nicht die Leute überhaupt den ganzen Sinn Ihres Projekts tun lassen, was sie wollen?

Ist es möglich, eine solche Situation zu vermeiden, wenn Sie ein einzelner Entwickler oder eine kleine Gruppe von Entwicklern ohne Fonds sind?

So'ne Art! Verwenden Sie zunächst eine Lizenz, die Ihren Zielen und Wünschen entspricht. Wenn Sie nicht möchten, dass jemand es auf eine Weise verwendet, die Sie nicht gut finden, sollten Sie es wahrscheinlich nicht als Open Source veröffentlichen - und ehrlich gesagt sollten Sie es vielleicht überhaupt nicht veröffentlichen! Wenn Sie nicht möchten, dass jemand eine abgeleitete Arbeit (wie eine Gabel) für ein kommerzielles Projekt verwendet, sollten Sie sich wahrscheinlich für eine Copyleft-Version der GPL entscheiden . Wenn Sie eine nichtkommerzielle Lizenz wünschen, sollten Sie sich wahrscheinlich von einem Anwalt für Urheberrechte / Lizenzrecht beraten lassen, da dies häufig überhaupt nicht als "Open Source" -Software angesehen wird und es keine größere vorab geschriebene Lizenz zur Unterstützung dieses Falls gibt.

Das Problem mit dem Kerfuffle von Xamarin und Coco ist weder ethisch noch rechtmäßig - es handelt sich um einen Internet-Kampf zwischen ein paar Leuten, die ein Rindfleisch miteinander haben. Wir sind alle Menschen, es passiert. Dies scheint das Ergebnis einer mangelnden Zusammenarbeit zu sein, wahrscheinlich aufgrund eines Persönlichkeitskonflikts oder unvereinbarer Vorstellungen darüber, wie das Projekt gehandhabt werden soll.

Die andere Art der Verteidigung ist offen für Zusammenarbeit und Veränderungen, aber verstehen Sie, dass, wenn es nicht funktioniert und die Visionen auseinander gehen, dies der Grund für die Option ist, ein eigenes Projekt zu entwickeln und zu haben.

Es ist sehr menschlich und verständlich für das Gefühl von Eigenverantwortung und Beliebtheit, Softwareprojekte sehr, sehr kompliziert zu machen. Aber das Ziel von Open Source ist es, zu versuchen, dies zu übertreffen und zu ermöglichen, dass die beste Software für alle frei verfügbar ist.

Fazit: Machen Sie sich Ihre Ziele klar, wenn Sie sich für eine Lizenz entscheiden, und verstehen Sie deren Auswirkungen auf Ihre zukünftige Kontrolle und Ausrichtung des Projekts. Wenn Sie nur für das Allgemeinwohl spenden möchten, ist Open Source der richtige Weg. Wenn Sie Ihr Projekt genauer kontrollieren möchten und Eigentümer und zumindest einen Rechtsstreit haben möchten, wenn jemand versucht, Ihr Projekt zu vermarkten oder (teilweise oder vollständig) in sein eigenes zu übernehmen, benötigen Sie eine andere Lizenz und müssen dies wahrscheinlich tun mit einem Anwalt klären.

Wenn Sie ein Projekt unter der MIT-Lizenz veröffentlichen, erhalten Sie die Erlaubnis, das Projekt abzweigen. Teil der Philosophie hinter freier Software ist es, Benutzern und Entwicklern das Recht zu geben, die Software auf eine Weise zu verwenden, zu modifizieren und freizugeben, die normalerweise nicht zulässig ist. Wenn Sie dies nicht möchten, verwenden Sie nicht die MIT-Lizenz. Sie können sich nicht wirklich beschweren, wenn Leute Code unter den Bedingungen der Lizenz verwenden, die Sie ihnen gegeben haben.

Gabeln sind in der freien Software-Community eine ganz normale Sache. Es sieht so aus, als hätten die Entwickler der Gabel versucht, zum ursprünglichen Projekt beizutragen, und waren nicht damit einverstanden. Sie haben stattdessen zu ihrem eigenen Projekt beigetragen. Freie Software fördert dies, damit Entwickler nicht daran gehindert werden, Software zu ändern, weil die Eigentümer ihre Änderungen nicht mögen.

Wenn Sie etwas unter einer Lizenz für freie Software freigeben, profitieren Sie auch von den Beiträgen anderer, die Sie möglicherweise nicht erhalten hätten, wenn es unter einer anderen Lizenz gewesen wäre. Wenn Sie Beiträge unter einer Lizenz akzeptieren, sollten Sie die Bedingungen der Lizenz selbst einhalten.

Eine Möglichkeit, die Kontrolle über eine offizielle Version zu behalten, besteht darin, sich auf Marken zu verlassen. Die Mozilla Corporation hat zum Beispiel ein Markenzeichen für Firefox, mit dem sie bestimmen können, was die Leute mit Firefox tun können, obwohl es Open Source ist (siehe Iceweasel für die Übersicht).

Andere Lizenzen wie LGPL erlauben weiterhin Forks, lassen den Code jedoch offen. Auf diese Weise können Sie zumindest alle Änderungen von der Gabel in Ihr ursprüngliches Projekt übernehmen und von der Entwicklung auf der Gabel profitieren. LGPL-Code kann mit jedem MIT-lizenzierten Code verwendet werden. Wenn Sie also mehr Kontrolle über das Projekt haben möchten, können Sie stattdessen LGPL verwenden.

Ich würde es nicht als unethisch bezeichnen. Ich würde es unsportlich nennen. Es besteht die ungeschriebene Erwartung, dass Sie sich nach Treu und Glauben bemühen, die ursprüngliche Version zu verbessern, bevor Sie sich für die Abspaltung entscheiden. Der ursprüngliche Autor ist der Ansicht, dass keine nach Treu und Glauben erfolgten Anstrengungen unternommen wurden.

Der beste Weg, um zu vermeiden, dass Ihre Software verfälscht wird, besteht darin, auf Kundenanfragen so zu reagieren, dass Ihre Software so attraktiv wie möglich ist. Niemand wird einer Gabel Halt geben, wenn er weiß, dass das Original überlegen ist. Abgesehen davon besteht Ihr einziger Schutz darin, die Lizenzbedingungen zu ändern.

• War Xamarins Handeln und die Art und Weise, wie es getan wurde, ethisch korrekt oder nicht?

Viele Menschen bringen die rechtliche und ethische Situation in Konflikt. Mit der X11-Lizenz kann jeder "Kopien der Software verwenden, kopieren, ändern, zusammenführen, veröffentlichen, verteilen, unterlizenzieren und / oder verkaufen und Personen gestatten, denen die Software zur Verfügung gestellt wird" .

Ethisch gesehen ist es jedoch komplizierter. In Open-Source-Communities ist es im Allgemeinen vorzuziehen, die ursprüngliche Software zu verbessern, anstatt eine Abzweigung zu erstellen. In dem Link, den du gegeben hast , sagt Miguel de Icaza:

Wie Sie wissen, haben wir einen umfangreichen Beitrag zu Cocos2D-XNA geleistet und konnten einfach nicht weiter zusammenarbeiten.

Als wir an einem Punkt angelangt waren, an dem wir nicht mehr zusammenarbeiten konnten, beschloss ich, das Projekt auf Kosten der Abwärtskompatibilität in die von mir gewünschte Richtung zu lenken.

Es ist nicht klar, warum sie "nicht zusammenarbeiten konnten", aber es hört sich so an, als hätte Xamarin einen vernünftigen Aufwand betrieben, um an dem ursprünglichen Projekt zu arbeiten, bevor er sich entschied, es zu teilen.

• Ist es möglich, eine solche Situation zu vermeiden, wenn Sie ein einzelner Entwickler oder eine kleine Gruppe von Entwicklern ohne Fonds sind?

Rechtlich gesehen können Sie eine Lizenz verwenden, die keine Weitergabe zulässt, indem Sie die Weitergabe des Quellcodes nicht zulassen (dies wäre zu diesem Zeitpunkt keine "freie Software"). Eine andere Möglichkeit besteht darin, den Code unbelastet zu lassen, aber die Weitergabe statischer Elemente wie Bilder oder Nicht-Code-Text nicht zuzulassen (einige Spiele haben Lizenzen wie diese).

In sozialer Hinsicht können Sie das Gabeln verhindern, indem Sie:

• Machen Sie es Ihren Mitarbeitern einfach, Änderungen an Ihrem Projekt vorzunehmen.
• Schnelle Überprüfung von Patches.
• Änderungen zulassen, von denen Sie nicht direkt profitieren.
• Höflich sein. Eine überraschende Anzahl von Gabeln ist darauf zurückzuführen, dass Mitwirkende nicht mehr bereit sind, miteinander zu arbeiten.

Gabelungssoftware ist eine Menge Arbeit, und die meisten vernünftigen Leute werden dies nicht tun, wenn sie eine einfachere Option haben. Wenn sie keine andere Wahl haben, zwingt das Verhindern, dass sie Ihren Code verfälschen, sie dazu, entweder den Code eines anderen zu verfälschen oder Ihre Software von Grund auf neu zu schreiben. Es könnte sie verlangsamen, aber es wird dir nicht wirklich viel helfen.

Durch die Verwendung einer restriktiveren Lizenz wird auch die Wahrscheinlichkeit verringert, dass einige Personen Beiträge leisten. Xamarin hat anscheinend "viel zu Cocos2D-XNA beigetragen", und ich bezweifle, dass sie das getan hätten, wenn die Lizenz es ihnen nicht erlaubt hätte, es weiterzuverteilen.

Was Xamarin getan hat, ist legal und ethisch ... fast.

Werfen wir einen Blick auf das Commit- Fixup der Lizenz und auf verschiedene Tippfehlerbehebungen in der Readme-Datei :

LicenseAndCredit.txt ( versch .)

-Copyright (c) 2010-2012 cocos2d-x.org
-
-Copyright (c) 2008-2010 Ricardo Quesada
-Copyright (c) 2011      Zynga Inc.
-Copyright (c) 2011-2012 openxlive.com
-Copyright (c) 2012      Totally Evil Entertainment, LLC
-Copyright (c) 2012      Gena Minchuk
-Copyright 2012 Xamarin Inc
+Copyright (c) The Cocos2D-XNA Team

Es gibt nur eine Anforderung in der gesamten MIT-Lizenz:

Der obige Copyright-Hinweis und dieser Erlaubnishinweis sind in allen Kopien oder wesentlichen Teilen der Software enthalten.

Und Xamarin hat genau das Verbotene getan. Xamarin mag denken, dass es die Lizenz "hübscher" macht, wenn weniger Copyright-Vermerke oben stehen, aber sie haben keine (rechtliche oder ethische) Erlaubnis, die "Redundanz" zu entfernen.

Wenn sie die Lizenzdatei reparieren, befinden sie sich natürlich wieder im rechtlichen Bereich. Der Autor der Originalbibliothek mag nicht einverstanden sein, aber er hat die Wahl der Lizenz getroffen und kann niemandem die Schuld geben, dass er das getan hat, was die Lizenz ausdrücklich erlaubt.

Es wäre zwielichtig, den Menschen zu erlauben, falsche Schlussfolgerungen über die Urheberschaft des Codes zu ziehen, den die Gabelschiffe haben, selbst wenn die Gesetzmäßigkeiten abgedeckt werden, indem jedem, der genau hinschaut, die erforderlichen Hinweise und der Änderungsverlauf zur Verfügung gestellt werden. Vielleicht ist Xamarins Präsentation unethisch, vielleicht auch nicht, aber ich denke, das ist die Grundlage für die Beurteilung: Irreführung?

Die Lizenz legt die Erlaubnis zur Verwendung des Codes sowie die Verpflichtung fest, den Kopien des Codes relevante Copyright-Hinweise beizufügen. Das ist alles auf einem recht niedrigen Niveau. Es wird nicht besprochen, wie Sie öffentlich zusammenfassen sollen, wer was beigetragen hat, aber nur, weil dies außerhalb des Geltungsbereichs der Lizenz liegt und nicht Teil der rechtlichen Vereinbarung ist, bedeutet dies nicht, dass etwas ethisch korrekt ist . Die Ethik ist unterschiedlich, aber es ist ein weit verbreitetes Prinzip, ehrliche Anerkennung zu geben, wenn dies fällig ist. Es ist daher leicht einzusehen, warum dies nicht der Fall ist.

Wie jeder sagt, gibt es in der MIT-Lizenz keine Absicht, Gabeln zu verhindern, also ist das an sich nicht unethisch. Wenn "Rebranding it as your own" ein Code für "öffentliche Kreditforderungen, die Sie nicht verdienen" ist, dann wäre dies sicher unethisch, wenn es wahr wäre.

Um zu verhindern, dass Ihnen etwas zustößt: Wenn Sie verhindern möchten, dass jemand anderes unterstellt, Ihr Code gehöre ihm, brauchen Sie eine laute Stimme, wenn Sie Guthaben beantragen. Wenn Sie vermeiden möchten, dass jemand eine Abzweigung Ihres Codes erstellt, der sich irgendwann als populärer als Ihr Original herausstellt (entweder aufgrund der größeren Ressourcen oder weil er sich nur auf die "richtigen" Benutzeranforderungen konzentriert), sind Sie meiner Meinung nach out Glück in OSS. Sie können sich nicht einfach dafür entscheiden, richtig zu liegen, wenn eine andere Gruppe andere Funktionen in der Software haben möchte, als Sie möchten, und wenn Sie sich (aus Sicht der Benutzer) irren, sollten Sie verlieren, unabhängig davon, ob Sie zuerst da sind. Dies ist eine Folge des primären Open-Source-Prinzips (oder eigentlich des Prinzips der freien Software), dass der Autor die Software nicht kontrolliert, sondern die Leute, die sie ausführen.

Eine Erweiterung des Markenthemas:

Bei der Apache Software Foundation ist der gesamte Code AL. Und wie bei der hier diskutierten BSD-Lizenz ist es völlig klar, dass die AL Gabeln zulässt. Zeitraum. Ende der Diskussion. In der Tat erlauben , wie in anderen Antworten diskutiert, alle echten Open-Source-Lizenzen Gabeln. Alles, was sie kontrollieren, ist die Lizenz / Nutzung des Forked-Codes.

Die Apache Foundation hat beschlossen, Marken zu registrieren und zu verteidigen. Wenn eine andere Entität als ein Foundation-Projekt "Apache Tomcat" gibt, ist das in Ordnung ... aber sie können es nicht als Apache Tomcat bezeichnen , und wenn wir die Marke verteidigen können, können sie es nicht als Tomcat bezeichnen .

Das Problem dabei ist, dass Markenzeichen nichts für schwache Nerven sind. Wenn Sie eine kleine Gruppe von Personen sind, die keine rechtliche Struktur und keine Finanzierung haben, können Sie das Markenrecht praktisch nicht anwenden, um Ihren Namen zu schützen.

Letztendlich ist so etwas einer der Gründe für die verschiedenen Stiftungen da draußen.

Aus ethischer Sicht, wenn es eine interne Spaltung zwischen den Mitwirkenden gibt, wer soll dann sagen, wer "verdient", den Namen zu behalten? Wenn sich andererseits ein Außenseiter gabelt, ist es wahrscheinlich nicht die ethischste Sache der Welt, den Namen unverändert zu lassen. Es ist auch keine abscheuliche Tat.

Github ist voller Gabeln . Manchmal ändern die Benutzer den Namen oder das Java-Paket oder was auch immer - insbesondere, wenn sie in Maven Central veröffentlichen möchten. Oft tun sie dies nicht und die Benutzer navigieren in einem Labyrinth der Verwirrung. Es ist nicht ideal, aber das ist der Bruch mit der Anarchie.