[broncode] wie is standaard de eigenaar?

[StM]

reacties afgesplitst vanuit topic De Devschuur Coffee Corner - Iteratie 4

Wat vinden jullie, moet je je klant in het offerte traject expliciet vermelden dat de source code niet onderdeel is van de levering? Het staat gewoon in mn AV van niet en ook de default van de wet is (volgens mij) nee. Ik heb weer een klant over de rooie nu het project af is en hij al betaald heeft en hij opeens om de source vraagt... En hij is boos omdat ik dat niet vooraf verteld heb of überhaupt ter sprake gebracht. Want dan had hij een ander kunnen kiezen.

Het onderbrengen bij een notaris vind ik prima en wil ik kosteloos aan meewerken, mocht er onverhoopt wat met mij gebeuren. Maar zomaar alles op voorhand vrijgeven niet, of je moet het auteursrecht willen kopen wat uiteraard ook een optie is. Maar dat vind hij oplichterij want hij heeft er immers toch al voor betaald.

[ Voor 5% gewijzigd door BtM909 op 23-09-2013 17:19 ]

[Ealanrian]

Je hebt neem ik aan gewezen op je AV voor de contracten zijn getekend? Ifso dan heb je hem er op gewezen en kan hij daar geen probleem van maken. Of je source code wel of niet levert is in mijn ogen afhankelijk van de opdracht.

[StM]

Uiteraard, het gaat ook niet om het juridische aspect want daar heeft hij geen poot om op te staan. Maar om het zakelijke want de klant is nu boos

[Firesphere]

StM schreef op maandag 23 september 2013 @ 15:31:
Wat vinden jullie, moet je je klant in het offerte traject expliciet vermelden dat de source code niet onderdeel is van de levering? Het staat gewoon in mn AV van niet en ook de default van de wet is (volgens mij) nee. Ik heb weer een klant over de rooie nu het project af is en hij al betaald heeft en hij opeens om de source vraagt... En hij is boos omdat ik dat niet vooraf verteld heb of überhaupt ter sprake gebracht. Want dan had hij een ander kunnen kiezen.

De beste klant heeft voor een product betaald. Dit is een functioneel eindproduct, niet een broncode. Daarnaast ben ik heel benieuwd waar de klant de broncode voor nodig denkt te hebben (Ik denk dat ik het wel weet, namelijk goedkopere jantje aan jouw product verder laten klooien).

De broncode valt gewoon onder jouw auteursrecht. Het eindproduct is wat hij heeft besteld en ontvangen.

[StM]

Firesphere schreef op maandag 23 september 2013 @ 15:38:
[...]

De beste klant heeft voor een product betaald. Dit is een functioneel eindproduct, niet een broncode. Daarnaast ben ik heel benieuwd waar de klant de broncode voor nodig denkt te hebben (Ik denk dat ik het wel weet, namelijk goedkopere jantje aan jouw product verder laten klooien).

De broncode valt gewoon onder jouw auteursrecht. Het eindproduct is wat hij heeft besteld en ontvangen.

Zijn officiële argument is continuïteit voor het geval ik tegen een boom rij, maar dat is ook wat ik vermoed. Mijn redenatie is trouwens exact hetzelfde, dat je betaald voor een eindproduct en niet hoe dat tot stand is gekomen. Voor de continuïteit wil ik gewoon kosteloos meewerken aan een depot

[BtM909]

Firesphere schreef op maandag 23 september 2013 @ 15:38:
[...]

De beste klant heeft voor een product betaald. Dit is een functioneel eindproduct, niet een broncode. Daarnaast ben ik heel benieuwd waar de klant de broncode voor nodig denkt te hebben (Ik denk dat ik het wel weet, namelijk goedkopere jantje aan jouw product verder laten klooien).

De broncode valt gewoon onder jouw auteursrecht. Het eindproduct is wat hij heeft besteld en ontvangen.

Het hangt er natuurlijk vanaf wat je afspreekt, maar ik durf zelfs te stellen dat in softwareland je niet een product afneemt, maar een (exclusieve) licentie op het gebruik van een product.

[Ealanrian]

StM schreef op maandag 23 september 2013 @ 15:40:
[...]


Zijn officiële argument is continuïteit voor het geval ik tegen een boom rij, maar dat is ook wat ik vermoed. Mijn redenatie is trouwens exact hetzelfde, dat je betaald voor een eindproduct en niet hoe dat tot stand is gekomen. Voor de continuïteit wil ik gewoon kosteloos meewerken aan een depot

Dan is dat een compromis waar hij maar mee moet leven. Wat nou als hij iets vind in de code wat gemist is door de requirements maar ook niet afgedekt word door de project grenzen, moet je dat ook kosteloos oplossen omdat je hem er niet op gewezen hebt?

[Puc van S.]

Volgens: http://www.nederlandict.nl/?id=8152# (1na laatste puntje) en http://www.auteursrecht.nl/auteursrecht/22253/ ligt het auteursrecht in eerste instantie bij de opdrachtnemer en niet de opdrachtgever.

[Grijze Vos]

StM schreef op maandag 23 september 2013 @ 15:40:
[...]


Zijn officiële argument is continuïteit voor het geval ik tegen een boom rij, maar dat is ook wat ik vermoed. Mijn redenatie is trouwens exact hetzelfde, dat je betaald voor een eindproduct en niet hoe dat tot stand is gekomen. Voor de continuïteit wil ik gewoon kosteloos meewerken aan een depot

Dat ligt er maar net aan. Als jij geen algemene voorwaarden hebt opgesteld, en je software in opdracht hebt gemaakt, dan is die broncode gewoon eigendom van de opdrachtgever. Dat is hoe de wet in elkaar zit.

[jbdeiman]

StM schreef op maandag 23 september 2013 @ 15:40:
[...]


Zijn officiële argument is continuïteit voor het geval ik tegen een boom rij, maar dat is ook wat ik vermoed. Mijn redenatie is trouwens exact hetzelfde, dat je betaald voor een eindproduct en niet hoe dat tot stand is gekomen. Voor de continuïteit wil ik gewoon kosteloos meewerken aan een depot

Hardstikke leuk, maar als jij tegen een boom rijdt, is jou programma dan "op"? Of draait die nog gewoon? Das net zoiets als dat nu Microsoft gewoon stopt, dan is Windows toch ook niet ineens over, dat werkt nog prima. Na verloop van tijd moet je je data ergens anders heen krijgen, om die niet verloren te laten gaan, maar het programma'tje zelf is niet waar het om draait.

Wij hebben hier (applicatie met een web front-end) de afspraak dat klanten de data kunnen krijgen wanneer ze dit willen, maar de applicatie-bron krijgen ze niet, daar hebben ze ook niets aan. Ze kunnen de applicatie "zoals die is" wel blijven gebruiken, maar op gegeven moment zal die dan niet meer aan wet- en regelgeving voldoen, dus moeten ze dan overstappen naar een andere applicatie.

[Ealanrian]

Grijze Vos schreef op maandag 23 september 2013 @ 16:03:
[...]

Dat ligt er maar net aan. Als jij geen algemene voorwaarden hebt opgesteld, en je software in opdracht hebt gemaakt, dan is die broncode gewoon eigendom van de opdrachtgever. Dat is hoe de wet in elkaar zit.

Heb je daar een bron van? Puk van S. beweert net totaal het tegenovergestelde met bron..

[Grijze Vos]

Het zit toch nog iets gecompliceerder in elkaar. (disclaimer: IANAL.) Mijn vorige werkgever heeft wel eens een aantal van dat soort akkefietjes gehad.

Waar ik eigenlijk op doel is als jij als opdrachtnemer een opdracht aanneemt van een opdrachtgever die een AV heeft. Als hij een AV heeft, en jij niet, en je de opdracht aanneemt, dan accepteer je impliciet die AV van de opdrachtgever. Daarmee kun je dus automagisch rechten afgeven. Het is dus belangrijk om zelf een AV op te stellen om je in te dekken.

[StM]

Waar jij het overhebt zijn inkoopvoorwaarden en ook die moeten ter hand worden gesteld voor aanvang van de overeenkomst. Ik heb niks gezien iig

[PatrickH89]

Blijkt maar weer dat je zo expliciet mogelijk moet zijn om conflicten zoals deze te voorkomen..

[Grijze Vos]

Hier is trouwens een voorbeeld van precies een omgekeerde redenering van het hof van arrest:

http://www.legaltree.nl/s...tware_20_januari_2012.pdf

[StM]

Grijze Vos schreef op maandag 23 september 2013 @ 16:16:
Hier is trouwens een voorbeeld van precies een omgekeerde redenering van het hof van arrest:

http://www.legaltree.nl/s...tware_20_januari_2012.pdf

In dat geval had de opdrachtgever al de broncode, maar wilde de maker de rechten intrekken na een ruzie. En aangezien er niks geregeld was verder, zei de rechter toen dat de opdrachtgever er van uit mocht gaan dat de opdrachtgever eigenaar was geworden van de broncode. Een afwijkende, maar opzich niet hele bijzondere uitspraak...

[TheNephilim]

Nog even over de source discussie hier; als Wordpress theme dev, geven wij altijd meteen de source code weg Dan kunnen ze er nog eens heel makkelijk bij dmv FTP

[StM]

Maar mogen ze er juridisch gezien ook iets mee? Waarschijnlijk niet

[BtM909]

Overigens wel grappig, want in 2010 had Arnoud ook al een stuk tekst over websites: http://blog.iusmentis.com...igenaar-van-onze-website/

[o_f_course]

We hebben zo'n zelfde overeenkomst gesloten (wij de source, zij de software) om dezelfde reden (continuiteit). De source + compilers + beschrijving + scripts etc om een werkende ontwikkelomgeving op te zetten zijn gedumpt bij een escrow agent.

Kostte aardig wat tijd om dit initieel te doen (je moet met zo'n gast ernaast bewijzen dat het op die manier werkt). Daarna is het alleen maar onderhoud.

Ook zijn er natuurlijk kosten aan verbonden. Hier zijn aanvullende afspraken over gemaakt.

[P.O. Box]

Bij mij staat het ook in mijn AV, maar ik wijs tot nu toe mijn klanten er ook op... voor een hoger uurtarief worden ze eigenaar van de broncode... tot nu toe geen problemen gehad (klop klop klop)

TS: ik kan me voorstellen dat het heel lastig is om een boze klant de waarheid te zeggen... je hebt dit inmiddels al gedaan, en ik zou proberen voet bij stuk te houden... dat zal echter zeker gaan ten koste van je relatie met die klant... financieel gezien kan het soms voordelig zijn "toe te geven", als je nog veel opdrachten van deze klant verwacht... dek je dan wel in voor het feit dat hij de code niet mag exploiteren, maar alleen voor zijn eigen toko mag gebruiken...

[ Voor 3% gewijzigd door P.O. Box op 23-09-2013 22:32 ]

[Firesphere]

En vooral niet mag bewerken!

[pedorus]

Op zich verkoop je normaal gesproken een licentie voor het uiteindelijke product. Echter wat P.O. Box zegt: toe geven kan natuurlijk ook in het kader van de klantrelatie. Ik kan me goed voorstellen dat een klant die hier geen rekening mee heeft gehouden zich bedrogen voelt.

Je kunt prima ook de code onder een licentie aan de klant verstrekken, waarbij ze deze bijvoorbeeld zelf mogen bewerken en gebruiken voor eigen gebruik en je de code zelf ook voor andere doeleinden kan blijven gebruiken. Ik zie zelf liever dat iemand anders het onderhoud overneemt, er is altijd genoeg 'nieuw' werk dat meestal interessanter is dan zo'n oud projectje van jaren geleden.

[assasinbats]

Ik ben benieuwd naar de beweegredenen vanuit de klant. Als hij het als een risico ziet dat de source bij jou blijft, kan je dan niet iets opstellen dat de source na het opheffen van je toko na je overlijden naar hem toe gaat, mits dit binnen x jaar gebeurt?

En dan wel even afschatten of hij maffia-connecties heeft.

[TheNephilim]

StM schreef op maandag 23 september 2013 @ 17:18:
Maar mogen ze er juridisch gezien ook iets mee? Waarschijnlijk niet

Maar toch, het neefje van de bakker kan altijd wel wat met de (simpele) Wordpress oplossingen die wij maken. Er zijn dingen die ik niet terug vind op het web, ogenschijnlijk ben ik dan de enige met een oplossing voor bepaalde problemen. Zonde als je dan blijkt dat je code, waarschijnlijk deels 'herschreven', toch door een ander gebruikt word die er gewoon z'n geld mee verdiend.

Je kunt nooit bewijzen dat een ander iets van jou gebruikt. Je ziet alleen clientside code en dat zegt niet zoveel. Maar goed, het totale plaatje is waar je beter in kunt zijn. Code verouderd immers!

[MSalters]

Klant moet niet zeuren. De wet is inderdaad helder, zoals de TS al vermoedde. Auteursrecht kan niet zomaar overgedragen worden, dat moet expliciet schriftelijk.

Als er dus een contract zou zijn waarin dat staat, dan zou hij ervoor betaald hebben, en een punt hebben. "Ik nam aan", "het is gebruikelijk dat", en dergelijke redeneringen zijn onvoldoende.

Maak dus duidelijk aan je klant dat je niet nog eens gaat uitspellen wat de wet allemaal bepaalt. Maak duidelijk dat hij de wet hoort te kennen, al helemaal wanneer hij zaken claimt. En maak hem duidelijk dat je op deze basis geen verdere zaken wenst te doen .

[PatrickH89]

MSalters schreef op dinsdag 24 september 2013 @ 12:19:
Klant moet niet zeuren. De wet is inderdaad helder, zoals de TS al vermoedde. Auteursrecht kan niet zomaar overgedragen worden, dat moet expliciet schriftelijk.

Als er dus een contract zou zijn waarin dat staat, dan zou hij ervoor betaald hebben, en een punt hebben. "Ik nam aan", "het is gebruikelijk dat", en dergelijke redeneringen zijn onvoldoende.

Maak dus duidelijk aan je klant dat je niet nog eens gaat uitspellen wat de wet allemaal bepaalt. Maak duidelijk dat hij de wet hoort te kennen, al helemaal wanneer hij zaken claimt. En maak hem duidelijk dat je op deze basis geen verdere zaken wenst te doen .

Je zou natuurlijk in het kader van 'ik wil deze relatie graag behouden' het ook anders kunnen aanpakken. Enig begrip tonen en samen tot een oplossing komen zou prima een vruchtbare optie kunnen zijn.

[Anoniem: 176826]

MSalters schreef op dinsdag 24 september 2013 @ 12:19:
Klant moet niet zeuren. De wet is inderdaad helder, zoals de TS al vermoedde. Auteursrecht kan niet zomaar overgedragen worden, dat moet expliciet schriftelijk.

Als er dus een contract zou zijn waarin dat staat, dan zou hij ervoor betaald hebben, en een punt hebben. "Ik nam aan", "het is gebruikelijk dat", en dergelijke redeneringen zijn onvoldoende.

Maak dus duidelijk aan je klant dat je niet nog eens gaat uitspellen wat de wet allemaal bepaalt. Maak duidelijk dat hij de wet hoort te kennen, al helemaal wanneer hij zaken claimt. En maak hem duidelijk dat je op deze basis geen verdere zaken wenst te doen .

Of de klant gelijk heeft en of de wetten die hier worden aangehaald relevant zijn, is trouwens maar de vraag.

Laat ik namelijk even een heel andere insteek pakken: De klant (opdrachtgever) neemt de TS aan (voor een project van beperkte duur) om een stuk software te bouwen. Of de TS daarbij ZZP'er is of op basis van een tijdelijk arbeidscontract aan het werk is, is daarvoor niet relevant. En let op, deze redenering kan ook opgaan in situaties waarbij duidelijk sprake is van detachering!!

Waar we het nu over hebben, is dus een situatie waarbij de TS de facto als werknemer van de opdrachtgever gezien kan/moet worden. Als werknemer is het (tenzij uitdrukkelijk schriftelijk en vooraf overeengekomen) zo dat al het werk wat je doet, ten goede komt aan de werkgever. Het auteursrecht (en dus ook de sourcecode) is dan dus eigendom van de opdrachtgever/werkgever.

Let op: Ook als jij in je eigen tijd (dus alleen proggen op zaterdag) een stuk software in elkaar steekt, liggen alle gerelateerde rechten van dat werk bij je baas.
(Geen uitzonderingen? Ja wel, maar dan moet jouw eigen werk echt significant verschillen van het werk dat je in je vrije tijd doet. Dus als je door de weeks slager bent en vervolgens schroef je in je vrije tijd forumsoftware in elkaar, dan lukt het ook wel om de gerelateerde rechten achteraf op te eisen. Maar ben je werkzaam in de IT, bijvoorbeeld als functioneel SAP consultant en vervolgens programmeer je in je vrije tijd wat aansturing voor SCADA en PLC's in elkaar, dan liggen de rechten daarvoor bij je baas.)

Om te kunnen bepalen of de TS of de opdrachtgever gelijk heeft, is het dus heel belangrijk om te weten of er sprake zou kunnen zijn van een arbeidsrelatieachtige overeenkomst. Pas als dat boven iedere twijfel verheven, niet zo is, bestaat er een mogelijkheid dat de TS inderdaad aanspraak kan maken op gerelateerde rechten.
Echter ook daar speelt de markt een rol. Als de opdrachtgever veel zaken doet met grotere partijen (die meestal afstand doen van de rechten ten behoeve van de klant/opdrachtgever) dan heeft de opdrachtgever wellicht een heel valide claim op basis van "gebruik in de branch".

(Dat mensen die voor zichzelf werken en/of voor heel kleine partijen, dit geen leuk nieuws vinden, snap ik uiteraard zeer goed.)

[deadinspace]

Anoniem: 176826 schreef op dinsdag 24 september 2013 @ 13:43:
Laat ik namelijk even een heel andere insteek pakken: De klant (opdrachtgever) neemt de TS aan (voor een project van beperkte duur) om een stuk software te bouwen. Of de TS daarbij ZZP'er is of op basis van een tijdelijk arbeidscontract aan het werk is, is daarvoor niet relevant.

Jawel, dat is heel erg relevant. In het eerste geval ben je in dienstverband; je werkt voor je baas. In het tweede geval voer je zelfstandig een opdracht uit voor een opdrachtgever. Dat heeft verregaande gevolgen voor onder aansprakelijkheid, belastingen en ook auteursrecht.

Waar we het nu over hebben, is dus een situatie waarbij de TS de facto als werknemer van de opdrachtgever gezien kan/moet worden.

Sorry, maar daar klopt niets van. Werknemerschap is echt iets heel anders dan werken in opdracht. Als je echt als zelfstandige werkt (je spreekt een project af met prijs en eisenpakket, je factureert, je hebt een var-wuo, etc), dan ben je geen werknemer en gaan de wetten over auteursrecht van werkgevers/werknemers niet op.
Arnoud Engelfriet schrijft hierover:

Ik ben freelancer. Wie heeft het auteursrecht, mijn opdrachtgever of ik?

Alleen bij een werknemer in dienstverband komt het auteursrecht automatisch toe aan de werkgever. Een freelancer behoudt zelf de rechten, en de opdrachtgever moet dus elke keer toestemming vragen om het werk te publiceren of herpubliceren.

Een dienstverband is niet hetzelfde als een opdracht tot vervaardiging van een werk, zelfs niet als de opdrachtgever daarbij instructies geeft (HR 17 november 1967, NJ 1968, 163, Voorvertaling).

De opdrachtgever krijgt wel automatisch het recht om het werk te gebruiken voor het doel van de opdracht. Wie dus als freelancer een artikel schrijft voor een tijdschrift, geeft daarmee automatisch aan het tijdschrift toestemming tot publicatie. Deze toestemming is dan wel eenmalig. Het tijdschrift moet dus bij bloemlezingen of bij online herpublicatie wel apart toestemming vragen.

Aan de topicstarter:

Als je daadwerkelijk als zelfstandige opereert, en je hebt geen afspraken gemaakt over het auteursrecht, dan ben jij dus eigenaar van zowel de broncode als het gecompileerde eindproduct. Je klant heeft echter wel het recht om hetgeen jij gemaakt hebt "te gebruiken voor het doel van de opdracht".

Het is dan dus de vraag wat het doel van de opdracht was. Dat de klant je software mag gebruiken lijkt me logisch. Of de klant dan recht heeft op inzage van de broncode (zonder meteen het auteursrecht te hebben!) hangt dus af van wat de opdracht precies was, maar ik kan me voorstellen dat dit een terecht twistpunt kan zijn in sommige situaties.

En verder nog even dit:

StM schreef op maandag 23 september 2013 @ 15:31:
Wat vinden jullie, moet je je klant in het offerte traject expliciet vermelden dat de source code niet onderdeel is van de levering? Het staat gewoon in mn AV van niet en ook de default van de wet is (volgens mij) nee. Ik heb weer een klant over de rooie nu het project af is en hij al betaald heeft en hij opeens om de source vraagt...

(nadruk van mij)

Dit is dus al vaker voorgekomen? Dan vraag ik me af waarom je het in godsnaam niet vermeldt in het offertetraject?

Los van de juridische kant is er dus blijkbaar herhaaldelijk sprake van verkeerde verwachtingen, het lijkt me nogal wiedes dat je dat voortaan wil voorkomen. De enige reden om het niet te vermelden is om klanten binnen te halen die anders af zouden haken, maar dat is verre van netjes, nietwaar?

[Infinitive]

Anoniem: 176826 schreef op dinsdag 24 september 2013 @ 13:43:
Let op: Ook als jij in je eigen tijd (dus alleen proggen op zaterdag) een stuk software in elkaar steekt, liggen alle gerelateerde rechten van dat werk bij je baas.

Wat eigenlijk als je in loondienst bent van meerdere bedrijven? Ik heb bijvoorbeeld expliciet toestemming van mijn hoofdopdrachtgever om ook nog wat prive-uren te werken bij een vorig bedrijf waar ik technisch gezien nog steeds in dienst ben (welliswaar op nul-uren basis), maar dat zegt niet wie de eigennaar is van mijn prive-broncode...

[ThomasG]

Anoniem: 176826 schreef op dinsdag 24 september 2013 @ 13:43:
[...]

Let op: Ook als jij in je eigen tijd (dus alleen proggen op zaterdag) een stuk software in elkaar steekt, liggen alle gerelateerde rechten van dat werk bij je baas.
(Geen uitzonderingen? Ja wel, maar dan moet jouw eigen werk echt significant verschillen van het werk dat je in je vrije tijd doet. Dus als je door de weeks slager bent en vervolgens schroef je in je vrije tijd forumsoftware in elkaar, dan lukt het ook wel om de gerelateerde rechten achteraf op te eisen. Maar ben je werkzaam in de IT, bijvoorbeeld als functioneel SAP consultant en vervolgens programmeer je in je vrije tijd wat aansturing voor SCADA en PLC's in elkaar, dan liggen de rechten daarvoor bij je baas.)

Zo simpel is dat niet, dat geld alleen voor programmeerwerk dat binnen jouw functieomschrijving past. Als je voor je werk PLC's programmeert, en in je vrije tijd een website bouwt, liggen de rechten niet bij jouw baas. Tenzij dat wel bij jouw functieomschrijving hoort, of explicit in het contract staat. Andersom is het ook zo, dat als je onder werktijd als programmeur een stripboek maakt, de rechten bij jouw liggen, en niet bij je baas.

[HollowGamer]

Maar hoe zit dit dan bij een Wordpress-systeem (of andere CMS-systemen)? Je upload de code meestal naar de klant websspace (als deze niet bij jou het afneemt). Ze kunnen dan toch zonder problemen de (PHP/MySQL) code inzien? Hoewel ze volgens de voorwaarden er niet aan mogen sleutelen, kan je er op nagaan dat dit wel gebeurd, en jawel door goedkope jantje: Ik dus.

Net alsof Tweakers niet benieuwd zijn naar anders code.

[StM]

deadinspace schreef op dinsdag 24 september 2013 @ 15:42:
[...]

Dit is dus al vaker voorgekomen? Dan vraag ik me af waarom je het in godsnaam niet vermeldt in het offertetraject?

Los van de juridische kant is er dus blijkbaar herhaaldelijk sprake van verkeerde verwachtingen, het lijkt me nogal wiedes dat je dat voortaan wil voorkomen. De enige reden om het niet te vermelden is om klanten binnen te halen die anders af zouden haken, maar dat is verre van netjes, nietwaar?

Nee, niet hierover. Heb alleen momenteel de buik een beetje vol van het freelancen aangezien er steeds gezeik is het afgelopen jaar. Heb ook nog een zaak lopen met een tussenpersoon die de boel heeft lopen bedonderen en iets van 1 op de 5 facturen die (net niet) een incassotraject ingaan. Gewoon een beetje frustratie die doorklinkt

Heb trouwens al een bijlage bij mijn offertes om dingen te verduidelijken of expliciteren en dit moet er dan misschien ook nog maar bij... Maar goed hoe ver moet je daar mee gaan.

Klant lijkt zich trouwens wel te kunnen schikken in het voorstel om een escrow regeling op te zetten. ik zal wel zien of ze het ook door willen zetten.

[MSalters]

Precies. De opmerkingen over 'ik wil deze relatie graag behouden` leken me al niet erg realistisch. De klant kwam tenslotte niet met het verzoek de code te mogen kopen. De onenigheid was niet over de prijs. Nee, de klant ging er al vanuit dat het gratis was.

Ik zou "auteursrecht en source overdracht" als optie tegeb meerprijs bij je offerte zetten. Dan is het duidelijk dat niet betalen = niet krijgen.

[Barryvdh]

Of gewoon duidelijk in je algemene voorwaarden zetten en zorgen dat ze die ook tekenen (alleen bijzetten dat ze van toepassing zijn is niet genoeg).
Verder is het natuurlijk niet raar dat mensen iets van zekerheid willen. Als jij failliet gaat en alle hosting etc wordt stopgezet, kan de klant niet meer bij zijn website.

Vanuit de klant gezien zou ik het ook logisch vinden, als ik jou betaal om iets te maken, wil ik ook graag dat het mijn eigendom wordt.
Simpel voorbeeld, ik wil een Drupal website, juist zodat ik niet vast zit aan 1 ontwikkelaar. Dan wil ik dus ook de vrijheid hebben om de website op te pakken en verder te laten ontwikkelen door iemand anders.
Wat ik natuurlijk niet wil is dat ik eenmalig iets ontwikkel en dat de klant het 5x doorverkoopt buiten mij om.

Een extra alinea met een opmerking dat de software in bruikleen/licent is of dat de broncode van de klant wordt, lijkt me een simpele oplossing.. (En daarnaast natuurlijk juridisch afdekken met je alg. voorwaarden)

[leuk_he]

StM schreef op maandag 23 september 2013 @ 17:18:
Maar mogen ze er juridisch gezien ook iets mee? Waarschijnlijk niet

Dat is wel heel interessant. Kleine aanpassingen wellicht wel. Maar even jouw naam weghalen uit de templates is niet de bedoeling. Maar wat als ze een 2e bedrijfje beginnen en daar dezelfde web-site willen gebruiken?

Bron code(omdat encrypten van templates/php code een klus is die niks oplevert) hebben wil nog niet zeggen dat hij eigendom is.

Het wordt ook interresant bij abandonware. Zo maakten wij gebruik van een exotische compiler die de klant zelf niet had, en waarvan het oorspronkelijke bedrijf niet meer vindbaar is. (eigenlijk; wel vindbaar, maar ze hadden daar geen kennis meer van, zoiets als de windows 3.0 SDK proberen te kopen mij MS). Iemand die het onderhoud wou overnemen hebben we flink laten zweten om een licentie te verkrijgen op die compiler

Merk overigens op dat er in onderhoud in de loop der jaren veel te verdienen is. En dat kun je uiteraard beter voor elkaar krijgen door goede dienstverlening dan door bovenop de source code te gaan zitten.

[Hydra]

PatrickH89 schreef op dinsdag 24 september 2013 @ 13:29:
Je zou natuurlijk in het kader van 'ik wil deze relatie graag behouden' het ook anders kunnen aanpakken. Enig begrip tonen en samen tot een oplossing komen zou prima een vruchtbare optie kunnen zijn.

Een klant moet wel retegoeie redenen willen om de broncode te willen hebben, an sich heeft hij er gewoon niks aan namelijk (afgezien van het doorspelen naar een 3e goedkopere partij). Wat betreft continuïteit in het geval van een faillissement van de maker; daar heb je escrow regelingen voor. Het is heel normaal dat een escrow regeling getroffen wordt. Zomaar de sourcecode overdragen kan helemaal niet; je hebt vaak een hoop gedeelde libraries die je hergebruikt in projecten; als de ander daar eigenaar van wordt mag jij ze niet meer gebruiken.

Anoniem: 176826 schreef op dinsdag 24 september 2013 @ 13:43:
Laat ik namelijk even een heel andere insteek pakken: De klant (opdrachtgever) neemt de TS aan (voor een project van beperkte duur) om een stuk software te bouwen. Of de TS daarbij ZZP'er is of op basis van een tijdelijk arbeidscontract aan het werk is, is daarvoor niet relevant.

Euh ja, dat is enorm relevant. Code die jij onder werktijd voor een baas maakt is over het algemeen van de baas. Code die je als ondernemer maakt voor een applicatie waarvan je de licentie verkoopt is gewoon van het bedrijf dat die applicatie gemaakt heeft, niet van de klant die de applicatie koopt. Of het nu custom werk is of niet maakt niet uit. Dit is hoe het standaard werkt.

Als er een auteursrecht overgedragen moet worden in een dergelijk geval moet dat expliciet geregeld worden.

MSalters schreef op woensdag 25 september 2013 @ 12:20:
Ik zou "auteursrecht en source overdracht" als optie tegeb meerprijs bij je offerte zetten. Dan is het duidelijk dat niet betalen = niet krijgen.

Voor 2x de prijs van het standaard product, minimaal. En dan moet je je hard achter de oren krabben of je niet alsnog je eigen glazen ingooit.

[ Voor 43% gewijzigd door Hydra op 25-09-2013 19:51 ]

[PatrickH89]

Hydra schreef op woensdag 25 september 2013 @ 19:45:
[...]


Een klant moet wel retegoeie redenen willen om de broncode te willen hebben, an sich heeft hij er gewoon niks aan namelijk (afgezien van het doorspelen naar een 3e goedkopere partij). Wat betreft continuïteit in het geval van een faillissement van de maker; daar heb je escrow regelingen voor. Het is heel normaal dat een escrow regeling getroffen wordt. Zomaar de sourcecode overdragen kan helemaal niet; je hebt vaak een hoop gedeelde libraries die je hergebruikt in projecten; als de ander daar eigenaar van wordt mag jij ze niet meer gebruiken.

Dat is natuurlijk onderdeel van het 'er samen uit komen'

[leuk_he]

Hydra schreef op woensdag 25 september 2013 @ 19:45:
[...]
; je hebt vaak een hoop gedeelde libraries die je hergebruikt in projecten; als de ander daar eigenaar van wordt mag jij ze niet meer gebruiken.

Je kunt het niet exclusieve gebruiksrecht overdragen. Je hoeft niet perse de volledige rechten over te dragen. Zo kan de andere partij doen met de code wat hij wil, en jij ook. (... als dat je uitgangspunt is...)

[igmar]

Grijze Vos schreef op maandag 23 september 2013 @ 16:09:
Het zit toch nog iets gecompliceerder in elkaar. (disclaimer: IANAL.) Mijn vorige werkgever heeft wel eens een aantal van dat soort akkefietjes gehad.

Waar ik eigenlijk op doel is als jij als opdrachtnemer een opdracht aanneemt van een opdrachtgever die een AV heeft. Als hij een AV heeft, en jij niet, en je de opdracht aanneemt, dan accepteer je impliciet die AV van de opdrachtgever. Daarmee kun je dus automagisch rechten afgeven. Het is dus belangrijk om zelf een AV op te stellen om je in te dekken.

Ook bovenstaande klopt niet : Dan moet je als opdrachtnemer er expliciet op gewezen zijn dan de afnemende partij inkoopvoorwaarden heeft.
Het is zelf nog complexer als bovenstaande, maar auteursrecht is behoorlijk dwingend : De rechten liggen bij de maker, tenzij expliciet anders overeengekomen. De uitzondering op de regel is als je als werknemer wat maakt voor je werkgever, daarvan liggen de rechten altijd bij de werkgever.
En dat laatste is ook niet in alle gevallen helemaal 100% accuraat.

[HenkEisDS]

HollowGamer schreef op dinsdag 24 september 2013 @ 22:54:
Maar hoe zit dit dan bij een Wordpress-systeem (of andere CMS-systemen)? Je upload de code meestal naar de klant websspace (als deze niet bij jou het afneemt). Ze kunnen dan toch zonder problemen de (PHP/MySQL) code inzien? Hoewel ze volgens de voorwaarden er niet aan mogen sleutelen, kan je er op nagaan dat dit wel gebeurd, en jawel door goedkope jantje: Ik dus.

Net alsof Tweakers niet benieuwd zijn naar anders code.

Daar heb je ionCube voor. http://www.ioncube.com/

[Jogai]

En hoe gaat dat met wat code die je bijdraagt aan een open-source project? Dat is bij een gpl pakket automatisch gpl, terwijl de nederlandse wet voor zou scrhijven dat het van je werkgever is.

Als je zelf een stuk software onder gpl (of een andere foss licentie) wil publiceren moet je dat waarschijnlijk ook eerst aan je werkgever vragen...

[downtime]

Jogai schreef op zaterdag 28 september 2013 @ 15:29:
En hoe gaat dat met wat code die je bijdraagt aan een open-source project? Dat is bij een gpl pakket automatisch gpl, terwijl de nederlandse wet voor zou scrhijven dat het van je werkgever is.

Het is niet automatisch van je werkgever, tenzij als onderdeel van je werk gemaakt, de lijn ligt alleen niet helemaal duidelijk waar je werk eindigt en hobby begint. Om misverstanden en vervelende situaties te voorkomen is het slim om met je werkgever te overleggen voordat je code bijdraagt aan iets wat gepubliceerd wordt, of dat nou onder GPL of een andere licentie is.
Worst case scenario is dat jouw baas jou ontslaat (en aanklaagt) omdat je code onder GPL publiceert waar jij formeel helemaal geen rechten op hebt. Jij zou dan zijn rechten geschonden hebben.
Misschien is het te vergelijken met een cassiere bij een supermarkt die klanten gratis spullen meegeeft die eigenlijk gewoon afgerekend moesten worden. De klanten zullen daardoor niet in de problemen komen maar de cassiere wel. Die zal uiteindelijk voor de schade opdraaien.

Als je zelf een stuk software onder gpl (of een andere foss licentie) wil publiceren moet je dat waarschijnlijk ook eerst aan je werkgever vragen...

Duidelijke afspraken met je werkgever maken, en die op papier zetten, is de beste aanpak. Anders neem je altijd het risico dat jouw baas later het copyright op jouw werk gaat opeisen. Of schadevergoeding gaat eisen als dat niet meer mogelijk is.

[IceM]

Jogai schreef op zaterdag 28 september 2013 @ 15:29:
En hoe gaat dat met wat code die je bijdraagt aan een open-source project? Dat is bij een gpl pakket automatisch gpl, terwijl de nederlandse wet voor zou scrhijven dat het van je werkgever is.

Als je zelf een stuk software onder gpl (of een andere foss licentie) wil publiceren moet je dat waarschijnlijk ook eerst aan je werkgever vragen...

Als je als softwareontwikkelaar ook bijdraagt aan een open source project is het verstandig dit op papier te zetten en je werkgever te laten tekenen voor akkoord. Doe je dat niet en je krijgt een arbeidsconflict dan kon je nog wel eens een groot probleem krijgen. Het auteursrecht van de broncode ligt vrijwel altijd bij de werkgever, ook als je dit in je vrije tijd hebt gemaakt, tenzij er in je arbeidsovereenkomst is vastgelegd dat jij als werknemer zelf het auteursrecht behoud op het gemaakte werk.

[ Voor 6% gewijzigd door IceM op 28-09-2013 17:03 ]

[Ealanrian]

Bijvoorbeeld de Apache Foundation vereist een licentie overdracht van het bedrijf naar de foundation om te voorkomen dat er conflicten komen. Dit is dan wel in het geval van software geschreven in opdracht van het bedrijf. Werk je in je eigen tijd mee aan een open source project wat niet gerelateerd is aan de werkzaamheden van het bedrijf, als het bedrijf werkt aan een ERP pakket is het niet verstandig om in de vrije tijd aan een Open Source ERP pakket te werken zonder overleg met de baas. Werk je echter aan een mail server dan is het een ander verhaal.

[begintmeta]

Worden opdrachten wel eens zo geformuleerd dat het product moet zijn 'source code' (die dan aan bepaalde voorwaarden moet voldoen)?

De vraag over de verdeling van rechten bij meerdere dienstverbanden is trouwens ook wel leuk IMHO

[Ealanrian]

Ik heb een vrij grote opdracht gehad waarbij inderdaad het product ook de source code omvatte. Dit was vooraf bekend en gewoon duidelijk en toen is ook uitgelegd waarom het in het contract stond, dus de regels dat het anders mijn eigendom zou zijn en dat de concurentie positie van de klant in gevaar kon brengen. Er werd dus iets meer betaald om te zorgen dat zij de code ook zouden krijgen.

[justahuman]

Jogai schreef op zaterdag 28 september 2013 @ 15:29:
En hoe gaat dat met wat code die je bijdraagt aan een open-source project? Dat is bij een gpl pakket automatisch gpl, terwijl de nederlandse wet voor zou scrhijven dat het van je werkgever is.

Als je zelf een stuk software onder gpl (of een andere foss licentie) wil publiceren moet je dat waarschijnlijk ook eerst aan je werkgever vragen...

Jij hebt nogsteeds het auteursrecht, als ze van license willen veranderen moeten ze aan jou vragen of je er mee akkoord gaat.

[D-Raven]

De invulling van Escrow regelingen wordt wel steeds lastiger overigens, in deze tijd van SaaS oplossingen. Moest er toevallig laatst eentje evalueren voor een klant als onafhankelijke derde.

Volgens de letter van het contract werd er aan de Escrow regeling voldaan, maar toch was de intentie van de Escrow regeling niet gehaald, immers de continuïteit was niet gewaarborgd.
Ja ze hebben de source, maar deze is useless zonder dat je precies weet hoe de hosted omgeving eromheen opgezet moet worden e.d.

[Douweegbertje]

Je staat gewoon in je recht hoor. Wij hebben ook software van een 3e partij en de bedoeling is nu dat wij de source gaan krijgen. Hiervoor gaan we nu ook extra dokken, en de programmeur zou het één en ander gaan gereedmaken om te zorgen dat wij er iets mee kunnen.

Ik zou je klant maar gewoon vertellen dat het absoluut niet gebruikelijk is dat iemand ook nog eens de source krijgt tenzij dat duidelijk wordt aangegeven. Dat is echt letterlijk overal zo.

Daarbij zou ik gewoon een offerte voor hem maken als hij ook de source wilt en vervolgens zo snel mogelijk zo'n klant zijn zooi geven en weg gaan (maar dat ben ik persoonlijk ).

[Nefje_]

Zoals anderen in dit topic al hebben gezegd: je staat juridisch in je recht. Dat zou pas anders kunnen zijn als het gaat om maatwerksoftware én je hebt afgesproken dat de maatwerksoftware volledig eigendom wordt van de cliënt. Zie ook het arrest Van Genk/De Wild. In dat arrest waren ze ook gehouden tot afgifte van de broncode, maar die situatie is duidelijk niet van toepassing in jouw geval.

Niettemin is het wel zo handig en netjes (hoewel ik bij een professionele partij eigenlijk wel verwacht dat ze dit weten. Ik krijg eerder het idee dat ze hopen goedkoop aan de broncode te komen) om ze hier duidelijk op te wijzen voor het sluiten van het contract. Dit lijkt mij dan ook meer een praktisch probleem dan een juridisch probleem. Je kan natuurlijk voet bij stuk houden (en daar is helemaal niets mis mee) maar dat zou aan de andere kant misschien niet zo goed zijn voor de relatie met de klant. Maar je hoeft natuurlijk ook niet over je heen te laten lopen. Voor hetzelfde geld doen ze dit met opzet en hopen ze dat de ander zwicht.

[raptorix]

Let wel op dat er ook jurispredentie is waarbij je je data zo moet kunnen aanleveren/omzetten dat de klant in staat word gesteld om naar een ander pakket over te stappen, is jurispredentie over:

http://internetrecht.mrju...xt_000000009&id=000000016

[Anoniem: 260522]

misschien een compleet andere branche, maar wel een vergelijkbaar verhaal.
Als een klant in mijn branche (matrijzenbouw) een matrijs afgenomen heeft, is het ook niet gebruikelijk dat daar de 3D tekeningen en freesprogramma's bijgeleverd zijn. dit puur om te voorkomen dat de klant naar een goedkopere gereedschapmakerij/china gaat waar hij onze kennis en technieken cadeau geeft.
het lijkt mij in dit geval ook een vergelijkbare situatie, waarbij de klant een werkend product afneemt en niet de extra bouwmethoden/broncode krijgt.

[Megamind]

Anoniem: 260522 schreef op maandag 30 september 2013 @ 19:04:
misschien een compleet andere branche, maar wel een vergelijkbaar verhaal.
Als een klant in mijn branche (matrijzenbouw) een matrijs afgenomen heeft, is het ook niet gebruikelijk dat daar de 3D tekeningen en freesprogramma's bijgeleverd zijn. dit puur om te voorkomen dat de klant naar een goedkopere gereedschapmakerij/china gaat waar hij onze kennis en technieken cadeau geeft.
het lijkt mij in dit geval ook een vergelijkbare situatie, waarbij de klant een werkend product afneemt en niet de extra bouwmethoden/broncode krijgt.

Maar waar betaald de klant voor? Ik heb vaak genoeg broncode vrijgegeven, ik reken af per uur dus wat ik voor de klant maak in zijn tijd is zijn bezit. Als ik zeg dat ze de broncode niet mogen hebben dan laten ze het gewoon ergens anders opnieuw bouwen. Ik sluit daarnaast wel langere SLA contracten af voor onderhoud.

[Voutloos]

Prima als je het doet, er fijn bij voelt en de zaken goed gaan, maar dat jij je broncode gewoonlijk verstrekt staat los van de wet. Het is jouw keuze en als dat goed werkt en je interessante onderhoudsafspraken weet te maken / klanten zich graag binden lijkt t geen slechte beslissing.

[EfBe]

Megamind schreef op maandag 30 september 2013 @ 19:34:
[...]
Maar waar betaald de klant voor? Ik heb vaak genoeg broncode vrijgegeven, ik reken af per uur dus wat ik voor de klant maak in zijn tijd is zijn bezit.

Als dit niet middels een contract is overeengekomen, is de broncode zeker niet het bezit van jouw klant. Jouw klant betaalt je voor een dienst, niet voor de code. Je moet het eigendomsrecht expliciet overdragen, omdat je niet in dienst bent bij de klant. Dit heeft verstrekkende gevolgen.

Als ik zeg dat ze de broncode niet mogen hebben dan laten ze het gewoon ergens anders opnieuw bouwen. Ik sluit daarnaast wel langere SLA contracten af voor onderhoud.

Dat is inderdaad verstandig, maar let op het volgende: wanneer de overeenkomst met je klant gezien kan worden als het leveren van een dienst en jij draagt het eigendom van de gemaakte materialen niet over, dan ontstaat de situatie dat jij later van je klant kunt eisen dat deze stopt met het gebruik van de gemaakte materialen of sterker: wanneer de klant de door jouw gemaakte programmatuur gebruikt om bv een succesvol product op de markt te zetten, kun je dan daar een deel van opeisen. Dit is in het verleden ook gebeurd dus het is voor jouw klant erg belangrijk dat de code wordt overgedragen.

Voor jou zelf is dit overigens ook verstandig: wanneer je een dienst levert en daarbij direct de gemaakte spullen overdraagt, draag je gewoonlijk geen verantwoordelijkheid voor wat er daarna mee gebeurt en wat er door de programmatuur eventueel als schade wordt geleden. (dit onder voorbehoud, het is alweer een tijd geleden dat ik me in deze materie verdiept heb).

Dus TL;DR: sluit altijd een contract af, en draag altijd de programmatuur over middels dat contract. Wanneer je de code zelf wilt houden, zorg er dan contractueel ook voor dat de klant de code middels een licentie kan gebruiken.

[raptorix]

Ik werk voor een vrij groot internetbureau, bij ons is de situatie heel duidelijk, de klant is ten alle tijden eigenaar van de broncode die wij bouwen, eventuele third party software zijn we niet verantwoordelijk voor, uiteraard krijgen ze gewoon een werkende solution.

[P.O. Box]

dus jullie hergebruiken nooit code voor nieuwe klanten? of mag je de code die van iemand anders is gewoon vrijelijk gebruiken volgens jullie agreement?

[raptorix]

P.O. Box schreef op woensdag 02 oktober 2013 @ 13:16:
dus jullie hergebruiken nooit code voor nieuwe klanten? of mag je de code die van iemand anders is gewoon vrijelijk gebruiken volgens jullie agreement?

Uiteraard hergebruiken wij code, maar mensen doen altijd zo panisch over "code" alsof het enorm veel geld waard is, wat ons betreft kan die code zo GitHub op, overigens willen klanten de code ook helemaal niet hebben omdat het geld waard is, maar simpelweg omdat ze niet met lege handen willen staan als ze weg willen bij ons.

Heb een keer of 5 gehad dat dit gebeurde, meestal gaat dat gewoon in goed overleg, ik maak een zipje van de SVN repo, backup van de database en mediafolder, en dat krijgen ze op een USB stick mee.

[pedorus]

raptorix schreef op donderdag 03 oktober 2013 @ 14:44:
Uiteraard hergebruiken wij code,

Als het waar is dat de klant eigenaar wordt van de code, dan kan dit niet omdat er maar 1 eigenaar tegelijkertijd kan zijn van de copyright op die code. Of bedoel je dat de klant de code in bezit en in licentie krijgt? Of zeggen jullie hier niets over en geven jullie de code? (Dit laatste levert een wat ongedefinieerde situatie op, in principe kan de klant de code dan wellicht niet zomaar gebruiken).

Persoonlijk zie ik ook liever meer public domain code, met afstand het eenvoudigst om mee te werken

[downtime]

raptorix schreef op donderdag 03 oktober 2013 @ 14:44:
Uiteraard hergebruiken wij code, maar mensen doen altijd zo panisch over "code" alsof het enorm veel geld waard is, wat ons betreft kan die code zo GitHub op, overigens willen klanten de code ook helemaal niet hebben omdat het geld waard is, maar simpelweg omdat ze niet met lege handen willen staan als ze weg willen bij ons.

Heb een keer of 5 gehad dat dit gebeurde, meestal gaat dat gewoon in goed overleg, ik maak een zipje van de SVN repo, backup van de database en mediafolder, en dat krijgen ze op een USB stick mee.

Je zult altijd duidelijk met je klanten moeten afspreken wie de eigenaar van die code is. Als je "zomaar" code aan klanten geeft kan dat de indruk wekken dat zij een exclusieve licentie hebben gekocht. Je zou dan door die klant aangeklaagd kunnen worden als je dezelfde code hergebruikt voor andere klanten. Je zult dus een overeenkomst moeten hebben dat jouw klant de code krijgt én een non-exclusieve licentie.

[begintmeta]

downtime schreef op donderdag 03 oktober 2013 @ 15:10:
...Als je "zomaar" code aan klanten geeft kan dat de indruk wekken dat zij een exclusieve licentie hebben gekocht. ...

Dat zou ik ook wel weer wat overtrokken vinden, maar je kan natuurlijk het beste alles zo duidelijk mogelijk afspreken.

[cariolive23]

raptorix schreef op donderdag 03 oktober 2013 @ 14:44:
[...]


Uiteraard hergebruiken wij code, maar mensen doen altijd zo panisch over "code" alsof het enorm veel geld waard is, wat ons betreft kan die code zo GitHub op, overigens willen klanten de code ook helemaal niet hebben omdat het geld waard is, maar simpelweg omdat ze niet met lege handen willen staan als ze weg willen bij ons.

Dit zal per situatie verschillen, maar onze code is geheim, daar zitten onze formules in. En ja, die zijn heel veel geld waard, 8 jaar research moet toch worden betaald...

Klanten kopen een licentie voor een periode en mogen gedurende die periode de software gebruiken. Wanneer ze de licentie niet verlengen, stopt de service en is het einde verhaal.

Onze eerste (en grootste) klant wilde in eerste instantie ook dat de broncode werd meegeleverd, maar dat hebben we onmiddellijk afgekapt. Ze konden een licentie kopen op het eindproduct of verder afzien van de aanschaf. Ze hebben daar heel moeilijk over gedaan, maar gingen uiteindelijk toch over stag en hebben de licentie zónder broncode aangeschaft.

We hebben wel de code wel in een escrow service ondergebracht waarbij in geval van een faillissement de klant wel beschikking kan krijgen over de code. Maar ook dan alleen in het geval de code niet wordt verkocht aan een andere partij die verder gaat met het product.

[Hydra]

cariolive23 schreef op donderdag 03 oktober 2013 @ 16:52:
Dit zal per situatie verschillen, maar onze code is geheim, daar zitten onze formules in.

Ik heb het idee dat een aantal mensen redeneren vanuit hun "yet another content management system". Dat het je niet zoveel boeit dat van de zoveelste drupal plugin de sourcecode naar een klant gaat geloof ik best. Maar in dat soort gevallen is "code reuse" ook gewoon een kwestie van copy-paste.

[begintmeta]

cariolive23, nemen jullie dan ook maatregelen tegen reverse-engineering?

[cariolive23]

begintmeta schreef op donderdag 03 oktober 2013 @ 19:24:
cariolive23, nemen jullie dan ook maatregelen tegen reverse-engineering?

In de contracten is een paragraaf opgenomen waarin expliciet wordt vermeld dat reverse enginering is verboden en hier een boeteclausule van toepassing is.

Gelukkig is reverse enginering niet zo eenvoudig, je moet ook de kennis en ervaring hebben met de data om te begrijpen wat er gebeurt en waarom het gebeurt. Daarnaast is reverse enginering niet gratis en is het maar de vraag wat goedkoper is: Een licentie of reverse enginering met onzekere resultaten en een rechtzaak aan je broek.

[farlane]

cariolive23 schreef op donderdag 03 oktober 2013 @ 19:41:
In de contracten is een paragraaf opgenomen waarin expliciet wordt vermeld dat reverse enginering is verboden en hier een boeteclausule van toepassing is.

Volgens mij is dat toch per wet toegestaan?

[downtime]

farlane schreef op vrijdag 04 oktober 2013 @ 00:17:
[...]

Volgens mij is dat toch per wet toegestaan?

Je mag de werking van een product nabootsen aan de hand van API's en specificaties maar zodra je de originele code probeert te achterhalen ben je alsnog patenten en copyright aan het schenden.

[EfBe]

downtime schreef op vrijdag 04 oktober 2013 @ 00:32:
[...]

Je mag de werking van een product nabootsen aan de hand van API's en specificaties maar zodra je de originele code probeert te achterhalen ben je alsnog patenten en copyright aan het schenden.

software patenten hebben we in NL niet en reverse engineering is niet gelijk aan het schenden van copyright. Je maakt inbreuk in intellectueel eigendom, en dat is weer wat anders.

raptorix schreef op donderdag 03 oktober 2013 @ 14:44:
[...]
Uiteraard hergebruiken wij code, maar mensen doen altijd zo panisch over "code" alsof het enorm veel geld waard is, wat ons betreft kan die code zo GitHub op, overigens willen klanten de code ook helemaal niet hebben omdat het geld waard is, maar simpelweg omdat ze niet met lege handen willen staan als ze weg willen bij ons.

Heb een keer of 5 gehad dat dit gebeurde, meestal gaat dat gewoon in goed overleg, ik maak een zipje van de SVN repo, backup van de database en mediafolder, en dat krijgen ze op een USB stick mee.

Je vergeet dat wanneer je de code expliciet overdraagt aan een ander, je niet die code nog eens aan een 3e partij over kan dragen, immers je bent niet meer de eigenaar. Je kunt dan dus ook niet de code meer op github plaatsen of iets dergelijks.

Je MOET panisch doen over code, of beter, copyright: het moet waterdicht worden afgekit, anders krijg je vroeg of laat problemen en dan wil je niets liever dan dat je het beter had geregeld. Het is gewoon om duidelijkheid te creeeren wanneer er gezeik komt. En dat komt er, vroeg of laat, altijd.

[ Voor 54% gewijzigd door EfBe op 04-10-2013 10:15 ]

[Voutloos]

Check. Je moet t alles gewoon expliciet regelen. Hoe eea en ander juridisch zit was al in een paar posts duidelijk. Eerlijk gezegd kabbelt dit topic maar een beetje zinloos voort op basis van lui die hun eigen (soms te) visie op dit alles hebben.

[Acid_Burn]

raptorix schreef op donderdag 03 oktober 2013 @ 14:44:
Uiteraard hergebruiken wij code, maar mensen doen altijd zo panisch over "code" alsof het enorm veel geld waard is, wat ons betreft kan die code zo GitHub op,

Uuh, ja. Onze code is heel veel geld waard. Daar zitten honderden, zo niet duizenden uren aan ontwikkeling in. Waarom zou dat niet veel geld waard zijn? Het heeft tonnen gekost om het te maken. Het is onze core business. Als wij dat op git zouden gooien dan kunnen we de tent wel opdoeken. Nu gaat het bij ons niet om websites, maar om Windows applicaties.

[raptorix]

Ik zal niet iedereen apart gaan quoten, maar ik denk dat er veel verschil bestaat tussen maatwerk en een product, wij leveren alleen maatwerk op basis van bestaande producten (veelal cms'en ecommerce), kortom de code die wij schrijven is zeer gericht op de klant en is daar buiten vrij nutteloos.

Uiteraard is het een andere zaak als je zelf je product maakt, en dan moet je inderdaad heel goed nadenken/afspreken waar de klant recht op heeft.

[Voutloos]

raptorix schreef op vrijdag 04 oktober 2013 @ 11:46:
kortom de code die wij schrijven is zeer gericht op de klant en is daar buiten vrij nutteloos.

Neeheehee. Je maakt iets, afhankelijk van de situatie ligt copyright _altijd_ bij jou of werkgever (geen uitzonderingen, de wet boeit t niet of er maar 1 klant is) dus moet je iets regelen. Punt.

[raptorix]

Voutloos schreef op vrijdag 04 oktober 2013 @ 12:49:
[...]
Neeheehee. Je maakt iets, afhankelijk van de situatie ligt copyright _altijd_ bij jou of werkgever (geen uitzonderingen, de wet boeit t niet of er maar 1 klant is) dus moet je iets regelen. Punt.

Ik schreef in eerdere reactie al dat bij ons contractueel geregeld is dat code door ons geschreven altijd eigendom is van de klant (geld trouwens ook voor designs).

[farlane]

Maar dat levert bij hergebruik van code dus potentieel een probleem op.

[raptorix]

farlane schreef op vrijdag 04 oktober 2013 @ 14:47:
Maar dat levert bij hergebruik van code dus potentieel een probleem op.

Mjah hoe dat juridisch dicht getimmert is weet ik niet, misschien is de formulering niet dat ze eigenaar worden maar dat ze het vrijelijk mogen gebruiken of iets in die trand.

[begintmeta]

't zal wel de een of andere licentie zijn inderdaad, geen overdracht van zeggenschap.