Open source licenties en verdienmodellen
public tech open source code for nl meetup
21 januari 2021
Vandaag een leuke Code for NL meetup over open source licenties en verdienmodellen. Walter van Holst van Hooghiemstra en partners vertelde over de verschillende, ook niet juridische, aspecten van deze licenties, waarna er ruimte was voor vragen.
Wanneer is iets een open source licentie? Volgens Walter is kenmerkend voor open source licenties dat ze de omstandigheden creëren om de broncode te mogen en kunnen bekijken en verspreiden, de vrijheid geven om aanpassingen te maken en te mogen verspreiden, dat ze de reputatie van de oorspronkelijke maker beschermen en waarborgen, en geen mensen, activiteiten, producten, en technologiën uitsluiten.
Naast de gebruikersovereenkomst is er de kant van de distributievoorwaarden. Dit is waar de licenties zeer uiteenlopen, van MIT aan de ene kant van het spectrum (de auteur is niet aansprakelijk, moet vermeld worden, en verder mag je doen wat je wil) via APL, MPL, GPL naar AGPL aan de andere kant van het specturm (alle code die je wijzigt of toevoegt moet ook weer worden vrijgegeven onder dezelfde voorwaarden).
Meer dan juridisch
Redenen voor het gebruik van open source licenties, en ook het kiezen daarvan, lopen uiteen, zo vertelt Van Holst. Zo vergemakkelijkt het bijvoorbeeld het samenwerken over organisatiegrenzen heen en maakt het peer review van code eenvoudig, maar liggen er soms ook politiek-ideologische argumenten aan ten grondslag. De hele free software beweging is immers ook ontstaan als verzet tegen de praktijken die closed source softwarebedrijven er eind vorige eeuw op nahielden.
Tip: publiceer wel altijd een licentie bij je broncode op github, want zonder licentie mag je code officieel niet eens gecompileerd worden door iemand anders.
Geld verdienen
Tot slot bespreekt Walter nog een flink aantal verdienmodellen die verschillende grote bedrijven gebruiken rondom of op open source software, van consultancy tot maatwerk in opdracht, van implementatie tot hosting en support. Ook worden online diensten genoemd die draaien bovenop open source software en daaraan bijdragen.
Openstaande vragen
Vragen waar we niet aan toe zijn gekomen, maar die we nog wel met elkaar willen bespreken in een vervolgmeetup:
- zijn er best practices / handige workflows voor het werken met open source licenties, bijvoorbeeld: wat zijn de stappen die je doet wanneer je een repository clonet op Github?
- op welke manier moet je minimaal invulling geven aan de naamvermeldingsverplichting, en wat is voor ons als community de manier waarop we dat (niet minimaal) willen doen; is dat in de interface, of in de repository, in de handleiding, “op de verpakking”, in artikelen?
- bovenstaande vraag, maar voor contributers;
- er zijn veel verdienmodellen rondom open source software, maar die vertrekken allemaal vanuit bestaande paketten; hoe zit het met innovatie, vooral in de publieke sector; wat zijn daar de verwachtingen, rollen, en omgangsvormen?
Meer weten?
De discussie gaat verder op de Code for NL Slack in kanaal #open-samenwerking, dus kom vooral meepraten. Voor meer diepgaande vragen aan Walter van Holst kun je kijken de website van Hooghiemstra & Partners.
Andere aantekenignen
Samen denken, ruwe schetsen
25 januari 2021
Als ik als visueel denker met mensen samenwerk, kom ik er niet omheen om ideeën ook visueel te maken en die plaatjes samen met mensen te bespreken, om te checken of ik het snap. Daarvoor is het helemaal niet nodig om mooie plaatjes te maken, heb ik gemerkt. Sterker nog, er valt veel voor te zeggen om juist hele ruwe schetsen te gebruiken.
Gemeente Amsterdam doet ‘t zelf(s)
18 april 2018
De gemeente Amsterdam ontwikkelt sinds twee jaar open source toepassingen in eigen huis. “Leveranciers houden de overheid vaak gegijzeld met ondoorzichtige software”, beweert Datalab directeur Berent Daan.
Open Source voor Open Samenwerken
2 september 2019
In de praktijk blijkt de mentaliteit in overheids ICT-projecten vaak nog best wel ‘closed source’ te zijn: pas als het project is afgerond, wordt de code openbaar gemaakt. Vaak duurt het zelfs nóg een paar maanden, omdat de code geschikt moet worden gemaakt voor publicatie.