Hoe kan ik een opensourcemodule opnieuw implementeren?

software-disc-cd-dvd-dragerEen lezer vroeg me:

Ik werk aan een opensourceproject dat een kloon (fork) is van een groter project. Wij krijgen bij onze nieuwste module nu het verwijt hun auteursrechten geschonden te hebben omdat de code te veel lijkt. Maar wij hebben deze echt zelf geschreven, hoewel de module wel exact hetzelfde doet. Plegen wij nu inbreuk?

Auteursrecht rust alleen op code zelf. Op functionaliteit of ideeën kun je geen auteursrecht claimen. Als persoon A een module van persoon B opnieuw implementeert zonder naar B’s code te kijken, dan heeft hij geen auteursrecht geschonden. Dit bewijzen is natuurlijk erg ingewikkeld als B’s code vrij op internet staat. Bewijs maar eens dat je die niet gezien hebt.

Mogelijk is er een beter argument. Als het écht zo is dat er maar één manier is om deze code te schrijven, dan kan er geen auteursrecht op rusten. Auteursrecht vereist creativiteit, en die kan niet bestaan als er maar één route is. Ik twijfel wel of het echt zo werkt. Vrijwel altijd zijn er alternatieven waaruit je kunt kiezen bij het schrijven van software. Al is het maar of een while() lus handiger is dan for() of dat je beter iets in een functie kunt stoppen.

Terug bij af dus. Bewijs maar dat je B’s code niet gezien hebt en er dus niet uit gekopieerd. Dat zal niet meevallen. De standaardtruc is clean room reverse engineering, maar dat werkt niet bij open source.

De enige optie denk ik is dat je heel veel tussentijdse versies publiceert om zo te laten zien dat je van nul bent begonnen met die module. Zeg maar elke keer met tien regels code erbij. Dan bewijs je dat je van nul af zelf schreef en dan heb je dus niet gekopieerd. Het lijkt me wel een heel gedoe.

Arnoud

18 reacties

  1. Zo ingewikkeld is het niet wat je voorstelt. Als je gitextensions oid open hebt staan dan kan in theorie je elke regel pushen(of elk half uur oid). (Of je stelt je ide zo in dat je bij elke save pushed) Je breekt dan wel de regel dat je nooit niet werkende code in mag checken, maar voor dit doel lijkt me dat wel legitiem. Je zou ook een working branch kunnen maken en die weerkunnen samenvoegen elke keer dat code wel werkt, dan houd je wat meer overzicht.Daarnaast heeft elke ide meestal nog wel een local history, wat het bewijzen ook wel eenvoudig maakt.

    1. Dat kan je oplossen door bijvoorbeeld een staging (of developer) repository gebruikt en een production repository. En de staging/dev repo alleen voor devvers van het project beschikbaar maken. Echter, ik vraag me af of je eens een project geforked hebt, er geen leentjebuur meer mag plaatsvinden van het originele project (of andersom) We hebben het over open source. Refereren naar de oorsprong is in dat geval wel nodig, maar als dat een probleem is dan hebben we naar mijn mening een serieus geval van haantjesgedrag te pakken.

    2. Dat zegt weinig over hoe de code tot stand is gekomen. Je kan er alleen maar mee bewijzen in welke volgorde je de code heb gecommit. Hoe bewijs je dat je de originele code niet uitgeprint naast je had liggen terwijl je de nieuwe code schreef.

      1. Hoe bewijs je dat je de originele code niet uitgeprint naast je had liggen terwijl je de nieuwe code schreef.

        Als je alleen werkende code commit? Knappe jongen die werkende brokken code uit het origineel kan omkatten en committen op een dusdanige manier dat het lijkt alsof het allemaal organisch tot stand is gekomen, met rare bugs en alles. Dan kun je net zo goed die code van de grond af zelf schrijven, kost waarschijnlijk een stuk minder tijd.

  2. Bij een kloon of een fork neem je juist wél code over, dus wat heeft de lezer hier precies gedaan? Of is het een fork van een open source project, dan is het nogal wiedes dat de code lijkt, maar dan mag dat toch gewoon?

    De vele tussentijdse versies kun je overigens oplossen door met versiebeheer te werken (zoals Mercurial of Git), dat is tegenwoordig heel gebruikelijk bij open source. Helaas is het ook vaak gebruikelijk om de eerste hap tot een werkbaar prototype in één geheel te committen, waardoor het bewijsverhaal weer lastiger wordt…

    1. Ik heb dezelfde vragen als Jorn. Jammer dat de OP de laatste tijd van die vage stukjes schrijft waar je alle kanten mee op kunt – dubbel jammer omdat de OP ons er al jaren op wijst dat ‘hangt er vanaf’ een toverspreuk in het recht is en dat je dus eigenlijk alleen over heel concrete situaties iets kunt zeggen.

      1. Ik ben juist altijd verbaasd dat iemand met een ongetwijfeld drukke praktijk toch nog de tijd vindt om dit blog bij te houden met interessante onderwerpen, en om zelfs te reageren op de reacties.

        ON TOPIC: Wat ik niet begrijp is wat nu precies het probleem is van de auteursrecht claimende partij. Wat is het nut van ‘open source’ als je vervolgens auteursrecht gaat claimen op de broncode? De ‘fork’ is immers ook een open source project en het hele idee van die openbare broncode was toch dat anderen er ook mee aan de slag kunnen? Wellicht vindt men dat de ‘fork’ de verkeerde open sourcelicentie gebruikt? Dan nog gaat het wel heel erg in tegen de geest van open source lijkt me.

        1. Dat is inderdaad het punt. In bepaalde kringen is de keuze van je opensourcelicentie net zoiets als bij ons welke kerk je behoort: leuk dat je protestant bent, maar hersteld hervormd is toch héél wat anders dan vrijzinnig gereformeerd en een zevendedagsadventist aanspreken als Jehova’s getuige is toch werkelijk ongehoord. Zeker als het om de GPL gaat, want daar zit meer achter dan alleen “deel uw broncode”, de GPL is een politieke boodschap, een maatschappelijke gedachte, die verpakt zit in een softwarelicentie.

    2. De vraagsteller heeft versie 1 van een OSS project geforkt (dat mag) en voegt nu eigen code toe (dat mag ook). Deze versie was dual licensed GPL/BSD en de fork is verder onder BSD gegaan (dat mag).

      Versie 2 van het originele project is beperkt tot GPL. De auteur van code daaruit stelt nu dat een deel van de in de fork toegevoegde code gekopieerd is uit hun GPL project, waardoor de fork een licetieprobleem heeft. De auteur van de fork-code in kwestie stelt dat hij die code zelf geschreven heeft en niet gekopieerd.

      En @Branko, het spijt me dat het zo overkomt. Het is drukker dan voorheen en daardoor kom ik niet zo vaak toe aan reageren als ik zou willen 🙁

    1. Omdat de nieuwe code objectief hetzelfde is als de oude (of er heel hard op lijkt). In eerste instantie is dan een inbreuk zeer aannemelijk , en om zijn vel te redden zal de nieuwe maker dan maar moeten aantonen dat hij van nul begonnen is en dat het toeval is dat de beide zoveel op elkaar lijken.

      Als jij een verhaal over een tovenaarsjongen wilt schrijven die naar een toverschool gaat, en die heet, volledig toevallig, Harry Potter, die naar Hogwarts gaat, dan zal niemand geloven dat dat toeval is. Zo is het hier ook.

  3. Als je gewoon versiebeheer doet en je bewaart je veranderingenvaak genoeg, heb je al een log van de veranderingen. Je kunt denk ik van twee willekeurige stukken code redelijk kunnen berekenen in hoeverre het eerste stuk tijdwinst oplevert bij het maken van het tweede (puur gerekend in het aantal editoperaties dat nodig is om dat tweede stuk code te maken). Is die tijdwinst spectaculair, dan kun je zeggen dat het klonen direct voordeel heeft opgeleverd; zo niet, dan is het toch vooral het idee dat is overgenomen, en als de oorspronkelijke makers dat willen bestrijden moeten ze met octrooien komen (en van goeden huize).

  4. Dat kan standaard praktijk zijn. Je kunt dan gelijk aan Test Driven Development (TDD) doen. Je schrijft een test, implementeert wat code en refactored deze. Volgens commit je werk in git. En daarvan kun je een kopie zetten op GitHub.

    De enige optie denk ik is dat je heel veel tussentijdse versies publiceert om zo te laten zien dat je van nul bent begonnen met die module. Zeg maar elke keer met tien regels code erbij. Dan bewijs je dat je van nul af zelf schreef en dan heb je dus niet gekopieerd. Het lijkt me wel een heel gedoe.
  5. De standaardtruc is clean room reverse engineering, maar dat werkt niet bij open source.

    Waarom werkt dat niet bij FOSS? Het gaat erom dat de ontwikkelaar niet de closed source broncode van het origineel ziet. Of bedoel je dat het origineel open source is? Wat is dan nog het probleem? (Hooguit incompatibele licenties.)

    Overigens komt het wel eens voor dat er inderdaad een stukje code letterlijk is gekopieerd. Een goede oplossing daarvoor lijkt me de ‘ontwikkelaar’ het project uitschoppen, de code eruit slopen en als je een dergelijke module nodig hebt, iemand anders de code opnieuw laten schrijven.

      1. De gangbare methode is dat je een team het origineel laat bestuderen, de interface laat beschrijven en zo een documentatie aanlegt. Input en output van alle methodes worden vastegelgd Met die documentatie in hand gaat een tweede team aan de slag om te implementeren.

        Ik zou zeggen dat als je deze weg hebt bewandeld jouw documentatie plus een verklaring van degenen die het gemaakt hebben dat jij daarbij niet betrokken was een redelijk overtuigend pleidooi zijn voor een onafhankelijke implementatie.

        Omdat het project een fork is en dezelfde functionaliteit wordt geimplementeerd is het overigens niet onverwacht dat er wat gelijkenissen zullen zijn. De meeste projecten gebruiken voorschriftebn voor de opmaak (gebruik van white space) en voor de naamgeving van functies en variabelen. Het is logisch dit bij een fork voort te zetten, anders mag je je hele codebase gaan aanpassen aan de nieuwe richtlijnen. Hierdoor is de kans groot op dezelfde naam voor variabelen als het dan ook nog een niet al te complex probleem is met een voor de hand liggende oplossing voor het probleem is, dan lijkt code al snel.

        Op de universiteit bij software engineeren genoeg opdrachten gezien waarin oplossingen van simpelere deelproblemen erg op elkaar leken. De code style van de syllabus werd aangehouden en iedereen had de beschikking over dezelfde literatuur als uitgangspunt. De verschillen kwamen vooral in de complexere delen naar voren.

        Zonder verdere informatie over het specifieke geval hier durf ik dan ook niet de conclusie van kopieren te trekken puur en alleen op basis van het gegeven dat de code op elkaar lijkt.

        1. Die gangbare methode werkt niet enkel omdat je zégt dat je de broncode niet hebt gezien in team 2. Het werkt omdat het redelijkerwijs onmogelijk is dat je bij de broncode had gekund. Dus hoe veel het ook lijkt, kopiëren was onmogelijk. Bij open source gaat dat argument niet op, het is triviaal even in die broncode te spieken bij team 2. Dat is de zwakte.

          Natuurlijk, je kunt als eerzaam mens (en de meeste programmeurs zijn dat) zweren onder ede dat je dat niet hebt gedaan. Alleen, het recht noemt dat een partijverklaring – een verklaring van iemand die baat heeft bij de acceptatie als juist van die verklaring. En om de negatieve effecten daarvan in te perken, zegt de wet (art. 164 Rechtsvordering):

          Indien een partij als getuige is gehoord, kan haar verklaring omtrent door haar te bewijzen feiten geen bewijs in haar voordeel opleveren, tenzij de verklaring strekt ter aanvulling van onvolledig bewijs.
          Oftewel, de rechter mág niet op basis van die verklaring zeggen “inderdaad, u heeft niet afgekeken”.

          1. Zonder specificatie is het nog steeds niet aannemelijk dat je niet in de code gekeken hebt, hoe heb je anders de functionaliteit gelijk gekregen? Met een specificatie erbij wordt je verhaal gewoon een stuk aannemelijker. Kan het voor een commerciële partij dan toch niet heel interessant zijn om een derde in te huren om zo’n specificatie te schrijven?

            Je is dan dus niet alleen tegen de rechter zeggen “ik heb niet gekeken” , je zegt “ik heb niet gekeken, kijk maar hier zijn mijn logs waarin je de code ziet ontstaan en hier is de specificatie die we hebben gebruikt omdat zo te doen.” En je staat sterker omdat je een document hebt dat zoiets ook mogelijk maakt zonder in de broncode te kijken.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.