Waarom is FRAND slecht voor Vrije Software?
"Eerlijk, redelijk en niet-discriminerend" ("fair, reasonable, and non-discriminatory" of FRAND) is een acroniem dat verwijst naar een breed spectrum aan licentiepraktijken dat is ontwikkeld in de context van industriestandaarden.
Ondanks het standaardiseren van een technologie is het nog steeds mogelijk dat iemand er in een bepaald rechtsgebied een patent over heeft. Omdat de handel zich wereldwijd afspeelt dwingt dit iedereen om voor het implementeren van een uitvinding aan de patenteigenaar een licentie te vragen. De concurrenten hebben dus veel macht. Om deze macht te verminderen zocht de industrie haar toevlucht in overeenkomsten om patenteigenaren te binden aan bepaalde licentievoorwaarden waarnaar meestal wordt verwezen als "eerlijke, redelijke en niet-discriminerende" termen ("fair, reasonable, and non-discriminatory" of FRAND).
In de meeste gevallen maken zulke licenties een juiste implementatie van Vrije Software onmogelijk. Dit komt door de verschillende incompabiliteiten met de manier waarop Vrije Software functioneert en wordt gedistribueerd. Als gevolg hiervan kunnen FRAND-licenties niet als eerlijk, redelijk en niet-discriminerend worden beschouwd.
Wat is FRAND?
Een belangrijke uitdaging voor FRAND is dat het een ambigu concept is, waarbij er sprake is van subjectief oordeel dat vaak alleen beschermd kan worden door middel van juridische actie. Er is bijvoorbeeld geen consensus over de termen "eerlijk", "redelijk" en "niet-discriminerend":
Eerlijk ("fair") houdt met name verband met onderliggende licentietermen die niet anti-competitief zouden moeten zijn en ook niet als buitenwettig zouden moeten worden beschouwd als zij worden opgelegd door een dominant bedrijf in haar relatieve markt.
Redelijk ("reasonable") verwijst met name naar licentietarieven.
Niet-discriminerend ("Non-discriminatory") verwijst zowel naar de termen als naar de tarieven, waarbij een vergelijkbare behandeling voor iedere licentiehouder wordt vereist.
Waarom is FRAND incompatibel met Vrije Software?
Over FRAND licentietermen wordt gewoonlijk in het geheim onderhandeld en ze worden vertrouwelijk behandeld door de betrokken partijen. FRAND-termen schijnen vaak een betaling van aandelen in de opbrengst gebaseerd op de kwantiteit van de distributie (zoals het aantal gedistribueerde kopieën) te vereisen. Ze staan ook slechts zelden sublicenties toe aan derde partijen, op een manier die geen verdere actie vereist van de sublicentiehouder om dezelfde rechten te verkrijgen om de standaard te implementeren. Het is een geaccepteerd feit dat zulke eisen incompatibel zijn met enkele van de meestvoorkomende termen waaronder Vrije Software wordt ontwikkeld en gedistribueerd1.
Vrije Software biedt gebruikers een hoog niveau aan controle over de software door verrijkende vrijheden toe te staan om de broncode te inspecteren en de software te bestuderen en te innoveren. Het is gebaseerd op het principe dat iedereen, of het nu een individu of een bedrijf is, een gebruiker, ontwikkelaar, distribueerder of welke combinatie hiervan dan ook kan zijn. Alleen de termen die toestaan dat technologie kan worden geïmplementeerd en gedistribueerd zonder in strijd te zijn met deze voorwaarden zullen in de praktijk compatibel zijn met Vrije Software.2.
Een voorbeeld: sectie 7 van GPL v2, een van de meest gebruikte Vrije Software-licenties, garandeert dat welke extra beperking dan ook die voorkomt dat gebruikers gebruik kunnen maken van de vrijheden in de licentie, dat wil zeggen het opleggen van betalingen voor auteursrecht ("patent royalties") of de eis om een afzonderlijke licentie te verkrijgen, het recht ontneemt om verder te gaan met het distribueren van de software.
Omdat Vrije Software aan iedere gebruiker de vrijheid geeft om de software zelf verder te distribueren is het in de praktijk dus onmogelijk om betalingen voor auteursrecht te verzamelen en bij te houden. Dit is niet alleen een kwestie van broncodelicenties; iedere term die vereist dat een ontwikkelaar verzoekt om, verder dan de licentie gaande, aanvullende goedkeuring om de software te gebruiken, te verbeteren of te delen zijn incompatibel met de normen van open gemeenschappen die Vrije Software ontwikkelen.
Een andere incompatibiliteit van FRAND met Vrije Software bevindt zich in de eis dat de afzonderlijke licentie gewoonlijk niet automatisch kan worden overgedragen aan derde partijen. Dit in tegenstelling tot Vrije Software, waarbij dezelfde rechten en vrijheden automatisch worden overgedragen aan ontvangers zonder de noodzaak van een sublicentie.
Als gevolg hiervan is geschat dat dankzij hedendaagse vrijwel universele software-ontwikkelingspraktijken vrijwel geen enkel nieuw product op de softwaremarkt wodt gebouwd zonder gemakkelijk beschikbare Vrije Software-code3 te bevatten. Dat maakt Vrije Software onontkoombaar voor innovatie en economische groei.
In dit opzicht kan er niet aan het "niet-discriminerende" criterium worden voldaan omdat het substantiële aantallen actoren en een innovatieve kracht waar Vrije Software mee werkt buitensluit van het implementeren van FRAND-gelicenseerde technologie. Hieruit volgt dat een FRAND-gelicenseerd standaard-essentieel patent ("Standard Essential Patent" of SEP) "eerlijk" ("fair") noch "redelijk" ("reasonable") is.
Kan FRAND echt FRAND zijn voor Vrije Software?
Sommige zeldzame FRAND-termen staan toe dat er een bedrag ineens wordt betaalt zodat de ontwikkelaars kunnen vermijden dat zij het aantal gedistribueerde kopieën moeten bijhouden. Deze praktijk lijkt misschien een werkbare mogelijkheid maar alleen grote bedrijven met een specifieke juridische afdeling zijn in staat om over deze termen te onderhandelen. Het midden- en kleinbedrijf (MKB) en individuele programmeurs worden dus buitengesloten. Het is essentieel om te garanderen dat verschillende actoren toegang hebben tot de markt, vooral in de ICT-sector, waar het niet ongebruikelijk is om van een startend bedrijf in minder dan een decennium een leidend bedrijf te worden.
In plaats daarvan dragen gestandaardiseerde technologieën bij aan competitie, omdat het meer nieuwe spelers is toegestaan om op de markt te groeien en hun ideeën te baseren op bestaande technologieën.
De eis van betalingen voor auteursrecht per kopie binnen FRAND vormt niet het enige obstakel voor het implementeren van de standaard in Vrije Software. De inherente incompatibiliteit ligt in het feit dat FRAND het samenwerkende open model achter Vrije Software volledig neutraliseert door het beperken van het gebruikmaken van de toegekende vrijheden.
Het is bijvoorbeeld gebruikelijk dat FRAND de eis bevat dat er contact wordt gezocht met de SEP-houder om een afzondelijke licentie te verkrijgen. Dit vormt ook discriminatie tegen Vrije Software, omdat het van iedere gebruiker die gewijzigde versies verder wil distribueren zou eisen om contact op te nemen met de SEP-houder. Dit is verspilling van tijd en hulpbronnen en brengt het samenwerkingsmodel achter Vrije Software serieuze schade toe. De geschiedenis leert dat ontwikkelaars technologieën met deze licentievormen vermijden.
Het licentieschema waarbij er geen beperkingen worden gesteld aan het gebruikmaken van de rechten die zijn toegekend door Vrije Software, de zogenoemde "restrictievrije" termen, zou geschikt zijn voor Vrije Software. Vergelijkbare licentietermen kunnen worden bereikt door FRAND te dwingen om standaard compatibel te zijn met de GPL. Standaardbepalende organisaties ("Standard setting organisations", SSO's) kunnen van deelnemers aan het standaardisatieproces eisen dat zij uitdrukkelijk instemmen dat een licentie alleen FRAND is wanneer het gebruik en de distributie van essentieel gepatenteerde technologieën die niet minder beperkend zijn dan GNU GPL v.2 of welke latere versie dan ook is toegestaan.
Verder zouden SSO's, om te garanderen dat zo'n beleid niet wordt ontdoken, zorgvuldig de status van alle onderdelen van iedere nieuwe standaard moeten overwegen. Om te garanderen dat zo'n beleid niet wordt ontweken zouden SSO's de status van alle componenten van iedere nieuwe standaard zorgvuldig moeten overwegen. Het is niet ongewoon dat een nieuwe standaard wordt gebouwd op een vorige. Als de herziene standaard is gebouwd op andere regels (bijv. FRAND dat betalingen voor auteursrechten of onbeperkte patenten toestaat) dan zou de volledige implementatie van de nieuwe standaard kunnen afhangen van de licentietermen van SEP's in de oudere standaard. Zo'n situatie zal de inspanningen om het probleem van SEP's op te lossen ondermijnen.
Het is voor bedrijven ook niet ongewoon om zogenoemde "algemene claims" ("blanket claims") vast te stellen, dat wil zeggen te verklaren dat zij SEP bezitten zonder de details van zulke patenten te specificeren. 4 Deze praktijken vormen, samen met het beleid, dat geen garantie vormt voor de geleverde informatie, zoals is aangenomen door verschillende SSO's, overbodige en lastige obstakels voor iedere ontwikkelaar die wenst gebruik te maken van de standaard-implementatie. Daarom vormt een adequaat afdwingbaar systeem om te garanderen dat patenteigenaren zich aan hun beloften houden, een laatste noodzakelijke toevoeging aan deze opzet.
Waarom is FRAND niet goed voor software?
Op het gebied van standaarden van toepassing zijn op de software, het internet en het web is er een duidelijke afwezigheid van SEP's5.
Dit is vooral overduidelijk en het beleid van verschillende SSO's die op deze gebieden werken: bijvoorbeeld het overgrote deel van de standaarden die zijn erkend door de Organisation for the Advancement of Structured Information Standards (OASIS) vereisen termen die vrij zijn van betalingen voor auteursrecht6 en hoewel hun beleid de FRAND-mogelijkheid bevat erkent OASIS de trend naar standaarden7 die vrij zijn van betalingen voor auteursrecht. De Internet Engineering Task Force (IETF) raadt in de algemene instructies voor hun werkgroepen 8 lastige patentstandaarden af. Beter nog: de W3C vereist dat iedere SEP voor iedereen gelicenseerd is op basis van vrijheid van betalingen van auteursrecht9.
SEP en FRAND komen voort uit de telecommunicatiesector en via traditionele SSO's. Software, internet- en webstandaarden zijn op een meer samenwerkende manier ontwikkeld, bijvoorbeeld via forums en consortia10. Er moet rekening gehouden worden met dit verschil bij het regelen van het werk van SSO's. Het in de ene sector toepassen van het model dat is ontwikkeld door de andere sector, die praktisch en historisch op een andere manier is ontwikkeld, kan leiden tot gevolgen die het tegenovergestelde zijn van het doel van standaardisatie. Daarom is de aanpak van 'een maat past allen' onjuist en kan deze innovatie onderdrukken in plaats van aanmoedigen.
Het alternatief voor FRAND
De manier om de breedste interoperabiliteit en marktcompetitie te bereiken is om Open Standaarden die compatibel zijn met Vrije Software aan te nemen.11
De snelle ontwikkeling van software, web- en internettechnologie is grotendeels gebaseerd op Open Standaarden, die vrij van beperkingen en betalingen voor auteursrecht beschikbaar zijn. Dit laat zien dat beperkingsvrije standaarden cruciaal zijn in een omgeving waar innovatie snel en versnellend plaatsvindt en waar de meeste actoren klein zijn en niet over de hulpbronnen beschikken om zich bezig te houden met ingewikkelde patentlicentie-overeenkomsten. Licentievoorwaarden die voor deze actoren obstakels vormen om zich op de markt te begeven of om de competitie aan te gaan met grote concurrenten vormen een belangrijke hindernis voor de competitie en kunnen daarom niet eerlijk, redelijk en niet-discriminerend worden genoemd. Daarom staan alleen licenties die daadwerkelijk vrij zijn van beperkingen de standaard toe om een Open Standaard te zijn, dat wil zeggen "vrij van juridische of technische clausules die haar gebruik door welke partij of welk bedrijfsmodel dan ook beperken"12.
Het op een minimalistische 13 manier herzien van zulke standaarden zal garanderen dat bedrijven van verschillend formaat daadwerkelijk in staat zijn om ze te implementeren. Dit zal leiden tot echte non-discriminatie in verschillende bedrijfsformaten in -modellen. Dit zal ook bijdragen aan een bredere en effectievere aanname van standaarden door verschillende bedrijfstakken. Daarentegen zijn niet-minimalistische standaarden lastig en vereisen zij enorme investeringen in tijd en hulpbronnen om te worden geïmplementeert.
Naast Open Standaarden kan de breedste aanname van standaarden in de praktijk worden bereikt door software ook toe te staan om te fungeren als referentie-implementatie. Dit is vooral belangrijk omdat voor de meeste software-standaarden de formele specificatie onvoldoende is en de daadwerkelijke standaard wordt gedefinieerd door zowel de geschreven specificatie als de daadwerkelijke implementaties. Voor degene die tot implementatie overgaat is de referentie-implementatie waardevoller omdat deze toestaat dat de uitgebreide fase van de proefondervindelijke methode om ambiguïteiten in de specificatie op te lossen, kan worden vermeden. Daarom zal het publiceren van software onder Vrije Software-licenties in de praktijk bijdragen aan de breedste aanname van deze standaarden.
Conclusie
FRAND is niet alleen incompatibel met de meeste Vrije Software maar ook in het geheel niet ontworpen om software te reguleren.
Om over deze tegenstelling heen te komen is het noodzakelijk om te garanderen dat SEP's een licentie hebben onder termen die compatibel zijn met Vrije Software, bijvoorbeeld vrij van beperkingen. Toch kan deze mogelijkheid, afhankelijk van de daadwerkelijke inhoud van van de SEP-licentie en de afdwingbare capaciteiten van de organisatie die de standaard bepaalt, nog steeds extra obstakels vormen voor de implementatie van de innovatieve technologie in Vrije Software.
De breedste aanname van standaarden, hetgeen in principe het doel is van FRAND, kan worden bereikt door ze open en minimalistisch te ontwikkelen en door het vereisen van een referentie-implementatie die is gepubliceerd als Vrije Software. Deze standaarden zullen de breedste competitie van verschillende Vrije Software- en propriëtaire actoren op de markt garanderen zonder wie dan ook uit te sluiten.
Voetnoten
Ian Mitchell, Stephen Mason, "Compatibility Of The Licensing Of Embedded Patents With Open Source Licensing Terms"", IFOSSLR, 2011.↩
Georg Greve, "Een evenwichtsonderzoek: standaardisatie en patenten", 2008.↩
Björn Lundell et al., "On Implementation of Open Standards in Software: To What Extent Can ISO Standards be Implemented in Open Source Software", International Journal of Standardization Research,Vol. 13, no 1, 47-73 p, 2015.↩
Rudi Bekkers, Joel West, "The Limits to IPR Standardization Policies as Evidenced by Strategic Patenting in UMTS",Telecommunications Policy, 2009.↩
Mark Bohhanon, "Out of the Murky Lagoon and into… Is there a Emerging Consistent US Government Policy on Standard Essential Patents?", 2014.↩
OASIS, FAQ section, question No. 7. “What are the IPR Policies of OASIS?”.↩
“OASIS response to NSTC request for feedback on standard practices”, 75 FR 76397 (2011).↩
Mark Bohhanon, “Out of the Murky Lagoon and into… Is there a Emerging Consistent US Government Policy on Standard Essential Patents?”, 2014-08-08.↩
Rishab Gosh, “An Economic Basis for Open Standards”, Policy Report of FLOSSPOLS Project managed by the European Commission, University of Maastricht, 2005.↩
Bernhard Reiter, “The minimal principle: because being an open standard is not enough”.↩