Meinungen zum Thema "Audacity"?

[mcb]

Das war es mit AudaCity – neue Datenschutzvereinbarung | Borns IT- und Windows-Blog:

https://www.borncity.com/blog/2021/07/0 ... einbarung/

In meinen Augen fährt Muse das bewußt oder unbewußt an die Wand.

Und nein unter Win braucht der Waveeditor auch keinen Updatecheck (wenn bitte opt-in).

[rockyracoon]

@mcb:

...bewußt oder unbewußt...

Das ist imho hier die zentrale Frage.

...(wenn bitte opt-in)...

Opt-In sollte imho sowieso Standard sein, beziehungsweise Prüfstein, wie seriös in Bezug auf "Privacy" ein Betreiber ist.

[mcb]

ja Muse hat sich bisher ausschließlich schofelig verhalten ... ich finde es schade und hoffe das unter Debian der Quatsch rausgepatched wird

- die alten Versionen funktionieren ja eh -

könnte Debian bei 2.4 bleiben ab bookworm ??

[MSfree]

könnte Debian bei 2.4 bleiben ab bookworm ??

Kein Programm kann auf Dauer auf einer Version verharren. Programme haben nunmal alle Sicherheitslücken und spätestens, wenn mal wieder eine bekannt wird, muß man diese beheben und anschließend die Versionsnummer hochzählen. Verbesserungsvorschläge von den Anwendern resultieren ebenfalls in steigenden Versionsnummern.

Auch, wenn ringsrum die ganze Laufzeitumgebung (aka Libraries) sich ändert, sind häufig Anpassungen an der Software nötig, damit diese mit der neueren Laufzeitumgebung wieder funktioniert. Anpassungen = neue Versionsnummer.

Normalerweise kümmert sich der Entwickler der Software um die Anpassungen an neuere Laufzeitumgebungen und Fehlerbehebungen, aber der fällt bei Audacity weg, wenn man Audacity forkt, da müßte sich dann schon ein neuer Maintainer finden, der den Fork pflegen will. Die Weiterentwicklung von Original unf Fork laufen dann langfristig auseinander und Anwender fragen sich, warum etwas mit der einen Version klappt, aber nichtm it der anderen...

OwnCLoud und NextCloud sind ein Beispiel dafür, daß ein Fork mit einem neuen Maintainer funktionieren kann. Es gibt aber auch genug Negativbeispiele.

[mcb]

Ja - ich denke manchmal bequem und einfach

Mal abwarten was ab bookworm kommt.

[ottonormal]

Kein Programm kann auf Dauer auf einer Version verharren.

Und wie wäre das mit einem AppImage?
Ich habe mir gerade mal davon die Version 2.3.3 heruntergeladen. Auf einem Rechner mit Linux Mint läuft die einwandfrei, auf meinen Buster leider nicht.
Außerdem sind 440 MB dafür ja auch nich gerade wenig. Ist das normal?

[MSfree]

Und wie wäre das mit einem AppImage?

AppImages bringen alles mit, um völlig autark laufen zu können. Die bringen ihre eigenen GTK-, KDE,- Qt, ssl, etc. Bibliotheken mit, also wirklich alles. Deshalb sind die auch so groß, weil sie praktisch fast eine komplette "Linuxdistribution" mitbringen. Ist auch nur eine der mitgebrachten Libs mit einer Sicheheitslücke versehen, muß das komplette AppImage ausgetauscht werden.

Für mich sind AppImages (genauso wie Flatpacks) ein NoGo, weil sie einerseits extrem groß sind und andererseits ein Breitseite an Angriffsmöglichkeiten bieten.

[hikaru]

Kein Programm kann auf Dauer auf einer Version verharren.

Und wie wäre das mit einem AppImage?

Appimages bringen Teile der Abhängigkeiten (Libs) ihrer "Nutzsoftware" selbst mit. Damit besteht die Chance, dass man ein altes Appimage länger nutzen kann als das entsprechende Debianpaket.
Das grundlegende Problem löst das allerdings nicht. Spätestens wenn alte libc-Aufrufe entfernt werden die das Programm nutzt, dann funktioniert es nicht mehr.
Der nächste Schritt wäre dann, ein altes Betriebssystem für die alte Software in einer VM zu betreiben. Das funktioniert, bis die Virtualisierungssoftware die alte VM nicht mehr unterstützt.
Der dann folgende Schritt ist, auf Bare Metal das alte System für die alte Software zu betreiben. Das funktioniert, so lange das alte Betriebssystem noch mit der neuen Hardware zurecht kommt.
Danach betreibt man dann alte Betriebssysteme auf alter Hardware bis sie irgendwann museeumsreif ist und anfängt auszufallen.

Diese zunehmend absurder (weil ohne Mehrwert aufwändiger) werdende Kette zeigt das Grundproblem von Appimages und ähnlichen Konzepten (z.B. Snap, Flatpak):
Klassische Linuxdistributionen sind eigentlich dafür ausgelegt, Software zu atomisieren. Deshalb gibt es abertausende kleiner Pakete und deshalb braucht Linux im Vergleich zu anderen Betriebssystemen relativ wenig Platz.
Appimages sind der erste Schritt, dieses Konzept zu untergraben. Und der Aufwand um so ein Hybridsystem ordentlich(!) zu pflegen ist sehr viel größer als die meisten wahrnehmen.

Zwischendurch kommen noch so lustige Effekte hinzu, wie dass sich die Standards für Codecs und Container ändern*, welche die alte Software natürlich nicht unterstützt.
Die alte Software (inkluse Libs und BS) hat natürlich auch Sicherheitslücken und man muss in dem Moment wo man sich von der Weiterentwicklung abkoppelt, diese entweder patchen oder zumindest dafür sorgen, dass das Museumsstück nicht mehr auf aktuelle Gefahrenquellen trifft, was v.A. bedeutet, rigeros den Netzwerkkontakt zu kappen.

Ich habe mir gerade mal davon die Version 2.3.3 heruntergeladen. Auf einem Rechner mit Linux Mint läuft die einwandfrei, auf meinen Buster leider nicht.

"Läuft nicht" ist natürlich eine dürftige Fehlrmeldung. Ich vermute, hier passiert bereits genau das was ich oben angerissen habe:
Das Appimage hat irgendeine Abhängigkeit in deinem Basissystem die nicht errfüllt ist. Da Appimages keine Abhängigkeitsbehandlung haben, musst du dich darum selbst kümmern. Und ob eine Lösung mit diesem Appimage überhaupt möglich ist, ist nicht garantiert.
Willkommen zurück bei Windows 98!

Außerdem sind 440 MB dafür ja auch nich gerade wenig. Ist das normal?

Ja, das ist wegen der enthaltenen Abhängigkeiten normal.
Du kannst ja mal die Gegenprobe machen und audacity auf einem frisch installierten Debian-Minimalsystem installieren. Die zusätzlich installierten Pakete sollten theoretisch der Größe des Appimages entsprechen. Wenn dass Appimage kleiner ist fehlen dort entweder Features (Recommends, Suggests) oder gar (in dem Fall undokumentierte) Abhängigkeiten, die das Appimage implizit erwartet.


*) passiert bei Audio nicht so oft, bei Video aber z.B. alle Nase lang

[willy4711]

Ich nutze Audacity nicht aber vielleicht interessiert es irgendjemand mal, hier zu schauen:
Desktop Privacy Notice

This occurs during a check for updates and can be disabled in Preferences at any time. Users also have the option to send error reports if they choose. The user is asked whether they would like to do so when an error occurs.

No other information is collected for any purpose. This can be confirmed in the source code (here and here), and by network analysis of the release binaries.

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

Hier wird es einige geben, die das analysieren können, und dann mal berichten können, was denn nun wirklich spioniert wird.

Hab zwar auch ocenaudio hier installiert, nutze aber bisher zu 100% audacity ....
Wenn hier der Wechsel zu bullseye ansteht, werde ich erst mal audacity nicht installieren und schauen, wie ich mit ocenaudio klar kommen ....
cu KH

Nach Wikipedia ist ocenaudio keine freie Software
https://de.wikipedia.org/wiki/Audioeditor

[TuxPeter]

Man könnte vielleicht was basteln, was die Netzverbindung kappt, dann audacity startet und nach Programmende wieder verbindet. Dann ist man natürlich, solange man damit arbeitet, recht eingeschränkt.
Habe gerade etwas anderes probiert: Neuen User angelegt. Beide User mit Xfce-Desktop, einer auf tty1, der andere tty2. Dann kann man mit Strg-Alt-F1 / F2 umschalten. Leider ist es mir nicht gelungen, einem User das Netz zu entziehen (simpel per Network-Applet), während der andere den üblichen Zugriff hat. Weil der andere User dann auch nicht ins Netz kommt - ist eigentlich logisch. Über "groups" scheint es auch nicht zu gehen, und damit bin ich mit meinem Latein am Ende. Ist aber unwichtig, zur Zeit bloß eine Spielerei, die ein bisschen OT ist, sorry.

[JTH]

Man könnte vielleicht was basteln, was die Netzverbindung kappt, dann audacity startet und nach Programmende wieder verbindet. Dann ist man natürlich, solange man damit arbeitet, recht eingeschränkt.

Das muss man gar nicht so aufwändig basteln. Es gibt genug Möglichkeiten, wie z.B. firejail, einzelnen Anwendungen z.B. den Netzwerkzugriff zu verwehren.

[willy4711]

@TuxPeter
gibt es denn überhaupt schon die neue Version, in der sich im Code nichts geändert haben soll, sondern lediglich die
Desktop Privacy Notice
Außerdem denke ich, das Debian die entsprechenden Code-Zeilen eh entfernen oder neutralisieren wird,
da zumindest die Update- Anfrage bei einem vorschriftsmäßig ( ) aus dem Dabian- Repo bezogenem Paket
eh obsolet ist.
Wo ist dann das Problem ??

[MSfree]

Außerdem denke ich, das Debian die entsprechenden Code-Zeilen eh entfernen oder neutralisieren wird,

Muse hat hat oder will noch die Lizenz von GPL in eine eigene ändern. Damit einher geht dann auch, daß die Code nicht mehr manipuliert werden darf, um die Spyware zu entfernen. 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.

[willy4711]

Muse hat hat oder will noch die Lizenz von GPL in eine eigene ändern. Damit einher geht dann auch, daß die Code nicht mehr manipuliert werden darf, um die Spyware zu entfernen.

Ich lese nur das:
https://www.heise.de/news/Audacity-Entw ... 60798.html

Derzeit untersteht Audacity der quelloffenen GNU General Public License (kurz GPL). Anstelle der bislang genutzten zweiten Version soll zukünftig die dritte Fassung der GPL zum Einsatz kommen. Damit ließen sich Bibliotheken und Techniken integrieren, die nicht mit der alten GPLv2 kompatibel sind. Als Beispiel nennen die Entwickler die weitverbreitete Plugin-Schnittstelle VST3. Darüber hinaus nutzt das ebenfalls von der Muse Group entwickelte Notensatzprogramm MuseScore die GPLv3. Durch einen Lizenzwechsel könnten sich die beiden Anwendungen einfacher Programmcode teilen.

Demnach ist also die von der FSF mit Gott Richard Stallman kreierte GPLv3 die Teufelsgeburt

Ich verstehe ja von dem ganzen Zeugs nichts.

Aber irgendwie erinnert mich das an Debians Iceweasel und Icedove

[MSfree]

Ich lese nur das:
https://www.heise.de/news/Audacity-Entw ... 60798.html

Mit anderen Worten, es dürfen nur noch die Änderungen in den Code, die Muse genehmigt. Das ist so ziemlich das Gegenteil einer freien Lizenz. Und wer die Spyware rauspatchen will, handlet sicher nicht im Sinne von Muse. Eine Umlizenzierung weg von der bisherigen GPL ist für Muse also unumgänglich. Lediglich die bisher unter GPL stehenden Versionen können nicht nachträglich umlizenziert werden, und genau an der Stelle kann ein Fork noch stattfinden.

Demnach ist also die von der FSF mit Gott Richard Stallman kreierte GPLv3 die Teufelsgeburt

GPL ist nicht der Nabel der Welt. Es gibt durchaus liberalere Lizenzmodelle, die trotzdem (auch von RMS) als freie Lizenz anerkannt werden, die BSD-Lizenz beispielsweise.

Aber irgendwie erinnert mich das an Debians Iceweasel und Icedove

Da ging es aber nicht um den Quellcode selbst sondern um den Produktnamen, den die Mozilla Foundation eingetragen hatte. Man wollte damit klarstellen, daß das, was Firefox/Thunderbird heißt, auch exakt aus dem Quellcode der Mozilla Foundation gebaut wird.

Ändert jemand den Code, so darf er das im Rahmen der Lizenz tun, darf es aber nicht mehr Firefox/Thunderbird nennen. Konkret ging es, so weit ich mich erinnere, um die Suchmaschinen, die in der FF/TB-Variante plötzlich die Produktsuche bei Amazon beinhaltete. Für Debian wurde die Amazonsuche rausgepatcht (Code verändert).

Mittlerweile wurden die Namen Firefox/Thunderbird aber von der Mozilla Foundation wieder freigegeben, auch für Varianten, die aus modifiziertem Quellcode gebaut werden.

[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