Hoe je een bak geld verdient door gewoon de inkoopvoorwaarden te accepteren, wacht wat?

| AE 11011 | Security | 1 reactie

Corporate purchasing and policies make funding open source Literally Impossible, aldus Swift on Security, een parodiërende maar serieus te nemen securityonderzoekster. De onderliggende klacht is namelijk best reëel: als je een paar tientjes wilt vragen van een groot bedrijf om een bug in je open source project te fixen, dan is dat enorm ingewikkeld. Maar vraag je tienduizend euro voor een supportcontract waaronder je hetzelfde doet, dan is dat zo geregeld. Met dus het advies, doe dat laatste. Waarbij allerlei juristen beginnen te roepen, ja maar de inkoopvoorwaarden dan. Nou ja, die accepteer je dan dus gewoon, wat kan je gebeuren.

In de kern is het probleem de bureaucratie en overhead die je krijgt als je met een groot bedrijf zaken gaat doen. Er moeten veel punten op de i worden gezet wil zo’n organisatie overtuigd zijn dat ze met jou in zee moeten. Dat gaat vaak beter als je een serieuze belofte met langetermijntoezegging kunt doen, oftewel een supportcontract voor drie jaar met 24/7 beschikbaarheid. Dat dat wat meer kost dan het half uurtje dat ze eigenlijk wilden, is een bijzaak.

Natuurlijk zal zo’n bedrijf ook flink wat verwachten, althans op papier. Denk aan stevige aansprakelijkheid, lange betalingstermijnen, eenzijdig opzeggen en al die andere dingen waar je als leverancier op dag 1 tegen gewaarschuwd wordt. Dat moet je niet accepteren natuurlijk. Alleen: als er in de praktijk echt niet meer te verwachten is dan af en toe wat kleine vragen over dingen die je toch al deed, en de software gratis weggegeven wordt, welke aansprakelijkheden zijn praktisch gezien dan te verwachten? Vanuit dat perspectief is “teken gewoon en pak dat geld” een hele logische.

Een andere reden voor dit probleem is denk ik dat een eenmalige uitgave van een paar tientjes vaak wordt gerekend onder het kopje reiskosten/onvoorzien, en bedrijven zijn daar vaak erg huiverig over omdat de kans voor misbruik groot is. Als iedereen in het bedrijf ineens 50 euro mag geven aan een vaag figuur op internet omdat die een of ander leuk tooltje zou hebben gemaakt, waar ben je dan als multinational? (Ik ken mensen die om die reden die 50 euro dan maar privé betalen en het later verrekenen met reiskosten naar een conferentie.)

Het doet natuurlijk raar aan, blog ik een hele serie over hoe je je verweert tegen inkoopvoorwaarden en dan kom ik ineens met een advies om ze gewoon maar te accepteren. Maar soms kan dat gewoon het goede advies zijn.

Arnoud

Nu ga ik aan mezelf twijfelen, is de GPLv2 eigenlijk wel een contract?

| AE 10903 | Intellectuele rechten | 48 reacties

Heibel in de Linuxtent, blogde ik vorige week. Ontwikkelaars aan het besturingssysteem lagen in de clinch over een Code of Conduct die ongepast gedrag vastlegt, met de nodige interpretatieproblemen tot gevolg. Dat leidde tot een oproep om je GPL-licentie in te trekken en zo je stem te laten horen. Waarop ik me afvroeg, kan dat wel, een contract opzeggen in zo’n situatie? Maar nu ga ik zelfs twijfelen of er wel een contract ís.

Dat de GPL naar Europees recht een contract is, is al een hele lange aanname. De standaardlicentie komt uit de VS, en daar is de twijfel wel iets serieuzer: voor een overeenkomst is onder de common law het specifieke concept ‘consideration’ nodig, oftewel een tegenprestatie. Een schenking is dus géén overeenkomst daar, maar een eenzijdige rechtshandeling. In Europa waar de civil law geldt (zeg maar heel Europa behalve Ierland, Engeland en Wales) is het goed mogelijk een overeenkomst te hebben met maar één prestatie.

De GPL kent geen tegenprestatie, en kan daarmee dus geen contract zijn onder common law principes. In Europa is dat geen beletsel, dus kun je hier prima spreken van een GPL contract. (Bijkomstig voordeel is dat het Amerikaanse juristen irriteert zonder dat ze er wat aan kunnen doen.) Voor een contract is niet meer nodig dan een aanbod (dit mag je doen, onder deze voorwaarden) dat wordt aanvaard (lijkt me leuk, ik ga typen en verspreiden).

Hoe meer ik er echter over nadenk, hoe meer ik twijfel of dit eigenlijk wel goed gaat. Want die aanvaarding past niet goed in het systeem van de wet, dat er vanuit gaat dat je akkoord zegt tegen de aanbiedende partij. Als die aanvaarding niet daadwerkelijk aankomt, dan gaat er van alles schuiven. Het belangrijkste is dat de aanbieder dan het aanbod mag intrekken, waarmee het vervalt. Oftewel, zolang niemand jou daadwerkelijk meldt “ik aanvaard de GPL op jouw software, dank je” dan kun je gewoon roepen “licentieaanbod ingetrokken, sorry” en kan niemand meer wat met je software.

De praktijk is natuurlijk dat iedereen gewoon zoekt naar de regel “GPL” in de hoofddirectory van de software en concludeert dat het wel goed zit. Maar je moet je best wel in juridische bochten wringen om dan tot een juridisch perfecte aanvaarding te komen. Een mogelijkheid is bijvoorbeeld dat je zegt, de aanvaardingshandeling (het gebruik van de software) bereikt de aanbieder niet maar dat is de aanbieder zijn eigen probleem (art. 3:37 lid 3 BW), had hij maar meer moeten opletten wie zijn software gebruikt.

Maar wat is het dan wel? De Amerikaanse constructie is een “toestemming onder voorwaarden”, analoog aan een bordje bij je erfgrens. Wie zijn landgoed openstelt met een bordje “Vrije toegang dagelijks tussen zonsopgang en zonsondergang” sluit dan geen overeenkomst, maar verleent eenzijdig toestemming onder een voorwaarde (namelijk dat het overdag is). Zolang die voorwaarde wordt gerespecteerd, mag je er zijn. Schend je de voorwaarde of vervalt deze, dan pleeg je erfvredebreuk en moet je dus wegwezen. Vertaal je dat naar softwareland, dan krijg je toestemming onder het auteursrecht om te handelen maar zodra je de voorwaarden schendt, eindigt de toestemming en heb je een probleem.

Het mooie van deze oplossing is, het maakt niet uit of je de voorwaarden aanvaardt of niet. Negeer ze en je pleegt sowieso inbreuk. Dus je hoeft helemaal niets te zeggen tegen de rechthebbende. De toestemming is ook niet zomaar intrekbaar: gezegd is gezegd, zeker gezien de constructie in de aanhef van de GPL dat het krijgen van een kopie van de software tevens toestemming inhoudt.

Het grote nadeel is natuurlijk, het is nog nooit getest bij de rechter. En ik weet ook niet op welke plek in het Burgerlijk Wetboek ik deze constructie zou moeten duiden. Maar het past beter bij mijn rechtsgevoel anno 2018.

Arnoud

Mag je geen open source meer op Github zetten?

| AE 9296 | Intellectuele rechten | 10 reacties

Paniek in de tent: softwarehostingsite Github heeft nieuwe voorwaarden, en die botsen met veel open licenties. Dat las ik op diverse plekken. Je moet ze een brede licentie geven en afstand doen van je persoonlijkheidsrechten, en dat kan nu eenmaal niet als je open source daar neerzet. Maar volgens mij valt dat wel mee.

De pijn zou zitten in sectie D, over eigendomsrechten. Allereerst de licentie die je moet verlenen:

If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub’s functionality. You may grant further rights if you adopt a license.

In gewone taal: wij als Github mogen jouw content (inclusief eventuele werken van derden daarin) gebruiken en verspreiden op onze dienst, en alle gebruikers mogen dat ook. Dit is typisch juridisch moeilijk doen: oh jee, straks zegt iemand dat wij een kopie maken van zijn software omdat hij die bij ons host, laten we maar even zeggen dat hij ons een licentie moet geven.

Maar belangrijker, ik zie er geen tegenspraak in met de opensourcelicentie die je op je werk plakt. Mensen moeten met de Github functionaliteit kunnen doen wat die functionaliteit doet. En met open source mag je alles: kopiëren, aan derden geven, importeren in je eigen project en ga zo maar door. Het is de distributie naar anderen toe waarop de voorwaarden geschreven zijn, en die anderen moeten dus gewoon zorgen dat ze de voorwaarden nakomen.

Dan de morele rechten: daar moet je inderdaad afstand van doen, iets dat van de Auteurswet mag (behalve het recht van verminking, maar hoe dat moet uitpakken bij software weet werkelijk niemand). Dat botst dan met licenties die naamsvermelding eisen, en dat is 99% van de opensourcelicenties. Maar ik zie ook dat niet als een probleem:

To the extent such an agreement is not enforceable by applicable law, you grant GitHub a nonexclusive, revocable, worldwide, royalty-free right to (1) use the Content without attribution strictly as necessary to render the Website and provide the Service; and (2) make reasonable adaptations of the Content as provided in this Section. We need these rights to allow basic functions like search to work.

Github wil met name voorkomen dat elke zoekopdracht moet zeggen “met code van Jan, Piet en Klaas”. Iets dat iedere rechter volkomen redelijk zal vinden. Zeker omdat je meteen wordt doorverwezen naar de resultaten, waar de naam van de programmeurs wel gewoon bij staat. Ik vraag me zelfs af of Github uberhaupt een licentie nodig heeft om zoekresultaten te mogen tonen, dat zie ik gewoon als citaatrecht.

Alles bij elkaar lijkt dit me dus een storm in een glas water, hoewel ik wel toegeef dat dit iets handiger had kunnen worden opgeschreven.

Arnoud

Opensourcewerk als nevenactiviteit in het arbeidscontract

| AE 9171 | Intellectuele rechten, Ondernemingsvrijheid | 18 reacties

Een lezer vroeg me: Ik ga binnenkort als programmeur aan de slag bij een middelgroot bedrijf. Naast mijn werk wil ik aan allerlei open source projecten kunnen blijven werken, maar dat botst met de auteursrechtclausule uit hun contract: alles is automatisch van hen, ook als ik het in eigen tijd maak. Is daar juridisch iets… Lees verder

Mag je licentie-incompatibele dependencies meeleveren met je software?

| AE 9144 | Intellectuele rechten | 34 reacties

Een lezer vroeg me: Bij veel opensourcepakketten heb je allerlei extra software nodig, zogeheten dependencies. Soms is deze extra software meegeleverd met het pakket, maar vaak niet. Je moet dan maar hopen dat het via de repository van je Linux-distributie beschikbaar is. Ik had vernomen dat dat soms een juridische keuze is, hoe zit dat?… Lees verder

Amerikaanse telecomwaakhond dwingt TP-Link open firmware toe te staan

| AE 8872 | Intellectuele rechten | 15 reacties

De FCC heeft een schikking getroffen met TP-Link van 200.000 dollar omdat verschillende wifi-routers van het bedrijf de radiofrequentieregels van de VS overtraden, las ik bij Tweakers. De routers konden met hoger vermogen zenden dan toegestaan. De schikking komt met een opmerkelijke uitkomst: het bedrijf zal opensourcefirmware toestaan op haar routers, iets dat sowieso vrij… Lees verder

Mag een licentie je verbieden Kwaad te doen?

| AE 8555 | Intellectuele rechten | 11 reacties

Een lezer vroeg me: Onlangs vond ik de zogehten Do no evil-licentie. De JSON licentie zegt “The Software shall be used for Good, not Evil”. Is zoiets juridisch afdwingbaar, of wat zou de rechter hiermee doen? De licentie voor JSON (een protocol voor data-uitwisseling in Javascript) is voor 94,9% gelijk aan de bekende simpele MIT… Lees verder

Hoe kan ik een opensourcemodule opnieuw implementeren?

| AE 8194 | Intellectuele rechten | 18 reacties

Een 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… Lees verder

Een medewerker heeft onze software ge-opensourcet, wat nu?

| AE 6258 | Intellectuele rechten, Ondernemingsvrijheid | 38 reacties

Een lezer vroeg me: Wij zijn een klein softwarebedrijf dat snel wil groeien, dus we hebben recent een aantal mensen aangenomen. Nu blijkt eentje daarvan in zijn vrije tijd aan een opensourceproject te werken. Op zich prima, alleen brengt hij code in dat project die hij voor zijn werk geschreven heeft. Hij zegt dat het… Lees verder