Input gevraagd voor boek “Software: Deskundig en praktisch juridisch advies”

In januari meldde ik al dat het er aan zat te komen: het boek Software: Deskundig en praktisch juridisch advies. De tekst vordert gestaag, en ik zou dan nu ook graag jullie feedback krijgen op de inhoudsopgave. Nu kan er nog wat bij of af 🙂

  1. Software juridisch bekeken
    • De prehistorie van software
      • Softwarepools
      • Een markt voor software
      • De keuze van de juiste bescherming
      • Vier modellen
    • De keuze voor auteursrecht
    • De grenzen opgezocht
      • Geen bescherming voor concepten
      • Structuren en processen
      • Bescherming van een idee
    • Octrooi op computerprogramma’s
    • De opkomst van open source
    • Software als dienst
  2. Auteursrecht op software
    • Rechten op software
      • kopiëren
      • gebruiken
      • verspreiden
    • Uitzonderingen volgens de wet
      • backups
      • reverse engineering
      • uitputting
    • Handhaving en naleving
      • BSA
      • technische maatregelen (DRM)
      • strafrecht
    • Eigenaar van software
      • werkgever/werknemer
      • freelance/inhuur
  3. Softwarelicenties
    • Uitgangspunten bij licenties
    • EULA’s
      • akkoord gaan met (algemeen)
      • shrinkwrap/clickwrap specifiek
      • bindendheid inhoud (consumentenrecht)
    • Licenties en appstores
    • Onderhoudsverplichtingen
    • Escrow van broncode
  4. Octrooi op software
    • Octrooieerbaarheid van software
      • Softwareoctrooien in Europa en de VS
      • Softwareoctrooien in de praktijk
    • Procedure om octrooi te krijgen
      • Opstellen van de aanvraag
      • Publicatie van de aanvraag
      • Nieuwheidsonderzoek
      • Beoordeling van de octrooieerbaarheid
      • Europees octrooi
    • Kosten van een octrooi
    • Het nut van een octrooi
      • Exclusiviteit
      • Actief licentiëren
      • Passief gebruik
      • Innovatiebox
    • Wel of geen octrooi?
  5. Open source software
    • Uitgangspunten van OSS
    • Soorten open source
      • BSD-achtig
      • Mozilla-achtig
      • GPL-achtig
      • GPL versie 3
    • Linken/combineren met open source
    • Bindendheid/rechtsgeldigheid open source
    • Bedrijfsmodellen bij open source
  6. Software as a service
    • Uitgangspunten van SaaS
    • Beschikbaarheid/downtime regelen
    • Aansprakelijkheid/schade bij downtime
    • API’s aanbieden
    • Persoonsgegevens bij SaaS
    • Beschikbaarheid van data in SaaS (export)
    • Escrow en continuïteit van SaaS bij faillissement

We hopen eind mei te kunnen publiceren 🙂

Arnoud

38 reacties

  1. Goed om te horen dat het boek er in mei al aan staat te komen! Komt als geroepen, met name het stuk m.b.t. SaaS. Ziet er goed uit allemaal.

    Voor wat betreft de “Soorten open source”… gaat LGPL onder de noemer “GPL-achtig”? Indien dit niet het geval is lijkt me LGPL wel een goede vorm om ook even (kort) te behandelen. Met name het gebruiken van LGPL in GPL software, maar niet andersom. Tenzij ik hier natuurlijk al een statement maak waarvan ik na het lezen van het boek zou weten dat dit onjuist is 🙂

  2. Wellicht dat het interessant is om een stukje te wijden aan garanties op Software, waar ligt de grens tussen redelijkerwijs te verwachten bugs en non-conformiteit (zoals je al eerder blogde over: “BSA lobbyt tegen nieuwe consumentenbescherming”). Hoe ver gaat consumentenbescherming hierin vergeleken met de B2B vrijheden.

  3. Misschien iets over de zin en onzin van NDA’s? Als ontwikkelaar word ik hier regelmatig mee geconfronteerd, en ik neig vaak naar niet tekenen/project niet aannemen bij te vage projectomschrijving/te zware NDA.

    “Persoonsgegevens bij SAAS” lijkt te gaan over bescherming van persoonsgegevens bij web applicaties (o.a.). Misschien mag dat iets prominenter, aangezien dat toch wel grootschalig genegeerd lijkt te worden.

    Tot slot, aandachtspunten als klant als je software laat ontwikkelen: beschikking over de sourcecode, API’s, data, etc., en afspraken over onderhoud, deadlines. Eigenlijk alles wat normaal gesproken mis gaat bij een implementatietraject.

  4. Wellicht iets over dongels ter bescherming van software(licenties)

    Vanuit welk perspectief is het boek geschreven? Developer of gebruiker?

    Bij eigenaarschap van software freelance/inhuur en denk ik “in opdracht”. Ik huur handen die ik zelf aanstuur bouw voor mij module x of ik geef een bedrijf opdracht module x te bouwen.

    Wellicht iets over appstores en killswitch achtige constructies.

  5. Door licenties en open source van elkaar te scheiden lijkt het alsof de licenties wat open source maakt wat het is niet volgens de zelfde criteria beoordeeld moeten worden.

    Het enige essentieele verschil is de motivatie voor de mogelijkheden en onmogelijkheden van open source licenties.

  6. Wat ik een regelmatig terugkerende interessante kwestie vind is: het recht op het verkrijgen van de broncode (in machineleesbare vorm, met recht op het uitvoeren van onderhoud en doorontwikkeling) na het laten ontwikkelen van maatwerk door een derde partij. Zowieso zou het onderscheid tussen pakketsoftware en maatwerk misschien aandacht verdienen.

  7. Wordt in het hoofdstuk “Eigenaar van software” ook natrekking/zaaksvorming van software behandeld ?

    En wordt bij het hoofdstuk “Octrooi: Opstellen van de aanvraag” ook een voorbeeld gegeven van hoe een gebruikersinterface kan worden beschermd ?

  8. Wow, iedereen ontzettend bedankt voor de nuttige suggesties! Ik reageer even op iedereen tegelijk:

    @Vic: LGPL hoort onder Mozilla-achtig, aangezien het maar een beperkte eis tot delen van eigen code heeft. Maar er is natuurlijk veel overlap tussen LGPL en GPL. Het punt van combineren moet ik zeker noemen! Misschien een tabel van wat je met wat kunt combineren.

    @Wesley: Ja, garantie moet er zeker bij. Komt in hoofsutk 2, nieuwe sectie.

    @VLDR: een NDA is niet echt softwarespecifiek, dus daar moet ik even over denken. Misschien in hoofdstuk 1 waar het gaat over ideebescherming.

    Een stuk over het ontwikkeltraject en hoe je dat juridisch inkleedt is wel een hele goeie. Dat vereist een nieuw hoofdstuk, maar het is een zeer belangrijk onderwerp. Gaan we doen!

    @Rashid: Export controls is een goeie, dat weten maar weinig mensen. Zal ik een alinea over opnemen.

    @Franc: Dongels vallen onder “technische maatregelen (DRM)”, dat kopje had duidelijker gekund. Appstores staan bij hoofdstuk 3 (licenties).

    Perspectief is niet specifiek gebruiker of developer, dat hangt af van het onderwerp. Bij bv. recht op broncode behandel ik de posities van beiden.

    @GerardM: Hoofdstuk 3 zie ik als een algemeen hoofdstuk over licenties: wat mag er in, hoe verklaar je ze bindend, hoe bied je ze aan (appstores, shrinkwrap). Hoofdstuk 5 gaat dan nader in op licenties in het specifieke geval van open source. Er zitten de nodige verrassende aspecten aan open source, vandaar. Misschien is het wel logischer om H4 open source te maken en H5 softwareoctrooien.

    @Ren?: toegang tot broncode staat nu hier en daar verspreid door hoofdstuk 2 en 3, dat kan nog wel duidelijker onderstreept.

    @Barend: Natrekking/zaaksvorming zal ik noemen, goede suggestie! Het is erg vroeg daarvoor (2 arresten) maar het verdient wel aandacht.

    Een interface beschermen via octrooien is heel moeilijk. Ik zal er een paar zinnen over toevoegen. Maar eigenlijk kan ik over softwareoctrooien een heel nieuw boek schrijven…

  9. Omdat Microsoft, Amazon, Google en diverse andere bedrijven bieden Cloud-diensten aan. Is het een idee om die diverse diensten ook even te noemen met bijbehorende voor- en nadelen? En dan vooral op licentie-gebied en auteursrechten die deze bedrijven in hun algemene voorwaarden hebben opgenomen.

    En natuurlijk de diverse app-stores waar iedereen hun eigen producten wereldwijd kan verkopen onder allerlei (vage) voorwaarden. Want stel dat een Duitser een App maakt en te koop aanbiedt op de Amerikaanse Google market, waarna ik in Nederland de App koop. Dan blijkt de App echter malware te bevatten en ben ik al mijn data kwijt. Bij wie kan ik de schade claimen?

  10. De Apache-licentie staat bij BSD-achtig neem ik aan? Gezien het belang ervan in de Java-wereld moet hij er zeker in, en bovendien was er destijds nog een leuk meningsverschil over compatibiliteit tussen de GPLv2 en de Apache-licentie (de precieze versie is me ontschoten). Dat kan er dan weer bij in het stuk over het combineren van licenties.

    Overigens lijkt het me ook goed om uit te leggen dat de BSD-licentie compatible is met de GPL, maar dat dat niet betekent dat je BSD-code mag herlicenti?ren onder de GPL. Het duurde bij mij in ieder geval wel even voordat ik de nuances daarvan begreep.

    Tot slot nog over de LGPL: die is in versie 3 een GPL-met-extra-uitzondering geworden, dus misschien zit ‘ie daarmee toch dichter bij GPL-achtig dan bij MPL-achtig? Daar kan dan ook meteen de vraag bij of bij het linken van een bibliotheek een afgeleid werk ontstaat, en de verschillen daarin tussen het Amerikaanse en Europese auteursrecht. Sowieso trouwens, als je de verschillen tussen Amerikaanse en Europese software-octrooien behandelt, is iets over de verschillen in auteursrecht ook wel aardig. Bijvoorbeeld de persoonsgebonden auteursrechten die je hier wel hebt maar in de VS niet, en waar J?rg Schilling steeds over loopt te klagen (distributies packagen zijn software niet goed, waardoor er bugs ontstaan, en hij beweert dat zijn reputatie wordt aangetast en dat die wijzigingen daarom verboden zijn).

  11. Een aparte sectie over compatibiliteit gaat er nu inkomen 🙂 En ja er is een verschil tussen integreren van BSD in GPL en herlicenti?ren van BSD als GPL. Kort gezegd: de BSD licentie stelt drie eisen, als je je daaraan houdt dan ben je legaal. Als je die code behandelt alsof deze GPL is, dan houd je je ??k aan die drie eisen. Je mag alleen niet zeggen dat de code GPL is, want dat is ie niet. Knip hem uit het GPL project en je hoeft de broncode niet meer te delen.

    Ah ja, persoonlijkheidsrechten. Dat is nog een leuk onderwerp voor hoofdstuk 2. Of ze uberhaupt gelden voor software is onduidelijk. Ga ik induiken.

    Ik krijg nu wel een dilemma dat het boek niet te dik moet worden en er z? veel onderwerpen zijn. Ik streef naar 100 ? 150 pagina’s en ik vermoed dat we daar nu dik overheen gaan.

  12. @Arnoud, wat je wel kunt doen is noemen welke verschillende voorwaarden er allemaal zijn en wat je allemaal moet meewegen als je je Cloud-applicatie ergens wilt onderbrengen. Vooral omdat die sites in hun voorwaarden de benodigde verantwoordelijkheden wel eens van zich af willen vegen.

    Stel dat je in een app-winkel van bedrijf X opeens malware te koop blijkt te zijn! Maar het beleid van dit bedrijf verwijst de verantwoording door naar de producent en de producent is verder nergens meer te bekennen…

    Een ander punt om bezorgd te zijn met Cloud-computing is in hoeverre het ene Cloud-proces de andere processen op een negatieve manier kan beinvloeden. In het verleden heb ik meegemaakt dat een site van mij die ik ergens liet hosten steeds weer opnieuw besmet raakte met malware. En dat terwijl mijn site geen lekken bevatte. Uit nader onderzoek bleek dat er wel 100 verschillende sites op een enkele server draaide en steeds een van die andere sites besmet raakte en daarbij het gehele systeem en dus alle andere sites ging besmetten. Dweilen met de kraan open dus… Dit doem-scenario kan zeker opduiken bij een Cloud-omgeving, mits de Cloud-software beveiliginglekken bevat. Nu is het zo dat systemen per lek een voor een besmet raken maar in de Cloud betekent een lek dat meteen alles besmet is! Lekker! (Not!) Dat is een risico van de Cloud…

  13. Mogelijk buiten de scope van het boek, of al ergens onder een hoofdstuk verwerkt, maar zit er ook in in hoeverre je als software leverancier aansprakelijk bent.

    i.v.m. software die bugs heeft, of laat leveren etc.. en in hoeverre algemene voorwaarden kunnen helpen en hoe de ICT~office AV dit bijvoorbeeld dekt.

    Verder top dat je dit boek schrijft! Als nieuwe ondernemer/zzp’er in de software ontwikkel hoek ga ik dit boek zeker bestellen.

  14. Ik weet niet precies wat je allemaal bij OSS wil coveren, maar wellicht is het een idee om ook iets als een CLA (Contributor License Agreement) te benoemen/bespreken? En wellicht iets noemen over hoe software licenties (kunnen) samenhangen met patenten, waardoor bijvoorbeeld iets niet vrijelijk te verspreiden is wegens beperkingen vanwege missende patentielicenties, terwijl er wel een vrije software licentie op de software zit.

    Daarnaast komt het woord “creative commons” niet in je index voor. Dit terwijl er best wel sotwarepakketten zijn die deze licentie gebruiken, en des te meer software pakketten die deze licentie voor hun documentatie gebruiken.

    Tot slot weet ik niet of je ook al aan de artistic license gedacht hebt? Dat is ook een onmogelijke licentie die vooral veel in de perl wereld gebruikt wordt.

  15. Zelf heb ik niks bij te dragen, maar:

    Even mijn petje af voor de idee?n en kennis die zichtbaar aanwezig is bij de reaguurders (nee, reagEErders dan toch maar!) van dit blog.

    Veel dingen zeggen mij niks, maar dat ligt aan mij. Ik zie na lezing wel in dat ze belangrijk zijn.

    Er bestaan ook blogs waar voornamelijk wartaal en/of ruzie- en scheldreacties onder staan.

    Zo kan het dus ook!

  16. Wellicht ook nog een leuk puntje, tot in hoeverre de architectuur (interne api) van een applicatie copyrightable is, en tot in hoeverre je bijvoorbeeld een licentie als gpl schendt door enkel de architectuur 1 op 1 over te nemen (en de implementatie zelf uitwerken).

  17. @23 Freeaqingme, volgens mij zou een gedeelte daarvan waarschijnlijk bij reverse engineering staan. Er staat mij in ieder geval iets bij dat nederland land bij uitstek is/was om te reverse engineeren zonder dat je wetten breekt. Dus het lijkt me niet dat je licenties schend door een API functioneel te dupliceren.

    Verder uiteraard niet aan mij om in te gaan op het vraagstuk, maar ik heb zo maar het vermoeden dat copyright nooit van toepassing is op abstracte zaken zoals architectuur of een API. Immers copyright gaat zover ik weet altijd over het product; De code, het boek, het gebouw etc.. Niet het idee daarachter.

  18. Wat punten waar ik aan denk maar waarvan ik niet zeker weet of het geheel bij het boek past:

    Moet je als leverancier zorgen dat de gegevens in te lezen blijven? Bijvoorbeeld: Microsoft komt elke 2 jaar met een nieuwe doc standaard en blijft maar 2 versies ondersteunen waardoor je elke 4 jaar je documenten om moet zetten. Dit kan heel lastig zijn bij archiveren.

    Wordt bij bescherming van een idee ook de haalbaarheid genoemd? (Elke tiener die probeert jouw idee na te maken juridisch volgen is misschien onhaalbaar)

    Hoe zit het met “leveren” van open source? Moet de klant die linux installatie zelf doen of mag jij dat doen?

  19. Ik zou in hoofdstuk 3 terughoudend zijn om overeenkomsten als enigste bron te verklaren waardoor iemand een licenties zou kunnen krijgen. Eenzijdige rechtshandelingen zijn als bron m.i. juridisch niet uitgesloten. Natuurlijk is het wel zo dat je langs deze weg niet snel een licentie zult krijgen van closed software, maar dat is een eenvoudige verklaring voor: de verkoper wil ook wat van de koper. Misschien ook een hoofdstuk over closed software opnemen? Daarin dan ook een stukje over Windows.

  20. @Erik: Ik zal proberen de grenzen van waar auteursrecht op software ligt, nader uit te werken in hoofdstuk 2. Inderdaad is een idee niet te beschermen (met een patent kom je hier verder dan met auteursrecht). Reverse engineering komt ook aan de orde.

    @Tobias: Dat is een leuk onderwerp maar ook h??l lastig want daar is volstrekt geen rechtspraak over. Het raakt aan het algemene probleem van digitaal archiveren. Daar kan ik praktisch gezien geen juridisch advies over geven, dus valt het buiten de scope van het “deskundig en praktisch juridisch advies” 🙂

    @Alex: Overeenkomsten zijn naar mijn stellige overtuiging de enige bron waarmee je in Nederland iemand kunt binden aan een licentie. Ik weiger een irrelevante fringe-interpretatie uit de VS in een Nederlands boek te bespreken.

    Sorry, deze discussie hebben we t? vaak gehad en ik wil daar niet steeds weer inhoudelijk op ingaan. Als je een gastblog wil schrijven met je juridische onderbouwing hoe die interpretatie naar Nederlands recht gaat, dan hoor ik dat graag. Maar niet in deze draad.

  21. @Arnoud: Ik ben bekent met jouw stellige overtuiging, maar jij vroeg aan iedereen om input voor je boek. En ik vind dat het mij vrij moet staan om zelf de inhoud van die input te bepalen en dus ook mag gaan over jouw stellige overtuiging nu deze mogelijk de inhoud van je boek raakt. Ik stel vast dat over jouw stellige mening geen consensus bestaat omdat naast mezelf genoeg anderen zijn die deze overtuiging betwisten. Mijn input is daarom om o.a. met deze stellige overtuiging terughoudend om te gaan.

    Ik meen namelijk dat een stellige overtuiging nog geen feit oplevert, zeker niet als er geen consensus over bestaat. Daarbij wil ik nog wel op wijzen dat je kritiek naar Brein toe was dat ze “zelf een interpretatie van de wet verzinnen en vervolgens deze als vaststaand feit presenteren naar partijen die daar niet over kunnen oordelen.”

    Maar doe verder met mijn input wat je wil.

  22. @Alex: Ik ontzeg je ook niet het recht je input te leveren. Je hebt gezegd wat je er in wil en ik reageer daarop. Ik wil alleen niet dat we nu in deze draad gaan discussi?ren over of “licenties als eenzijdige wilsuiting” een mogelijke rechtsfiguur is.

    Ik ken naast jou en Eben Moglen geen mensen die deze rechtsfiguur verdedigen, en al helemaal niet naar Nederlands recht. Ik nodig je uit om dit uit te zoeken; in de Nederlandse literatuur kon ik werkelijk niets vinden over dit onderwerp. Iedere Nederlandse juridische bron over software en licenties is het met mij eens dat licenties overeenkomsten zijn. Je opmerking dat “er geen consensus over bestaat” is dus feitelijk onjuist. Dat verklaart mijn stellige overtuiging en mijn keuze om dit onderwerp niet te behandelen in het boek.

    Je reactie leest als die van een creationist die in een biologieboek ruimte opeist voor zijn visie omdat evolutie “maar een theorie is” waar “geen consensus over is”.

  23. Komt er ook nog een stukje over de gevolgen van een faillisement? Stel, bedrijf X maakt een toepassing in de Google Cloud en ik gebruik die toepassing. Bedrijf X gaat failliet, maar de toepassing zou in principe gewoon in de Cloud door kunnen draaien, want het is Google die dat draaiende houdt, niet bedrijf X. Hoe zit het dan met de rechten, en met wat de curator kan doen en hoe lang ik die toepassing daarna eigenlijk nog kan gebruiken?

    Er is bijvoorbeeld ook zoiets als “Abandonware“. Software die al jaren niet meer wordt door-ontwikkeld en waarvan de maker is gestopt, overleden, failliet gegaan is of die gewoon gestopt is met dat product. De legale status van dergelijke software is niet al te duidelijk. Maar vanuit een juridisch oogpunt kan dit best interessant worden. 🙂

  24. Faillissement is zeker een belangrijk onderwerp. De curator kan ongestraft de licentiecontracten negeren (Nebula-arrest). Hm, waar zal ik dat behandelen? Het past denk ik het beste bij het hoofdstuk over licenties want het gaat over de rechten van de licentienemer. Maar het kan ook bij het stuk “moet ik een licentie nemen of de auteursrechten opeisen”.

    Abandonware is een goeie, maar veel valt er niet over te zeggen: je mag het niet gebruiken zonder licentie, en dat de rechthebbende verdwenen is, is jouw probleem. Daar moet wat aan gebeuren, zeker, maar dat vereist wel een wetswijziging (en mogelijk zelfs aanpassing aan Berner Conventie).

  25. Abandonware is goed want wie zal er aktie ondernemen indien ik dergelijke software zonder licentie gebruik? De eigenaar is mogelijk verdwenen of wil misschien helemaal geen moeite meer doen om de licentie te handhaven! Wat kan er uiteindelijk gebeuren als er bij een audit opeens abandonware wordt ontdekt? Is het te vergelijken met als ik op straat b.v. een gloednieuw toetsenbord zie liggen zonder enige aanwijzingen over de eigenaar ervan? Als ik het hou, is het diefstal? Is abandonware vergelijkbaar met gevonden voorwerpen?

    Faillisementen zijn zeker belangrijk omdat het om meer dan alleen de toepassing kan gaan! Stel, een bedrijf schrijft toepassingen voor financiele adviseurs en duizenden adviseurs nemen een licentie erop. Alle data ervan wordt naast de toepassing in de Cloud opgeslagen. Maar het bedrijf gaat vervolgens failliet en de curator trekt de stekker eruit. Toepassing plus data zouden dan meteen uit de Cloud kunnen verdwijnen en omdat niet het bedrijf maar de eigenaar van de Cloud alles verwijderd is het ook nog eens lastig om te eisen dat je eigen data alsnog teruggezet wordt zodat je erbij kunt. Of om een kopie te ontvangen van je eigen data…

    Persoonlijk vind ik Cloud applicaties ook vrij riskant omdat je van meerdere partijen afhankelijk wordt. Eerst en vooral de internet-provider want je hebt een stabiele internet-verbinding nodig. Daarnaast de Cloud-beheerder die ervoor moet zorgen dat de Cloud netjes draait en vooral een veilige omgeving biedt. Dan de maker van de toepassing die moet zorgen dat de toepassing goed in elkaar zit en dus niet per ongeluk allerlei data kan lekken. En omdat een toepassing wel eens een combinatie kan zijn van toepassingen van meerdere bedrijven die samenwerken om een geheel pakket te maken kan het aantal afhankelijkheden best wel groot worden. Misschien moet je dat risico ook iets toelichten. 🙂 Een keten is zo sterk als de zwakste schakel.

  26. Misschien ook aardig om ergens iets over shareware als marketingmodel te vertellen. Daarnaast zou je ook nog iets kunnen opnemen over “cracks” en keygenerators (wellicht onder “reverse engineering”?). En ook verspreiding via peer-to-peer netwerken als onderwerp.

  27. Heb even je ToC tegen mijn lijst van onderwerpen gehouden van het SPM cursusdeel IP, misschien nog wat interessante topics voor je boek

    • duidelijk onderscheid tussen beschermen van software en respecteren en omgaan met andermans bescherming.
    • trade secrets: hoe bescherm je intern je software
    • off shoring: eigendomsrecht van software die ver weg gemaakt wordt
    • relicensing van OSS: dit komt zo vaak voor dat we de meest voor de hand liggende voorbeelden behandelen.
    • merkenrecht: toch ook wel veel voorkomend, zowel naammerken, beeldmerken als domeinnamen.
    • hoe octrooi claims te voorkomen: kosten en baten in praktijk
    • beperkende licentie voorwaarden op standaarden en ontwikkeltools: dit lijkt steeds vaker voor te komen?
    • vinden en administreren van andermans IP (heb een lijst van praktische tips als je dat nuttig vind hoe het te vinden)
    • gebruik van code snippets (van fora, internet, boeken)
    • wat is een “derived work”: komt zo veel voor en vrijwel niemand heeft er een beeld bij.
    • gebruik van ?, ???, etc.
    • the other licenses (dus niet commercieel, maar ook geen open source, beerware enz)
    • juridische hulp inroepen: wanneer en wie moet je dan roepen

    Heb zeker interesse in je boek, al vele jaren blijkt dat veel (kleine en middelgrote) software product organisaties worstelen om de juridische kant van hun product in praktische daden om te zetten.

  28. Mooi dat je een boek over software adviezen schrijft. Ik mis met name kopjes die duidelijke de grenzen van het boek aangeven (al kun je stellen dat die impliciet bestaan uit de inhoudsopgave). Bijvoorbeeld vanuit welk recht (Nederlands?) je je onderwerp schrijft, welk aspect(en) van SW je behandelt (applicaties?), welke deskundigheid van toepassing is en waar de praktische component hem in zit.

    Mogelijke elementen om mee te nemen:

    het SW domein; totstandkoming (combinatie techniek/bemensing/proces beschermd?), resources (bv CPU cycles, memory state beschermd?), HW (bv porten of emuleren en is het andere SW op andere HW?), firmware (niet updaten = laakbaar gedrag?), embedded (automotive, medisch, industrieel -> gevoelige markt!), middleware (drivers/frameworks/OS(?)), tooling (bv wat je hiermee maakt is van mij), protocol (bv mp3 of verwachtingen IPSec), apps, interface (bv foute knopjes of 1-click buy), documentatie (gebruiksaanwijzing/EULA/licentie), content/invoer, gebruiker (gebruik).

    definities van SW, welke bestaan (ook internationaal) (waar loopt bijv de stelling internet = SW spaak?) toepasbaarheid “bestaand” recht/jurispudentie op software (de prehistorie van het recht? wanneer ontstaat/ontwikkelt zich nieuwe wetgeving op dit gebied. gaat je boek over het Nederlands recht?) waar zit de verantwoordelijkheid in de ketting (de “spelers” en hun context (bv land, zelfde soort lijstje als SW domein is mogelijk)) welk deel van de ketting/definitie(s) behandel je (waar gaat dit boek niet over)

    de opkomst van walled gardens (bv Apple, telecoms, settop boxen, gameconsoles, maar ook virtueel geld) malware/cybercrime/HTC (benadering vanuit de illegale kant) appendix met checklists of toestanddiagrammen voor de leek, bijvoorbeeld voor: is het software welk (wan)gebruik is (il)legaal welk (wan)gedrag van de software is (il)legaal wie is verantwoordelijk welke instantie behandelt mijn vraag

    Om het praktische te benadrukken! (inkopper op de vraag: wat is er zo praktisch aan je boek)

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.