Wat mag ik met snippets van Stack Overflow?

| AE 11706 | Intellectuele rechten | 17 reacties

Een lezer vroeg me:

Zoals vele ontwikkelaars neus ik vaak op Stack Overflow naar oplossingen voor mijn programmeerproblemen. Ik zie dan vaak broncode die de oplossing implementeert, maar ik weet dat ik die niet zomaar mag copypasten in verband met licentieproblemen. Maar wat mag ik dan wel?

Stackoverflow is de bekendste site voor programmeurs om met elkaar tips, ideeën en oplossingen te delen. Meestal gebeurt dat in de vorm van programmeercode (broncode) omdat dat nu eenmaal de meest exacte en directe manier is om aan te geven hoe je in software een bepaald probleem aanpakt. Die oplossingen zijn vaak relatief kort en worden dan ook wel snippets genoemd.

Op software rust auteursrecht. Je mag dus iemands software niet overnemen, ook niet als hij de broncode publiceert of die broncode ergens neerzet waar het de bedoeling is om erover te praten en er naar te kijken. Alleen als er een licentie bij staat, kun je de software gebruiken – binnen de grenzen van de licentie. Helaas zetten maar weinig SO gebruikers expliciet een licentie bij hun snippets.

Bij snippets kun je dan weer wel je afvragen óf er auteursrecht op rust. Er moet wel iets van creativiteit in het werk zitten. Dat kan bij een kort werk, maar zeker bij software is dat geen automatisme. Een snippet die laat zien hoe een API aangeroepen moet worden, zou ik niet creatief noemen. Dat is alleen “kijk hier moet de sessiesleutel, hier zet je parameters zoals kleur en gewicht en dan krijg je een array terug met de actuele voorraad”. Zo’n snippet heeft geen auteursrecht en daarmee mag je natuurlijk doen wat je wil.

Helaas is zodra je boven dergelijke trivialiteiten gaat het al snel onduidelijk. Er zijn geen juridische vuistregels zoals dat tot tien regels code vrij van rechten zijn. Zo werkt auteursrecht gewoon niet. Je moet dan inhoudelijk je afvragen of dit iets creatiefs is of ‘gewoon’ zoals je het zou doen. Dertig regels code met hoe een quicksort werkt zou ik niet creatief noemen (dat is nu eenmaal grofweg een standaard algoritme) maar 5 regels om snel een matrix te scannen is vaak juist héél creatief.

Wat natuurlijk wel altijd mag, is het idéé dat men je communiceert met zo’n snippet overnemen en in eigen code verwerken. Ideeën, principes en algoritmes vallen buiten het auteursrecht en mogen dus vrij worden gebruikt. Dat doe je dan dus door eerst in eigen woorden (of pseudocode) op te schrijven wat er onder die geposte broncode zit, en daarna dat in echte code uit te werken in je eigen applicatie.

Arnoud

Moeten we echt elk jaar de copyrightvermelding in onze broncode updaten?

| AE 9248 | Intellectuele rechten | 23 reacties

Een lezer vroeg me:

Alle broncodes binnen ons bedrijf hebben een copyrightvermelding, als volgt:
Copyright © 2016 $NAAM
THIS SOURCE CODE IS THE UNPUBLISHED AND CONFIDENTIAL PROPERTY OF $NAAM<
AND MAY NOT BE COPIED, MODIFIED OR DISTRIBUTED WITHOUT PRIOR WRITTEN AUTHORIZATION.
(Iets ingekort in verband met leesbaarheid.) Nu moet ik al die notices aanpassen want het is 2017. Kan dat echt niet anders?

Vrijwel alle broncode heeft een copyright notice, maar juridisch is dat eigenlijk nergens voor nodig. Heel formeel bestaat een copyrightvermelding uit drie elementen, in deze volgorde:

  • Het woord "copyright", de afkorting "copr." of het C-in-een-cirkel symbool ©. Allebei is dus eigenlijk dubbelop, en wie "(C)" doet is eigenlijk fout bezig.
  • Het jaar van eerste publicatie van het werk. Als het gaat om een aangepaste versie, dan moeten de jaren van elke wijziging ook worden vermeld. Zo geeft "1985, 1987-1989" bijvoorbeeld aan dat het werk gemaakt is in 1985 met wijzigingen in 1987, 1988 en 1989. Onze vraagsteller hoeft dus niet álle bestanden aan te passen, maar alleen bij de eerste wijziging in 2017 dat jaar toe te voegen.
  • De naam van de auteur. Dit mag een afkorting of pseudoniem zijn, zolang de auteur maar te identificeren is. In dit geval mag de statutaire naam worden gevoerd, of een andere handelsnaam die het bedrijf gebruikt.

Het punt is alleen dat geen enkele wet een copyrightvermelding eist als voorwaarde om auteursrecht te hebben op die software. Auteursrecht ontstaat namelijk enkel door het werk te maken, ongeacht wat er bij staat aan naams- of copyrightvermeldingen.

In de VS was het tot 1978 wél verplicht om zo'n vermelding te doen, anders was je werk niet beschermd. Maar juristen zijn een conservatief stel mensen, en bovendien het stáát heel juridisch dus laten we het maar doen. Cargo culting dus. Hetzelfde geldt voor all rights reserved.

Een naamsvermelding van de rechthebbende is natuurlijk wel zo handig, en een waarschuwing dat zonder licentie deze broncode niet mag worden verspreid kan ook geen kwaad. (Alleen graag zonder hoofdletters, dat leest beter.) Het is dus prima om vanaf nu "Copyright $NAAM" zonder jaartal te doen, dan hoef je er nooit meer aan te komen (tenzij je de auteursrechten verkoopt uiteraard.)

Arnoud

Mag je software reverse engineeren om fouten te vinden?

| AE 8023 | Intellectuele rechten, Security | 31 reacties

Een lezer vroeg me:

Is reverse engineering legaal als het doel is om beveiligingslekken te vinden? Jij zei ooit van wel, maar in de wet staat volgens mij dat je alleen mag reverse engineeren om compatibiliteit te realiseren.

Oef, dat is lang geleden, maar inderdaad:

Alleen die vormen waarmee je compatibiliteit met zelfgeschreven software wilt bewerkstelligen, of waarmee je alleen de achterliggende ideeën, concepten en principes achterhaalt zijn legaal. Met name is het niet legaal om de informatie te gebruiken om een kloon van de software te maken.

Waar de vraagsteller naar refereert, is het wetsartikel dat het eerste deel van die zin onderbouwt:

Als inbreuk op het auteursrecht op [software], worden niet beschouwd het vervaardigen van een kopie van dat werk en het vertalen van de codevorm daarvan, indien deze handelingen onmisbaar zijn om de informatie te verkrijgen die nodig is om de interoperabiliteit van een onafhankelijk vervaardigd computerprogramma met andere computerprogramma’s tot stand te brengen, mits: (bla)

Dit is inderdaad beperkt tot reverse engineeren met als doel het maken van een interoperabel eigen programma. Soms is het daarvoor nodig dat je de broncode van andere software achterhaalt, omdat je anders onvoldoende informatie hebt over hoe je eigen software moet gaan werken. Het vinden van een fout in software is natuurlijk niet hetzelfde als “interoperabiliteit tot stand brengen”, tenzij je zegt “ik moet weten hoe die fout werkt want ook daarin moet ik compatibel zijn”.

Er is echter nog een ander artikel dat specifieker op fouten ziet:

De verveelvoudiging, als bedoeld in de eerste zin, die geschiedt in het kader van het laden, het in beeld brengen of het verbeteren van fouten, kan niet bij overeenkomst worden verboden.

Reverse engineeren is een vorm van verveelvoudigen. Dat is waarom deze actie in principe inbreuk op het auteursrecht maakt. Echter, dit artikel verklaart het verveelvoudigen ter herstel van fouten legaal (zelfs als in de EULA staat dat dat niet toegestaan is). Daarom zou dit volgens mij toch gewoon toegestaan zijn.

Dus ik geloof dat ik toch gelijk had, hoewel om een andere reden dan ik zei 🙂

Arnoud

Schendt HTC de GPL door broncode vertraagd te publiceren?

| AE 2269 | Intellectuele rechten | 29 reacties

Een lezer wees me (dank!) op een bericht bij Freedom to Tinker waar werd gesignaleerd dat de Android-gebaseerde HTC smartphone Linux draait, maar de broncode maar moeizaam beschikbaar komt. Linux is open source (GPL versie 2) en de broncode moet dus meegeleverd worden (of er moet een schriftelijk aanbod bij zitten waar staat waar je… Lees verder