Dit is dus niét hoe je reageert als mensen je als gratis leverancier zien met je open source

| AE 13131 | Ondernemingsvrijheid, Security | 44 reacties

Gisteren blogde ik over een OSS developer die de vraag van een gebruiker kreeg “graag binnen 24 uur hoe uw bedrijf is ingericht op het afdekken van risico’s rondom de enorme log4j bug”. Dat is een typische grootzakelijke manier van doen, die verder met de realiteit niets te maken heeft. Kan gebeuren, je stuurt een “haha no sla okthxbye” mailtje of en klaar. In de comments werd ik getipt over ene meneer Marak die anders reageerde: hij saboteerde zijn eigen code, waar vele vele mensen en projecten door gedupeerd werden.

Marak is ontwikkelaar van een uitbreiding op het bekende node.js framework voor Javascript. Zijn module colors zorgt voor mooie stijling van de beheersomgeving. Verder weinig opmerkelijk, alleen bleek dat recent een toevoeging te hebben gekregen die zorgt voor een oneindige lus, waardoor je hele systeem niet meer werkte als je deze module automatisch liet updaten. Wat iedereen en z’n moeder doet, dus dat gaf de nodige ergernis.

Een foutje? Nee, zeker weten niet. Allereerst niet omdat het een losse nieuwe regel was, met ook nog eens “for i = 666; i < infinity” er in, en dat getal heeft natuurlijk een negatieve betekenis. En ten tweede omdat Marak eerder al boos was dat bedrijven zijn code gebruiken zonder hem financieel te steunen. Wat zijn goed recht is, daar niet van, maar dan volautomatisch je code saboteren, dat kun je niet maken.

Of was het dom van al die mensen, hadden ze maar de code moeten controleren en niet automatisch updaten? Dat vind ik te makkelijk. Natuurlijk hoor je niet zomaar willekeurige code van internet te halen en in productie te nemen, maar dit is een project dat al enige tijd bestaat, goed aangeschreven staat en daarom vertrouwd wordt. Dan wek je bepaalde verwachtingen – en dat gaat boven je opensourcelicentie waarin “als het breekt, mag je de stukjes houden” staat als beperking van aansprakelijkheid.

(Voor de juristen: dit lijkt mij zo’n geval  van opzet of grove nalatigheid waarbij je beperking van aansprakelijkheid niet geldt.)

Regelmatig zie ik dan de opvatting “het is mijn code, ik doe wat ik wil en ik heb geen contract met die mensen dus ik ben niets verplicht”. Dat is dus te kort door de bocht. Door op een bepaalde manier te handelen, schep je verwachtingen. Als jij die verwachtingen regelmatig waar maakt, ontstaat een patroon waar mensen op mogen vertrouwen. Dat kun je niet eenzijdig doorbreken, zeker niet op zo’n lompe en schadebrengende manier. Dat noemen we in Nederland gewoon onrechtmatig, dat kun je niet maken.

Arnoud

 

Deel dit artikel

  1. Doet me denken aan dit hypothetische verhaal: https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 Gaat over hoe je als developer van een onschuldig ogende module, creditcardgegevens zou kunnen stelen van duizenden sites. Moraal van het verhaal: gebruik van OSS is prima in de bijna alle gevallen. Maar misschien niet op de plekken waar super kritische dingen gebeuren, zoals invullen van creditcard gegevens.

  2. De vraag is hoe die Marak wel had moeten reageren. Want het was wel heel erg zuur. Hij ontwikkelde een oss applicatie, en om de ontwikkeling te funden bedacht hij er een saas dienst bij, omdat vrijwel niemand wilde doneren. En toen bleek een bedrijf met diepe zakken direct het hele concept over te nemen en aanvankelijk gratis aan te bieden, om hem uit de markt te drukken.

    Ik denk eigenlijk dat hij de volgende update zonder veel bombarie de licentie had moeten veranderen in een betaalde versie. Dan wachten tot dat bedrijf de laatste versie implementeerde. En dan had moeten aanklagen. Dan kon huj weer een versie later terug naar oss.

    • Marak had gevonden dat het bedrijf achter de schermen gewoon van zijn dienst gebruik maakte. Dus als hij het bedrijf het lastig had willen maken zonder dat ongerelateerde partijen benadeeld zouden worden, dan had hij z’n applicatie dusdanig kunnen aanpassen dat op alle requests vanuit de dienst van dat andere bedrijf er onzin werd teruggeleverd. En dan het liefst onzin die er, zeker in een debug-sessie, niet uitziet als onzin.

      • Mijn buurman heeft de buitenkraan zo aangesloten dat die lekt op mijn grond. Ik stop een filter in die kraan zodat er langzaam kobalt in zijn grond lekt. Hmm, ik weet het niet. Ik zou liever het IP-adres van dat bedrijf blokkeren of zoiets, zodat het bedrijf wel meteen meekrijgt dat er iets mis is. Als het bedrijf een jaar lang niet zag wat voor subtiele fout er in de uitvoer zat en zij verkochten dat aan klanten, ontstaat er een enorme schadepost. Die discussie wil je niet.

  3. Als developer moet ik zeggen dat ik niet weet of ik het met je eens ben. Wellicht is hier inderdaad sprake van opzet dan wel grove nalatigheid. Maar, wat voor schade loop je hier als gebruiker van dit product door op?

    Als je product hierdoor stuk gaat heb je bij het updaten zelf nagelaten goed te testen of alles nog werkte. Wellicht kon je je product niet deployen omdat bij het deployen automatisch de laatste versie werd binnengehaald; maar dan is de vraag wat je procedure is voor wanneer NPM.js (het distributieplatform) een keer een storing heeft. Ook komt het bij NPM packages met enige regelmaat voor dat ze ‘gehackt’ worden en malware bevatten. Ook dat is een reden om een standaardprocedure te hebben om updates goed te reviewen.

    De licentie bevatte de volgende tekst:

    THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

    Zelfs al zou er een bepaald patroon zijn dat de auteur van deze software te vertrouwen is, kies je er als gebruiker van de software wel voor om deze licentie als zodanig te accepteren. Als je die licentie als zodanig accepteert hoort daar voor mij ook bij dat je procedures inregelt waarmee je je indekt voor het geval dat de software toch een keer niet fit for purpose is.

    Als je dat als bedrijf allemaal niet doet, heb je wat mij betreft pech als het dan toch een keer mis gaat; dan had je maar een manier moeten bedenken om je wel in te dekken.

    Los van allerlei procedures zou zo’n manier om je in te dekken ook kunnen zijn dat je een commerciele softwareleverancier inschakelt die de software voor je audit en een eigen repository met ‘verified’ software aanbiedt inclusief ondersteuning en een garantie dat de software fit for purpose is. Dat is bijvoorbeel het business model van diverse commerciele aanbieders van LibreOffice of van partijen als Canonical die Ubuntu aanbieden met SLA.

    • Het puur juridische punt is dat zelfs als je zo’n dikke disclaimer in je voorwaarden hebt, je nog steeds onbeperkt aansprakelijk bent bij opzettelijk toegebrachte schade. We vinden het moreel onacceptabel (art. 3:40 BW) om straffeloos opzettelijk anderen schade toe te brengen.

      Natuurlijk kunnen fouten gebeuren, maar dat is geen argument bij opzettelijk toegebrachte schade. Ik kan per abuis op je tenen stappen, dat rechtvaardigt toch ook niet dat ik je opzettelijk keihard op je grote teen stamp?

      • Ik begrijp dat je aansprakelijk bent. Maar de vraag is vervolgens wat voor schade je kan eisen als benadeelde. Doorgaans is het zo dat als je schade lijdt je wel zelf ook alles in ’t werk gesteld moet hebben om (vervolg-)schade te voorkomen.

        Wat mij betreft had de benadeelde partij dus sowieso al moeten nadenken over hoe ze het risico in zouden dekken dat die software het een keer niet goed zou doen. Het feit dat die partij dat klaarblijkelijk niet gedaan heeft (anders was er geen schade te eisen) doet mij denken dat ze daarom nu ook geen schade vergoed zouden moeten krijgen.

        Onderbouwen met de wet kan ik het in dit geval niet. Het kan natuurlijk zijn dat de wet in deze glashard is of niet matcht met mijn (rechtvaardigheids-)gevoel. Such is life 😉

        • “Alles in het werk” is nogal hard geformuleerd, je moet het redelijke hebben gedaan en dat is een lagere lat. Uiteindelijk is en blijft het wel jóuw onrechtmatige daad, dus dan tegen het slachtoffer zeggen “ja hee je had meer moeten doen” is eigenlijk zelden een acceptabele reactie. In het algemeen risico’s indekken is een terecht argument, maar had je dan deze sabotage-lus ook gevonden? Had je dit móeten vinden?

          Het voelt voor mij wel een heel onverwacht iets, alsof je virusscanner ineens een cryptominer zou krijgen om een bizar voorbeeld te noemen. Moet ik bij updates van Norton dan steeds kijken of er zo’n ding in zit? Of zeggen we dat dat onredelijk is en dat Norton dat gewoon niet moet doen?

          • Het redelijke is echter in mijn ervaring een lat die de ruime meerderheid ook niet gaat halen. Ik ken een handje vol partijen die private repositories hebben van alle packages die ze gebruiken en deze (licht) vertraagd updaten om ‘de markt’ eventuele bugs te laten ontdekken en verder alleen kritieke beveiligingsupdates fasttracken.

            De rest werkt vanuit de standaard package repositories npm, PyPi, pip, nuget of zelfs trunk/master branches op Git. Die partijen doen helemaal niets heb zelfs meegemaakt dat software stopte met werken omdat er automatisch een update met een API change was binnengehaald. bBlijkbaar deed die partij niet eens aan automated testing/CI!

            En dan vind ik het of het nu door een foutje of een bewuste actie van de auteur van een pakket komt dat je gewoon zelf verantwoordelijk bent. In dit geval had een infinite loop in je automatische testomgeving ontdekt moeten worden, anders test je niet voldoende. En dat is jouw eigen verantwoordelijkheid!

            • Je hoeft niet eens een eigen private repository bij te houden. Het zou gewoon standaard moeten zijn dat in je productiesoftware alle package-versies zijn gelockt op een specifieke versie. Uiteraard is het wel belangrijk om een (eventueel geautomatiseerd) proces te hebben om zeer snel package-updates naar productie te brengen. Een issue als nu in Colors.js geïmplementeerd zou zelfs de meeste domme geautomatiseerde teststraat eruit filteren. (Waarschijnlijk door enorm hard te crashen in dit geval)

              Ergens ben ik blij met de actie van Marek. Het zorgt ervoor dat gebruikers van software-repositories welke slecht tot niet worden geaudit een goede wake-up call krijgen. De actie van Colors.js is destructiever dan het had hoeven zijn (zie het leftpad debacle, deze was een stuk minder destructief) maar ook lang niet zo destructief als het had kunnen zijn (zie de link in de eerste post van Niels) Mijn reactie zelf is geweest om alle dependencies van mijn NodeJS projectje te verwijderen zo ver dat kan. Van ~200 dependencies (die voornamelijk meekomen als een hele boom aan dependencies van andere paketten) ben ik nu terug naar ééntje. Security meldingen van Github zijn allemaal gelijk afgesloten op deze manier en het project is van 1,5MB naar 215KB gekrompen.

              Het mooie van deze hele actie is dat (voornamelijk na het leftpad debacle) libraries als Colors.js juist gebruikt werden als voorbeeld van nutteloze dependencies, beveiligingsrisico’s en luie ontwikkelaars. Elke fatsoenlijke programmeur kan de leftpadd library in één minuut schrijven in een regel of 3, de Colors.js library zal misschien een kwartiertje onderzoek vergen naar ANSII codes, daarna ben je in een paar minuten klaar met een regel of 15 aan code.

    • Zelfs al zou er een bepaald patroon zijn dat de auteur van deze software te vertrouwen is, kies je er als gebruiker van de software wel voor om deze licentie als zodanig te accepteren. Als je die licentie als zodanig accepteert hoort daar voor mij ook bij dat je procedures inregelt waarmee je je indekt voor het geval dat de software toch een keer niet fit for purpose is. Als je dat als bedrijf allemaal niet doet, heb je wat mij betreft pech als het dan toch een keer mis gaat; dan had je maar een manier moeten bedenken om je wel in te dekken.

      Als prive- en (zeer) kleine zakelijke gebruiker, niet in de IT, met een positieve instelling ten opzichte van OS ben ik het niet met je eens.

      Hoe moet ik dat in hemelsnaam allemaal checken? Als ik dat zou moeten doen kan ik net zo goed commerciele software nemen, al dat checken kost veel te veel tijd/geld en documentatieinspanning.

      Dan schiet de OS gemeenschap zichzelf in de voet. De achtergrond van OS is gemeenschapszin. Bewust software aanpassen met kritische fouten past in het geheel NIET in de spirit van OS, daar hoef je dus ook niet voor te checken. Ja, de licentie is zo, dus de ontwikkelaar is juridisch gedekt tegen fouten. Maar het past niet in het algemene wereldbeeld dat bij OS hoort, namelijk van goedwillende mensen.

      Het is eerder de OS gemeenschap die zo’n individu moet opsporen en virtueel lynchen. Het feit dat er een vandalist rondloopt in de OS wereld vind ik op zich al vervelend. Maar dat de OS gemeenschap daarover zijn schouders ophaalt, dat schaadt mijn vertrouwen in OS nog veel meer.

  4. Wie is hier nalatig? Ik denk dat ieder bedrijf moet weten dat er in (updates van) libraries bugs zitten – bedoeld of onbedoeld. Als je daar niet naar handelt (je installeert automatisch ongetest de nieuwste versie in je productieomgeving) ben je toch echt nalatig bezig. Je neemt daarmee bewust risico’s.

    Kom je dan met de gang naar de rechter weg met ‘ja, maar hij heeft opzettelijk de nieuwe versie kapot gemaakt’? Lijkt mij te kort door de bocht. Je moet weten dat zoiets altijd kan gebeuren, al is het meestal per ongeluk. Wie de billen brandt, moet op de blaren zitten.

  5. Arnoud, Als die meneer Marak nou boven dat regeltje code had gezet “/* #Enter loop to test possible vulnerability due to timeout */” (of iets dergelijks van gelijke strekking), en hij had daarna gezegd “Oops per abuis mijn development code gepusht”, zou hij er dan mee weg zijn gekomen? Of zou het dan nog steeds grove nalatigheid of zo zijn geweest?

    • Dan wekt hij de indruk dat het een slordige fout was, en dus geen opzet. Maar zijn doel wás opzettelijk schade toebrengen, hij was immers boos en wilde de profiteurs straffen. Dus of je het bewijs rondkrijgt wordt dan de vraag. Had hij dan parallel een blog geplaatst met daarin een bekentenis, dan had dat natuurlijk gewonnen van die comment.

      Zonder bekentenis had ik als groot bedrijf een deskundig programmeur erbij gehaald en gevraagd “is deze regel code ook maar énigszins relevant voor de gestelde functie uit de comment”. Omdat er dan a) 666 in de init staat (terwijl je normaal bij 0 begint) en b) hij expliciet loopt naar forever en c) er geen body is, zal deze deskundige zeggen dat iedere programmeur moet weten dat dit een busy infinite loop is die geen redelijk doel dient.

          • Niet helemaal. Een infinite loop ís inderdaad de meest makkelijke manier om een timeout te veroorzaken en het gebruik van een grappig nummer is helemaal niet vreemd. Het argument kan inderdaad ook nog zijn dat je eenvoudig kan zoeken naar 666 of zelfs een automatische softwaretest draait die ervoor zou moeten zorgen dat code met 666 nooit naar productie moet kunnen gaan (die blijkbaar niet goed werkte, dat was eigenlijk nooit zo goed getest… Kan gebeuren.). Ik vind het aardig steekhoudend eigenlijk. Ik ben wel vreemdere dingen tegen gekomen in testcode (dat is een understatement, een heel groot understatement) en voor een klein projectje zoals colors.js is het helemaal niet vreemd dat je proces om het naar productie te krijgen bestaat uit ‘git push’.

            Samen met de ontevredenheid die de ontwikkelaar op andere platformen heeft geuit (en in dit geval ook nog wat andere zaken in de broncode van Colors.js) maakt bovenstaand argument uiteraard een stuk minder houdbaar maar wat Franc zegt is zeker geen onzin.

  6. Arnoud

    Ik vind dat zo gek nog niet (de 666) in testcode. Niet dat ik iets heb met 666, ik zou eerder 456 nemen of 789, maar bij debuggen is dat wel onmiddellijk duidelijk. Dat kan redelijk wat tijdwinst geven bij debuggen. (Kan ook met naamgeving, maar die zie je niet in alle debugscenario’s, bv. bij IOT toepassingen)

    De licentiecode aanpassen lijkt me wel zoveel handiger voor zijn actie, zeker als je eerdere versie van het openbaar versiebeheer kan weghalen. –> De kans is groot dat iedereen zonder nadenken de gelicentieerde code gaat gebruiken.

  7. Ik maak software en maak deze gratis beschikbaar voor een wijd publiek, omdat ik een Discordianist ben. Mijn (onherroepelijke) fouten worden onderdeel van andere code, en dit geeft mij een zalig gevoel. Ik roep in de disclaimer altijd dat het een leerproject is (open source gebruik ik om te leren, niet om professioneel te bouwen wat ik al ken), dat ik niet verantwoordelijk ben voor bugs, en dat alle mogelijke schade op mij te verhalen gelijk staat aan de verkoopprijs van de software en diensten (0 dollar). Stel, een groot bedrijf neemt die code over, repareert de bugs, maar contribueert niets terug, dan ben ik pissig en beledigt in mijn geloof. Stel, een leger van een groot land neemt die code over en gebruikt het om te inventoriseren of surveilleren, of men doet kankeronderzoek ermee. Dan wordt ik zenuwachtig, en ontstaat druk om de code niet meer uit te breiden met nieuwe (minder-geteste) functionaliteit.

    Marak is duidelijk een Satanist, gegeven zijn voorkeur voor het nummer 666. Ikzelf prefereer 23 en 5 en Ramanujan’s Taxi nummer, vallen in huidige samenleving wat minder op. Ik mag echt hopen dat bedrijven geen poot om op te staan hebben. Hier is THIS SOFTWARE IS PROVIDED AS IS voor bedoeld. Opensource geeft je de vrijheid om een weekend dronken te besteden aan het pushen van een nieuwe versie, en er dan op maandagavond achter te komen dat je software niet meer installeert op Windows, en dat na te laten tot een dinsdag. Grove nalatigheid? Absoluut! Maar ook grove nalatigheid om je software niet zelf te schrijven en uit te besteden aan een hongerige anonieme Bulgaarse IT student. En jij wordt ervoor betaald, en ik niet.

    Maker van open-source schaakprogramma, saboteerde zijn laatste release met een notitie dat schaken een nutteloze tijdsbesteding is die kostbare tijd steelt van slimme mensen. Alles weg, inclusief historisch gespeelde spellen. Zal wel een zenuwinzinking gehad hebben. Moet je die dan ook nog aansprakelijk stellen voor “geschepte verwachtingen” als een bedrijf zijn programma gebruikte voor een belangrijke taak, en nu enorm last had?

    Ik zie dit uiteindelijk als hotlinken van een plaatje, en dan het plaatje veranderen (ook veel gedaan, hahaha). Marek heeft een site met voorbeeldplaatjes die je kan gebruiken bij website ontwerp. Hij heeft ook een betaalde service, waar grote commerciele website ontwerpers gebruik van kunnen maken, maar die doen dat lekker niet, die hotlinken gewoon, en imponeren daarmee haar klanten. Marek is het zat, en veranderd die voorbeeldplaatjes in een foto van Lucifer die 5000pixels lang is. De commerciele website ontwerper staat enorm voor aap als zij een klant haar design wil laten zien.

    • Misschien wat genuanceerder. Vergelijken met open wetenschap. Marak pleegt fraude met de onderzoeksresultaten om de commercieele partij, die irritante plagiaat pleegt door nooit terug te citeren, op het verkeerde been te zetten. Beiden zitten dan fout. Marak vernield ook nog zijn reputatie als professioneel. Plagiaatpleger kan wel gelijk halen, maar alleen ten koste van meer aandacht aan eigen fouten. Uiteindelijk wint niemand, maar geef ik Marak meer voordeel van de twijfel: het was zijn spel, en zijn regels, en dan schuift er ineens een onbeschoft bedrijf met 1000+ werknemers aan de tafel.

      De stappen zijn niet zo groot van intentionele fouten bestraffen, naar open-source kaartmakers bestraffen voor foute resultaten of:

      Landkaarten maken is een tijdrovende bezigheid. En als de kaart dan eindelijk af is, loop je altijd het risico dat iemand de kaart kopieert en gaat verkopen. Heel vervelend. Om plagiaat tegen te gaan, bedachten kaartenmakers tientallen jaren geleden een slim trucje. Ze zetten een niet-bestaande plaats op de kaart. Doken er vervolgens kaarten op waar diezelfde fictieve plaats op stond, dan wisten ze dat die kaarten kopieën waren. — Agloe: Het verhaal van de plaats die niet bestaat

      Ik zie het als een glijdende schaal. Absoluut: Stel een open-source developer zet de kraan dicht, alle code in de release is exact nul, klaar ermee — alles weg. Dan is dat maar zo. As is. Jij was zo slim om die code onbetaald op een belangrijk telecommunicatienetwerk te zetten. Dat systeem onklaar is dus jouw schuld. Wil je contracten en garanties, betalen. Open source discrimineert niet op geloof, en iedereen, inclusief satanisten met een kort lontje, is welkom, niet alleen de grijze pakken met SLA drang.

      Ben je minderjarig, dan moet je vrij met open-source kunnen experimenteren, zonder legale klachten van legale afdeling groot bedrijf. Dat is goed voor later.

      • In een download-een-auto analogie: Marak heeft een boomgaard en een boom zonder hek bij de weg met twee bordjes “heerlijke appels om taarten mee te bakken. pluk ze gerust! maar eigen risico voor wormen enzo heh!” en “vindt u ze erg lekker, en werkt u bij een groot restaurant, dan hebben wij appelkeurders en grotere sappige appels en verse sla in de boomgaard voor een aantrekkelijk tarief.”. Marak ziet dat de kok van het grootste restaurant steeds vaker de appels keurt en plukt. Op een dag spreekt hij hem aan, wijst naar het tweede bordje, en de kok zegt, “nee joh, wij gebruiken appels uit eigen tuin voor onze taarten.”. De volgende dag is het niet de kok, maar de koksknecht.

        Een laakbare fout voor een professioneel: Marak plukt niet reeds de rotte appels weg, die taarten laten mislukken. Maar had je de SLA maar moeten aangaan. Een intentionele fout: Marak sproeit azijn op de appels, maar laat de bordjes staan. Het restaurant in het dorp krijgt een slechte beoordeling, omdat toevallig alle taarten mislukken. Marak wekt verwachtingen, maar misleid, en berokkend moedwillig schade. Maar wat vaker gebeurd: Marak gaat failliet, de boom bij de weg kaalgeplukt, en de boomgaard verlaten.

    • Hier is THIS SOFTWARE IS PROVIDED AS IS voor bedoeld. Opensource geeft je de vrijheid om een weekend dronken te besteden aan het pushen van een nieuwe versie, en er dan op maandagavond achter te komen dat je software niet meer installeert op Windows, en dat na te laten tot een dinsdag.

      Nee dus.

      Het is bedoeld ervoor dat mensen niet twee, of drie, of honderd, keer onafhankelijk van elkaar het wiel hoeven uit te vinden. Niet om alle wielexperimenten en halfklare wielen maar langs de kant van de weg te dumpen.

      Opensource heeft de gemeenschap als uitgangspunt, waar mensen naar eer en geweten aan bijdragen. Open source is niet bedoeld als verantwoording voor het individu om met onderdoordachte experimenten de omgeving te vervuilen.

      • Open source is niet bedoeld als verantwoording voor het individu om met onderdoordachte experimenten de omgeving te vervuilen.

        Misschien niet bedoeld, maar nog steeds welkom. Ik zie Open Source minder als gratis vorm van professionele software-ontwikkeling, en meer als vrije meningsuiting. Jij hoeft niet te luisteren, en sprekers hoeven zich niet aan voorgeschreven grammatica te houden.

        Ik heb echt populaire software (1000+ installs per maand) die op deze manier ge-update wordt. Vrijdagavond beginnen, en zondagavond de nieuwe versie van de grond af herschreven. Dan staat er nog “bill gates de anti-christ” in het installatie-script voor Windows, die ben ik vergeten weg te halen, toen de installatie natuurlijk weer eens brak voor Windows, en eigenlijk wil ik alleen Linux supporten, maarja, gemeenschapszin zegmaar.

        Als open-source mij die vrijheid niet geeft. De klant wordt echt koning zegmaar. Ik moet de testnamen vervangen door saaie Bugs Bunny characters, om maar niemand te beledigen. Dan koopt het maar lekker commercieele meuk. Mijn favoriete open-source licentie is overigens https://en.wikipedia.org/wiki/WTFPL staat niets over ondoordachte experimenten die niet bedoeld zouden zijn. Ik doe lekker wat ik wil, onverantwoord, en jij, mits volgend de licentie, wat jij wil. Klaar. Halfklaar wiel vernield de auto van de baas? Misschien niet mekkeren over de wielen van een ander, als jij, professioneel wielenmaker, niet weet waar je gratis goede wielen kan vinden, of zelf goede wilt maken.

        Iedereen is welkom in open-source. Zelfs met een kromme spaak.

        • Iedereen is welkom in open-source. Zelfs met een kromme spaak.

          Nee, alleen mensen die naar eer en geweten willen bijdragen (en daarin natuurlijk fouten mogen maken en zich mogen vergissen), niet mensen die alleen of hoofdzakelijk op zoek zijn naar een podium om marginale meuk te dumpen.

          Die kromme spaak maakt niet uit. Zolang het wiel maar vooruit draait.

          Onze views over open source zijn alleen verenigbaar als je het over rationele gemeenschapsgezinde individuen hebt. Het lijkt alsof jij vindt dat de belangen van de ontwikkelaar om zijn spul in de ‘pool’ te gooien zwaarder weegt dan het belang van iedereen om de ‘pool’ netjes en bruuibaar te houden.

          Ik zie jouw standpunt wel (en ik had dat nooit eerder zo gezien tot deze discussie) en ik respecteer jou standpunt, maar ik sta er anders in.

          • ik had dat nooit eerder zo gezien tot deze discussie

            Ik eigenlijk ook niet, dus bedankt daarvoor! En excuses beste mensen voor enige spelfouten.

            Het ideaal is natuurlijk dat de maatschappij tezamen helpt om sneller, betere, complexere software te schrijven, en daar ben ik het dan ook hartelijk mee eens. Maar ergens is de “dependency hell” onterecht een probleem geworden van ontwikkelaars. En echt samen schrijf je open-source software niet. Duizenden developers gebruiken het om goed-ogende software mee te maken, als een soort plug-and-play benadering. Ze doen er kritische dingen mee, waar je zelf van denkt: “daar zou ik deze software nooit voor durven gebruiken”, omdat de 300 sterren van plug-en-play developers die misschien 10 minuten naar je software hebben gekeken een waan van autoriteit geven. Het is niet eens software schrijven om de geldstromen van politici na te gaan, het is voortgang laten zien aan investeerders die je 75 miljoen hebben gegeven, om meer persoonlijke data te delven. Misschien 3 mensen die meewerken aan je software, omdat zij werkelijk ontslagen worden als jij dronken iets pushed op zondagavond, en ze dat klakkeloos overnemen.

            Het is dus veel meer een podium, met duizenden consumenten, die niets bijdragen dan een ster soms, of een bug aankaarten. Meer zoals Twitter dus. Stel, ik heb duizenden volgers, en ik schaap de verwachtingen dat ik een grappig account ben dat je best op je werk kunt lezen, tijdens de koffiepauze. En op een dag ben ik boos, en Tweet ik “Kut met peren!” en krijgen duizenden mensen last van waarschuwingen voor pornobrowsen van de IT afdeling. Ik had dat kunnen weten, laatste Tweet was nog zo’n schattig katje met hartjes enzo. Werk ik nu voor een bedrijf als sociaal media influencer, of heb ik sponsors, ja die hebben iets met contractbreuk. Jij zit met de gebakken peren. Zo zie ik open source. Gebruik best mijn grappen, maar als iemand boos op je wordt, jammer dan!

            Hier vind ik het wel een beetje misleiding, en juridisch gezien zeker niet de weg om te gaan (wat als je kritieke communicatienetwerken platlegd?!). Er zijn aan meningsuiting ook grenzen. Altijd vrijwillig de kinderen laten oversteken, en op een dag de auto’s in de vijver laten rijden, omdat de burgemeester niet betaald, is geen rechtmatige daad. Daarom, in plaats van een corrupte World Health Organization, zou ik graag een World Source Organization willen zien. De diensten van landen zijn dan direct concurrenten om veiligheidsbugs op te lossen. Makers van maatschappelijk nuttige software kunnen dan in dienst van de overheid treden, en voor een volle baan betaald worden. Universiteiten kunnen meer betrokken worden. Een hoop gedoe, maar mijn inziens ideal om naar het ideal te groeien, in plaats van steeds meer te vertrouwen dat het reeds realiteit is. Marak heeft slechte reputatie, maar developers klagen over Marak en geven toe dat hun werk is gebouwd op andermans puzzelstukjes achtergelaten door iemand met slechte reputatie.

          • Ik heb overigens ooit een drol van een programma geschreven, zeer experimenteel en ondoordacht, waarschijnlijk tientallen developers ter wereld die er misschien iets aan hadden. Het werkte, zoals iemand in Feyenoord zich in het zweet werkt door telkens achter de bal aan te rennen. Het maakte een conversie tussen programmeertalen, en daarbij moest het bestanden van de harde schijf deleten (of ik had daar hele functionaliteit/cache/weet u zeker? omheen moeten schrijven, en daar had ik echt geen zin in of tijd voor). Lang zitten twijfelen of ik die keutel nu moest openbaren, en uiteindelijk toch maar gedaan, met waarschuwingen en verwijzingen naar het gedeelte dat bestanden verwijderd.

            Een Chinese PhD student nam die code over, en gebruikte het tijdelijk om de juiste complete functionaliteit aan te kunnen bieden, en de conversie te begrijpen. Toen zijn project populair werd, kwamen er bijdragen die mijn code in de steigers zetten. Ik vond dat erg gaaf en ook een ideaal aan open-source. Laatst nog dat project gebruikt en veel tijd gewonnen. Zonder die kromme spaak, die misschien wel achteruit draaide, had ik dat wiel opnieuw moeten uitvinden. En de PhD student had misschien gedacht dat een auto niet haalbaar zou zijn. Totdat hij mij langs de kant van de weg ziet staan, en weet dat er meer mensen in autos geïnteresseerd zijn.

          • Een grappige TV-show mag van mij een fictief account aanmaken op Twitter (Open Debate) of Github (Open Source). Maar ik heb problemen met aanpassen van Wikipedia (Open Encyclopedie) of fictieve papers (Open Science). Misschien ligt voor jou de grens hier anders?

            Voor een ontwikkelaar afhankelijk van open-source om snel, competitief te bouwen, moet je wel kunnen vertrouwen dat alles wat je gratis pakt door iemand met juiste motieven is geschreven. Ongangbare motieven schaden dan dat vertrouwen. Maar is dat vertrouwen geen illusie in de eerste plaats?

            Moet je in plaats van achter “fake news” aangaan, niet als journalist bij jezelf te rade of het nu zo nieuwswaardig is om Twitter af te struinen voor commentaar en drama? Journalisten gebruiken makkelijke onbetrouwbare bronnen, en klagen dan dat deze bronnen onbetrouwbaar zijn. Ga zelf op zoek naar betrouwbare bronnen dan, daar word je voor betaald. Prik door die leugens heen, en klaag niet over misleiding.

      • Voor spelfouten mag u de SLA aangaan :).

        Ik gebruik dit blog om Nederlands te schrijven, omdat ik lang in het buitenland woon. Het gaat al rap achteruit merk ik. Deze had ik ook al opgemerkt, maar de edit-functie van dit blog is niet gebruiksvriendelijk. Dat houdt me scherp.

        Ultrabrede geschepte verwachtingen zie ik dan maar als een fietser die geschept wordt door een auto.

        Maar vindt je dat die Christelijk-herboren maker van het schaakspelschilprogramma nu aansprakelijk is voor de onrechtmatige daad? Iedereen heeft wat meer last van zenuwinzinkingen dezer dagen.

        En “geschepte verwachtingen” heeft zo te zien maar een schaapachtig klein duwtje nodig om gangbaar te worden.

        Productbeschrijving kan gevolgen hebben voor garantietermijn Niet alleen de feitelijkheden in de productbeschrijving kunnen bindende gevolgen hebben, ook de geschepte verwachtingen kunnen dat doen. Staat er in de productbeschrijving te lezen dat het een ‘fantastisch televisietoestel is om Netflix in HD te kijken’? — 3 juridische aandachtspunten bij redactie productbeschrijvingen

  8. Okay, even terugkerend naar de discussie hier… Deze auteur heeft zijn eigen code gesaboteerd en ik vraag mij daarmee af of de open source licentie die hij heeft gegeven daardoor kan komen te vervallen. Immers, het is zijn eigen code. Als hij nu de licentie intrekt, moet dan al zijn werk van GitHub af en dus ook uit NPM?

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS