YouTube-downloader youtube-dl is na aanpassing code weer beschikbaar op GitHub

De originele repository youtube-dl is weer beschikbaar op GitHub. De bekende YouTube-downloader ging eind oktober offline na auteursrechtclaims van de Amerikaanse muziekindustrie. De ontwikkelaars hebben daarna code verwijderd.

Het herstel van youtube-dl is in een opmerking over de toekomst van de software op Github gemeld en inderdaad is de repository op de oorspronkelijke plek terug. Details over de terugkeer en de wijzigingen staan nog niet online. Wel is duidelijk dat de ontwikkelaars bezig waren met het verwijderen van code waar de branchevertegenwoordiger van de Amerikaanse muziekindustrie, de RIAA, aanstoot aan nam.

De auteursrechtenclaims van de RIAA hadden onder andere betrekking op teksten in de broncode, die verwezen naar artiesten en nummers die als test van YouTube te downloaden zijn. Het ging om het nummer 'I Love It' van Icona Pop, 'Tunnel Vision' van Justin Timberlake en 'Shake it Off' van Taylor Swift. GitHub haalde de repository eind oktober offline vanwege de DMCA-claims.

Uit een technische analyse bleek dat in de code verwezen werd naar de nummers voor het automatisch testen van de functionaliteit door ontwikkelaars, dat het om het testen van specifieke video's zoals die van VEVO ging en dat de software bij de test alleen de eerste 10kB van de tracks binnenhaalde. De passages zijn hoe dan ook verwijderd, waardoor GitHub de software op zijn platform hersteld heeft. Youtube-dl is een commandlinetool voor het downloaden van video's op internet, waar meerdere sites en programma's hun functionaliteit op gebaseerd hebben.

Reacties (70)

[hostname]

Belangrijk om te vermelden is dat de EFF de juridische verdediging van de ontwikkelaars op zich heeft genomen, en een counter-notice heeft ingediend bij GitHub. Door deze counter-notice kon GitHub de repository weer online plaatsen zonder hun bescherming als "safe harbor" onder de DMCA kwijt te raken. De EFF is een non-profit die al jaren opkomt voor een vrij internet en volledig draait op donaties. Je kan hier doneren.

[Reactie gewijzigd door hostname op 22 juli 2024 14:28]

[Kewne]

Zie ook de blog post van GitHub: "Standing up for developers: youtube-dl is back", waar meer uitleg in staat over de wijzigingen die aan de kant van GitHub zelf gemaakt zijn.

[Jerie]

Niet te vergeten het feit dat GitHub/Microsoft 1 miljoen dollar heeft gedoneerd aan EFF in de vorm van een Defense Fund:

Developer defense fund

Developers who are personally affected by a takedown notice or other legal claim rely on non-profits like the Software Freedom Law center and the Electronic Frontier Foundation (EFF) to provide them with legal advice and support in the event that they face an IP claim, under the DMCA or otherwise. These organizations provide critical legal support to developers who would otherwise be on their own, facing off against giant corporations or consortia.

Nonetheless, developers who want to push back against unwarranted takedowns may face the risk of taking on personal liability and legal defense costs. To help them, GitHub will establish and donate $1M to a developer defense fund to help protect open source developers on GitHub from unwarranted DMCA Section 1201 takedown claims. We will immediately begin working with other members of the community to set up this fund and take other measures to collectively protect developers and safeguard developer collaboration.

If you want to support developers facing legal challenges, you can consider supporting SFLC and EFF yourself as well.

[Reactie gewijzigd door Jerie op 22 juli 2024 14:28]

[wankel]

Niet te vergeten het feit dat GitHub/Microsoft 1 miljoen dollar heeft gedoneerd aan EFF in de vorm van een Defense Fund:

Het is ingepakt tussen twee alinea's die wel over de EFF gaan, maar die 1 miljoen gaat niet naar EFF.

Ze maken los van EFF een bedrag beschikbaar voor ontwikkelaars die door specifiek deze (1201) voorwaarde in DMCA geraakt worden.

[Eonfge]

Ook mooi om te weten, alle grote Linux distributies waren gewoon doorgegaan met de distributie van Youtube-DL:
https://pkgs.org/download/youtube-dl

Fedora, Debian en dergelijke hebben allen hun eigen juridische team en ze wilden de uitdaging wel aan gaan om met de RIAA om de tafel te moeten. de RIAA durft wel een paar buitenlandse vrijwilligers voor het blok te zetten, maar IBM is ze waarschijnlijk iets te lastig. Nu nog kijken of het chilling-effect aan houdt.

[Reactie gewijzigd door Eonfge op 22 juli 2024 14:28]

[Peetz0r]

Grappig dat je Fedora noemt, want de Fedora packages stonden best een tijdje stil. Todat iemand besloot het zelf te fiksen en een Pull Request te sturen.

https://src.fedoraproject.org/rpms/youtube-dl/pull-request/5

[Eonfge]

Soms omdat veel van die systemen geautomatiseerd zijn. Ik had de release van afgelopen week ook gemist omdat ik geen emailtje had gekregen... Net maar even de build-server aangeslingerd voor 2020.11.12

[michaelkamen]

Uit een technische analyse bleek dat in de code verwezen werd naar de nummers voor het automatisch testen van de functionaliteit door ontwikkelaars, dat het om het testen van specifieke video's zoals die van VEVO ging en dat de software bij de test alleen de eerste 10kB van de tracks binnenhaalde.

Het ging om verwijzingen in unit tests, en er werd hard-coded verwezen naar deze video's omdat ze specifieke elementen hadden die nodig waren voor de tests (bijv. leeftijdsrestricties)
Mooier zou geweest zijn als de maker van youtube-dl zelf rechtenvrije video's had geupload met deze restricties, maar om hiervoor nou een hele repo offline te halen gaat echt te ver.

[Navi]

Sowieso een aparte keus dat hij hiervoor publieke videos gebruikte en niet gewoon (zoals je zegt) zelf wat test videos geupload heeft in een eigen beheerd kanaal.

[Reactie gewijzigd door Navi op 22 juli 2024 14:28]

[Kewne]

De copyright/cipher flag die getest wordt kun je niet zelf op een video activeren, alleen mensen die een kanaal beheren dat onder het YouTube CMS/content ID systeem valt kunnen dat. Een gewoon kanaal of partnered kanaal is niet genoeg.

[Kriekel]

Als je een video upload met een halve minuut aan muziek onder copyright zit die flag er binnen een paar minuten op. Lang niet alle video's worden dan gelijk offline gehaald, je hebt dan zelf alleen geen controle over eventuele reclame meer.

[m8ZBm1Si]

Het doel is hier om niet copyrighted materiaal als testbasis te hebben. De oplossing is dan niet om copyrighted materiaal zelf te uploaden. Wonderlijk genoeg.

[supersnathan94]

Nou meer dat er dus expliciet copyrighted materiaal gebruikt wordt. De ontwikkelaar had de tests ook kunnen baseren op tracks van NCS (NoCopyrightSounds). Functioneel exact hetzelfde, maar dan daadwerkelijk legaal.

[theguyofdoom]

Die hebben niet de extra beveiliging op youtube die bepaalde VEVO tracks wel hebben.

[supersnathan94]

Oke fair enough, maar dan nog is het wel een beetje vragen om issues daarmee. Juist als het dus expliciet gaat om materiaal wat extra aangeeft copyright te hebben.

[Jimbolino]

Het waren tests om het extracten van metadata zo goed mogelijk te laten werken.
Daarom zijn het video's van verschillende jaren, met verschillende age restrictions, en automatisch geïmporteerde muziek van platenlabels (Provided to YouTube by [label])
Het is lastig/onmogelijk om al deze scenario's onder eigen beheer te uploaden, of terug te vinden bij NCS.

[mjtdevries]

Volgens mij is dat vooral een makkelijke smoes.

Maar stel dat het inderdaad onmogelijk is om die scenarios onder eigen beheer te uploaden, dan vraag je vooraf toestemming met de valide legale reden om dit te doen.

[Jimbolino]

Sinds wanneer moet je toestemming vragen om openbare data van een openbare website te lezen?

Er werd geen video gedownload, geen data gedistribueerd. Alleen een unit test gedraaid op meta data van openbare video's op een openbaar platform.

Github heeft beloofd dat ze dit soort nep-claims in de toekomst eerst zullen toetsen voordat ze ze uit gaan voeren: https://github.blog/2020-...opers-youtube-dl-is-back/

[mjtdevries]

Sinds wanneer moet je toestemming vragen om openbare data van een openbare website te lezen?

Wat dacht je van "goed fatsoen"?
Bv omdat je heel veel extra hits op hun website kan veroorzaken en ze daar wellicht helemaal niet blij mee zijn?

Als jij wil gaan testen dan doe je dat lekker op je eigen sites/data en daar ga je geen anderen mee lastig vallen. Een test kan altijd overlast veroorzaken. Zeker als je acties ook nog kunnen veroorzaken dat een groot aantal mensen die ander er mee lastig gaan vallen.
Als jij het niet zelf kan testen dan is het gewoon een kwestie van goed fatsoen dat je even overlegt met die ander of die het niet erg vind.

Sinds wanneer beseffen mensen dat niet meer uit zichzelf en moet je ze dat uitleggen?

[Tweekzor]

[...]

Het ging om verwijzingen in unit tests, en er werd hard-coded verwezen naar deze video's omdat ze specifieke elementen hadden die nodig waren voor de tests (bijv. leeftijdsrestricties)
Mooier zou geweest zijn als de maker van youtube-dl zelf rechtenvrije video's had geupload met deze restricties, maar om hiervoor nou een hele repo offline te halen gaat echt te ver.

Dit geeft juist aan dat ze geen enkele andere manier konden vinden om de repo offline te halen, dus dan maar op zo iets lulligs als een unit-test die 10kb van een beschermde video download.

[kidde]

Nee, de DCMA verbied ook het 'omzeilen van technische maatregelen".

De RIAA redeneerde als volgt:

"YouTube stuurt een deel van de URL. Daarna sturen ze extra JavaScript, die mogelijk onder bepaalde voorwaarden (reclame kijken of zo) een tweede deel van de URL berekent. Dat is een "technische maatregel" die het voorkomt, zonder autorisatie van YouTube, en dus de copyright-houder een video te downloaden"

Als "case-law" werd een uitspraak van een rechter in Hamburg gebruikt, die het berekenen van het tweede deel van de URL een beveiliging vind, die door youtube-dl wordt omzeild.

De EFF redeneert dat het niet omzeilen is, omdat youtube-dl hetzelfde doet als een webbrowser, en de JavaScript code die wordt gestuurd om het 2e deel van de URL te berekenen 'publiek' is. Er wordt geen geheime code ontfutseld, er wordt niet noodzakelijk aangezet tot kopiëren en verspreiden, het Duitse recht is niet van toepassing in de VS en de Hamburgse rechter begreep geen JavaScript.

[theguyofdoom]

Er waren bepaalde extra beveiligingen op bepaalde videos, dus dat is niet mogelijk.

[cricque]

Dat had gekunnen uiteraard, maar niet iedereen heeft een zee van tijd. Meestal zijn deze dingen gewoon een "hobbyprojectje". En dus bijgevolg moeten er keuzes gemaakt worden. Als ik moest kiezen tussen tijd steken in een paar films te maken of een bug op te lossen, tsja dan zal ik toch altijd eerst voor de bug gaan. Dus daar snap ik het wel. En omdat ik die films gemaakt hebt, kan het misschien nog verkeerd zijn. Deze zijn tested op die content, dus als er wat wijzigt, kan je dat dan ook in de unit tests zien. Uiteraard kan je dat ook allemaal zelf opzetten etc. Enja een avondje werk had dit wel opgelost, maar het staat iedereen vrij om zelf een paar test/demo films te voorzien, zodat daar mee kan gewerkt worden.

[5pë©ïàál_Tèkén]

Kan ook zijn dat ze bewust de RIAA uit de tent hebben gelokt. Nu weten ze dát ze mee kijken, waar de pijn precies zit en hebben ze, min of meer, het moment van de botsing met RIAA kunnen plannen. Gezien het feit dat anderen voort borduren op hun werk kan ik me voorstellen dat men niet wil dat 'de hele boel' omvalt als deze repository offline moe(s)t. Nu weet men hoe de RIAA er in staat en kan men verder werken.

Slim gespeeld van ze.

[Accretion]

Neeui, je schrijft een paar tests, met een lijstje van een paar video's.
Maar blijkbaar is zelfs dat een probleem.

Dit soort open source software heeft niet vaak een "verborgen masterplan", aangezien de discussies hierover ook inzichtelijk zijn en ze vooral code ontwikkelen en zich juist niet teveel willen bemoeien met politiek.

[cappie]

Als dat bewust is geweest, zijn ze wel heel erg gehaaid geweest.. daar zie ik die devs niet voor aan, als je hun codebase bekijkt ^_^

[_Thanatos_]

De RIAA had gewoon een PR kunnen indienen, maar daar vinden ze zichzelf blijkbaar te goed (of te slecht) voor

[HollowGamer]

Meer informatie van GitHub zelf: https://github.blog/2020-...opers-youtube-dl-is-back/

via TF

[JazzKatua]

Bij deze de repo gecloned om meer te weten te komen over dit project. Zelf gebruik ik Video DownloadHelper al jaren, maar sinds geruime tijd niet meer zo happig op het gebruik ervan... Dus mss kan YT-DL wel interessant zijn om naar over te schakelen.

[sfranken]

Youtube-DL is een prima product. De vele frontends zijn niet altijd even jofel, echter. Daarom pak ik gewoon de youtube-dl versie die gepacked word met Fedora hier en download wat ik nodig heb via de commandline.

[WhatsappHack]

Idem hier op MacOS. En wat aliases gemaakt om snel zaken te doen zoals omzetten naar mp3, cut of andere videocodec. Op de terminal is zoveel fijner werken dan een GUI voor simpele zaken als dit

[sfranken]

Ik heb één specifieke youtube-dl alias:

alias youtube-dl-sound='youtube-dl -x --audio-format=flac --audio-quality=0 --xattrs'

Doet wat het moet doen.

[deadinspace]

Realiseer je wel dat --audio-format=flac niet betekent dat het als flac gedownloadt wordt van youtube.

Het wordt gedownload als een lossy format (bv opus) en daarna geconverteerd naar flac. In dit scenario is dat vooral verspilling van je disk space, want de kwaliteit gaat niet beter worden dan het bronmateriaal.

[sfranken]

Dat weet ik. De reden dat ik dat doe is omdat alles hier in huis in flac is, ik wil geen 2 verschillende codecs door elkaar. Disk space zat

[eric.1]

Uit het vorige artikel van Tweakers:

Volgens de advocaten van de auteursrechtenorganisatie schendt de YouTube-downloader de rechten van de contentbedrijven die het vertegenwoordigt, zoals Sony Music en Universal Music. Die willen niet dat hun video's van YouTube worden gedownload.

Als ik het nu goed begrijp ging het hier dus helemaal niet om. Dat zou wat reacties hebben gescheeld

[StefanJanssen]

Jawel, in de tests van het systeem werden die video's gedownload

[eric.1]

Ja, 10Kb, daar ging hun opmerking gok ik niet over.

[StefanJanssen]

Heel veel meer dan dat kan zo'n platenmaatschappij ook niet op juridisch gebied.

Al heeft het nieuws rond deze YouTube downloader denk ik wel bekendheid voor gemaakt waardoor het uiteindelijk averechts werkt. Volgens mij zijn er op Tweakers al 3 nieuws berichten geweest over Youtube-dl door het "neerhalen".
1. Over het neerhalen
2. Over de forks die mensen online gingen zetten
3. Het bericht dat het weer is teruggekomen

Ik denk dat menig Tweaker zonder al deze aandacht niet van youtube-dl had geweten.

[Mr777]

Kan bevestigen dat het weer werkt onder Linux. Alleen Video Downloader, een grafische schil die er omheen gebouwd is werkt nog niet, die zoekt nog steeds naar een module "youtube_dl" (met underscore i.p.v. koppelteken). Heel vreemd, vroeger nooit problemen mee gehad. Maar dit zal mettertijd ook wel gladgestreken worden.

[The Third Man]

Youtube-dl gebruikt wel gewoon een _ in z'n mapnaam, dus als je hem in Python code wil importeren is het wel 'import youtube_dl'. Dat het nu niet werkt suggereert dat je hem wellicht moet herinstalleren.

[biomass]

Merkwaardig, alsof de Youtube downloader niet gevonden mocht worden als je zou zoeken op "I Love It" (en hoe een generieke term is dat wel niet). Het individueel downloaden van video's is voor YT gerommel in de marge.

[ikt]

Details over de terugkeer en de wijzigingen staan nog niet online. Wel is duidelijk dat de ontwikkelaars bezig waren met het verwijderen van code waar de branchevertegenwoordiger van de Amerikaanse muziekindustrie, de RIAA, aanstoot aan nam.

Het leuke aan git is dat de geschiedenis vast staat. Te zien is dat de commits tussen de laatste publieke versie (mirror van 23 oktober) en de huidige repository, de history niet is veranderd ten opzichte van de oude publieke versie. Dit sluit uit dat de ontwikkelaars code hebben gecensureerd, omdat de git hashes wijzigen wanneer iets in het verleden wordt veranderd (geschiedenis herschrijven).

Dan is de zoektocht makkelijker en hoef je niet handmatig te diffen naar wat er is veranderd. Uit de commits is sowieso te zien dat er expliciet een commit is geweest om bepaalde teststappen te verwijderen, die inderdaad content download waarop copyright rust: de betreffende commit.

Als we dan verder willen zoeken naar wat er is veranderd, kan dat via een handige compare functie van GitHub: Hier een vergelijking tussen de laatste pre-takedown commit en de huidige master-commit.

Ik kan zo geen wijzigingen vinden van functionele code, dus mijn conclusie is dat alleen het testen met media waarop copyright zit, de aanleiding voor de DMCA takedown is geweest. De vermoedens dat het aan de decryptiecode ligt, lijken hiermee ongegrond.

Conclusie fout - zie GitHub zelf

[Reactie gewijzigd door ikt op 22 juli 2024 14:28]

[Bulkzooi]

Heb je git blame in een hex editor gecompared? Hoe lang geleden? Library, project scrubben zijn oude bezigheden.

Firefox is ook net geswitched naar vp9 geloof ik.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 14:28]

[MrFax]

Ik had al gedacht: Wat aan youtube-dl is aan een copyright claim onderheven? Als de broncode origineel is, is alleen de moraliteit van het programma aan sprake, en daar heeft een DMCA-claim niks mee te maken.

... Maar het blijkt dus te zijn dat er verwezen werd naar een nummer in de broncode. Maar is het dan zo dat alleen de titel en artiest van een nummer genoeg is voor een DMCA-claim?

Kan Tweakers nu een DMCA-claim krijgen omdat het deze nummers bij naam genoemd heeft? Niemand zou ja zeggen, maar zoals ik het lees slaat het daar in dit geval wel op.

[The Third Man]

Niet alleen het verwijzen, het is dat als je de unit test uitvoert, hij de clips van die partijen gebruikt om 'even' te testen of de functionaliteit werkt. Dat valt buiten de fair use waar een download wel onder valt omdat die dan logischerwijs wel gedaan wordt om vervolgens te bekijken.

[Accretion]

Waarom geen fair use?
D'r wordt niks met de content gedaan, het is niet eens "use" en zeker niet "unfair" als in kopiëren en verkopen?

[The Third Man]

Omdat content gratis beschikbaar wordt gesteld voor een reeks vastgestelde doeleinden. Primair is dat het online bekijken. Echter het eerst downloaden, dan kijken wordt niet direct daarbij gerekend maar als fair use toch toegestaan. Immers het doel blijft hetzelfde maar wordt via een omweg bereikt. Dat men dan bij herhaaldelijk kijken reclameinkomsten mist is dan maar jammer, want men weet ook dat als je het blokkeert je alleen maar de kans verkleint dat mensen het uberhaupt nog gaan kijken.

Het laden van content om functionaliteit van je programma te testen valt daar niet onder. Dan regel je die zelf maar, en dat is ook iets wat de makers ook eenvoudig hadden kunnen regelen via rechtenvrije content. Dit is overigens vrij normaal in de videotechnische industrie waarbij de meeste bedrijven zelfs eisen dat de softwareleverancier rechtenvrije testcontent gebruikt om zelf niet in conflicten verzeild te raken.

[GewoonWatSpulle]

Tweakers speelt niet de eerste 10 seconden af van het bestand maar verwijst er enkel naar, dat is het verschil.

[Raymond Deen]

10K is zelfs nog minder dan 10 seconde aan muziek...
Volgens mij halen radiozenders van het begin en einde van een nummer zo'n stukje af om minder te hoeven betalen dus het zal wel ergens benoemd zijn als essentieel deel van de productie of zo.

[The Third Man]

Niet zozeer minder betalen, de meeste platenlabels verbieden integrale uitzending over radio. Je moet dus er altijd dus doorheen kwekken, crossfaden of op een andere manier de eindjes verstoren of knippen.

[wild_dog]

Als onderdeel van de DMCA is niet alleen inbreuk verboden, maar ook het maken van tools/producten die copyright beschermende technieken omzeilen. Denk aan de mod chips waarmee je bijvoorbeeld gebrande schijfjes kan spelen op een playstation.

Om als dergelijk te worden bestempeld, moet de tool of geen andere significante functie hebben dan copyright omzeilen, of voornamelijk voor dat doel worden geadverteerd. En de claim tegen YouTube-dl was dat ze "adverteerde" dat het copyright beschermd materiaal kan downloaden... in een unit test... die (As Far As I Know) specifiek test dat de video's in questionnaires niet te downloaden waren....

[RoestVrijStaal]

Ik snap niet dat de ontwikkelaars (van youtube-dl) nog vertrouwen hebben in GitHub. Leuk dat de repository weer hersteld is, maar de repository had niet met het DMCA-verhinkel offline gehoeven. Een medewerker van de RIAA kon ook eerst een issue aanmaken om de boel aan te kaarten. Sterker nog dan was er geen advocaat nodig geweest om die DMCA-verzoek te schrijven.

Als ik de developers van youtube-dl was, zou ik de repository van youtube-dl zelf hosten of bij een andere Git repository service¹ herbergen en die van GitHub gebruiken als read-only mirror zodat andere applicaties e.d. die van youtube-dl afhankelijk zijn niet over de zeik gaan.

De RIAA mag dan wel "gewonnen" hebben, maar door dit gebeuren heeft ze veel mensen in hun harnas gejaagd èn ook tegen GitHub opgezet.

¹ Zie mijn reactie op het vorige artikel.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 14:28]

[JeroenED]

Mag ik eens weten waar jij ziet dat de RIAA gewonnen heeft? Je kan hooguit zeggen dat ze alletwee gewonnen hebben, want youtube-dl staat gewoon integraal terug online zonder wijzigingen in het programma zelf. De RIAA heeft enkel een heel beschamende copyright claim gedaan en heeft enkel wat minder gezichtsverlies geleden.

[RoestVrijStaal]

"Gewonnen" stond niets voor niets tussen aanhalingstekens

De Youtube-videos van de slaven artiesten van de RIAA worden niet meer in enige vorm gebruikt door het youtube-dl project. Dit staat los van de discussie of er praktisch auteursrechteninbreuk is geweest. De tests horen of zien immens de streams niet zoals stervelingen dat kunnen.

Ik heb het idee dat juist door deze actie de weggezakte haat tegen de RIAA sedert het neerhalen van Napster en LimeWire weer opgeborreld is.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 14:28]

[JeroenED]

Ok. Voor mij is dit gewoon correcte schrijfwijze want persoonlijk vind ik dat ook al haal je 100% je slag binnen (evt met een extraatje) je nog steeds niet als winnaar kan voelen.
Er is een reden waarom je een rechtzaak aanspant en die reden is altijd negatief (dus verlies), anders heb je gewoon geen zaak. Maar dit is een compleet andere zaak.

[CyBeR]

Ik snap niet dat de ontwikkelaars (van youtube-dl) nog vertrouwen hebben in GitHub. Leuk dat de repository weer hersteld is, maar de repository had niet met het DMCA-verhinkel offline gehoeven.

Ik denk niet dat je snapt hoe de DMCA werkt. Als GitHub (of een ander platform) een DMCA-takedown notice krijgt zijn ze verplicht om die repo offline te halen.

Een medewerker van de RIAA kon ook eerst een issue aanmaken om de boel aan te kaarten.

Waarom zouden ze dat doen als ze ook gewoon een DMCA takedown notice kunnen sturen en het probleem dan direct weg gaat?

Sterker nog dan was er geen advocaat nodig geweest om die DMCA-verzoek te schrijven.

De RIAA is een advocatenclub net als BREIN dat hier is. Dat is echt geen probleem voor ze.

Als ik de developers van youtube-dl was, zou ik de repository van youtube-dl zelf hosten of bij een andere Git repository service¹ herbergen en die van GitHub gebruiken als read-only mirror zodat andere applicaties e.d. die van youtube-dl afhankelijk zijn niet over de zeik gaan.

Maakt niet uit, dan had dat andere platform gewoon ook een DMCA takedown notice gekregen.

De RIAA mag dan wel "gewonnen" hebben, maar door dit gebeuren heeft ze veel mensen in hun harnas gejaagd èn ook tegen GitHub opgezet.

Again dat is hun hele business model.

[RoestVrijStaal]

Ik begrijp je reactie heel goed. Maar doordat de RIAA zo gehandeld heeft, worden stereotype beelden van de USA en de copyrightindustrie versterkt. Coöperatie gaat beter als er geen dwang is geforceerd met een wet of juridische druk. En dat staat nog even los van dat door dit alles youtube-dl bekender is geworden.

Niet mijn probleem natuurlijk Echter vind ik het wel jammer van de verspilde energie. Daarnaast vind ik het hilarisch dat GitHub nu volledig in damage control modus gaat door deze acties en beterschap belooft heeft.

Maakt niet uit, dan had dat andere platform gewoon ook een DMCA takedown notice gekregen.

Het kan voor de RIAA aardig lastig worden als elke ontwikkelaar een eigen mirror van de youtube-dl-repository met bijvoorbeeld Gitea op een server bij een van de vele bulletproof hosters heeft draaien.

Daar komt bij dat de originele DMCA verzoek erg summier was over hoe en waar in de repository de zogenaamde "inbreuk" (De tests horen of zien immens de streams niet zoals stervelingen dat kunnen) heeft plaatsgevonden.

"Als ik GitHub was", had ik het teruggestuurd met "Iets meer concreet bewijs graag a.u.b."

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 14:28]