Tag Archives: patent

Patent-Infringement-Avoidability

Ja, trottoir is ook een moeilijk woord, alleen dat is in het Frans. Dus bij deze een andere, maar dan in het Engels… Waarom?

Ik had een redelijk primaire reactie na het lezen van deze. Gelukkig is wordpress ook weer niet zo laagdrempelig dat die reactie 1-op-1 op je blog komt 😉 Anyway, Blackboard gaat weer achter een patent aan. Even disclaimer:

  • Ik ga er van uit dat er allerlei redenen zijn waarom een leverancier, buiten zijn eigen wil om, in een patenten-oorlog verzeild raakt.
  • Ik ga er van uit dat Amerikaanse situaties i.v.m. patenten verschillen van Europese.
  • Ik ga er vanuit dat zo’n patenten-oorlog als klant te ingewikkeld is om echt te volgen. Voor wie dat wil ervaren: lees Michael zijn feed van Edupatents maar eens door.
  • Ik ga er van uit dat een klant niet eens wil weten hoe die patenten in elkaar steken. Als klant wil je er vooral geen last van hebben. Bijvoorbeeld door verminderde investeringen in innovatie, die zijn weerslag krijgen in een applicatie die trager ontwikkelt.

Maar even verder redenerend: hoe kan een edupatent nadelig werken voor het onderwijs?

  • Ontwikkeling: juridische processen zijn kostbaar, waardoor minder geld overblijft voor de ontwikkeling van het pakket. Dus in plaats van geld te besteden aan innovatie, wordt er geld besteed aan advocaten en juristen.
  • Licentie-kosten: een leverancier moet het geld ergens vandaan halen. Dat leidt indirect tot afwenteling op de klant door hogere licentiekosten. Waar een onderwijsinstelling weer voor opdraait.
  • Verminderde functionaliteit door patent-inbreuk, als deze functionaliteit echt uit de applicatie gesloopt moet worden.

Of een leverancier zijn geld, tijd en energie niet steekt in zinloze patent rechtszaken, kun je geen onderdeel maken van de functionele eisen van een software pakket. Als je nog bezig met de keus er van of zo. Of als je onderzoek doet of je het huidige pakket niet eens wil migreren naar een ander… Ten minste, niet direct: als een patent zou leiden tot afwezigheid van functionaliteit, dan zou het gemis ervan gewogen kunnen worden, t.o.v. je eisen.

Hoe kun je dit dan wel meenemen in pakketkeuze?

Ten eerste zou er een nieuw soort eis geformuleerd kunnen worden, maar dan onder het hoofdstuk “Non-functional-Requirements“. Wikipedia geeft een hoop voorbeelden, waaronder “Legal and licensing issues”. Meer specifiek zou dit dan kunnen heten: “Patent-Infringement-Avoidability” oftwel het vermogen patent-inbreuken te vermijden.

Ten tweede zou je hier indicatoren voor kunnen verzinnen, die antwoord geven op de vragen:

  • Hoe groot is de kans dat deze leverancier betrokken raakt bij patent conflicten?
  • Hoe zou deze leverancier zich gedragen als het conflict niet vermeden kan worden?
  • Wat zou hij dan doen om negatieve gevolgen voor de klant te vermijden?

Het kunnen scoren van de antwoorden op deze vragen lijkt me wel moeilijker en het werk van analysten en marktkenners. Iemand een idee?