Mag ik de API achter een app zelf aanroepen?

| AE 9484 | Innovatie | 26 reacties

Een lezer vroeg me:

De app van mijn bank is leuk en aardig, maar ik wil eigenlijk bepaalde kerncijfers in mijn thuisdashboard getoond hebben. Technisch kom ik daar wel uit, maar mag ik die API aanroepen voor mezelf? Het is in principe dezelfde informatie heen en weer als de app zou doen, maar ik doe het niet op de officiële manier. Krijg ik dan problemen?

Zuiver juridisch gezien zie ik hier geen probleem mee. Als je gerechtigd bent een API aan te roepen, dan is het niet strafbaar of onrechtmatig om die aan te roepen. Je gaat hier dus niet voor de cel in, en de bank zal ook geen schadeclaim kunnen indienen.

Als je rare trucs gaat toepassen om de API dingen te laten doen die niet de bedoeling zijn, dan kan dat anders liggen. Informatie opvragen waar je eigenlijk niet bijhoort, mag je niet zomaar doen. In theorie is dat computervredebreuk.

Praktisch gezien kun je er wel problemen mee krijgen, in ieder geval één simpele: als de bank jouw aanroepen ziet als misbruik of bedreiging, dan blokkeren ze die. Dat zal al snel betekenen dat je ook via de officiële app niet meer bij je bankgegevens kunt of overboekingen kunt doen, en dat lijkt me erg vervelend voor een consument. Want zonder internetbankieren je bankzaken doen is een hele uitdaging tegenwoordig.

Ik zou dit dus alleen doen als de bank het goedvindt, of als je zeker weet dat de aanroepen niet te onderscheiden zijn van ‘echte’ aanroepen.

Arnoud

Mag je licentie-incompatibele dependencies meeleveren met je software?

| AE 9144 | Open source, Software | 34 reacties

Een lezer vroeg me:

Bij veel opensourcepakketten heb je allerlei extra software nodig, zogeheten dependencies. Soms is deze extra software meegeleverd met het pakket, maar vaak niet. Je moet dan maar hopen dat het via de repository van je Linux-distributie beschikbaar is. Ik had vernomen dat dat soms een juridische keuze is, hoe zit dat?

Het lijkt zo logisch om, als je eigen software afhankelijk is van andermans open source, die open source mee te leveren. Het is immers gewoon toegestaan om open source software te verspreiden, dat is het hele punt van open source. Het doet dus wat raar aan dat je bepaalde open source niet mee mag leveren.

De reden dat het soms toch niet kan, zit hem in de licentievoorwaarden. Sommige opensourcelicenties (met name de GNU GPL) eisen dat zogeheten afgeleide werken alleen mogen worden gedistribueerd onder die licentie. Als de licentie van het andere werk dit niet toestaat – zogeheten licentie-incompatibiliteit – dan is het dus niet mogelijk die twee samen te verspreiden.

Wat precies een afgeleid werk is, is al decennia een lange discussie, maar goed verdedigbaar is dat gebruik van een dependency daaronder valt. Heb je een specifiek ander stuk software nodig, dan bouw je voort op dat andere stuk software en dus ben je daar een afgeleide van. Hoewel ook goed verdedigbaar is dat je dan alleen functionaliteit aanroept, en dat valt buiten het auteursrecht en dus ook buiten de licentiescope. Maar als je dus zegt dat inroepen van dependencies jouw software een afgeleid werk daarvan maakt, dan moeten de licenties van de software en de dependencies allemaal compatibel met elkaar zijn.

Het gekke is dat het wél toegestaan is – ongeacht compatibiliteit – om te melden welke dependencies er gelden en de gebruiker die zelf te laten downloaden en installeren. Dat mag je zelfs automatiseren met een handig installatiescript of package manager-functionaliteit. Opensourcelicenties zijn namelijk distributielicenties, oftewel de voorwaarden gelden pas bij distributie. Wie alleen downloadt en gebruikt, heeft dus niets te maken met compatibiliteit van eventuele licenties.

Arnoud

Ik wil niet namens mijn werkgever akkoord gaan met Microsoft’s EULA

| AE 9075 | Arbeidsrecht, Software | 15 reacties

eula-ridge-trail-bordje-sign-flickr-oregon-brandon.jpgEen lezer vroeg me:

Deel van mijn werk is het uitrollen van Office 365. Eén van de installatiestappen is het akkoord gaan met de hele riedel gebruiksvoorwaarden en privacy condities van de firma Microsoft. Dit snap ik niet. Waarom moet dat, als wij al een contract hebben? En hoe voorkom ik dat ik straks privé akkoord ga of zo?

Het is compleet onzinnig dat een bedrijfsmatige installatie van reeds gelicentieerde software zou vereisen dat je akkoord gaat met op het scherm gepresenteerde gebruiksvoorwaarden. Precies om de reden die de vraagsteller noemt: de licentienemer hééft al akkoord gegeven op voorwaarden, zij het ouderwets op een stuk papier en niet met een klik. Maar dat doet er niet toe.

(En breek me de bek niet open over akkoord op privacyverklaringen. Dat slaat écht helemaal nergens op. Privacyverklaringen verklaren. Ze zijn verplicht op grond van de Wbp ter toelichting op wat je gaat doen. Maar een akkoord daarop is net zo relevant als akkoord op de dienstregeling van de NS.)

Die software is echter geprogrammeerd om bij installatie die voorwaarden te tonen, en doet dat dus vrolijk ook al betekent het niets. Maar daar staat tegenover dat klikken dus op zich ook niets betekent, afgezien van 5 seconden extra moeite. (Ik herinner me dat er opties zijn bij zakelijk installeren om dit te skippen, wie ‘m weet mag het roepen!)

Sowieso ben je niet privé gebonden, dit installeren doe jij zakelijk dus handel jij namens je werkgever. Jij als persoon bestaat niet, onder de wet. Jij bent een hand van je werkgever en niets dat die hand doet, kan bindend worden op de persoon achter die hand.

Arnoud

Waarom EULA’s allemaal zo verschrikkelijk onleesbaar zijn

| AE 9049 | Contracten | 12 reacties

Mooi stuk bij BoingBoing: onze digitale economie zit vol met licenties (EULA’s, end user license agreements) maar geen hond die ze leest. Is dat luiheid van de consument? Onoplettendheid in het bestelproces? Nee. Dit zit fundamenteler. Het concept van licenties – verlening van toestemming – is natuurlijk al veel ouder dan internet. De visvergunning is… Lees verder

Wat als een licentie zichzelf tegenspreekt?

| AE 8780 | Auteursrecht | 27 reacties

Via Twitter: waar sta je als een licentietekst enerzijds zegt “Alle rechten voorbehouden” met standaard blaftekst en anderzijds een keurige Creative-Commonslicentie benoemt, inclusief icoontje? Iets preciezer: Mijn eerste gedachte is: ik zie de tegenspraak niet. Het voorbehoud zegt immers dat er niets mag zonder schriftelijke toestemming. En wat staat er boven dat voorbehoud geschreven? Precies,… Lees verder

Mag een licentie je verbieden Kwaad te doen?

| AE 8555 | Contracten, Open source, Software | 11 reacties

Een lezer vroeg me: Onlangs vond ik de zogehten Do no evil-licentie. De JSON licentie zegt “The Software shall be used for Good, not Evil”. Is zoiets juridisch afdwingbaar, of wat zou de rechter hiermee doen? De licentie voor JSON (een protocol voor data-uitwisseling in Javascript) is voor 94,9% gelijk aan de bekende simpele MIT… Lees verder

Hoe laten we zien dat we oude software hebben gedeïnstalleerd?

| AE 8305 | Software | 24 reacties

Een lezer vroeg me: We hebben (eindelijk) een legacy-softwarepakket kunnen vervangen door iets nieuws. Nu wil de leverancier daarvan de garantie dat we deze volledig hebben verwijderd, en daarvoor willen ze hun auditor langs laten komen. Zijn wij verplicht hieraan gehoor te geven? En mag deze dan ook backups en dergelijke bekijken? Als je een… Lees verder

Waarom garandeert mijn softwarelicentie de afwezigheid van virussen?

| AE 8033 | Software | 13 reacties

Een lezer vroeg me: Vaak zie ik in softwarelicenties iets als dit: “Leverancier garandeert dat de Software geen virussen, achterdeuren, logische bommen of andere kwaadaardige routines bevat.” Waarom doen juristen dat? Het is toch raar dat een leverancier zou zeggen “onze software bevat een virus”? Voor mijn gevoel is de clausule vandaag de dag een… Lees verder

Is embedded software het einde van het concept ‘eigendom’?

| AE 7693 | Innovatie, Software | 38 reacties

Voertuigfabrikanten John Deere en General Motors willen het concept eigendom afschaffen, gilde Wired onlangs. In de VS staat de DMCA ter discussie: welke uitzonderingen op het auteursrecht moeten er in de wet blijven staan, en met name wat gaan we doen met de regels over het omzeilen van technische kopieerbeveiligingsmaatregelen in software. En de reden… Lees verder