Een lezer mailde me:
Wij gebruiken al een flink aantal jaren een bepaald softwarepakket voor onze bedrijfsvoering. De leverancier heeft het onderhoud vorig jaar gestaakt, en dat begint nu een probleem te worden. We zouden nu graag een ander wat noodzakelijk onderhoud laten uitvoeren, en een paar nieuwe features inbouwen. Maar kan dat zomaar?
Nee, dat kan niet zomaar. De auteursrechten op het pakket liggen nog steeds bij die leverancier, en dat betekent dat je zijn toestemming nodig hebt om het pakket te mogen wijzigen. En dat gaat geld kosten, zeker als je ook nog eens de broncodes wilt hebben. In de meeste gevallen vermeldt het contract niets over de mogelijkheden van onderhoud nadat de leverancier ondersteuning heeft beëindigd.
Het is wel toegestaan dat de nieuwe ontwikkelaar de API’s en interfaces achterhaalt en op basis daarvan eigen modules maakt. Daarvoor heb je geen medewerking van de huidige leverancier nodig. Ik hoop voor je dat de software dergelijke interfaces heeft op een eenvoudig te achterhalen manier.
Er is bar weinig jurisprudentie op dit gebied. Als het gaat om maatwerksoftware, dan is er het arrest Van Genk/De Wild kun je dan aanspraak maken op de broncodes om zo onderhoud te verrichten. Wel moet het contract dan bepalen dat je de volledige eigendom krijgt van de maatwerksoftware (een gebruikelijke bepaling overigens). Maar bij standaardsoftware kun je het vergeten.
Er zijn genoeg bedrijven die dan maar de code afschrijven en een nieuwe codebase laten bouwen waarbij ze wel de gewenste rechten hebben. Steeds meer kiezen daarbij voor open source, omdat je dan per definitie dit probleem niet hebt.
Arnoud
Hangt het er niet ook een beetje vanaf waarom het onderhoud gestaakt is? Als de producent gewoon een nieuwe product heeft gemaakt dat het oude product moet vervangen en daarom na verloop van tijd gestopt is met ondersteuning (zoals bij Windows- en Ubuntu-versies gebeurt) dan lijkt het me dat je weinig kunt beginnen. Maar als de producent gewoon gestopt is omdat het niet meer haar prioriteit is, heb je dan niet wat meer kans voor de rechter?
Als er van te voren over nagedacht is, kunnen dit soort problemen voorkomen worden middels escrow. Maar dat kost dan natuurlijk wel ook weer extra geld.
http://en.wikipedia.org/wiki/Sourcecodeescrow
Open Source is de beste keuze, altijd.
Het ruikt naar ‘misbruik van auteursrecht’ indien geen toestemming gegeven wordt zelf onderhoud/wijzigingen door te voeren bij software pakketen waar de levenrancier note bene het onderhoud van gestaakt heeft.
Moet je eens voorstellen dat je een auto koopt en je mag geen wijzigingen aanbrengen, ondenkbaar. Niet valt in te zien waarom leveranciers van software het recht behoren te hebben op verzet tegen eigen onderhoud cq zelf aanbrengen van wijzigingen wanneer de leverancier support staakt.
Ik vind ze altijd weinig toevoegen die vergelijkingen tussen IT en auto’s, maar…
Dat je er zelf een trekhaak aan kunt zetten of de banden vervangen betekent nog niet dat je recht hebt op de blauwdrukken als de fabrikant de productie stopzet.
Bovendien denk ik dat het woord “onderhoud” een heel andere betekenis krijgt in deze analogie. Onderhoud op software bestaat uit reparatie van bugs en ontwikkeling van de functionaliteit. Geen van twee?n worden nodig door gebruik, zoals onderhoud bij een auto.
@Hans
Heb het over ‘misbruik van auteursrechten’. De blauwdruk van een auto staat tot de beschikking zodra de auto gekocht is. Eigendom heet dat dan. De auto mag dan naar hartenlust aangepast worden. Alle ins en outs van de auto zijn bekend. Wie wil kan de auto pimpen. Je mag ook onder de motorkap kijken de motor binnenste buiten halen. Cylinders uitboren, andere velgen, spoiler. Hoeft niet eens van dezelfde leverancier te zijn als de auto.
Bij software is dat helemaal anders. Afnemers zijn afhankelijk van de nukken van leveranciers die zich te pas en te onpas beroepen op het auteursrecht. Broncode bekijken, het equivalent van onder de motorkap kijken, is verboden. Mede daardoor valt feitelijk niet te controleren of de auteursrechtenclaims op die broncode terecht zijn. Aanpassen omdat er geen service meer is, is ook verboden. Pimpen van de software, is verboden. Alleen het gebruik wat in de licentie is toegestaan, mag. Een dergelijke vergaande ‘dictatuur’ van software leveranciers levert uiteraard alras misbruik van recht op.
Dictatuur? Je hebt er toch zelf voor gekozen? En de bijbehorende prijs betaald… Maar dat open source een goed idee is zijn we het wel over eens, geloof ik. 😉
@jdk : Bij software is het inderdaad anders. Die koop je (over het algemeen) niet, maar je koopt een gebruiksrecht. Vergelijk het dus niet met het kopen, maar eerder met het huren van een auto. En de verhuurder van een auto zal ook niet blij zijn als je bijvoorbeeld de cylinders gaat uitboren…
Heb eens meegemaakt dat een leverancier van software niet meer in staat was om licentiecodes te genereren voor een produkt dat ze een paar jaar daarvoor geleverd hadden. Die nieuwe licentiecode was nodig nadat we vanwege hardwareproblemen wat onderdelen aan de computer vervangen hadden. Daar sta je dan met je eeuwigdurende gebruiksrecht voor die software en een knullige leverancier. Op zo’n dag vergeet je graag heel eventjes het auteursrecht en brengt wat wijzigingen aan.
@7
Maakt niet uit waarmee vergeleken wordt. Misbruik van auteursrecht is het.
Het is zinloos om de code van een te laten bouwen maatwerk product open source te laten worden zodat je concurrentie een zelfde appliacite goedkoper kan laten maken. Zorg gewoon dat de developer van je maatwerkapplicatie de volledige rechten op de code meelevert
Open source is eigenlijk alleen boeiend voor aan te schaffen software pakketten of software grotendeels gebaseerd daarop. Niet voor maatwerk.
@10 De gedachte achter open source is juist om dit soort problemen te voorkomen: het betekent niet dat de broncode publiek gepubliceerd dient te worden, maar dat wanneer je als organisatie de software “aanschaft” deze ook de broncode krijgt.
Het hangt af van de strategie die je met het maatwerkproduct voorziet. Wil je daarmee een uniek product of dienst leveren naar klanten, dan moet je het zeker niet open sourcen. Wil je dat het product de wereldstandaard wordt zodat jij op basis van dat product iets unieks kunt neerzetten, dan is open sourcen juist een slimme stap.
Adobe zou bijvoorbeeld haar Acrobat Reader best kunnen open sourcen, omdat ze geld verdient met de Creator (of hoe heet die volledige suite). En bedrijven als Philips laten custom versies van Linux maken voor in televisies, omdat ze dat een hoop geld scheelt dat dan weer in de wel unieke delen van de software ge?nvesteerd kan worden.
@11, Jan Martijn Volgens mij is dat dus geen open source maar juist closed source (alleen dan gemaakt in opdracht).
@13, hAl,
Dit is een welkbekende misvatting over open source en closed source. Bij closed source krijg je de software als “executable”. Open source wil enkel zeggen dat de broncode meegeleverd wordt.
@Jan Martijn: niet elke licentie waarbij de licentienemer de broncode krijgt, is open source. Essentieel is a) dat je deze mag wijzigen en uitbreiden zoals het jou goeddunkt en b) dat je distributierechten hebt en zo ook anderen diezelfde rechten mag geven. (De OSI definitie omvat nog meer dingen maar dit is de kern.)
BSD licenties zijn open source en die staan toe dat de broncode niet meegeleverd wordt.