Meinungen zum Thema "Audacity"?

[hikaru]

Dort sind die entsprechenden Stellen im Code verlinkt:
https://github.com/audacity/audacity/bl ... er.cpp#L69
und hier:
https://github.com/audacity/audacity/bl ... #L224-L239

Explizit erfasst werden hier Betriebssystem, Version und Architektur. Hinzu komt ein User Agent String (wie bei Webbrowsern), welcher laut Audacity sowas wie "Audacity 3.03" enthalten wird und dazu dienen soll, DDOS-Angriffe auf den Update-Server abzuwehren (wer nicht "Audacity" heißt wird geblockt). Die Darstellung erscheint mir plausibel. Die IP-Adresse wird vermutlich serverseitig erfasst.

Wenn man sich also damit abgefunden hat, dass ein Updatemechanismus über das Netz zwangsweise gewisse Daten generiert, dann sieht das aus Datanschutzsicht recht harmlos aus.
Man wäre aber auch schön dämlich, hier ausgerechnet problematische Codestellen zu verlinken. Die mag es geben, oder auch nicht. Nichts von dem hier Erfassten taugt z.B. für juristsiche Zwecke, mal abgesehen vielleicht von einer ziemlich vagen Überprüfung, ob ein Rechner online war oder nicht.

Spyware

Du bist nach wie vor den Nachweis schuldig um die Einordnung von Audacity als Spyware zu rechtfertigen.

Spätestens dann ist das Projekt aber sowieso für Debian gestorben, weil nur Software unter freier Lizenz enthalten ist. Um einen Fork der letzten GPL-Version wird man also sowieso nicht herum kommen, wenn man das Programm weiterhin im Repo haben will.

Das sehe ich nicht so. Aktuell steht Audacity unter GPLv2. Demnächst soll es unter GPLv3 gestellt werden, weil die zur Einbindung geplante VST3-Schnittstelle ebenfalls unter GPLv3 steht und GPLv2 und GPLv3 bei ausschließlicher Lizensierung zueinander inkompatibel sind.

Zusätzlich soll ein CLA jeden der zu Audacity beiträgt dazu zwingen, weiteren (auch proprietären) Relizensierungen zuzustimmen. Dagegen regt sich gerade Widerstand. Aber das CLA ist rein formal für Debian irrelevant, denn der zukünftig unter GPLv3 stehende Code wird davon nicht eingeschränkt, sondern nur dessen Autoren.
Das CLA wird für Debian nur insofern relevant, wenn (z.B. in Folge eines Bugreports) ein Debian-Maintainer Upstream-Code ändern möchte. Dann muss er nämlich dem CLA zustimmen. Aus Debian-Sicht ist das dann aber seine "Privatangelegenheit" und keine Angelegenheit des Codes.

Alles in Allem finde ich die aktuelle Situation hässlich, aber ich sehe hier nichts, das man rein formal beanstanden könnte. Die meisten FLOSS-Lizenzen und andere Regelwerke (DFSG) stammen ihrem Charakter nach aus den 80ern und sind gegen moderne Winkelzüge (CLAs, Tivoisierung) machtlos, weil damals keiner an sowas gedacht hat.

[willy4711]

Ich möchte mich der Meinung von @ hikaru anschließen.
In Information About Our New Contributor License Agreement steht unter anderem:

Although we may choose any license for the code that we have written ourselves, we do not have this ability when it comes to code written by additional contributors. The purpose of the CLA is to provide future flexibility in altering (i.e. - uplicensing, dual licensing) for the entire Audacity project, not just the parts of the code that we have written ourselves.

Und am Beispiel vom VLC:

Finally, we wish to make Audacity available to everyone, which means releasing it on all platforms and through as many distribution channels as possible. Unfortunately, some platforms have policies or technical processes that make it difficult or impossible for Audacity to exist on them while it is licensed solely under the GPL (v2 or v3). Apple's App Store on iOS and macOS is one example of this, which is the reason that VLC Media Player was removed from the store back in 2011. (VLC returned to the AppStore later but not under the GPL.)

[...]

The CLA provides the ability to release Audacity under multiple licenses, which will enable us to release it on the App Store while still making the code available under the GPL. This will ensure that an even wider audience is able to appreciate the wonderful piece of open source software that is Audacity.

Das ist zumindest für mich schlüssig und nachvollziehbar.

Mir ist auch überhaupt nicht klar, wie unter diesen Bedingungen unfreier Code in
Audacity einfließen soll, wie hier vermutet wird.

[MSfree]

Du bist nach wie vor den Nachweis schuldig um die Einordnung von Audacity als Spyware zu rechtfertigen.

Darf ich dich nochmal auf diesen Link hinweise?
https://www.heise.de/news/Audacity-Sind ... 29737.html

Vor allem dieser Satz aus dem verlnkten Artikel:

Des Weiteren darf Audicity alle Daten erheben, die Behörden benötigen. Sie seien zum Durchsetzen der rechtlichen Interessen des Anbieters notwendig,

Hmm, die Software leitet also das, was ich gerade bearbeite, weiter, um eventuelle Urheberrechtsverletzungen verfolgen zu können.

Ein Jurist würde das möglicherweise als "berechtigtes Interesse" beurteilen. Ich nenne es Spionage.

[willy4711]

Hmm, die Software leitet also das, was ich gerade bearbeite, weiter, um eventuelle Urheberrechtsverletzungen verfolgen zu können.

Ein Jurist würde das möglicherweise als "berechtigtes Interesse" beurteilen. Ich nenne es Spionage.

Das sollte man dann im Code nachweisen können. In dem von dir verlinkten Artikel von Heise ist da auch nichts konkretes vorhanden.

In der von mir verlinkten "Desktop Privacy Notice" steht da nichts von dem allem - soweit das korrekt ist.

Edit:

Und da der Code unter GitHub ja verfügbar ist, sollten dort doch wenigstens die kritischen Stellen genannt werden ??
Hat da jemand Fundstellen ??

[MSfree]

Hat da jemand Fundstellen ??

Ja Audacity selbst:
https://www.audacityteam.org/about/desk ... cy-notice/

Unter Punkt 2 und 4 steht alles relevante.

[hikaru]

Unter Punkt 2 und 4 steht alles relevante.

Relevant für das Verhalten des Programms ist Quellcode, nicht was irgendwer in die Prosa auf irgendeiner Webseite hineininterpretiert.
Also: Wo ist der Spionage-Code?

[MSfree]

Relevant für das Verhalten des Programms ist Quellcode, nicht was irgendwer in die Prosa auf irgendeiner Webseite hineininterpretiert.

Es ist nicht "irgendwer", der die "Prosa" formuliert hat sondern der Hersteller. Glaubst du wirklich, daß der sowas schreibt, ohne den entsprechenden Code zumindest vorrätig zu haben (auch, wenn der im Moment noch nicht im Release eingebaut ist)?

[willy4711]

Nur zur Erklärung:

Die russische WSM Group ist der Eigentümer von Audacity / Muse (Neusprech: Eigentum vom Schlächter Putin )

Wüsste nicht welches Interesse die an deinem gerade "geklautem" Liedchen haben sollte, wo doch
das Copyright auf solche Dinge im Reich Putins mehr als lässig ist.

Es geht wohl da mehr um die Lizenzrechte der Software.

[hikaru]

Glaubst du wirklich, daß der sowas schreibt, ohne den entsprechenden Code zumindest vorrätig zu haben (auch, wenn der im Moment noch nicht im Release eingebaut ist)?

Was ich glaube ist reichlich irrelevant. Relevant ist, was an Code ausgeführt wird. Wenn du problematischen Code kennst, dan zeig ihn einfach!
Ob solcher Code in irgendeiner Schublade schlummert weiß ich nicht. Das Schöne an FLOSS ist, dass wir es sofort mitbekommen (können), wenn der aktiviert wird. Angesichts der aktuellen Lage ist es sicher richtig, wachsam zu sein. Aber das ist es eigentlich immer.

[mcb]

Hier sollte sich der Code einfach finden lassen:

https://github.com/tenacityteam/tenacity

Grafisch markiert

[willy4711]

Hier sollte sich der Code einfach finden lassen:

Aha in der Begründung ist heiße Luft und nix von Code. Telemetrie ist doch inzwischen
wieder entfernt ??

Why did this project fork audacity/audacity?
You can find more information on the causes of the fork here:

Privacy policy which may violate the original project's GPL license
Contributer's License Agreement (CLA) which may violate the same GPL license
Attempts at adding telemetry using Google services for data collection

Zum Rest hat ja @hikaru ausführlich Stellung genommen

[mcb]

Nein die Codestellen ala 'removed'

Man kann sich doch die Unterschiede anzeigen lassen Fork <-> Original ...

[DeletedUserReAsG]

Das Schöne an FLOSS ist, dass wir es sofort mitbekommen (können), wenn der aktiviert wird.

Das weniger Schöne ist, dass man sich in falscher Sicherheit wiegt, wenn man die „irgendwer wird schon draufschauen und was sagen, wenn was sein sollte“-Schiene fährt. Das passierte in der Vergangenheit selbst bei sicherheitsrelevanten Sachen nicht ausreichend, und man müsste schon sehr naiv sein, wenn man sich drauf verlassen würde, dass es bei ‘nem Audioeditor gemacht wird.

Jetzt guckt vielleicht der Eine oder Andere von denen, die zumindest eine Chance haben, die gröbsten Sachen zu entdecken, drauf. Aber sobald sich der Staub gelegt hat, und sich das Interesse dem nächsten Aufschrei zugewendet hat, tut’s keiner mehr. Die Frage ist schon berechtigt: wenn der neue Hersteller nicht vor hätte, sowas zu machen – warum schreibt er’s dann hin?

[mcb]

Ach ich warte erstmal ab und hoffe das Debian ab nach bullseye eine Lösung bietet:

- Fork
- Audacity mit 2 / 3 Patches
- Audacity 3.02 ?!? Mit backportierten Zeugs o.ä.
- Audacity 2.4

Aber ich bleibe dabei: Ich möchte und brauche keine Internetverbindungen im Audioeditor. 'Wo ein Trog ist kommen die Schweine' und schon war die Datenschutzbestimmung nur heiße Luft.

[mcb]

Unter Punkt 2 und 4 steht alles relevante.

Relevant für das Verhalten des Programms ist Quellcode, nicht was irgendwer in die Prosa auf irgendeiner Webseite hineininterpretiert.
Also: Wo ist der Spionage-Code?

Der wäre an folgenden Stellen:

https://github.com/tenacityteam/tenacit ... eb300dfd1c

https://github.com/tenacityteam/tenacit ... 38a25d69bd

https://github.com/tenacityteam/tenacit ... 38a25d69bd

https://github.com/tenacityteam/tenacit ... 38a25d69bd

https://github.com/tenacityteam/tenacit ... eb300dfd1c

Unter "Load Diff" ?!? Ich verstehe da eh nur Bahnhof ...

[hikaru]

Das weniger Schöne ist, dass man sich in falscher Sicherheit wiegt, wenn man die „irgendwer wird schon draufschauen und was sagen, wenn was sein sollte“-Schiene fährt. Das passierte in der Vergangenheit selbst bei sicherheitsrelevanten Sachen nicht ausreichend, und man müsste schon sehr naiv sein, wenn man sich drauf verlassen würde, dass es bei ‘nem Audioeditor gemacht wird.

Das ist richtig. Und es ist das größte Problem von FLOSS, dass viel zu wenig von unabhängiger Stelle in den Quellcode geschaut wird.

Das wird von Closed-Source-Vertretern gern als Argument gegen FLOSS angeführt, denn das Problem hat man mit CS nicht. Den Strohmann erkennen dann unbedarfte Nutzer oft nicht mehr. Unter CS bleibt das Problem nicht deshalb aus weil CS besser wäre, sondern weil es um so vieles schlechter (=intransparenter) ist, dass man gar nicht in die Lage kommt, sich dem Problem überhaupt stellen zu können.

Die Frage ist schon berechtigt: wenn der neue Hersteller nicht vor hätte, sowas zu machen – warum schreibt er’s dann hin?

Ja, die Frage ist berechtigt. Und sie sollte zu erhöhter Wachsamkeit führen, den Code auch in Zukunft wirklich zu überprüfen. Ich habe hier prinzipiell Vertrauen in Debian, weiß aber auch, das man nicht alle Maintainer über einen Kamm scheren kann.

Der wäre an folgenden Stellen:

https://github.com/tenacityteam/tenacit ... eb300dfd1c

https://github.com/tenacityteam/tenacit ... 38a25d69bd

https://github.com/tenacityteam/tenacit ... 38a25d69bd

https://github.com/tenacityteam/tenacit ... 38a25d69bd

https://github.com/tenacityteam/tenacit ... eb300dfd1c

Danke! Damit kann man Aussagen treffen.
Hier wurden Codeteile entfernt, die mit Crashreports, Updates und allem was irgendwie mit Netzwerk zu tun hat. Ich halte alles was hier entfernt wurde für harmlos.
Angenommen, hier sind alle als problematisch angesehenen Stellen erfasst, dann hätte man das aber auch alles im Originalcode zur Compilierzeit abschalten können ohne den eigentlichen Code anzufassen, denn das ist dort alles konfigurierbar.

Unter "Load Diff" ?!? Ich verstehe da eh nur Bahnhof ...

Da wurden ganze Quellcode-Dateien entfernt, weil die sich nur mit z.B. Updates beschäftigt haben. Hier einen vollständigen Diff auszugeben ist nicht wirklich sinnvoll. Daher lediglich die Meldung, dass die Datei entfernt wurde und der Vollständigkeit halber der Link um doch den ganzen Diff (zur dann leeren Datei) zu sehen.

[JTH]

[…] dann hätte man das aber auch alles im Originalcode zur Compilierzeit abschalten können ohne den eigentlichen Code anzufassen, denn das ist dort alles konfigurierbar.

Was dann auch der Weg ist, den ein Debian-Maintainer zum AusbauenNicht-Einbauen dieser ganzen Funktionalität nutzen wird.

[mcb]

[…] dann hätte man das aber auch alles im Originalcode zur Compilierzeit abschalten können ohne den eigentlichen Code anzufassen, denn das ist dort alles konfigurierbar.

Was dann auch der Weg ist, den ein Debian-Maintainer zum AusbauenNicht-Einbauen dieser ganzen Funktionalität nutzen wird.

Ja das sind ja auch Pros

[mcb]

.......................

Unter "Load Diff" ?!? Ich verstehe da eh nur Bahnhof ...

Da wurden ganze Quellcode-Dateien entfernt, weil die sich nur mit z.B. Updates beschäftigt haben. Hier einen vollständigen Diff auszugeben ist nicht wirklich sinnvoll. Daher lediglich die Meldung, dass die Datei entfernt wurde und der Vollständigkeit halber der Link um doch den ganzen Diff (zur dann leeren Datei) zu sehen.

Ja das die ganzen Dateien weg sind ist klar, ich meinte ich verstehe den Inhalt kaum bis gar nicht.

PS:

Audacity Audio-Schnittprogramm will Daten sammeln und mit Regierungen teilen https://netzpolitik.org/2021/audacity-a ... en-teilen/

Mit Regierung(en) teilen -> 'steht nur drin, gilt aber nicht' <- will man nicht abnicken, oder ?

[hikaru]

Audacity Audio-Schnittprogramm will Daten sammeln und mit Regierungen teilen https://netzpolitik.org/2021/audacity-a ... en-teilen/

Auch in diesem Artikel steht nichts Wertvolles drin. Es ist das gleiche reißerische und haltlose Blabla wie im Heise-Artikel. Offenbar hält es kein einziger Journalist für angebracht, selbst in den öffentlich einsehbaren Code zu schauen, bevor er Artikel veröffentlicht.
Das ist schade, denn ich hatte bisher eine hohe Meinung von netzpolitik.org.

Ein wichtiger Satz ist mir in dem Artikel allerdings doch aufgefallen (stand aber wohl auch schon irgendwo bei Heise):

Vor diesem Hintergrund weniger brisant scheint die Kritik daran, dass mit den neuen Datenschutzbestimmungen auch ein Mindestalter für die Nutzer:innen von 13 Jahren vorgeschrieben wird, obwohl das der Lizenz widerspricht, unter der die Software veröffentlicht ist.

Das ist momentan der einzige Punkt in dem Audacity angreifbar ist. Die GPLv3 erlaubt bestimmte Nutzungseinschränkungen. Diese sind abschließend in Punkt "7. Additional Terms" aufgelistet. Eine Altersbeschränkung gehört nicht dazu. Alle weiteren Einschränkungen sind gemäß Punkt "10. Automatic Licensing of Downstream Recipients." unzulässig.
Audacity würde mit dieser Bestimmung gegen die GPLv3 verstoßen und dürfte so gemäß Punkt "8. Termination." die eigene Software weder nutzen noch verbreiten.

Nebenbei verstößt die Altersbeschränkung auch gegen Punkt "5. No Discrimination Against Persons or Groups" der DFSG. Das könnte ein Aufhänger sein, Audacity aufgrund einer Policy Violation* doch aus Debian (main) zu entfernen.

*) ist ein rc-Bug; Freiwillige vor!

[mcb]

Ich glaube die brauchen da keine freiwillige Meldung ...

Darf ich mich dann wieder mit Fremdquellen oder Flatpaks beschäftigen für ein paar Hobbyaudioprojekte

[mcb]

Ein 'Vorteil' von flatpaks:

https://github.com/flathub/org.audacity ... /issues/72

Man kann networking sperren.

[hikaru]

Das ist kein Vorteil von Flatpaks.
Dort wurde einfach nur mit -Daudacity_has_networking=no compiliert. Das Gleiche kann man auch mit einem Debian-Paket machen, ohne sich die Nachteile von Flatpaks an Bord zu holen.

[mcb]

Das ist kein Vorteil von Flatpaks.
Dort wurde einfach nur mit -Daudacity_has_networking=no compiliert. Das Gleiche kann man auch mit einem Debian-Paket machen, ohne sich die Nachteile von Flatpaks an Bord zu holen.

Oh Danke ! Das wußte ich nicht. Nun ja flatpak Berechtigungen verstellen ist für Benutzer aber 'leichter' ... Flatseal

[hikaru]

Das hat nichts mit Berechtigungen zu tun.
Das Audacity-Binary in diesem Flatpak wurde ohne Netzwerkunterstützung compiliert. Darauf hast du als Anwender keinen Einfluss mehr.

Flatseal ist offenbar eine Sandboxing-Methode um Flatpaks nachträglich(!) bestimmte Funktionalität zu entziehen. [1] Das Gleiche kannst du beim Debianpaket mit firejail erreichen, wie von JTH hier [2] schon angemerkt.
Das Flatseal-GUI zu verstehen mag einfacher sein als Firejail, aber im Gegenzug muss man sich beim Flatpak dann mit den üblichen Fremdquellen-Problemen beschäftigen, die einem das Debian-Repo weitgehend abnimmt:
Vertrauenswürdigkeit, Kompetenz, Abhängigkeiten, Sicherheitslücken (auch für im Flatpak enthaltene Libs)

Natürlich kann man diese Prüfungen auch alle sein lassen und einfach blind darauf hoffen, dass der Flatpak-Anbieter schon wissen wird, was er da tut. Aber wenn man auf dem Level unterwegs ist, dann kann man auch einfach darauf vertrauen, dass Audacity schon nichts Dreckiges tun wird.*

Ich finde die Gesamtsituation komisch (lustig und traurig):
Audacity, ein FLOSS-Projekt dessen Code sich jeder anschauen kann, hat in einer öffentlichen Bekanntmachung bedenkliche Aussagen gemacht. Und es passieren drei Dinge:
1. Ein paar Leute die den Code verstehen machen einen Fork, der im Wesentlichen darin besteht, völlig unproblematische Codeteile zu entfernen, die sich zudem ohne Fork abschalten lassen. Ich nenne das kosmetischen Aktionismus.
2. Die Presse** zerreißt sich das Maul auf Basis dieser Bekanntmachung und öffentllicher Panikkommentare (und produziert dabei mehr Panikkommentare).
3. Unbedarfte User die den Code nicht verstehen (was kein Vorwurf ist), konsumieren und produzieren Panikkommentare und pflastern ihr System in ihrem Unverständnis des Codes und im Versuch die vermeintlichen Probleme zu beheben mit noch mehr unverstandener Software voll.

Genau so war FLOSS nicht gemeint.


[1] https://www.omgubuntu.co.uk/2020/02/fla ... ermissions
[2] viewtopic.php?f=15&t=181421&start=30#p1276252
*) Was sie auf Basis des mir aktuell bekannten Codes gar nicht könnten, selbst wenn sie es wollten.
**) Welche im Interesse qualitativ hochwertiger Berichterstattung ein Code-Audit machen/beauftragen sollte.