|
DasIch
Anmeldungsdatum: 2. November 2005
Beiträge: 1130
|
Seriennummern und DRM Systeme sind allesamt relativ leicht knackbar und damit kommt man nicht mehr an den Code und es ist kein Open Source, den Code aufteilen in Open Source und geschlossenen Teil der Sicherungsmechanismen hat ist sinnlos wenn letzterer nicht essentielle Teile implementiert und damit den Open Source Teil quasi sinnlos macht. Schlimmernoch Seriennummern mit einem Multiplayer Spiel zu verwenden führt allzuleicht zu Kollisionen, sobald der Algorithmus kompromittiert ist und damit zu sehr unzufriedenen Kunden. Wenn du die Assets rauslässts wird es für die allermeisten wieder uninteressant und du hast gar nichts erreicht oder es formiert sich eine Gruppe die freie Assets entwickelt und dann hast du wieder ein Problem und das jemand sein Copyright einfach abgibt wirst du nicht erreichen. Ein Multiplayer System mit freiem Client ohne Server ist sinnlos, da man dann keine neuen Elemente ins Spiel einbringen oder die Spielregeln verändern kann.
|
|
Basinator
(Themenstarter)
Anmeldungsdatum: 22. November 2009
Beiträge: Zähle...
|
Seriennummern und DRM Systeme sind allesamt relativ leicht knackbar
Worin aber kein Unterschied zu den closed-source-Spielen besteht, nicht wahr? 😉
damit kommt man nicht mehr an den Code und es ist kein Open Source,
Damit kommt man gewiss nicht an den Kode...^^
Ja, der Teil der Anwendung wäre kein O-S, aber ich wüsste nicht, warum es sinnig sein sollte, gerade einen solchen Teil open-source zu publizieren - Denn damit wäre der Sinn wohl ausgehebelt.
den Code aufteilen in Open Source und geschlossenen Teil der Sicherungsmechanismen hat ist sinnlos wenn letzterer nicht essentielle Teile implementiert und damit den Open Source Teil quasi sinnlos macht.
Wenn es dir nciht zu schwer fällt, kannst du ein paar Kommas setzen? Verstehe den Sinn dieses Satzes nicht ganz.
Was willst du als freier Programmierer denn bitte an den Sicherheitsmechanismen (NICHT anti-cheat) schrauben, was das Produkt für dich besser macht? Gibt vllt. einige Dinge, aber sicherlich weitesgehend uninteressant.
Wenn du diese Dinge offen weitergibst als Publisher, dann lädst du ja gerade dazu ein, dass man deine eigenen Server umgeht und die Leute für lau zocken (aufgrund Raubkopien des Spieles, die dann ja auch über einen MP-Modus verfügen).
Schlimmernoch Seriennummern mit einem Multiplayer Spiel zu verwenden führt allzuleicht zu Kollisionen, sobald der Algorithmus kompromittiert ist und damit zu sehr unzufriedenen Kunden.
Wie viele Spiele nutzen Seriennummern und bei denen funktioniert es wunderbar? Oder redest du davon, dass Keygens erstellt würden? Dasselbe Problem bei proprietären Spielen. Der Prozess zur Erstellung der Schlüssel würde ja sowieso nicht dem Spiel beiliegen, wäre ja sinnlos.
Ein Multiplayer System mit freiem Client ohne Server ist sinnlos, da man dann keine neuen Elemente ins Spiel einbringen oder die Spielregeln verändern kann.
Mir fällt eine bessere Idee ein: Ein Master-Server, der jedoch den Serienschlüssel abfragt. Zumidnest sollten Spieler dann nicht fähig sein, den Schlüssel aus den bekanntesten Webadressen heraus zu suchen, weil sie sicherlich nicht der Einzige mit dem Schlüssel wären.
Ansonsten ggf. auch freier LAN-Modus, wo Server verwendet werden können, birgt aber Sicherheitsrisiken (mehr kritscher offen Kode, VPN-Netzwerke)
Wenn du die Assets rauslässts wird es für die allermeisten wieder uninteressant und du hast gar nichts erreicht oder es formiert sich eine Gruppe die freie Assets entwickelt und dann hast du wieder ein Problem und das jemand sein Copyright einfach abgibt wirst du nicht erreichen.
Assets = die angesprochenen Media? Könnte man sicherlich alles in die Lizenz mit aufnehmen - Kein Ersetzen dieser erlaubt, außer sie kommen vom Entwickler. Möglicherweise wäre auch denkbar, dass der FOSS-Autor eine kleine Aufwands-Entschädigungssumme erhält, wenn er die Media an den Publisher übergibt.
|
|
ChemicalBrother
Ehemaliger
Anmeldungsdatum: 17. Mai 2007
Beiträge: 3136
|
Basinator schrieb: Ich habe mehrere Möglichkeiten aufgelistet. Dazu gehört auch eine, dass nur der Kode [...] weitergegeben werden dürfen
Widerspricht das nicht dem, was ich vorher zitiert habe? Ich bin verwirrter denn je. Ich dachte, der Code soll bei den Erstellern des Spiels bleiben (und damit closed source).
|
|
kamijou
Anmeldungsdatum: 30. Dezember 2010
Beiträge: 232
|
Basinator schrieb:
Das ist der Denkfehler. Du gehst davon aus, dass der Quellkode beliebig weitergegeben werden darf. Oder mitsamt dem Kode auch die Media, Sound, Grafiken, Animationen, Textpassagen etc.
Es gibt ja mehr als nur die GNU GPL, der Entwickler kann eine eigene Lizenz verwenden.
Kein Denkfehler. Denn wenn der Quellcode nicht beliebig weitergegeben werden darf, wo soll dann der Anreiz für eine Community liegen, sich damit überhaupt zu beschäftigen? Entweder ist der Quellcode frei und offen mit allen Konsequenzen oder eben nicht. Ich lasse es mir eingehen, dass die Assets nicht Bestandteil einer Veröffentlichung als Open Source sind, aber der Quellcode? Wenn der Quellcode das Alleinstellungsmerkmal sein soll, um den sich eine Community bilden soll, dann gibt's entweder nur ganz oder gar nicht.
|
|
DasIch
Anmeldungsdatum: 2. November 2005
Beiträge: 1130
|
Basinator schrieb: Seriennummern und DRM Systeme sind allesamt relativ leicht knackbar
Worin aber kein Unterschied zu den closed-source-Spielen besteht, nicht wahr? 😉
In denen muss man aber noch den Code dekompilieren, müsste man hier nicht.
den Code aufteilen in Open Source und geschlossenen Teil der Sicherungsmechanismen hat ist sinnlos wenn letzterer nicht essentielle Teile implementiert und damit den Open Source Teil quasi sinnlos macht.
Wenn es dir nciht zu schwer fällt, kannst du ein paar Kommas setzen? Verstehe den Sinn dieses Satzes nicht ganz.
Was willst du als freier Programmierer denn bitte an den Sicherheitsmechanismen (NICHT anti-cheat) schrauben, was das Produkt für dich besser macht? Gibt vllt. einige Dinge, aber sicherlich weitesgehend uninteressant.
Wenn du diese Dinge offen weitergibst als Publisher, dann lädst du ja gerade dazu ein, dass man deine eigenen Server umgeht und die Leute für lau zocken (aufgrund Raubkopien des Spieles, die dann ja auch über einen MP-Modus verfügen).
Wenn du ausschliesslich den DRM Teil im geschlossenen Code hast kann man den einfach weglassen. Damit dass nicht geht, musst du für das Spiel essentielle Funktionen im geschlossenen Teil implementieren.
|
|
Basinator
(Themenstarter)
Anmeldungsdatum: 22. November 2009
Beiträge: 535
|
ChemicalBrother schrieb: Basinator schrieb: Ich habe mehrere Möglichkeiten aufgelistet. Dazu gehört auch eine, dass nur der Kode [...] weitergegeben werden dürfen
Widerspricht das nicht dem, was ich vorher zitiert habe? Ich bin verwirrter denn je. Ich dachte, der Code soll bei den Erstellern des Spiels bleiben (und damit closed source).
Sind mehrere Ansätze, obgleich ich momentan dazu tendiere, dass der mit den Seriennummern wohl der Sinnigste wäre.
Kein Denkfehler. Denn wenn der Quellcode nicht beliebig weitergegeben werden darf, wo soll dann der Anreiz für eine Community liegen, sich damit überhaupt zu beschäftigen? Entweder ist der Quellcode frei und offen mit allen Konsequenzen oder eben nicht. Ich lasse es mir eingehen, dass die Assets nicht Bestandteil einer Veröffentlichung als Open Source sind, aber der Quellcode? Wenn der Quellcode das Alleinstellungsmerkmal sein soll, um den sich eine Community bilden soll, dann gibt's entweder nur ganz oder gar nicht.
Siehe oben.
Wenn du mir ein Geschäftsmodell nennen kannst, wo man auch die Sicherheitsaspekte unter offenem Quellkode stellen kann, dann nur her damit. Aber in dem Moment, wo du dies tust, tust du dich - IMHO - als Publisher einer großen Gefahr aussetzen, da das Spiel dann von jedem für lau gezockt werden kann.
Daher halte ich es ncith für verkehrt, wenn einzelne, sehr wenige, nicht elementare Bestandteile des Spieles closed-source bleiben. Wir reden hier vermutlich von höchstens 2 Megabyte bei mindestens 300 MB Daten des Spieles.
Auch: Wofür willst du als FOSS-Dev den Quellkode dazu haben (vom Prinzip selbst her, dass alles Open-Source sein soll, abgesehen)? Zumindest mir fällt dort nur ein, dass du das Spiel kostenfrei für dich oder andere zugänglich machen möchtest, aber vielleicht habe ich da ja auch etwas wichtiges vergessen, dann zeige es mir nur gerne auf.
In denen muss man aber noch den Code dekompilieren, müsste man hier nicht.
Bei Seriennummern? Liege ich da falsch, oder liegt der Algorithmus zur Erstellung dieser wirklich im Kode/der Software selbst und nicht nur rein beim Publisher?
Außerdem, wie schon gesagt, möglicherweise müssten gewisse Kleinigkeiten, worunter acuh dies fallen mag, closed-source bleiben. Für viele sicherlich nicht optimal, aber ich finde, dass es neutral betrachtet, kaum eine andere Lösung gibt - Zumindest ist mir noch keine andere eingefallen.
Wenn du ausschliesslich den DRM Teil im geschlossenen Code hast kann man den einfach weglassen. Damit dass nicht geht, musst du für das Spiel essentielle Funktionen im geschlossenen Teil implementieren.
Ich habe zwar nicht so viel wissen um DRM, aber warum müssen essentielle Teile (= für mich Kodeabschnitte, die das Spiel selbst beeinflussen) dadurch closed-source werden? GIbt doch z. B. den DRM-Schutz, dass während des Spieles oder der INstallation eine Verbindung mti dem Internet vorhanden sein muss (Nein, damit meine ich gewiss nicht, dass ich ein Fan davon wäre).
|
|
kamijou
Anmeldungsdatum: 30. Dezember 2010
Beiträge: 232
|
Basinator schrieb:
Wenn du mir ein Geschäftsmodell nennen kannst, wo man auch die Sicherheitsaspekte unter offenem Quellkode stellen kann, dann nur her damit. Aber in dem Moment, wo du dies tust, tust du dich - IMHO - als Publisher einer großen Gefahr aussetzen, da das Spiel dann von jedem für lau gezockt werden kann.
Ich habe keine Ahnung, was Du willst und warum Du versuchst, mir die Worte im Mund umzudrehen. Ich habe schon ganz zu Anfang geschrieben, dass ich genau zwei Möglichkeiten sehe: entweder gar keine Veröffentlichung des Codes oder Veröffentlichung, nachdem das Spiel kommerziell ausgewertet wurde (siehe id Software).
Daher halte ich es ncith für verkehrt, wenn einzelne, sehr wenige, nicht elementare Bestandteile des Spieles closed-source bleiben. Wir reden hier vermutlich von höchstens 2 Megabyte bei mindestens 300 MB Daten des Spieles.
Wenn sie nicht elementar sind, wieso sollten sie dann dann closed source bleiben?
Auch: Wofür willst du als FOSS-Dev den Quellkode dazu haben (vom Prinzip selbst her, dass alles Open-Source sein soll, abgesehen)? Zumindest mir fällt dort nur ein, dass du das Spiel kostenfrei für dich oder andere zugänglich machen möchtest, aber vielleicht habe ich da ja auch etwas wichtiges vergessen, dann zeige es mir nur gerne auf.
Ja, wofür denn sonst!? Soll das jetzt hier eine Parodie werden? "Kommerzielle Open-Source-Spiele". Dein Thema. "Freies und quelloffenes Spiel". Deine Worte. Wenn das nicht den Quellcode ohne Einschränkungen beinhaltet, was denn bitte dann? Woran sollte ein FOSS-Entwickler sonst Interesse haben, wenn nicht am Quellcode?
|
|
Basinator
(Themenstarter)
Anmeldungsdatum: 22. November 2009
Beiträge: 535
|
kamijou schrieb: Basinator schrieb:
Wenn du mir ein Geschäftsmodell nennen kannst, wo man auch die Sicherheitsaspekte unter offenem Quellkode stellen kann, dann nur her damit. Aber in dem Moment, wo du dies tust, tust du dich - IMHO - als Publisher einer großen Gefahr aussetzen, da das Spiel dann von jedem für lau gezockt werden kann.
Ich habe keine Ahnung, was Du willst und warum Du versuchst, mir die Worte im Mund umzudrehen. Ich habe schon ganz zu Anfang geschrieben, dass ich genau zwei Möglichkeiten sehe: entweder gar keine Veröffentlichung des Codes oder Veröffentlichung, nachdem das Spiel kommerziell ausgewertet wurde (siehe id Software).
Mir geht es um ein Modell, bei dem der SC schon zu Beginn offen liegt. Kann die Abneigung egtl. nicht vollständig nachvollziehen. War war das letzte Spiel, - ohne angreifend sein zu wollen - was du dir gekauft hast (nicht Humble Bundle)?
Daher halte ich es ncith für verkehrt, wenn einzelne, sehr wenige, nicht elementare Bestandteile des Spieles closed-source bleiben. Wir reden hier vermutlich von höchstens 2 Megabyte bei mindestens 300 MB Daten des Spieles.
Wenn sie nicht elementar sind, wieso sollten sie dann dann closed source bleiben?
Nicht elementar für das Gameplay, hätte mich da wohl etwas klarer ausdrücken sollen. IMHO muss man eben Kompromisse eingehen, wenn der Quellkode bereits zu Beginn offen vor liegen soll - Da muss man Beschränkungen setzen, auch wenn diese einem selber anpissen - Nur ganz ohne diese wird es eben nicht gehen.
Auch: Wofür willst du als FOSS-Dev den Quellkode dazu haben (vom Prinzip selbst her, dass alles Open-Source sein soll, abgesehen)? Zumindest mir fällt dort nur ein, dass du das Spiel kostenfrei für dich oder andere zugänglich machen möchtest, aber vielleicht habe ich da ja auch etwas wichtiges vergessen, dann zeige es mir nur gerne auf.
Ja, wofür denn sonst!? Soll das jetzt hier eine Parodie werden? "Kommerzielle Open-Source-Spiele". Dein Thema. "Freies und quelloffenes Spiel". Deine Worte. Wenn das nicht den Quellcode ohne Einschränkungen beinhaltet, was denn bitte dann? Woran sollte ein FOSS-Entwickler sonst Interesse haben, wenn nicht am Quellcode?
Es kommt auf die Defintionen von frei und open-source an - Meiner Auffassung nach wird beinhaltet dies hauptsächlich das Offenliegen des Kodes. Ist ja nicht so, dass der FOSS-Entwickler keinen Zugriff auf überhaupt einen Kode hätte - Nur eben nicht auf wenige Teile, schätzungsweise maximal 2 % der Produktes. Mag sein, dass meine Ideen und Konzepte nicht perfekt und mir selbst auch nicht vollständig zusagen - Aber mir wäre es persönlich deutlich lieber, wenn ich ein Spiel kaufen würde, dass wenigstens zu einem Großteil offen ist als eines, was ohne Ausnahme closed-source ist. Ich weiß durchaus, dass die Konzepte nicht ganz den Geist von FOSS-Entwicklern wiederspiegeln, aber ich denke eben, dass es dafür in der Praxis eventuelle möglich wäre, diese Konzepte durchzusetzen - Was bei einem absolut offenem Spiel sich eher als schwierig gestalten würde.
|
|
ChemicalBrother
Ehemaliger
Anmeldungsdatum: 17. Mai 2007
Beiträge: 3136
|
Basinator, du widersprichst dir zum einen, zum anderen habe ich das Gefühl, dass du das Konzept von open source noch nicht so ganz begriffen hast. Was bringt es, wenn der (wenn auch nur ein kleiner Teil) Code offen ist und für jeden zugänglich ist? Entwickler können sich den Code ansehen, davon lernen, ihn verbessern, ihn für verschiedene Plattformen portieren (zB für Linux oder für 64bit oder, oder, oder...), etc. pp. Und Code, der nur für bestimmte Entwickler zur Verfügung steht, ist nicht open source. Das ist ganz einfach closed source. Du solltest dir erstmal klar werden, was die Begriffe bedeuten (und was vorallem open source Entwicklung bedeutet).
|
|
Basinator
(Themenstarter)
Anmeldungsdatum: 22. November 2009
Beiträge: 535
|
?
Was bringt es, wenn der (wenn auch nur ein kleiner Teil) Code offen ist und für jeden zugänglich ist? Entwickler können sich den Code ansehen, davon lernen, ihn verbessern, ihn für verschiedene Plattformen portieren (zB für Linux oder für 64bit oder, oder, oder...), etc. pp. Und Code, der nur für bestimmte Entwickler zur Verfügung steht, ist nicht open source. Das ist ganz einfach closed source. Du solltest dir erstmal klar werden, was die Begriffe bedeuten (und was vorallem open source Entwicklung bedeutet).
In einigen meiner Vorschlägen ist genau dies der Fall. Ich denke, dass die Begriffe Entwickler und Dev etwas irreführend waren. \\Von jetzt an: FOSS-Dev = open-source-Entwickler, Fan-Coder Komm-Dev = Die, die das Spiel von Anfang an entwickeln und vollen Zugriff auf den Kode haben. In vielen/den Meisten/allen (?) meiner Modelle haben FOSS-Devs auch Zugriff auf den Kode - Auf fast den gesamten. Nur nicht auf kritische Kode-Teile, die den kommerziellen Erfolg gefährden - Dinge wie Seriennummer/CD-Key, Verbindungsinformationen zum offiziellen Masterserver (damit niemand einen anderen Masterserver bereitstellen kann) etc. pp.
Masterserver = Der Server, der dafür zuständig ist, dass die einzelnen Gameserver für den Clienten sichtbar werden. Beispiel: Counter-Strike: Die Gameserver würden auch ohne den Masterserver existieren, aber man könnte (intern) die anderen Server nicht mehr sehen. Wenn der Masterserver down ist, hat man einfahc nur eine leere Serverliste.
|