smarken blog

Digital Sovrignty, Privacy, EU Law & Legislation, IT, Linux

Ever since Microsoft acquired GitHub for $7.5 billion in 2018, a question has hovered over the world's largest code host: *what exactly can Microsoft do with the code you publish there?* The short answer is: Microsoft does not claim **ownership** of your code ...but its terms grant Microsoft and its affiliates a broad **license to use** it, and since April 2026 that license extends by default to AI model training on your live Copilot sessions.

Ever since Microsoft acquired GitHub for $7.5 billion in 2018, a question has hovered over the world's largest code host: what exactly can Microsoft do with the code you publish there? The short answer is: Microsoft does not claim ownership of your code ...but its terms grant Microsoft and its affiliates a broad license to use it, and since April 2026 that license extends by default to AI model training on your live Copilot sessions.

1. Public repositories: no ownership, but a broad license

You keep the copyright to anything you publish. But under GitHub's Terms of Service, posting public content grants GitHub and its corporate family (which includes Microsoft) a license to host, display, and analyze that content. In practice, public repositories have been treated as fair game for training GitHub Copilot and Microsoft's in-house models ...Copilot was originally trained on billions of lines of public GitHub code, without regard for open-source license terms requiring attribution.

In 2024 GitHub introduced a per-repository opt-out toggle ("Prevent use of my code in AI training"), but its protection is limited:

Scenario Opt-out respected?
GitHub Copilot / Microsoft models Yes
Third-party models (CodeLlama, StarCoder, etc.) No, they scrape GitHub independently
Forks of your repo No, only the original repo's setting is honored
Code already used in past training runs No, not retroactive
Private repositories N/A, excluded from repo-level training by default

2. The 2026 change: Copilot interaction data is opt-out, not opt-in

On March 25, 2026, GitHub announced that from April 24, 2026 onward, interaction data from Copilot Free, Pro, and Pro+ users ...prompts, outputs, code snippets, surrounding code context, accepted and rejected suggestions, even from sessions in private repositories... will be used to train and improve GitHub's and Microsoft's AI models, unless you opt out in your account settings.

"Unless you opt out, you grant GitHub and our affiliates a license to collect and use your inputs (e.g., prompts and code context) and outputs (e.g., suggestions) to develop, train and improve AI models." ...GitHub Terms of Service, Section J

Key caveats:

  • Copilot Business and Enterprise are exempt ...their contracts prohibit training on organizational data.
  • Data may be shared with GitHub's affiliates (i.e., Microsoft), but GitHub says it will not share your inputs/outputs with third-party AI model providers for their own training.
  • GitHub distinguishes private code "at rest" (not used) from code actively sent to Copilot during a session (collectible unless you opt out).
  • For EEA/UK users, GitHub relies on "legitimate interest" as the legal basis ...the same contested approach the Irish DPC accepted in the Meta AI case, which privacy regulators across Europe continue to scrutinize.

3. What the courts say: Doe v. GitHub (9th Cir., Sept. 2026)

The most significant independent documentation is the law itself. In Doe v. GitHub, anonymous developers sued GitHub, Microsoft, and OpenAI, arguing that Copilot reproduced their open-source code without attribution or license terms ...a violation of the DMCA's copyright-management-information rules, with statutory damages up to $25,000 per violation.

On September 16, 2026, the Ninth Circuit affirmed dismissal of the DMCA claim: Copilot creates new works rather than stripping attribution from copies of existing ones, so nothing was "removed." Crucially, the court declined to consider the plaintiffs' input theory ...the question of whether stripping license information during training data preparation is illegal remains undecided. Two breach-of-contract claims are still pending in the lower court. Translation: the legality of training on licensed code is still not settled law.

4. The FOSS community's own documentation

The Software Freedom Conservancy has run its "Give Up GitHub" campaign since June 2022, arguing that Copilot's training on GPL and other copyleft-licensed code violates those licenses, and ...most recently ...that GitHub joined an industry coalition opposing updates to California's AI transparency act on misleading licensing grounds. Independent analyses have also noted that GitHub published no verifiable benchmarks for its claim that training on user interaction data meaningfully improves models ..."trust us, it's better" is a marketing pitch, not documentation.

Bottom line

Microsoft does not own your code ...but its terms of service give it permission to use public code for AI development, and, since April 2026, to train on your Copilot sessions by default. The opt-out works within GitHub's own pipeline only, is not retroactive, and does not stop independent scrapers. The one major legal test so far ended in GitHub's favor on a technicality, without deciding the core training question. If you publish open-source code and care about how it is used: check your repo's AI-training settings, opt out of Copilot interaction-data training if you are on Free/Pro/Pro+, and follow the still-evolving case law.

Sources and further reading

GitHub / Microsoft (official)

Courts and legal analyses

Independent journalism and community

Lex Futura forklarer @LexFutura-DigitalCompliance


Kan en virksomhed kræve adgang til din telefon for at beskytte dig mod svindel?

Det spørgsmål står centralt i en opsigtsvækkende afgørelse fra det italienske datatilsyn, som udløste bøder på over 12,5 millioner euro.

I videoen ser vi nærmere på, hvor grænsen går mellem effektiv cybersikkerhed og retten til databeskyttelse – og hvorfor afgørelsen kan få betydning langt ud over Italiens grænser.


https://www.youtube.com/watch?v=JyHxwazPTWM

Vi i Lex Futura har selv været en tur i Italien – ikke for pasta, sol og gelato, men fordi Italien faktisk har leveret lidt af en GDPR-godbid til os. Derfor fortsætter vi i dag vores italienske tema.

Tilbage i april 2026 kom det italienske datatilsyn med en afgørelse om en bankapp, antifraud-teknologi og adgang til oplysninger om, hvilke apps brugerne havde installeret eller kørende på deres telefoner. Det lyder måske teknisk, men afgørelsen handler om noget ret grundlæggende: Hvor langt må virksomheder gå i sikkerhedens navn, før det bliver for indgribende for forbrugerne?

Sagen: Bankapps, svindelbekæmpelse og "Threat Matrix"

Sagen handler om to selskaber, Poste Italiane og Postepay, som står bag to apps – Bankoposta og Postepay – der blandt andet bruges til bank- og betalingstjenester i Italien.

I begge apps havde selskaberne integreret en løsning kaldet Threat Matrix: en teknologi til at forebygge og opdage svind. Formålet var at beskytte brugerne mod blandt andet malware, kontovertagelse og uautoriserede transaktioner.

Afgørelsen handler således om balancen mellem effektiv digital sikkerhed og brugeres ret til privatliv og databeskyttelse.

Brugernes valg: Adgang eller deaktivering

Brugerne af Android-versionerne fik en besked om, at de skulle give appen adgang til såkaldte usage data. Beskeden forklarede, at adgangen skulle bruges til at opdage skadelig software – men sagde også, at det var obligatorisk. Gav brugerne ikke adgang, kunne de kun logge ind tre gange mere, hvorefter appen blev deaktiveret.

Brugerne blev altså i praksis stillet over for et ret skævt valg: giv adgang, eller mist adgangen til appen – uden alternativer.

Adgangen gik længere end ventet

Appen fik ikke kun adgang til almindelige tekniske oplysninger som enhedsmodel, IP-adresse og operativsystem. Løsningen kunne også behandle oplysninger om installerede og/eller kørende apps på brugerens telefon – teknisk blandt andet hashværdier og metadata til at vurdere tegn på malware.

Og her bliver sagen interessant: En liste over apps på en telefon kan fortælle overraskende meget om personen bag den. Apps til medicin, fertilitet, investering, gambling, dating eller religion kan tilsammen give et ret detaljeret billede af ens privatliv.

Derfor lagde det italienske datatilsyn vægt på, at oplysninger om installerede og/eller kørende apps ikke bare er neutrale tekniske oplysninger – det er personoplysninger, som i nogle tilfælde endda direkte eller indirekte kan være følsomme oplysninger.

Selskabernes argument: PSD2 og nødvendighed

Selskaberne argumenterede for, at behandlingen var nødvendig, og henviste blandt andet til PSD2-reglerne og reglerne om stærk kundeautentifikation. Deres argument: Betalingsudbydere skal kunne opdage svindel og malware, og den konkrete løsning var derfor nødvendig for at beskytte både kunder og transaktioner.

Tilsynets konklusion: Behandlingen gik for langt

Det italienske datatilsyn vurderede, at den konkrete behandling gik for langt:

  • Mindre indgribende alternativer fandtes – f.eks. ekstra autentifikation i risikosituationer, tekniske sikkerhedstjek, netværksmonitorering eller målrettede advarsler. Sikkerhed var et legitimt formål, men den valgte løsning var hverken nødvendig eller proportional.
  • Manglende behandlingsgrundlag – selskaberne henviste til retlig forpligtelse i GDPR. Men tilsynet konstaterede, at reglerne kræver fraud-monitorering, men ikke specifikt indsamling af oplysninger om brugernes apps. En generel sikkerhedsforpligtelse er ikke det samme som en konkret hjemmel til meget indgribende behandling.
  • Gennemsigtighedsproblemer – brugerne fik en besked i appen, men ikke tilstrækkelig klar og specifik information om, hvilke oplysninger der blev behandlet, hvorfor og på hvilket grundlag. En teknisk tilladelse i en app er ikke det samme som en GDPR-compliant privatlivspolitik.
  • Manglende privacy by design og by default (artikel 25, stk. 1 og 2) – selskaberne havde ikke dokumenteret, at de havde overvejet mindre indgribende løsninger før udrulningen, og havde ikke lavet en tilstrækkelig specifik DPIA for netop denne behandling.
  • Problemer med databehandlerstyring og opbevaring – utilstrækkelig kontrol med leverandørkæden, og data i Threat Matrix' database kunne opbevares i op til 28 måneder uden tilstrækkelig begrundelse.

Sanktionerne

Konklusionen var, at behandlingen var ulovlig, med overtrædelser af centrale GDPR-regler: behandlingsgrundlag, gennemsigtighed, dataminimering, privacy by design, DPIA, kontrol med databehandlere, sikkerhed og opbevaringsbegrænsning.

Selskaberne blev pålagt at stoppe indsamlingen af oplysninger om installerede/kørende apps og at fastsætte klare opbevaringsperioder for de resterende data.

  • Poste Italiane: 6,6 mio. euro
  • Postepay: næsten 5,9 mio. euro
  • Samlet sanktion: ca. 12,5 mio. euro

Hovedlæringen: Sikkerhed er ikke et magisk ord

Sikkerhed er ikke et magisk ord, der tilbageviser alle GDPR-krav. Virksomheder må gerne beskytte brugerne mod svind – i den finansielle sektor er de ofte forpligtede til det. Men de skal stadig kunne dokumentere, at løsningen er nødvendig, proportional og gennemsigtig.

Den korte version: Formålet var legitimt, men løsningen var for bred, for indgribende og for dårligt dokumenteret. Man må gerne beskytte brugeren – men ikke ved at kigge længere ind i brugerens telefon, end det kan retfærdiggøres.


Transcript(original): Vi i Lex Futura har selv været en tur i Italien. Ikke for pasta og sol og gelato, selvom det selvfølgelig også er dejligt, men fordi Italien faktisk har leveret lidt af en GDPR godbid til os. Derfor fortsætter vi i dag vores italienske tema, som vi jo også har været inde på tidligere. Tilbage i april 2026 kom det italienske datatilsyn med en afgørelse, som handler om en bankapp, antifraud teknologi og adgang til oplysning om hvilke apps brugerne havde installeret eller havde kørende på deres telefoner. Og ja, det lyder måske teknisk, men afgørelsen handler i virkeligheden om noget ret grundlæggende. Hvor langt må virksomhed gå i sikkerhedens navn? før det bliver for indgribende forbrugere. Så i dag tager vi turen til Italien igen. Denne gang desværre ikke med en aparol i hånden, men GDPRbrillerne på. Den italienske sag handler om to selskab. Hoste Italienne og Postepage. De står bag to apps. Bankoposta og Postepay. Det er apps, der blandt andet bruges i bank- og betalingstjenester i Italien. I de her to apps, der havde selskaberne integreret en løsning, der hedder Thread Matrix. Det er en teknologi, som bliver brugt til at forebygge og opdage svind. Formålet med den her teknologi, det var at beskytte brugerne imod blandt andet mallware, kontovertagelse og uautoriseret transaktion. Afgørelsen handler om balancen mellem effektiv digital sikkerhed og brugernes ret til privatliv og databeskyttelse. Så i og for sig ret simpelt. Brugerne af Androidversionerne af appsene fik en besked om at de skulle give appen adgang til såkaldte usage data. Beskeden den forklarede, at adgangen skulle bruges til at opdage skadelig software, men den sagde også at det var obligatorisk. Hvis brugerne ikke gav adgang, kunne brugerne kun logge ind tre gange mere, og derefter så ville appen blive deaktiveret. Så brugerne, de blev i praksis stillet over for en et ret skævt valg. Give adgang eller miste adgang til appen og ingen alternativ. Og hvad var det så appen egentlig fik adgang til? Det handlede ikke kun om almindelige tekniske oplysninger som enhedsmodel og IP-adresse eller hvad for et operativsystem der var på telefon. Den konkrete løsning kunne også behandle oplysninger om installerede og eller kørende apps på brugerens telefon. Mere teknisk var der blandt andet tale om hashværdier og metadata, som kunne bruges til at vurdere, om der var tegn på mallware på brugernes ø telefon. Og det er her sagen den bliver interessant. For selvom oplysningerne blev brugt til sikkerhed, kan en liste over apps på en telefon fortælle overraskende meget om den person, der har telefonen. Hvis man for eksempel har apps til medicin, fertilitet, investering, gambling, dating eller religion, kan det samlede billede af den her appliste give et ret detaljeret billede af ens privatliv? Det er lige netop derfor det italienske datatilsyn de lagde vægt på at oplysningerne om installerede og eller kørende apps ikke bare er neutrale tekniske oplysninger. Det er personoplysninger. Og i nogle tilfælde så kan de endda direkte eller indirekte være følsomme oplysninger. De her to italienske selskaber de argumenterede for at behandling den var nødvendig. Vi henviste blandt andet til PSD2 reglerne og reglerne om stærk kundeautentifikation. Deres argument var, at betalingsudbyderne de skal kunne opdage svindel og malware og at den konkrete løsning derfor var nødvendig for at beskytte både kunder og transaktion. Okay. Hvad kommer det italienske datatilsyn så frem til? Ja, de italienske datatilsyn, de vurderede, at den konkrete behandling gik for langt. Tilsynet lagde blandt andet vægt på, at det her system thread matrix, det kunne konfigureres på forskellige måder, og at adgangen til oplysninger om installerede og eller kørende apps, det var en meget indgribende funktion. Der fandtes også mindre indgribende alternativer. For eksempel en ekstra autentifikation i risikosituationer, tekniske sikkerhedstjek, netværksmonitorering eller målrettede advarsler til brugerne. Med andre ord, sikkerhed var et legitimt formål, men den valgte løsning var hverken nødvendig eller proportional. Det italienske datatilsyn, de vurderede også, at selskaberne ikke havde et grundigt behandlingsgrundlag for den konkrete behandling. Selskaberne havde især henvist til retlig forpligtelse i GDPR. De sagde, at reglerne om betalingstjenester krævede, at de overvågede svindelissesi. Men tilsynet sagde, reglerne de kræver godt nok, I skal lave fraud monitorering, men de kræver ikke specifikt, at man indsamler oplysninger om, hvilke apps brugerne har installeret eller kørende på deres telefon. En generel sikkerhedsforpligtelse, det er altså ikke det samme som en konkret hjem til meget indgribende behandling af personoplysning. Derudover så var der problemer med gennemsigtighed. Brugerne fik ganske vist en besked i appen, men det italienske tilsyn vurderede, at de ikke fik tilstrækkelig klar og specifik information om, hvilke oplysninger der blev behandlet, hvorfor de blev behandlet og på hvilke grundlag. Og det er en vigtig pointe. En teknisk tilladelse i en app er ikke det samme som en GDPR compliant oplysningsskrivelse, altså en privatliftspolitik. Tilsynet kritiserede også selskaberne for manglende privacy by design og privacy by default i GDPR artikel 25 styk et og to. De havde ikke dokumenteret godt nok, at de havde overvejet mindre indgribende løsninger før den her teknologi den blev rullet ud. De havde heller ikke lavet en tilstrækkelig specifik depia, altså en konsekvensanalyse for netop den her form for behandling af personoplysning. Der fandtes en mere generel vurdering af antifraud aktiviteter, men den dækkede ikke den her konkrete behandling af oplysninger om installerede og eller kørende apps. Ikke nok med det, så var der også problemer med styring af databehandlerne og opbevaring. Blandt andet så mente de italienske tilsyn ikke, at selskaberne havde ført tilstrækkelig kontrol med leverandørkæden og oplysninger i Threat Matrix Analytics database, som kunne blive opbevaret i op til 28 måneder uden en tilstrækkelig konkret begrundelse for, hvorfor de skulle ligge der så længe. Konklusionen blev, at behandlingen var ulovlig. Det kommer ikke som den store overraskelse. Det italienske Datatilsyn fandt overtrædelser af flere centrale GDPR-regler. Blandt andet reglerne om behandlingsgrundlag, gennemsigtighed, dataminimering, privacy by design, depia, kontrol og databehandlere, sikkerhed og opbevaringsbegrænsing. Der er tæt på at være fuld plade. Selskaberne blev pålagt at stoppe den her konkrete behandling via Thread Matrix, som bestod i at indsamle oplysninger om installerede og eller kørende apps. De blev også pålagt at fastsætte klare opbevaringsperioder for de resterende data. Og så til bøderne. Det ene selskabte Italienne, de fik en bøde på 6,6 millioner euro. Det andet selskab Postepay, de fik en bøde på næsten 5,9 millioner euro. Så altså samlet set, så lander sanktionen for den her overtrædelse på 12,5 millioner euro. Og hvad kan vi så tage med fra den her afgørelse, når vi sidder i Danmark her på den anden side af sommeren i Italien? Den vigtigste læring er, at sikkerhed ikke er et magisk ord, der til sidesætter alle kravene i GDPR. Virksomheder, de må gerne beskytte brugerne mod svind. I mange tilfælde så er de forpligtet til at gøre det, ikke mindst i den finansielle sektor. Men de skal stadig kunne dokumentere, at løsningen er nødvendig proportional og gennemsigtig. Hvis en teknologi kan give indblik i brugernes privatliv, for eksempel gennem oplysninger om installerede eller kørende apps, så skal virksomheden kunne forklare meget præcist, hvorfor netop den adgang er nødvendig. Den korte version er derfor, formålet var legitimt, men løsningen var for bred, for indgribende og for dårligt dokumenteret. Og det er nok i virkeligheden afgørelsens vigtigste budskab. Man må gerne beskytte brugeren, men man må ikke gøre det ved at kigge længere ind i brugerens telefon end det der kan retfærdiggøres eller det der er nødvendigt.

Some people love AI. If you're not one of them (or if you have a favorite AI tool that isn't baked into it), using Windows 11 can feel increasingly hostile. It seems like every part of it now exists to push you into using Copilot—even notepad.exe has a prominent AI button in the user interface at this point.

If you'd like your operating system to go back to being an operating system, check out RemoveWindowsAI. This free script changes various registry keys to disable AI features including Copilot, Recall, and the Copilot integrations in applications including Edge, Paint, and Notepad. Using various workarounds , it then configures Windows Update to not install those updates again (the documentation breaks the process down, if you're interested).

Script : https://github.com/zoicware/RemoveWindowsAI

TL;DR Windows 11 ships with Copilot, Recall, AI in Notepad, AI in Edge, Widgets, and 13+ AI features running by default — all consuming RAM and CPU in the background. You can remove all of them through Settings without PowerShell, and block Windows from reinstalling them after updates.