Nein, das reicht nicht. Was gegen die GPL verstößt, ist die Tatsache, daß man die App nicht an jemand anderen weiterreichen kann, weil Installation nur über den Store geht. Spezifisch gegen GPLv3 verstößt außerdem noch, daß man aus den Sourcen kein direkt installationsfähiges Binary bauen kann.

Der Grund, wieso es GPL-Apps gibt, ist der, daß deren Autoren eine Doppellizenz verwenden. Speziell für iOS. Tun sie das nicht, ist die App ganz schnell aus dem Appstore verschwunden, wie VLC oder GNU Go.

Einige iOS Apps mit GPL Code die im AppStore sind , haben ihr Projekt so öffentlich gemacht das man ein installationsfähiges Binary erstellen kann. Reicht das auch nicht?

__________________
1.e4e5=

Nein, weil der normale Nutzer weder Binaries von außerhalb des Stores installieren kann noch vorhandene Programme auf seinem iDevice an andere Nutzer weitergeben kann. Das ist gegen GPLv2 und GPLv3. Genau das sagt die FSF ja auch bezüglich GNU Go:
https://www.fsf.org/news/2010-05-app-store-compliance
https://www.fsf.org/blogs/licensing/...pl-enforcement

Selbst mit Installation über Entwickler-ID ist man immer noch an einen funktionierenden Apple-Account gebunden, um das AppPaket vor der Installation erstmal zu signieren. Das fällt bei GPLv3 unter das Tivoisierungsverbot, weil nämlich effektiv Apple entscheidet, wer signieren darf und wer nicht.

Es gibt daher keine GPL-Projekte unter iOS, sondern die jeweiligen Entwickler veröffentlichen das mit einer Duallizenz. Das ist z.B. bei Stockfish so, weil die drei Autoren sich einig sind, daß sie das so akzeptieren. In dem Moment, wo auch nur einer der drei auf die Einhaltung der GPL pochen würde, würde Apple die Stockfish-App aus dem Appstore genauso entfernen wie VLC oder GNU Go.

Der Store-Zwang hat als Nebenwirkung übrigens auch noch, daß man als Entwickler 100 Euro jedes Jahr zahlen muß, zusätzlich zu den 30%, die Apple bei den App-Verkäufen abzieht. Und man braucht einen Mac.

Außerdem erlaubt Apple keine Anwendungen, die andere Anwendungen starten, so daß man die normale GUI/Engine-Aufteilung nicht haben kann und auch noch eine GUI schreiben muß, die dann überhaupt erstmal durch Apples Review gelangen muß.

Bei Android? Wenn man sowieso schon eine Linux-Version der Engine hat, compiliert man sie einfach mit Googles NDK durch, das es für Windows, Linux und Mac gibt. Dann schiebt man die Engine z.B. über USB rüber und installiert sie in Chess for Android oder Droidfish. Der Nutzer muß sich dann auch nicht für jede Engine wieder an eine andere GUI gewöhnen - allein schon deswegen ist Android für Schach die bessere Wahl.

Wir haben aktuell beim Pewatronic Grandmaster die Engine CT800 von der v1.12 auf die v1.34 zu aktualisiert. Dabei haben wir die Option "UCI_Elo" implementiert. Leider spielt die Engine bei eingestellten 1000 Elo viel zu stark. Woran kann das liegen?

Miniaturansicht angehängter Grafiken

 

Hallo Peter,

sehr gut, ist ein deutlicher Zugewinn, da Rasmus viel an der Engine gearbeitet hat.

Die Frage muss Rasmus beantworten. Aber auf der DGT PI wird diese Funktion nicht unterstützt.

Gruß
Micha

Ich glaube ich habe den Fehler gefunden: UCI_LimitStrength ist ein bool, welches "true"/"false" erwartet. Jedoch übergebe ich "0" und "1". Ich werde das am Wochenende mal ausprobieren.

Sofern alles klappt, wird es nächste Woche vorraussichtlich ein Update vom Pewatronic Grandmaster geben (Update ist fertig, es hapert nur noch am Feinschliff).

__________________
Software-Entwickler des Pewatronic Grandmaster

Ja, "0" oder "1" wird der UCI-Parser ignorieren und den eingestellten Wert nicht verändern. Da der Default nach dem Starten "keine Elo-Begrenzung aktiv" ist, wird die Engine dann ungedrosselt spielen.

Cool! :-) Für die höheren Spielstufen wäre es gut, wenn man der Engine über UCI mehr Hash erlaubt. Von selber genehmigt sie sich lediglich 6 MB. Wobei sich die Engine oft weniger als den eingestellten Wert nimmt, weil die Hash-Größe keine Zweierpotenz ist.

Etwa bei
setoption hash value 256
werden real nur 165 MB alloziert, nicht 256.
Mit
setoption hash value 512
werden es dann 329 MB.

Jedenfalls ist das in V1.34 so - muß aber nicht zwingend so bleiben. Garantiert ist nur, daß die Engine sich nicht mehr nimmt als erlaubt.

Es wäre für maximale Performance außerdem wohl gut, mit einem aktuelleren GCC auf dem Zielsystem (!) durchzucompilieren; das fertige Executable für Raspi ist mit einem bereits etwas älteren GCC erstellt.

Das passende Buildscript dafür ist make_ct800_raspi.sh .

Hallo Rasmus,

noch eine Nachfrage. Der Parameter UCI_LimitStrength wird auf der DGT Pi mit false ausgeworfen. Was mich zu der Annahme führt, dass dieser Parameter nicht unterstützt wird. Verstehe ich es richtig oder falsch?

Danke.

Gruß
Micha

Hi Micha,

Ich nehme an, Du meinst die folgende Zeile in der Engine-Ausgabe nach "uci"?

option name UCI_LimitStrength type check default false

Das deklariert, daß der Parameter als Checkbox verfügbar ist, deren Default-Wert "false" ist, d.h. per default ist die Elo-Begrenzung nicht aktiv. Eine GUI würde also diese Checkbox als nicht gecheckt anzeigen.

"type check" impliziert auch, daß die beiden möglichen Werte, die die GUI einstellen kann, "true" oder "false" sind.

Grüße, Rasmus

Danke Rasmus, super erklärt.

Gruß
Micha