[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:nl:is-uw-opensourceproject-commercieel-onder-de-cra-de-zeven-toetsen-van-de-commissie":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"nl","is-uw-opensourceproject-commercieel-onder-de-cra-de-zeven-toetsen-van-de-commissie","Is uw opensourceproject 'commercieel' onder de CRA? De zeven toetsen van de Commissie, met haar voorbeelden","De CRA raakt vrije en opensourcesoftware alleen waar zij in het kader van een commerciële activiteit wordt geleverd, en de verordening laat 'commercieel' over aan twee overwegingen. De richtsnoeren van de Commissie van 27 juli 2026, deel 3, maken daar zeven toetsen van: een prijs, een betaalde editie of open core, het te gelde maken van andere diensten of persoonsgegevens, ondersteuningsdiensten, donaties, sponsoring en de status zonder winstoogmerk, met 22 voorbeelden. Waar een maintainer, een open-corebedrijf en een stichting elk belanden, en wat een pull request van u maakt.","2026-09-11","\nDe Cyber Resilience Act, Verordening (EU) 2024\u002F2847, is op vrije en opensourcesoftware alleen van toepassing wanneer zij \"op de markt wordt aangeboden\", dat wil zeggen geleverd \"in het kader van een commerciële activiteit\". [De drie gevallen](\u002Farticles\u002Fdoes-the-cra-apply-to-open-source-software), een niet te gelde gemaakt project, een product gebouwd op opensourcecomponenten en de beheerder van opensourcesoftware, komen uit de verordening zelf. Wat de verordening niet doet, is zeggen wanneer een project dat geld aanneemt, ondersteuning biedt, een betaald niveau heeft of door een bedrijf wordt gefinancierd, de grens overschrijdt. De overwegingen 15 en 18 geven de richting; de richtsnoeren van de Commissie van 27 juli 2026, C(2026) 5252, deel 3, punten 42 tot 89, geven de toetsen, en 22 uitgewerkte voorbeelden genummerd 13 tot 34.\n\nDit artikel is dat deel. Het is geschreven voor de drie mensen die het vragen: de maintainer met een donatielink, het bedrijf met een community-editie en een enterprise-editie, en de stichting.\n\n## Eerst: wat überhaupt als open source telt\n\nArtikel 3(48) definieert vrije en opensourcesoftware als \"software waarvan de broncode openlijk wordt gedeeld en die beschikbaar wordt gesteld onder een vrije en opensourcelicentie die voorziet in alle rechten om haar vrij toegankelijk, bruikbaar, wijzigbaar en herdistribueerbaar te maken\". Punt 44 leest dat als twee cumulatieve voorwaarden: een licentie die de volledige set rechten verleent, en broncode die openlijk wordt gedeeld. Punt 46 trekt de conclusie voor source-available- en alleen-klantenmodellen: software \"waarvan de broncode alleen wordt gedeeld (of mag worden gedeeld) met betalende klanten of een beperkte groep gebruikers, wordt niet als FOSS beschouwd\". De richtsnoeren noemen geen licenties. Zij noemen de twee voorwaarden.\n\n## Wie verantwoordelijk is: maintainers, niet bijdragers\n\nVoordat wordt gevraagd of een project commercieel is, vraagt punt 48 of u degene bent die het levert. Punt 49: opensourcesoftware valt \"onder de verantwoordelijkheid\" van de personen \"die haar publiceren en de primaire controle uitoefenen over haar ontwikkeling, releases en distributiebeslissingen (vaak 'maintainers' genoemd)\". Bijdragers, die \"broncode bijdragen maar geen controle hebben over releases, roadmaps of governancebeslissingen\", zijn niet verantwoordelijk, \"ook al hebben zij er code aan bijgedragen\", en \"het louter bestaan van technische machtigingen, zoals commit-toegang, is niet voldoende\". Voorbeeld 13 is de pull request: de persoon die een patch indient die maintainers beoordelen en mergen \"is een 'bijdrager' en valt niet onder de CRA\".\n\nDe punten 86 en 87 sluiten de cirkel voor bedrijven: een fabrikant die een component integreert en aan het onderhoud ervan bijdraagt, wordt niet verantwoordelijk voor dat component, en het integreren van een component in een te gelde gemaakt product \"heeft geen invloed op de status van dat FOSS-component onder de CRA\". Of de verordening op een component van toepassing is, \"hangt uitsluitend af van de vraag of de natuurlijke of rechtspersoon die het publiceert het in de handel brengt\".\n\n## De zeven toetsen\n\n**1. Een prijs vragen voor de software.** Punt 51: geld vragen voor de software zelf, \"bijvoorbeeld door een prijs te vragen voor de voorgecompileerde binaries\", is in de handel brengen, en wie de prijs vraagt is fabrikant.\n\n**2. Een betaalde editie naast een gratis editie, open core inbegrepen.** Punt 52 behandelt ze als twee producten. De betaalde versie wordt in de handel gebracht; \"de gratis geleverde versie (of community-versie) wordt niet te gelde gemaakt en wordt daarom niet geacht in de handel te zijn gebracht\". Dat geldt \"waar de betaalde versie een 'verrijkte' commerciële versie is, die de codebasis van de gratis geleverde versie uitbreidt, of die versie opneemt in een breder product (bijvoorbeeld zoals in het 'open-core'-model)\". Punt 53 voegt de valkuil voor bedrijven toe: een rechtspersoon die de community-versie levert, is er beheerder van; een natuurlijke persoon valt daarvoor buiten de verordening.\n\n**3. Andere diensten te gelde maken via de software, of persoonsgegevens vereisen.** Punt 54: een project wordt in de handel gebracht waar de uitgever er \"andere producten met digitale elementen of diensten mee te gelde maakt\", of \"als gebruiksvoorwaarde de verwerking van persoonsgegevens vereist om andere redenen dan uitsluitend het verbeteren van de beveiliging, compatibiliteit of interoperabiliteit van de software\". Voorbeeld 14 is een gratis marktplaats-app die commissies of advertenties verdient; voorbeeld 15 een gratis VPN-client die toegang tot extra servers verkoopt; voorbeeld 16 een gratis fitness-app waarvan het gebruik afhankelijk is van gegevensverwerking voor gerichte reclame. Alle drie zijn op de markt.\n\n**4. Ondersteuningsdiensten.** De punten 55 tot 57 trekken de grens waarop de meeste opensourcebedrijven leven. Betaalde ondersteuning aanbieden maakt de software \"als zodanig niet\" commercieel: \"de beslissende factor is of de toegang tot de FOSS zelf, met inbegrip van het onderhoud ervan, afhankelijk wordt gesteld van een vergoeding, en niet het louter aanbieden van professionele diensten rond een vrij beschikbaar product\". Voorbeeld 18, een vrij downloadbaar commandoregelprogramma met optioneel betaald advies, is niet op de markt. Voorbeeld 17, een besturingssysteem met een betaalde versie \"die ondersteuningsdiensten omvat, zoals technische bijstand of prestatie-optimalisatie\", is dat wel, en punt 57 zegt dat \"ongeacht of functioneel gelijkwaardige software ook gratis beschikbaar is\". Voor particulieren voegt punt 58 de kostendekkingsregel van overweging 15 toe: bijstand bundelen met toegang is nog steeds niet commercieel \"als de gevraagde prijs alleen dient om de werkelijke kosten terug te verdienen\", die \"de redelijke kosten van levensonderhoud van de persoon omvatten\".\n\n**5. Donaties.** Punt 61, uit overweging 15: \"het aanvaarden van donaties zonder winstoogmerk mag niet als een commerciële activiteit worden beschouwd\", en een donatielink is geen winstoogmerk \"zelfs wanneer het via donaties opgehaalde bedrag de loutere kosten overschrijdt\", redelijke vergoeding van bijdragers en kosten van levensonderhoud inbegrepen. \"Een FOSS die uitsluitend door donaties wordt ondersteund, wordt daarom waarschijnlijk niet geacht in de handel te zijn gebracht.\" Punt 62 geeft de uitzondering: donaties die \"de facto gelijkstaan aan het vragen van een prijs\", waar \"de toegang tot de FOSS, tot essentiële functies of tot updates in de praktijk afhankelijk is van een donatie\". Voorbeeld 21 levert releases en beveiligingsupdates alleen aan donateurs: op de markt. Voorbeeld 22 publiceert de broncode maar geeft \"voorgecompileerde binaries, regelmatige updates en gegarandeerde beveiligingsfixes alleen aan donateurs\": op de markt.\n\n**6. Sponsoring en gefinancierde ontwikkeling.** De punten 63 tot 65: subsidies, bugbounty's, sponsoring en betaald functiewerk \"mogen niet in aanmerking worden genomen bij het bepalen van het commerciële karakter van die activiteit\". Voorbeeld 23 is een bedrijf dat een individuele maintainer betaalt om een functie toe te voegen die vervolgens openlijk wordt gedeeld; de maintainer heeft niets in de handel gebracht, en het bedrijf is zorgvuldigheid verschuldigd onder artikel 13(5) wanneer het het resultaat integreert.\n\n**7. Uitgevers zonder winstoogmerk.** Punt 66: een rechtspersoon \"die zo is opgezet dat alle inkomsten na aftrek van kosten worden gebruikt om doelstellingen zonder winstoogmerk te verwezenlijken\", brengt zijn software niet in de handel, zelfs waar zij rechtstreeks te gelde wordt gemaakt. Voorbeeld 24 is een browser \"die rechtstreeks te gelde wordt gemaakt via partnerschappen met zoekmachines\" en waarvan de inkomsten na kosten naar doelstellingen zonder winstoogmerk gaan: niet op de markt, en de uitgever is beheerder.\n\nPunt 67 voegt het geval toe waarvoor het hele beheerdersregime bestaat: software \"bestemd voor integratie door andere fabrikanten in hun eigen producten\" wordt niet in de handel gebracht tenzij de uitgever haar ook te gelde maakt; de rechtspersoon die haar publiceert is beheerder als hij duurzame ondersteuning biedt. De voorbeelden 25 en 26 zijn een UI-bibliotheek en referentie-implementaties die een bedrijf zonder vergoeding publiceert.\n\n## Waar elk van de drie belandt\n\nDe illustratieve scenario's van deel 3.5 leggen de toetsen op reële vormen, en drie ervan dekken de meeste lezers.\n\n**De individuele maintainer met een donatielink** (voorbeelden 27 en 34): niet op de markt, geen verplichtingen onder de verordening, hoeveel bedrijven ook van het project afhangen en hoeveel zij ook doneren. De bedrijven die het integreren zijn zorgvuldigheid verschuldigd onder artikel 13(5) en, onder artikel 13(6), zijn zij de maintainer meldingen verschuldigd van kwetsbaarheden die zij vinden en de fixes die zij schrijven.\n\n**Het bedrijf met een community-editie en een betaalde editie** (voorbeelden 29 en 30): fabrikant voor de betaalde editie, met de volledige verordening eraan, en beheerder voor de community-editie die het gratis levert, met de lichtere plichten van artikel 24 daaraan. De punten 72 tot 74 zeggen uitdrukkelijk dat één rechtspersoon beide tegelijk kan zijn, project voor project, en \"voor elke specifieke FOSS die hij publiceert\" moet beslissen welke hij is.\n\n**De stichting** (voorbeelden 28, 32 en 33): beheerder, of zij nu wordt gefinancierd door overheidssubsidies, donaties, partnerschapsprojecten of lidmaatschapsbijdragen, mits zij zo is opgezet dat inkomsten na kosten doelstellingen zonder winstoogmerk dienen en zij de software in stand houdt. Haar leden en financiers zijn niet verantwoordelijk voor de naleving door de software; fabrikanten die erop bouwen zijn zorgvuldigheid verschuldigd.\n\n## Wat u opschrijft\n\nVoor elk project dat u publiceert, één pagina: of het aan de twee voorwaarden van artikel 3(48) voldoet; wie de primaire controle over releases uitoefent; aan welke van de zeven toetsen het, in voorkomend geval, voldoet, met het nummer van het voorbeeld waarop het lijkt; en de rol die daaruit volgt, fabrikant, beheerder of geen van beide. Een bedrijf dat meerdere projecten publiceert, schrijft die pagina meerdere keren, omdat punt 74 zegt dat het antwoord per project geldt. Een fabrikant die opensourcecomponenten integreert, schrijft haar daarvoor niet; hij legt in plaats daarvan de zorgvuldigheid van artikel 13(5) en de meldingen stroomopwaarts van artikel 13(6) vast, waar [de twaalf stappen](\u002Farticles\u002Fthe-cyber-resilience-act-for-a-small-software-manufacturer-in-twelve-steps) ze plaatsen.\n\n## Bronnen\n\n- Verordening (EU) 2024\u002F2847, artikel 3(14) en (48), artikel 13(5) en (6), artikel 24, overwegingen 15, 18 en 19.\n- Europese Commissie, richtsnoeren van de Commissie over de toepassing van Verordening (EU) 2024\u002F2847, C(2026) 5252 final van 27 juli 2026, bijlage, deel 3, punten 42 tot 89 en voorbeelden 13 tot 34.\n\nDit is geen juridisch advies. Deel 3 is veertien pagina's, en de 22 voorbeelden zijn het deel om te lezen; de meeste projecten zullen zichzelf in een ervan herkennen.\n",1789383977610]