GitLab draait beslissing terug om trackers in software te plaatsen

GitLab komt terug op een omstreden beslissing om telemetrie in de applicatie te plaatsen. Het van origine Nederlandse bedrijf wilde JavaScript-trackers inzetten om te bekijken hoe gebruikers de applicatie gebruiken. Dat leidde echter tot veel kritiek.

GitLab kwam begin oktober met de eerste plannen en stuurde gebruikers op 23 oktober een e-mail waarin het aankondigde het privacybeleid daarop aan te passen. Nu schrijft GitLab op die beslissing terug te komen. GitLab was van plan om trackingsoftware te gebruiken om te kijken hoe gebruikers met de dienst omgingen. Dat was volgens GitLab nodig om 'sneller beter te worden'. Die software zou worden ingezet bij de services die door GitLab zelf werden gehost, en in de gelicenseerde producten. Gebruikers die zelf GitLab hosten, zouden geen trackers krijgen. Het zou gaan om 'JavaScript-snippets' die zowel open source als proprietary waren.

Het plan kwam op veel kritiek van gebruikers en klanten te staan, maar ook van GitLab-medewerkers zelf. Die stelden bijvoorbeeld dat het verzamelen van telemetrie altijd opt-in zou moeten zijn. GitLab heeft nu besloten het plan terug te trekken. "Op basis van veel feedback van klanten, gebruikers en de bredere gemeenschap hebben we de plannen teruggedraaid en de wijzigingen ongedaan gemaakt voordat ze actief werden", schrijft oprichter Sid Sijbrandij in een e-mail aan de gebruikers en een blogpost. Hij zegt ook dat GitLab 'zijn eigen kernwaarden niet volgde' door de gebruikers niet bij de beslissing te betrekken.

Sijbrandij schrijft ook dat GitLab ook in de toekomst in de producten geen telemetrie zet die gebruikersdata naar derde partijen stuurt. Het bedrijf zegt in de komende tijd te komen met een nieuwe strategie rondom het verzamelen van data, waarbij de gemeenschap wordt betrokken.

Door Tijs Hofmans

Nieuwscoördinator

31-10-2019 • 11:20

48

Submitter: MadEgg

Reacties (48)

48
48
19
5
0
28
Wijzig sortering
Gewoon als opt-in een optie geven om apps te tracken om zo de app te verbeteren heb ik geen enkel probleem mee. Mits ze ook open zijn indien ze data met een 3e partij delen.

Juist als dev kan dit erg veel bruikbare data opleveren. Zelfs Tweakers maakt heatmaps van gebruikers (Annomniem) om zo te leren van gebruikers.
Alleen hebben die heatmaps helemaal geen zin afhankelijk van waar je het voor wil gebruiken. Je ogen kijken naar een hele andere plaats dan je cursor. Les 1 van online marketing volgens mij :P Als je wil zien waar ze op klikken kan dat wel ja, mja dat kun je ook wel in je http logs zien aan het aantal pageviews en referers :+
Veel gebruikers laten de cursor de ogen volgen, omdat het vaak gebieden zijn waar ze verwachten te klikken of om bij te houden waar ze aan het lezen zijn.

Veelal onbewust en dus absoluut geen exacte data, maar het geeft wel indicaties over het gebruik.
Veel gebruikers schuiven de cursor buiten beeld omdat ze hinderlijk afleiden. Zeker op pagina's waar wat te zien en/of lezen is. Op z'n best wordt de cursor gebruikt bij het scrollen of zo, maar sinds de muis-wiel is dat minder relevant.
Fijn dat ze zo snel hebben geluisterd en het plan direct hebben ingetrokken in plaats van te proberen om het recht te praten. Ik geloof daardoor dat het een oprechte vergissing is. Natuurlijk hadden ze beter moeten weten, maar overal worden fouten gemaakt. Het gaat er om hoe je daar mee om gaat, en dit geeft vertrouwen.
Het is niet heel moeilijk om je voor te stellen hoe iemand op dit idee is gekomen, in andere delen van de software-wereld is het namelijk bijna standaard om je gebruikers te tracken.
Het zou gaan om 'JavaScript-snippets' die zowel open source als proprietary waren.
En dat is waarom ik het altijd over "Vrije Software" heb, ook al klinkt dat minder sexy dan "Open Source".
Open broncode is alleen de technische kant van "vrije software" en gaat voorbij aan de bijhorende filosofie van openheid en samenwerking. In de wereld van Javascript en scripted webapplicaties is zo'n beetje alles wat online gebeurt technisch gezien "open source". Maar als het niet ook vrije software is heb je er niet zo veel aan.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 14:57]

Ik geloof daardoor dat het een oprechte vergissing is. Natuurlijk hadden ze beter moeten weten, maar overal worden fouten gemaakt.
Sorry, maar dat is wel heel naïef denken, het gaat hier om een 8 jaar oude organisatie met bijna 1000 medewerkers die eigenlijk puur bezig zijn met software development. Als ze niet hadden geweten dat dit een slecht idee zou zijn na de kritiek op oa. MS over W10, dan hebben ze niets te zoeken in deze business!

Maar het alom bekende "It's better to ask for forgiveness then for permission..." steekt weer z'n kop op. Het voelt weer heel erg aan als de commercialisering van Sourceforge.
Ik zie het helemaal voor me, hoe de overleggen hierover tussen techneuten/vakspecialisten en de managers zijn verlopen:
Techneut: ja het is misschien handig, maar echt een slecht idee. Gebruikers vinden dit niet leuk.
Manager (kijkt op van zijn smartphone/laptop met Powerpoint slide of Excel tabelletje): maar we kunnen wel efficienter werken omdat we meer weten van de software, dat zie ik hier echt staan.
Techneut: ik zou het niet doen.
Manager: noem me dan nog een reden, zo erg is het toch niet?
Techneut: ja, maar.
Manager: okee, volgens mij moeten we het gewoon doen.
Techneut: ehm...

...en de rest is geschiedenis...
Ook toepasbaar op T-Mobile deze week trouwens....
Ik zie het wellicht anders...

Manager: We kunnen zo veel efficiënter werken, risico is acceptabel, wanneer kan je dit geïmplementeerd hebben?
Techneut: Donderdag...


De doorsnee techneut is echt niet zo ad rem en heeft vaak oogkleppen op. Het is er soms maar 1 in een organisatie die roept "Hoooo!" en als die even niet wordt meegenomen in een gesprek, een weekje ziek is of met vakantie, dan heb je de poppen aan het dansen...

@veltnet Ik weet exact wat je bedoelt en dat is niet alleen bij developers zo, maar het is ook zeer hoe je het brengt. Het issue is dat de meeste techneuten geen communicatie wonders zijn, waardoor ze veel te vaak als heel negatief worden ervaren als er kritiek is. Vaak mist dan ook een consistente motivatie voor die kritiek waardoor het al helemaal slecht wordt ontvangen. "Gebruikers vinden dit niet leuk." is namelijk niet bepaald een goede redenering "Gebruikers vinden dit niet leuk, omdat..." En als je vervolgens wat voorbeelden noemt dan wordt het als opbouwende kritiek ontvangen en als je vervolgens later gelijk blijkt te hebben dan zal men zeker vaker naar je luisteren.

[Reactie gewijzigd door Cergorach op 23 juli 2024 14:57]

Inderdaad, en als je als developer gaat doorvragen over dit soort issues dan wordt je vaak als 'lastig' gezien.
Jammer dat veel personen dat niet gewoon kunnen accepteren en daardoor dus ook maar niks zeggen :p

Verschilt natuurlijk per persoon, organisatie en cultuur van die organisatie maar ik vind persoonlijk dat het veel IT collega's goed zou doen als ze leren om hun problemen zo te formuleren dat de managers het begrijpen.
Bij het vorige bedrijf waar ik werkte had ik hier veel last van. (totalitaire scrum-burocratie)
Managers begrijpen het wel maar vaak wordt scrum/agile als excuus gebruikt om het ergens in een backlog te plempen en er dan niet meer naar terug te kijken.
De productowner wil er niets aan doen omdat het op korte termijn geen waarde oplevert voor het bedrijf.
De CIO/securitypersoon/privacypief doet er niets mee omdat we die niet hadden (klein bedrijf)
Collega's doen er niets mee omdat dat programmeurs zijn (u roept, wij typen) en geen software engineers (geheel kunnen overzien en ook rekening houden met security, privacy en dat soort zaken)
Het leek dus eerder op het scenario van @zordaz : https://gitlab.com/gitlab-org/gitlab/merge_requests/14182

Met dank aan @iBugged voor de link
Dat is ook een mogelijk scenario ja. Inderdaad een beetje afhankelijk van de assertiviteit van de techneut. :)

[Reactie gewijzigd door zordaz op 23 juli 2024 14:57]

Ik ben een vrij idealistische developer, maar ook ik word gewoon overruled door mijn opdrachtgever (in mijn context ging dit over het scrapen van een site om userinfo te vergaren). Toen ik weigerde dit te implementeren werd een minder idealistische collega gevraagd.

Ook uitleggen waarom ik het niet vond kunnen hielp niet.

Management doet meestal niet aan ideologie, maar puur aan winstbejag :)
Zeker als je kijkt naar de kritiek die Github kreeg toen MS het gekocht had. Veel mensen overgestapt naar GitLab omdat ze daar niet zouden tracken.
Sorry, maar dat is wel heel naïef denken, het gaat hier om een 8 jaar oude organisatie met bijna 1000 medewerkers die eigenlijk puur bezig zijn met software development. Als ze niet hadden geweten dat dit een slecht idee zou zijn na de kritiek op oa. MS over W10, dan hebben ze niets te zoeken in deze business!
Ik ben het er eigenlijk wel mee eens, maar de rest van de wereld niet. Zo'n beetje iedere website bevat trackers, ook de website waar we nu op zitten. De telemetrie in W10 is anders (ik zeg niet beter of slechter) omdat het lokale software is en geen website. In het hoofd van mensen maakt dat op een of andere manier veel verschil.
De marketing & communicatie-mensen waar ik mee te maken heb kijken op een heel andere manier naar techniek en trackers. Die beweren vol overtuiging dat ze gebruikers natuurlijk niet gaan tracken maar dat ze alleen Google Analytics en een Facebook-knop hebben toegevoegd want dat geeft zoveel handige informatie.
Het is een slecht idee omdat de doelgroep heel anders is dan de doorsnee gebruiker en ze hebben geen dominante positie in de markt die niet kan worden opgevangen door de concurrentie. We hebben het over techneuten en ontwikkelaars, een heel ander slag dwaas dan de doorsnee internet gebruiker. ;-)

Marketing & Communicatie is inderdaad vaak een ander slag mens, maar dat ligt ook heel erg aan welke discipline ze gebruiken/aanhangen. Al ver voor het tracken van internet data werd immers reclame gebruikt en ook toen waren er een heleboel twijfelachtige technieken die danste met de illegaliteit...

Daarnaast hebben mensen oogkleppen op, ze zijn puur gefocused op hun 'ding' en besteden erg weinig aandacht aan anderen en andere zaken.
Tweakers heeft het meest sappige detail van dit verhaal niet beschreven.

Gitlab zelf was helemaal geen voorstander, zowel de engineers als de juridische afdeling van Gitlab zelf was fel tegenstander van het idee, en uiteraard de gebruikers ook.

Toen kwam de enorme hork van een CFO aan die zei: wat nou opt-in/out? Klanten/gebruikers hebben geen keuze, dit is een voorwaarde om ons produkt te gebruiken!

Zelfs nadat duidelijk werd gemaakt dat dit illegaal is (GDPR), zette hij gewoon door met zijn onkunde.

Het is dus niet Gitlab die niet bewust is van het gevaar van telemetrie, het betreft slechts een man.
Heb je hier een bron van?

@Fledder2000 Helemaal top! Ik zou je +3 geven als het kon.

[Reactie gewijzigd door Cergorach op 23 juli 2024 14:57]

Jazeker:

https://gitlab.com/gitlab...ests/14182#note_203849107

Wanneer de pagina opent moet je mogelijk een tijdje wachten tot deze naar de comment zelf springt.
Een vergissing kan je dit toch niet noemen? Dit was een doelbewuste beslissing. Je duwt niet per vergissing wat knopjes in en je hebt een tracking module en een aangepast privacy beleid. Daar kruipt tijd in, weloverwogen keuzes. Foute keuzes? Ja. Een vergissing? Nee, een foutieve inschattig in de impact die dit zou hebben zou ik zeggen. Een impact waarvan ik zelfs niet begrijp hoe je die foutief kan inschatten op dit moment.

In Open Source ga je helemaal niet voorbij aan de bijhorende filosofie. Die is namelijk onlosmakelijk verbonden met de term open source. Wat ook bestaat is zogenaamde "source available". Wanneer je broncode wel mag inkijken, maar de licentie je verder geen enkel recht geeft om er iets mee te doen.
In Open Source ga je helemaal niet voorbij aan de bijhorende filosofie. Die is namelijk onlosmakelijk verbonden met de term open source. Wat ook bestaat is zogenaamde "source available". Wanneer je broncode wel mag inkijken, maar de licentie je verder geen enkel recht geeft om er iets mee te doen.
Binnen de Open Source/Free Software wereld wordt dat begrepen. Daar buiten niet. Daar kijkt men helaas alleen naar het labeltje. Open Source => je kan de broncode zien, Free Software => het is gratis.
In het Nederlands kan ik het gelukkig over "vrije" software hebben zonder dat de meeste mensen denken dat ik "gratis" bedoel.
Maar als het niet ook vrije software is heb je er niet zo veel aan.
Wat versta jij onder vrije software? Moet het dan ook gratis zijn?

Naar mijn mening biedt open source proprietary software nog steeds diverse voordelen tov closed source proprietary software:
- je kunt de software eenvoudiger controleren (bijv op backdoors)
- je kunt vaak eenvoudiger wijzigingen maken (hangt af van licentie)
- je kunt vaak eenvoudiger add ons maken (omdat je de werking van de software beter kunt herleiden)
[...]
- je kunt de software eenvoudiger controleren (bijv op backdoors)
Dit is maar heel beperkt waar, aangezien je een versie van broncode kan bekijken en een vorm van "draaiende" code. Maar of die gelijk zijn dat is nog maar de vraag.

Bijv hier hadden ze al het plan om de trackers enkel in de draaiende web-site code te zetten en niet in de broncode.
Maar het kan ook zijn dat jouw compiler al een backdoor bevat waardoor broncode niet zoals standaard gecompiled wordt en er dus een backdoor in meegecompiled wordt.
Of dat er in de broncode gebruik gemaakt wordt van een speciale compilerbug waardoor er in de gecompileerde code een backdoor ontstaat.

En dat is als je al de tijd en de kennis hebt om de broncode daadwerkelijk door te gaan spitten (wat al slechts iets van 0,00001% van de gebruikers oid heeft, 1% zal wellicht de broncode doorzoeken op bepaalde dingen, maar compleet doorspitten dat gebeurt echt zowat niet)
Wat versta jij onder vrije software? Moet het dan ook gratis zijn?
Die vraag laat ik graag beantwoorden door de Free Software Foundation:

“Vrije software” is software die de vrijheid en gemeenschap van gebruikers respecteert. Het betekent grofweg dat gebruikers de vrijheid hebben om de software te gebruiken, kopiëren, verspreiden, bestuderen, veranderen en verbeteren. Dus “vrije software” gaat over vrijheid, niet over prijs. Om het concept te begrijpen, moet je denken aan “vrij” zoals in de “vrijheid van meningsuiting”. We noemen het soms ook “libre software”, waarbij we het Franse of Spaanse woord voor “vrij” gebruiken, om aan te geven dat we niet bedoelen dat de software gratis is.

Wij zetten ons in voor deze vrijheden omdat iedereen hier recht op heeft. Met deze vrijheden hebben de gebruikers (individueel en collectief) zeggenschap over het programma en wat het doet voor hen. Wanneer gebruikers geen controle over het programma hebben, noemen we dat een “niet-vrij” of “privaat” programma. Het niet-vrije programma heeft controle over de gebruikers, en de ontwikkelaar heeft controle over het programma; dit maakt het programma een instrument van onrechtvaardige macht.
De vier essentiële vrijheden

Een programma is vrije software wanneer de gebruikers vier essentiële vrijheden hebben:

- De vrijheid om het programma te gebruiken zoals jij dat wilt, voor elk doel (vrijheid 0).
- De vrijheid om de manier waarop het programma werkt te bestuderen, en om het aan te passen aan je behoeften (vrijheid 1). Beschikbaarheid van de broncode is noodzakelijk hiervoor.
- De vrijheid om het programma te verspreiden, zodat je anderen kan helpen (vrijheid 2).
- De vrijheid om het programma te verbeteren en te verspreiden, zodat de hele gemeenschap hier voordeel van heeft (vrijheid 3). Beschikbaarheid van de broncode is ook hiervoor noodzakelijk.

Van https://www.gnu.org/philosophy/free-sw.nl.html
Naar mijn mening biedt open source proprietary software nog steeds diverse voordelen tov closed source proprietary software:
- je kunt de software eenvoudiger controleren (bijv op backdoors)
- je kunt vaak eenvoudiger wijzigingen maken (hangt af van licentie)
- je kunt vaak eenvoudiger add ons maken (omdat je de werking van de software beter kunt herleiden)
Het is zeker beter dan closed source, maar dat je de broncode kan zien betekent nog niet niet dat je er iets mee kan. Het ligt, zoals je al zegt, aan de licentie. Vrije Software slaat op een groep softwarelicenties die bovenstaande zaken toestaan.
Wat versta jij onder vrije software? Moet het dan ook gratis zijn?
Zowel Free Software als Open Source zijn per definitie gratis:
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
De eerste zin is misleidend. De eis is dat er geen verbod op weggeven of verkopen in de licentie mag staan. Echter dit gaat je niet helpen om betaling af te dwingen. De 2e zin verbiedt dat namelijk expliciet. Royalties zijn feitelijk de enige manier om geld te krijgen voor software (in plaats van voor support / documentatie / manuren etc).
open source proprietary software
Bestaat niet. Als het Open Source is, is het per definitie niet proprietary.
Wat wel bestaat is 'shared source' proprietary software. Hierbij krijg je inzage in, maar geen rechten op, de broncode van de software. Onder andere Microsoft heeft een dergelijk programma voor overheden.
En dat is waarom ik het altijd over "Vrije Software" heb
Volgens mij is alle vrije software ook open source software, maar niet andersom. Dit kun je afleiden uit het feit dat de GPL (de licentie die door de Free Software Foundation wordt gepromoot) gewoon 1 van de licenties is in de lijst die het OSI bijhoudt.

Persoonlijk vind ik de term 'free software' nogal verwarrend. Feitelijk is de licentie minder vrij dan de meeste andere Open Source licenties. Zo stelt de MIT eigenlijk maar 1 voorwaarde aan het gebruik: de copyright statement en warranty disclaimer moeten meegebundeld worden. De GPL daarentegen stelt veel meer eisen. Onder andere dat eventuele wijzigingen en aanvullingen weer onder de GPL license beschikbaar gesteld moeten worden.

Overigens zijn zowel Vrije Software als Open Source software per definitie gratis. Dit is wellicht wat mij een beetje steekt aan de GPL; alle eisen worden gesteld aan developers. Wie de software alleen gebruikt hoeft helemaal niks te betalen of te doen, maar wie er wat bij bouwt wordt ineens aan allerlei voorwaarden gebonden. Ik zal zelf nooit GPL licensed software gebruiken in mijn projecten omdat ik niet het risico wil lopen dat straks ineens mijn hele project GPL licensed moet worden. Zo'n eis valt bij mij onder de noemer 'verplichting'... het tegenovergestelde van 'vrij' dus...
Volgens mij is alle vrije software ook open source software, maar niet andersom.
Correct.
Persoonlijk vind ik de term 'free software' nogal verwarrend. Feitelijk is de licentie minder vrij dan de meeste andere Open Source licenties.
<knip>
Dit is wellicht wat mij een beetje steekt aan de GPL; alle eisen worden gesteld aan developers. Wie de software alleen gebruikt hoeft helemaal niks te betalen of te doen, maar wie er wat bij bouwt wordt ineens aan allerlei voorwaarden gebonden.
Dat is precies de bedoeling en inderdaad is het GPL daarin totaal anders dan alle andere software-licenties. GPL is een hack die het systeem tegen zichzelf gebruikt. De meeste software licenties zijn er juist om eenzijdig de belangen van de ontwikkelaar te beschermen. Dat is leuk voor de ontwikkelaars, maar niet voor de gebruikers. GPL is de licentie waar gebruikers op de eerste plaats komen. GPL geeft vrijheid aan gebruikers, in tegenstelling tot zo'n beetje alle voorgaande licenties die alleen maar rechten van gebruikers wegnamen.

Ik snap best dat er developers zijn die geen zin hebben in GPL, zij zijn ook niet de doelgroep. Net zoals garantie goed is voor de klanten, en niet voor de fabrikant of winkelier.
Natuurlijk is het niet zo zwart-wit. Ik ben programmeur, maar ik ben ook gebruiker, en ik gebruik meer software dan ik in mijn hele leven zelf bij elkaar geschreven krijg. Zelfs als programmeur ben ik netto beter af met het GPL.
De meeste software licenties zijn er juist om eenzijdig de belangen van de ontwikkelaar te beschermen.
Bijna letterlijk vertaald uit de originele licentie tekst :+
Maar wie is 'de ontwikkelaar' als je het hebt over Open Source software?
Juist: de community
Bijna letterlijk vertaald uit de originele licentie tekst :+
Ik ben goed geïndoctrineerd :)
Maar wie is 'de ontwikkelaar' als je het hebt over Open Source software?
Juist: de community
Bij veel van dit projecten lopen ontwikkelaars en gebruikers door elkaar, maar om precies te zijn is het in deze context diegene die de auteursrechten heeft.
Bij veel van dit projecten lopen ontwikkelaars en gebruikers door elkaar
Tja, sorry maar dat vind ik als developer toch moeilijk om te geloven. 'Gewone' gebruikers kunnen gewoon niet programmeren. Klaar. En ik als dev. gebruik liever geen GPL omdat die voor mij alleen maar extra beperkingen betekent vergeleken met bijv. MIT of Apache etc. Ik snap die restricties ook niet echt; je geeft iets weg maar niet echt... alleen als jij ook iets weggeeft.. quid pro quo...

Mijn projecten zijn in de regel gewoon of MIT licensed of Creative Commons. Wat betekent dat je ze gewoon mag gebruiken, ook in je commerciële project.
"Free Software" gaat om vrijheid als filosofisch concept, niet om prijs. GPL is gericht op het behoud van vrijheid van de gebruikers, niet op het gratis weggeven van broncode aan programmeurs.
BSD beschermt de rechten van de programmeur. GPL beschermt de rechten van de gebruiker.
Tja, sorry maar dat vind ik als developer toch moeilijk om te geloven. 'Gewone' gebruikers kunnen gewoon niet programmeren.
Ik bedoel dan ook het omgekeerde, alle programmeurs zijn ook gebruiker. Zelfs als ze zelf aan de software werken die ze gebruiken wordt de meeste code waarschijnlijk door andere programmeurs geschreven. Grote software projecten zijn tegenwoordig altijd teamwerk.
En ik als dev. gebruik liever geen GPL omdat die voor mij alleen maar extra beperkingen betekent vergeleken met bijv. MIT of Apache etc.
GPL richt zich op gebruikers, niet op developers. Zolang je het vanuit het oogpunt van een developer blijft bekijken zul je het niet kunnen begrijpen. De beperkingen voor developers zijn rechten voor gebruikers.

Er zijn overigens argumenten die de Free Software Foundation zelf niet belangrijk vind maar sommige anderen wel. Zo zijn er een hoop mensen die het niet leuk zouden vinden als iemand anders hun werk opeens gaat verkopen. Zelf hebben ze het weg gegeven als goede daad of zo iets, en dan gaat iemand anders er geld mee verdienen zonder ooit iets terug te doen. De vraag is een beetje hoe vaak dat in praktijk echt gebeurt, maar de angst bestaat. Ik geloof dat een heel stel van de bedrijven die aan de Linux-kernel werken dat doen omdat ze er op vertrouwen dat het GPL de andere medewerkers eerlijk houdt en voorkomt dat iemand op een of andere manier alles inpikt of forkt op een manier waar de anderen niet in mee kunnen gaan.
Ik snap die restricties ook niet echt; je geeft iets weg maar niet echt... alleen als jij ook iets weggeeft.. quid pro quo...
Het gaat niet om weggeven. Het is inderdaad een quid pro quo, net zoals de bakker quid pro quo wil voor ik een brood mag meenemen. Gratis is niet hetzelfde als vrij. Slapen in een gevangenis is gratis, maar veel vrijheid heb je daar niet, dan kun je beter betalen voor een hotel.

BSD is een licentie voor developers die hun software gratis weg willen geven. Prima licentie verder, maar niet waar het GPL om gaat. GPL gaat om vrijheid voor gebruikers van tyranieke developers of overheden, niet om gratis broncode.
Toegang tot de broncode is een overeenkomst tussen GPL en BSD maar niet de kern. Voor BSD is verspreiden van de broncode het doel, voor GPL is het een middel.

De FSF wil voorkomen dat we in een wereld terecht komen die draait op geheime algoritmes* en black boxes die achter onze rug om beslissingen nemen over ons leven en waar we zelf niks aan kunnen veranderen zodat we volledig afhankelijk zijn van de goede wil van een hand vol developers (of hun bazen/aandeelhouders).

Als ik, als gebruiker en klant, software wil hebben waar ik mee vooruit kan, dan wil ik meer dan alleen de broncode. Dan wil ik ook toegang tot de compiler die nodig is om die broncode te compileren. Ook wil ik zelf de digitale handtekening kunnen zetten zodat de bootloader van mijn apparaat mijn eigen code net zo accepteert als de code van de oorspronkelijke developer. Liefst wil ik ook toegang hebben tot de documentatie. Ik wil niet hoeven nadenken over misschien patenten geschonden worden door die broncode waar ik rekening mee moet houden als ik het in mijn product zou willen gebruiken.

GPL probeert er voor te zorgen dat de broncode nuttig en bruikbaar is. BSD is een simpele dump van bits.
Mijn projecten zijn in de regel gewoon of MIT licensed of Creative Commons. Wat betekent dat je ze gewoon mag gebruiken, ook in je commerciële project.
Super, heel fijn, dank je voor werk!


* "Algoritmes?", denk je misschien, "dat is toch het moderne modewoord voor AI terwijl het GPL al 30 jaar oud is?". Dat klopt. Richard Stallman (de oprichter) heeft niet alleen een zeer vooruitziende blik maar ook een achtergrond in AI. Hij is een van de eersten geweest die door had dat "slimme" software een steeds grotere rol in ons leven zou gaan spelen en dat het een bedreiging voor onze vrijheid kan zijn als we daar geen controle over krijgen.
Ach, met wat additionele logica kan je ook prima vooruit met oldschool access logs analytics (bv pixel tracking).
Wil je niet trackable zijn, gebruik dan zo'n dienst niet , en/of stop met gebruik van browser-based diensten as a whole.
Ja, maar het analyseren van logfiles om te zien op welke knoppen ik geklikt heb en op welke pagina's ik geweest ben is wel een heel ander kaliber dan Javascript wat elke muisbeweging, elke toetsaanslag en elke scrollbeweging naar de server verstuurd. Dat eerste heb ik weinig moeite mee (als het door de dienst zelf gedaan wordt, niet door een grote advertentieboer als Google), dat laatste is in elke situatie niet acceptabel voor mij. Het zou best opt-in mogen, als ik af en toe een popup zou krijgen met het verzoek of mijn huidige sessie op die manier getracked mag worden wil ik daar best aan meewerken. Maar het moet niet de standaard zijn.
Gitlab is niet enkel online maar ook on-premise.
Naast dat dit gold voor Gitlab.com, wilde men ook dat dit ging gelden voor self-hosted Gitlab. Dat was al helemaal een stap te ver en vaak ook simpelweg niet toegestaan door regelgeving of policies.

Opmerkelijk was dat ontwikkelaars van Gitlab vraagtekens zetten bij deze telemetrietoevoeging en zich afvroegen of het uberhaupt mocht en of men het zou willen, maar Paul Machle hogerop bij Gitlab zei het volgende in een discussie hierover:

"I don’t understand. This should not be an opt in or an opt out. It is a condition of using our product. There is an acceptance of terms and the use of this data should be included in that."

Al met al sowieso een interessante discussie om te lezen: https://gitlab.com/gitlab...ests/14182#note_203849107.
Opmerkelijk transparant dit. Je ziet van het bedrijf welke personen welke insteek geven.
Toch best grappig, waar mensen juist van GitHub naar lab gingen vanwege de angst dat MS zulke praktijken zou gaan toepassen, was het dus Lab die dit juist wilde doen :P

Maar zoals ik nu die reacties lees, was het dus Sijbrandij zelf die als CFO dit hele zooitje ging overrulen en hiermee door zou zetten?
Our main mistake was that we did not live up to our own core value of collaboration by including our users, contributors, and customers in the strategy discussion and, for that, I am truly sorry
Dus eest overrule je elke zorg om dit door te zetten, tot het een backfire geeft en opeens veel spijt dat je je core values opzij hebt gezet?
Dit hadden ze van te voren kunnen bedenken en dit is geen vergissing. Er zijn vele issues inmiddels hierover op Gitlab die door Gitlab zelf zijn aangemaakt. In een van die issues is terug te lezen dat de CFO niet alleen engineers wil overrulen maar ook hun global compliance director. Dan is er toch wel iets goed mis met je management.

Gitlab heeft vele klanten die geen trackers kunnen toestaan zoals overheidsdiensten. Er staat een publieke comment tussen van één van hen die de enterprise editie heeft voor 50.000 gebruikers. Was een universiteit. Die geven heel hard aan onmiddellijk hun abonnement op te zeggen als dit door zou gaan. Verder nog meer comments van hun eigen account managers die hetzelfde melden van verschillende klanten.

Helemaal geen goede bedoelingen vergissing maar gewoon keihard centen tellen. Het is dat ze heel veel geld gaan verliezen als dit door zou gaan anders was het er gewoon in gekomen. Aan de gebruiker denken doen ze daar helemaal niet.
Dit is een van de problemen die organisaties hebben die hun boekhouders de macht geven. Er wordt dan alleen aan de financiële belangen waarde gehecht met als gevolg dat juist die dingen die het bedrijf waardevol maken voor zowel de werknemers als de klanten ineens weggewerkt worden. Meestal gaat het dan ook snel bergafwaarts met zo'n bedrijf.

[Reactie gewijzigd door CrazyJoe op 23 juli 2024 14:57]

Het geeft vrij veel aan over hun manier van werken. Ik draag Gitlab een warm hart toe, maar zeker als bedrijf moet je je wel even achter de oren krabben over of je wel met een partij als Gitlab wil samenwerken. Zowel qua juridisch inzicht, als in hun beleidsvormingsproces, als in gevoel voor wat klanten willen, als qua communicatie zijn ze hier volledig de mist in gegaan. En hier ga je als bedrijf dan je kroonjuwelen stallen.
Tja, we moesten allemaal overgaan van GitHub naar GitLab na de overname door Microsoft, want het was er toch zoveel beter en Microsoft was niet te vertrouwen. Wat een belachelijk gedoe was het toen.

En, naar welk platform gaan we nu gaan?

Vond het toen al belachelijk dat zovele een migratie gingen maken naar GitLab omdat "Microsoft niet te vertrouwen is". Het was toen opvallend stil toen Alphabet (moederbedrijf van Google) een investering maakte in GitLab (inmenging??). Ze gingen plots van Microsoft Azure naar Google Cloud Platform, maar dat was allemaal dik oké... veel betrouwbaarder? Nu komen ze er ook mee weg door een beslissing terug te draaien. Hypocriet toch, of was het gewoon toen weer Microsoft bashen en accepteren we van andere veel meer? |:( :+ :Y)

[Reactie gewijzigd door MrAndy9797 op 23 juli 2024 14:57]

CVS ?

;) :+
Kan je het ook inhoudelijk reageren? Laat het anders, want je ontwijkt de inhoud precies. Geeft toe dat het wel allemaal een beetje vreemd gelopen is. Van de ene partij wordt meer geaccepteerd (ondanks hun verleden) dan van anderen, en dat vind ik wel opvallend...
CVS is een versioning systeem wat ik nog steeds moet ondersteunen, ondanks dat het al zo'n 30 jaar oud is en niet meer ontwikkeld.

Het was dus een geintje.

Bij GitLab heeft men weer het voordeel bij twijfel teruggewonnen door actie te ondernemen en excuses aan te bieden.

Gebruik hier zelf de Community versie van GitLab, want zoals gemeld, CVS is echt oud en aangezien alles tegenwoordig via een web browser moet gebeuren, werd er van mij verlangd om GitLab uit te gaan proberen.

GitLab is op zich vrij aardig in elkaar gezet, maar zo geweldig vind ik de web-interface nou ook weer niet.
Maar dat kan ook meer te maken hebben met mijn aversie tegen web-interfaces in het algemeen (niet de look, maar de sloomheid ervan).

GitHub en consorten zijn voor mijn doeleinden compleet uit den boze, dus is on-premise een verplichting.
GitLab zit wel bomvol met functionaliteit, maar er zijn genoeg alternatieven. Er zijn dus mogelijkheden om GitLab links te laten liggen als je geen vertrouwen meer hebt in dat project.

Alternatieven:
Gitea - https://gitea.io/en-us/
GitBucket - https://github.com/gitbucket/gitbucket/releases
Gogs - https://gogs.io
Gitolite - https://gitolite.com/gitolite/index.html
GitBlit - http://gitblit.com
RhodeCode - https://rhodecode.com
GitPrep - http://gitprep.yukikimoto.com
Savannah - https://savannah.nongnu.org/projects/administration
KalliThea - https://kallithea-scm.org

Of deze, in vergelijking met GitLab/gitHub, hetzelfde aan functionaliteit bieden, dat zul je zelf uit moeten zoeken. Kijk ik naar screenshots en demos, dan zien sommige alternatieven er echt wel interessant uit.
Anderen zijn simpeler, maar als dat je benodigdheden al dekt, dan is het ook goed natuurlijk.

Een aantal is zelfs direct in Windows te installeren (i.p.v. een container of virtueel). Mocht zoiets je interesseren.

Vroeger werd Google ook gezien als het vriendelijkste speler op internet. Daar is tegenwoordig niet zoveel meer van over. Veel van die goodwill is verhuist naar Microsoft en Apple. Hoe deze bedrijven door het publiek worden gewaardeerd, dat vereist dus continue werk. Dat geldt net zo goed voor projecten als deze.

Wie weet, GitHub heeft misschien al vaker zich van een vervelende kant laten zien dan GitLab.
Anoniem: 1248170 31 oktober 2019 11:27
Wat had je zelf verwacht, dat men dit met open armen ontvangt.
Mooi ook de manier waarop het terug gedraaid wordt, in de toekomst geen trackers die data naar derde sturen. Dus met andere worden die trackers komen er gewoon alleen zullen ze niet van derde partijen zijn en zal de data alleen naar GitLab gestuurd worden. Wat er daarna met de data gebeurt... voor analyse kan het als nog zo maar worden door gestuurd naar een derde partij want een stuk goedkoper dan zelf een oplossing daar voor bouwen en beheren.

Ik snap alle ophef niet zo, het gaat het bedrijf er gewoon om om bij te houden hoe mensen de website gebruiken waar klikken ze waar zijn ze naar op zoek en wat werkt wel of juist niet goed in de interface. En omdat soort dingen uit te vinden wil je als het even kan (en dat kan dus ook gewoon) van alle klanten weten hoe ze de site gebruiken niet alleen van de mensen die beseffen dat het de moeite waard is om dit soort data met een site die ze regelmatig gebruiken te delen.
De (f)ophef rond het gebruik van een tracker is in mijn ogen dan ook gewoon onzin, zo lang de tracker puur en alleen gebruikt wordt om bij te houden hoe mensen de site gebruiken is het echt geen probleem. Als men dit ook gebruikt om bijvoorbeeld Google, Facebook en al hun partners van dit soort informatie te voorzien is dat een iets ander verhaal. Maar een tracker is voor een site veel al een zeer goedkope en toch zeer waardevolle toevoeging aan het ontwikkelingstraject van een product. Je kunt immers zien wat wel en niet gebruikt wordt welke dingen meer aandacht verdienen en welke gewoon goed werken.

Het probleem met feedback van klanten is dat je eigenlijk alleen maar negatieve feedback krijgt, en als je al positieve feedback krijgt is het veel al zo algemeen dat het leuk maar nutteloos is voor het bepalen of bepaalde dingen goed werken of niet.

Op dit item kan niet meer gereageerd worden.