Upstream != Fabrikant. Fabrikanten kunnen bijdragen aan upstream, maar dat maakt ze geen upstream.
Ja, dat klopt, maar de meeste drivercode in upstream komt van de fabrikant vandaan. Als het niet fabrikanten zijn, zijn het vaak bedrijven die producten verkopen met spul van de fabrikant erin die een open-source-driver hebben geschreven (al dan niet gebaseerd op documentatie waar zij bij kunnen en anderen niet).
Op zich mooi, natuurlijk, maar als AMD, Intel, Broadcom en Nvidia morgen besluiten om geen moeite meer te steken in Linux, zal Linux 7.0 maar op weinig nieuwe apparaten komen te draaien.
Ik kan prima alles met AOSP-gebaseerde distributies, zonder code van Google.
Gesloten code van Google neem ik dan aan; AOSP is natuurlijk bijna volledige code van Google
Ik vind dat eerlijk gezegd knap, want ik kreeg bij mijn laatste AOSP-experiment bijvoorbeeld dingen als updates voor het WebView-runtime niet werkend (zonder een iOS-stijl systeemupdate dan). Met de Fossify/Simple apps kon ik een hele hoop dingen terugkrijgen die AOSP miste, maar de camera kreeg ik gewoon niet goed. OpenCamera deed het het beste, maar het viel toch allemaal een beetje tegen.
Fabrikanten kunnen gewoon verplicht worden om (in het kader van duurzaamheid, right to repair...) aan de GPL te voldoen, en om niet binary blobs onlosmakelijk aan specifieke versies van de kernel te koppelen.
Daar drink ik op. Ik ben sinds dag één al klaar met de binary blobs die bij Android de norm zijn geworden, alsook de manier waarop Qualcom en Mediatek met kernels omgaan (zij verkopen je een gewijzigde kernel waar je het mee moet doen, in plaats van zelf de boel te upstreamen en fabrikanten een normale kernel te kunnen laten gebruiken). Je ziet deze onzin ook wel op amd64-land (Nvidia t/m Pascal

), maar Android-apparaten zijn vele malen erger.
Eerlijk gezegd snap ik ook niet helemaal hoe fabrikanten om de GPLv
32-restricties heen komen met hun blobs, maar ik heb er nooit echt diep in gezocht.
[Reactie gewijzigd door GertMenkel op 22 juli 2024 13:19]