WinGet: Microsoft soll Package Manager von AppGet gestohlen haben

Auf der BUILD 2020, welche in der vergangenen Woche als virtuelles Event stattgefunden hat, hatte Microsoft wieder zahlreiche Ankündigungen und Neuerungen für Entwickler vorgestellt, die neben Produkten wie Microsoft Edge und den PowerToys auch verschiedene Werkzeuge für die Kommandozeile betrafen....

Klicke hier, um den Artikel zu lesen

Da bin ich mal gespannt wie man sich einigen wird - wenn nicht Code 1:1 uebernommen wurde duerfte das rechtlich gesehen analog zu Oracle/Google bzgl. Java laufen. D.h. die API Nutzung (worunter ja auch die Struktur des Paketes etc.) faellt ist rechtlich nicht zu beanstanden.
Moralisch sieht das ganze aber echt nicht so gut aus. Da ist zu hoffen das Microsoft irgendeine saubere Loesung findet. Geld dazu sollte ja genug vorhanden sein...

Traurige Geschichte (Wenn das alles so stimmen sollte). Leider reicht es halt schon, wenn ein Mitarbeiter von vielen "Mist baut". Bei der "Aufklärung" könnte man ja jetzt zeigen, dass es besser geht.

Kuriosität am Rande (zumindest für mich): Warum dauert es Monate bis zur Einstellung? So viele AppGet-Entwickler stehen ja auch nicht zur Auswahl.

Normalerweise wird eine Übernahme von Know How in Entwicklungen eines potentiellen Vertragspartners nach Gesprächen zur Geschäftsanbahnung durch eine Geheimhaltungsvereinbarung ausgeschlossen. Würde mich sehr wundern, wenn eine solche hier nicht unterschrieben wurde und einen oben beschriebenen Vorgehen seitens Microsoft nicht entgegenatünde.

@MikeG
Eine Geheimhaltungsvereinbarung werden sie mit Sicherheit nicht unterzeichnet haben. AppGet ist ein nichtkommerzielles OpenSource-Projekt und generell erfolgt der Transfer von Technologien bei solchen Projekten nicht im Geheimen, sondern öffentlich und auf Basis der jeweiligen Lizenzen, die der Entwickler dem Projekt beifügt. WinGet steht unter der MIT-Lizenz, AppGet unter der APL 2.0, beide Lizenzen sind zueinander kompatibel und die Übernahme von Code entsprechend erstmal kein Problem, solange sich die Entwickler an die Bedingungen der jeweiligen Lizenz halten. Erst wenn AppGet kommerzielle Zusatzdienste durch eine zusätzliche Klausel absichert, wäre eine solche Vereinbarung wieder notwendig, aber meistens mündet das dann wie bei MongoDB oder Redis in einer eigenen Lizenz oder man nimmt eine andere Lizenz als die APL 2.0 (zum Beispiel die BSD-Lizenz, die dafür gerne u.a. von Facebook verwendet wurde).

Die Frage ist vor allem, ob Microsoft in WinGet einen offiziellen Fork von AppGet erstellt hat oder nicht. Was den Paketmanager selbst betrifft, habe ich da mittlerweile meine Zweifel, denn soweit ich das überblicken konnte, wurde AppGet in C# und WinGet aufgrund der Tatsache, dass er auf dem AppInstaller von Windows 10 aufsetzen soll, in C++ geschrieben. Damit wäre das kein Fork, sondern nur ein extrem vom Design eines Konkurrenten inspirierter Neuling, so wie Keivan Belgi das auch im Blogpost schreibt. Das Gleiche kannst du beim jeweiligen Repository für die Packages sagen. WinGet verwendet für die Installation PowerShell-Skripte, bei AppGet sind es YAML-Dateien, wie sie zum Beispiel auch bei den Ansible Playbooks verwendet werden, um Verteilungen in lokalen Netzwerken vorzunehmen. Auch hier steht wieder die MIT bei WinGet gegen die APL 2.0 von AppGet, es fand aber aufgrund der unterschiedlichen technischen Basen höchstens eine ganz massive Inspiration von Ideen von AppGet statt. Auch das wäre kein offizieller Fork.

Heißt auf Deutsch: Rein rechtlich wäre das Vorgehen von Microsoft, was die technische Umsetzung von WinGet angeht, absolut sauber. Was den Umgang mit Keivan Belgi als Entwickler angeht, das steht menschlich und moralisch auf einem anderen Blatt. Die Absage an ihn hätten sie im Sinne der Fairness nicht auf die lange Bank schieben sollen.