Voordat je een productfeed aansluit, verzamel je bewijs dat de beoogde verzameling, transformatie, bewaring en gebruik precies toestaat. Een publieke URL, een geldig account, een endpoint dat antwoordt of een tolerante robots.txt zijn niet voldoende. Koppel elke verwerking aan een licentieclausule, algemene voorwaarden, een leveranciersovereenkomst of een schriftelijke toestemming, en noteer vervolgens de beperkingen op het gebied van frequentie, territorium, duur en herdistributie. Als een essentieel recht dubbelzinnig blijft, blokkeer dan de automatisering en vraag bevestiging aan de leverancier of passend juridisch advies. Deze controle beschermt zowel de bron als de omkeerbaarheid van het project.
Vijf vaak verwarde vragen scheiden
De eerste fout is gebruiksrechten te herleiden tot "kunnen we het bestand downloaden?". Technische toegang is slechts één laag. Een correcte aansluiting onderscheidt minstens vijf vragen:
1. Toegang: is het account, de sleutel, het pad of de export voor dit gebruik verstrekt? 2. Verzameling: is geautomatiseerd downloaden toegestaan, met welke frequentie en binnen welke grenzen? 3. Transformatie: mogen kolommen genormaliseerd, indicatoren berekend of producten gematcht worden? 4. Bewaring: welke gegevens mogen worden opgeslagen, hoe lang en met welke verwijderingsmaatregelen? 5. Verspreiding: mogen titels, afbeeldingen, prijzen of voorraden aan gebruikers worden getoond, geëxporteerd of aan een derde worden doorgegeven?
Een positief antwoord op één vraag geldt niet automatisch voor de andere. Een leverancier kan import in een intern tool toestaan zonder publieke herpublicatie van zijn afbeeldingen toe te staan. Hij kan ook een handmatige export toestaan zonder geautomatiseerde bevraging te voorzien. Alleen de toepasselijke tekst en, indien nodig, een expliciete bevestiging bieden uitsluitsel.
Een bewijsdossier per bron opbouwen
Het dossier moet gekoppeld zijn aan een duidelijk geïdentificeerde bron. Vermijd algemene notities zoals "catalogus toegestaan". Leg vast: de naam van de leverancier, de betrokken dienst, het accounttype, het document, de versie of datum ervan, de officiële URL en de persoon die de interpretatie heeft gevalideerd. Een enkele screenshot is kwetsbaar als de tekst kan worden gedownload of in zijn oorspronkelijke formaat gearchiveerd.
| Vraag | Te zoeken bewijs | Mogelijke beslissing | Punt om te herzien |
|---|---|---|---|
| Wie verleent toegang? | contract, uitnodiging, accountdocumentatie | toegang erkend | wijziging van houder of account |
| Welk kanaal is toegestaan? | API-, FTP- of exportdocumentatie | gekozen kanaal | verplaatsing van endpoint of einde van dienst |
| Welke frequentie? | quotum, tijdvenster, beleefdheidsregel | begrensd tempo | herhaalde fouten of nieuw quotum |
| Welke gegevens? | bereik van de catalogus en uitsluitingen | toegestane velden | toevoeging van afbeeldingen, teksten of prijzen |
| Welke verwerking? | doel omschreven in de licentie | interne import, analyse of ander genoemd doel | nieuwe functie of nieuw publiek |
| Welke bewaring? | duur, einde contract, verwijdering | bewaarbeleid | opzegging of verwijdering van een product |
| Welke herdistributie? | publicatie- of deelclausule | verspreiding toegestaan of verboden | toevoeging van een export naar een derde |
De vorm van de feed verandert deze verplichting niet. De technische verschillen tussen CSV, XML, API en FTP helpen bij het bouwen van de aansluiting, maar geen van deze technologieën kent op zichzelf een hergebruiksrecht toe.
Wat de Europese databankrichtlijn verandert
Richtlijn 96/9/EG regelt de juridische bescherming van databanken in de Europese Unie. Ze voorziet onder meer, onder voorwaarden, in een recht op opvraging of hergebruik van het geheel of een substantieel deel van de inhoud wanneer een substantiële investering is gedaan. Ze behandelt ook bepaalde herhaalde en systematische handelingen op niet-substantiële delen. De toepassing op een concrete catalogus hangt echter af van de feiten, het nationale recht en het contract.
Deze richtlijn is geen toegangslicentie en ook geen automatisch verbod op elke import. Ze toont waarom "de pagina's zijn zichtbaar" of "we nemen maar een paar regels tegelijk" niet volstaan als analyse. De contractuele rechten, het eventuele auteursrecht op de inhoud, de bescherming van de databank en andere toepasselijke regels moeten apart worden onderzocht. Bij reëel belang of een dubbelzinnige clausule hoort de validatie bij een bevoegde juridisch professional; dit artikel biedt een documentaire methode, geen juridisch advies.
Waarom robots.txt de kwestie niet regelt
RFC 9309 formaliseert het Robots Exclusion Protocol. Ze geeft aan dat de gepubliceerde regels worden gevraagd aan robots die URI's doorzoeken en stelt uitdrukkelijk dat ze geen vorm van toegangsautorisatie vormen. Het bestand dient dus om de technische voorkeuren van de dienst te respecteren, maar vervangt geen authenticatie, licentie of algemene voorwaarden.
Het praktische gevolg is tweeledig. Een pad dat door robots.txt is toegestaan, geeft geen recht om de inhoud ervan te kopiëren of te herpubliceren. Een verboden pad moet door de betrokken robot worden gerespecteerd, ook als het team meent een commercieel belang te hebben. Als een specifiek contract een technische beperking lijkt tegen te spreken, probeer deze dan niet te omzeilen: vraag de leverancier naar het officiële kanaal dat bij de overeenkomst hoort.
Validatieprocedure vóór aansluiting
Stap 1: het werkelijke gebruik omschrijven
Schrijf een concrete zin: "dit bestand ophalen via dat kanaal, met die frequentie, deze velden bewaren en gebruiken voor dat doel." Vermeld de gebruikers en eventuele doorgiftes. Een vaag doel maakt het onmogelijk het project met de clausules te vergelijken.
Stap 2: de toepasselijke teksten verzamelen
Verzamel het contract, de algemene voorwaarden van het account, de licentie van de feed, de technische documentatie en de schriftelijke communicatie die de toestemming preciseert. Noteer hun datum en reikwijdte. Commerciële pagina's kunnen de dienst toelichten, maar vervangen niet noodzakelijk de contractuele voorwaarden.
Stap 3: de rechtenmatrix invullen
Citeer voor elke actie — verzamelen, transformeren, opslaan, tonen, exporteren, verwijderen — het bewijs en classificeer het resultaat: toegestaan, verboden, voorwaardelijk of onbepaald. Gebruik "toegestaan" nooit zonder verwijzing. Een onbepaald vakje wordt een vraag aan de leverancier.
Stap 4: de grenzen vertalen naar waarborgen
Zet de bevestigde verplichtingen om in instellingen: maximale frequentie, uitgesloten velden, bewaartermijn, logging, verwijdering bij einde van het contract en beperking van exports. Documentatie en uitvoering moeten consistent blijven. Als de toestemming vervalt, moet de verzameling kunnen stoppen zonder het bewijs te wissen dat nodig is voor een audit.
Stap 5: testen op een omkeerbaar bereik
Zodra de rechten zijn vastgesteld, gebruik je een proefpartij leverancier om het kanaal en de grenzen te testen op een klein, gecontroleerd bereik. Deze test regulariseert geen ongeoorloofd gebruik; hij komt na de documentaire validatie.
Stap 6: de herziening plannen
Bepaal de gebeurtenissen die een nieuwe lezing vereisen: wijziging van de algemene voorwaarden, nieuw domein, accountwijziging, toevoeging van afbeeldingen, delen met een derde, hogere frequentie, nieuw doel of opzegging. Een toestemming mag niet als eeuwig worden beschouwd als de context verandert.
Grijze zones beheren zonder een toestemming te verzinnen
Als een clausule ontbreekt, formuleer dan een gesloten en traceerbare vraag aan de leverancier. Bijvoorbeeld: "Staat ons account een dagelijkse ophaling van dit bestand toe voor interne analyse, met bewaring van identifier, prijs en voorraad?" Voeg de vraag over weergave en export toe als dat gebruik gepland is. Een vaag commercieel antwoord moet worden verduidelijkt vóór automatisering.
Kopieer geen extra data "voor het geval dat". Minimalisatie beperkt risico's en vereenvoudigt verwijdering. De controle van de kolommen van een groothandelscatalogus helpt om te bepalen welke velden echt nodig zijn en welke een niet-aangetoond doel hebben.
Leg tot slot weigeringen vast. Een bron die geblokkeerd is wegens gebrek aan toestemming, is geen technische mislukking: het is een compliancebeslissing. De status moet de reden, de datum en de volgende mogelijke actie tonen, zonder de verzameling automatisch te herstarten.
Wat ArbitragePro+ kan automatiseren / wat de verkoper zelf moet controleren
De functie bronrechten-register is een voorgestelde specificatie, geen functie die als beschikbaar wordt aangekondigd. Ze zou aan elke bron een gebruiksmatrix kunnen koppelen, de officiële documenten, hun datums, de beperkingen, een herzieningstermijn en een blokkerende status. Ze zou ook verzameling kunnen verhinderen wanneer een vereiste toestemming ontbreekt of verlopen is, met behoud van de geschiedenis van beslissingen.
De verkoper moet de toepasselijke contracten interpreteren, toestemmingen verkrijgen, doeleinden bevestigen en waar nodig juridisch advies inwinnen. Hij controleert ook of de technische configuratie daadwerkelijk het toegestane tempo, de velden, de bewaring en de verspreiding respecteert. Geen enkel geautomatiseerd register verandert een dubbelzinnige clausule in een toestemming.
Checklist vóór activering
- Het werkelijke gebruik, het kanaal, de frequentie en de ontvangers zijn omschreven.
- De accounthouder en de verstrekker van de toestemming zijn geïdentificeerd.
- Algemene voorwaarden, licenties en technische documenten zijn gedateerd en gearchiveerd.
- Verzameling, transformatie, bewaring en verspreiding hebben elk een bewijs.
- De
robots.txt-regels worden gerespecteerd zonder als licentie te worden behandeld. - De verzamelde velden hebben een expliciet doel.
- De grenzen zijn vertaald naar technische waarborgen.
- Er bestaat een stop- en verwijderingsprocedure.
- Doelwijzigingen leiden tot een nieuwe herziening.
- Elke onbepaalde zone blijft geblokkeerd tot verduidelijking.
Een toegestane bron documenteren
Open het bronnenbeheer in ArbitragePro+
Officiële bronnen
- EUR-Lex, richtlijn 96/9/EG betreffende de rechtsbescherming van databanken: https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX%3A31996L0009 (geraadpleegd op 17-08-2026).
- IETF, RFC 9309 — Robots Exclusion Protocol: https://www.rfc-editor.org/rfc/rfc9309.html (geraadpleegd op 17-08-2026).
