Bitwarden maakt gebruik van sdk met niet-vrije licentie in client - update

Gebruikers op GitHub ontdekten dat de desktopclient van de opensource wachtwoordbeheerder Bitwarden afhankelijk is van een software development kit die geen vrije software is. Bitwarden-cto Kyle Spearrin zegt dat de sdk en client als gescheiden programma’s moeten worden gezien.

De kwestie kwam aan het licht via een pull request waarin een nieuwe dependency, 'bitwarden/sdk-internal', werd geïntroduceerd. De licentie van deze sdk bevat een beperking: ontwikkelaars mogen de sdk niet gebruiken voor toepassingen buiten het Bitwarden-ecosysteem of voor de ontwikkeling van alternatieve sdk’s. Verschillende gebruikers op Github reageerden negatief op het nieuws.

In een reactie verklaarde Kyle Spearrin, de oprichter en cto van Bitwarden, dat de sdk en client als gescheiden programma's moeten worden gezien die via standaardprotocollen communiceren. Volgens hem blijft dit in lijn met gpl-compatibiliteit. De huidige problematiek bestempelt hij als een bug die zal worden opgelost. Het bedrijf heeft later via sociale media nogmaals gezegd dat het 'toegewijd blijft aan het opensourcelicentiemodel' en dat het hier gaat om een packing-bug. De discussie op GitHub is inmiddels beperkt tot alleen medewerkers.

Correctie, 13.13 uur - Aanvankelijk stond in de titel van dit artikel dat de gebruikte sdk 'closed source' is. Dat klopt echter niet. De broncode van de sdk is openbaar, hoewel deze een licentie bevat die gebruikers verbiedt om de sdk te gebruiken in combinatie met andere software dan Bitwarden, of voor het ontwikkelen van eigen sdk's. Dit is verbeterd.

Hi Josh, It seems like a packaging bug was misunderstood as something more, and the team plans to resolve it. Bitwarden remains committed to the open source licensing model in place for years, along with retaining a fully featured free version for individual users

— Bitwarden (@Bitwarden) 20 oktober 2024

Reacties (77)

[djoelzz]

Vooropgesteld: ik ben geen hardcore IT'er met kennis van beveiliging. Als doorsnee gebruiker van Tweakers mis ik in dit artikel wel wat context. Wat is nu eigenlijk het probleem en waarom? Dit mag voor mij wat uitgebreider worden toegelicht in het artikel zelf, zonder dat dit uit de community moet komen in de reacties.

[Verwijderd]

Admin-edit:

Let op: door Ai gegenereerd antwoord met potentieel onjuiste informatie

Het artikel beschrijft een situatie waarin Bitwarden, een populaire opensource wachtwoordbeheerder, gebruikmaakt van een gesloten broncode (closed source) software development kit (SDK) in hun desktopclient. Dit heeft tot enige onrust geleid binnen de community van opensourcegebruikers. Ik zal proberen uit te leggen wat het probleem is, waarom dit belangrijk is en waarom het tot discussie leidt.

Wat is het probleem?
Bitwarden is een opensourceproject, wat betekent dat de broncode voor iedereen beschikbaar en controleerbaar is. Veel gebruikers kiezen voor opensourceprogramma’s vanwege de transparantie en de mogelijkheid om zelf de veiligheid en integriteit van de software te verifiëren. Echter, gebruikers op GitHub ontdekten dat Bitwarden nu afhankelijk is van een closedsource-SDK, wat betekent dat een deel van de softwarecode niet openbaar beschikbaar is.

De SDK in kwestie, genaamd 'bitwarden/sdk-internal', heeft bovendien een licentie die beperkingen oplegt aan het gebruik ervan. Zo mogen ontwikkelaars deze SDK alleen gebruiken binnen het Bitwarden-ecosysteem en niet voor andere toepassingen of voor het ontwikkelen van alternatieve SDK’s. Dit heeft tot kritiek geleid omdat het ingaat tegen de verwachtingen van volledige openheid en hergebruik die gebruikers van een opensourceproject hebben.

Waarom is dit belangrijk?
Voor veel gebruikers van opensourcesoftware is het van groot belang dat alle onderdelen van een programma transparant en controleerbaar zijn. Dit zorgt ervoor dat:

Veiligheid: Iedereen de code kan inspecteren en controleren op mogelijke kwetsbaarheden, fouten of zelfs achterdeurtjes.
Transparantie: Gebruikers kunnen precies zien hoe de software werkt en vertrouwen hebben in de werking ervan.
Vrijheid: De software kan worden aangepast of hergebruikt voor andere projecten of toepassingen.
Wanneer een deel van de code gesloten is, zoals bij deze SDK, kunnen gebruikers niet meer dezelfde mate van controle of inzicht uitoefenen. Dit kan zorgen voor een verlies aan vertrouwen, omdat ze niet kunnen controleren of deze code veilig en zonder verborgen risico’s is.

De reactie van Bitwarden
De CTO van Bitwarden, Kyle Spearrin, heeft verklaard dat de SDK en de client als twee gescheiden programma’s moeten worden gezien, die communiceren via standaardprotocollen. Volgens hem betekent dit dat de opensourceclient nog steeds voldoet aan de eisen van opensourcelicenties (zoals de GPL). Spearrin noemde het gebruik van de closedsource-SDK een "bug" die zal worden opgelost. Bitwarden gaf later ook via sociale media aan dat het bedrijf zich blijft inzetten voor opensourcelicenties.

Waarom de zorgen blijven?
Hoewel Bitwarden heeft beloofd deze situatie aan te pakken, blijven er enkele zorgen bestaan bij de gebruikers:

Gebrek aan controle: Zolang een deel van de software gesloten blijft, kunnen gebruikers het gevoel hebben dat ze niet de volledige controle over hun software hebben.
Potentiële precedenten: Als een opensourceproject begint met het introduceren van gesloten componenten, kan dit wantrouwen zaaien over de toekomst. Gebruikers vragen zich dan af of er in de toekomst nog meer gesloten delen zullen worden toegevoegd.
Communicatie: Sommige gebruikers vinden dat Bitwarden transparanter had moeten zijn over deze wijziging en eerder duidelijkheid had moeten geven over de situatie.

Conclusie
Kortom, het probleem draait om de spanning tussen het opensourcekarakter van Bitwarden en het gebruik van een gesloten SDK. Voor veel gebruikers van opensourcesoftware is volledige transparantie essentieel, en de ontdekking van een gesloten component heeft daarom zorgen gewekt over veiligheid en controle. Bitwarden heeft gereageerd en gezegd dat dit wordt opgelost, maar voor een deel van de community blijft het een punt van zorg dat ze niet direct zelf inzicht hebben in alle onderdelen van de software.

[Reactie gewijzigd door Bor op 22 oktober 2024 12:06]

[ajbu]

De uitleg is lang maar helaas klopt de uitleg niet, de source is wel beschikbaar op github maar licentie heeft een beperking voor het gebruik ervan. Er zijn veel open source licentie modellen en restricties maken het niet noodzakelijk 'closed'. Omdat de source beschikbaar is zal het gebruik bv. ook gewoon transparant zijn ondanks dat het niet voor andere doeleinden gebruikt mag worden

[hoeksmarp]

Als dat zo is, klopt de titel van dit artikel ook niet.

[EnigmA-X]

Dat is zo en de titel klopt inderdaad niet.

De definitie van "closed source" is dat de source code niet gepubliceerd wordt. De source code van het bewuste stuk "sdk-internal" wordt *wel* gepubliceerd en wel hier:

https://www.npmjs.com/pac...k-internal?activeTab=code

Update: @Stetsed hieronder heeft helemaal gelijk en... ik heb zelf niet goed gekeken. Hoewel het wel mogelijk is om van .js naar wasm te gaan, is dat hier niet het geval. Iets met aanname, de moeder van en het feit dat de .js zoveel groter was dan de .wasm.

Sommige stukjes van sdk-internal zijn dus "source available" en (een belangrijk stuk) is closed source (als in binary/compiled code).

[Reactie gewijzigd door EnigmA-X op 22 oktober 2024 20:11]

[Stetsed]

Alles is open-source als je assembly kan lezen /s.

Dit is well closed source, voor de internal SDK die jij hebt gelinkt is ook de source code niet beschikbaar. Ik heb effe door de package zitten te kijken en het lijkt erop dat het alleen een distributed compiled versie er van is(Als je de .JS file pakt zie je ook dat dit niet de source code is waar jij op wijste in de comment op @luxebenen) , niet de source code zelf.

Ik denk dat er hier twee dingen door elkaar gaan in deze thread ook, je hebt "Open Source" en je hebt 'Source Available'. De eerste is vaak geacepteerd met de definitie van het OSI(Open Source Initiviate[1]), dit betekent dat je (binnen mate) met de code iets mag, dit zagen we ook recent met WinAmp, ja je kon de code zien maar je mocht er niks mee want ze hadden eigenlijk "Je mag er mee aan developen.. maar meer niks".

Source available is hier ook niet van toepassing, want de source-code is niet toeganbaar het is duidelijk een compiled versie, anders zou je een heel ander file structuur zien, want nu is het alleemaal in 1 file voor de javascript deel met compressie etc, en compiled naar WebAssembly.

Dus dit is inderdaad gewoon closed source, dat het op NPM staat maakt niet uit dat verandert het niet, want eigenlijk exposed het alleen de API calls zover ik kan zien in de non-existant documentatie en het in development env gooien.

Als ze de source code publiek make MAAR dan dezelfde license houden zou Source Available een beter woord er voor zijn.

1. https://opensource.org/osd

[Reactie gewijzigd door Stetsed op 22 oktober 2024 13:21]

[luxebenen]

De source code van het bewuste stuk "sdk-internal" wordt *wel* gepubliceerd en wel hier:

Als je doorklikt naar de link zie dat er helemaal geen source te vinden is, alleen een binary WASM.
Dat iets op NPM staat wil nog niet zeggen dat het open-source is

[EnigmA-X]

De .js staat toch ook gewoon in die repo? (waarmee de WASM gebouwd wordt?)

[quote]
bitwarden_wasm_internal_bg.wasm.js
[/quote]

I stand corrected. (zie ook hierboven).

[Reactie gewijzigd door EnigmA-X op 22 oktober 2024 20:12]

[malmeloo]

Daarmee wordt de wasm niet gebouwd, het is zelfs andersom. De wasm is in de JavaScript geencapsuleerd zodat het in te laden is zonder het .wasm-bestand zelf te importeren. Handig voor als je bundler (nog) geen WebAssembly ondersteunt, maar dat maakt het nog niet open source.

[Creesch]

Met als kanttekening dat gepubliceerde code dus niet betekent dat het "open source" is. Wat wellicht voor veel mensen ook verwarrend is.

Open source heeft een specifiekere betekenis dan alleen maar de bron code inzichtelijk hebben (source available).
Er is dan ook echt een verschil tussen code inzichtelijk maken en code beschikbaar stellen onder een open source licentie.

[tedvg]

Hier zou dan ook de term "vrije software" gebruikt moeten worden.

Vaak ziet men de term Open Source als synoniem voor Vrije Software, maar dit is dus een gevalletje waar het verschil tussen de twee wel heel belangrijk is.

Open source is een voorwaarde voor software om vrij te zijn (je moet het immers kunnen aanpassen en kunnen delen), maar je kunt dus, zoals in dit geval, prima je broncode openbaar maken en daar een licentie op zetten dat je het mag inzien, maar het niet aan mag passen.
Dan is je software dus open source, maar niet vrij.

Meer over vrije software: https://www.gnu.org/philosophy/free-sw.html

[Goderic]

zoals in dit geval, prima je broncode openbaar maken en daar een licentie op zetten dat je het mag inzien, maar het niet aan mag passen.
Dan is je software dus open source, maar niet vrij.

Nee, dan is je software ook niet open source, jij hebt het over source available.

[tedvg]

De definitiediscussie is al zo oud als de term zelf, maar
"De term 'open source' is enigszins dubbelzinnig omdat deze ook gebruikt zou kunnen worden voor het toegankelijk maken van de broncode aan een beperkt publiek, zonder dat de code mag worden hergebruikt of aangepast. " - (Wikipedia: Open source)

De tendens is wel om de term Open Source meer naar de kant van Vrije software uit te leggen, dan naar de Source Available kant.

Vindt de term Source Available wel een betere term. Zal hem vaker gaan gebruiken.

[Goderic]

Wat jij beschrijft is source available en dat is niet hetzelfde als open source. Restricties op het gebruik van de code maken het per definitie niet open source (ongeveer toch, het combineren van code met een incompatible licentie kan wel voor restricties zorgen, maar daar gaat het hier zeker niet over).

[Remzi1993]

Maar dat mag niet van de GPL licentie toch? Dat kan je niet mixen met licenties die niet vergelijkbaar zijn volgens mij.

[Abanu]

Dit comment geeft wel duidelijk het gevaar van een door LLM gegenereerd antwoord. Het lijk heel uitgebreid, doordacht en wordt dan ook voor waar aangenomen (met +3 waardering) maar het is voor een groot deel foutief en misleidend. Omdat de source wel in github staat en alleen de licentie meer 'gesloten' is dan de GPL klopt de bulk van de uitleg niet. De genoemde problemen door het niet inzien van de code zoals transparantie en veiligheid zijn dus fout en misleidend.

[ironx]

Beetje offtopic, maar ik zit al te wachten op de dag dat er hele discussies (lees: lappen en lappen tekst) komen die door AI gegenereerd zijn... Zit toch niemand op te wachten?

/edit

Kan me voorstellen dat als dit (gegenereerde AI brabbels) de standaard gaat worden mensen (waaronder ik) echt geen reacties meer gaan lezen, laat staan er op gaan reageren.

Maar waarom zou je *uberhaupt* AI gebruiken om een reactie op te stellen? Doe het gewoon lekker kort en bondig in je eigen woorden. Ik hou ervan om met mensen te communiceren in "mensentaal"...

Maargoed, dat is mijn mening

[Reactie gewijzigd door ironx op 22 oktober 2024 19:19]

[dog4life]

Daar hoef je niet meer op te wachten, volgens mij zijn we daar al beland..

[Arfman]

Kijk maar eens op Reddit

[Nicked]

Daar hebben we gelukkig de moderatie voor. Die comments krijgen gauw genoeg een 0 of -1 toch?

[jpsch]

Heb het even gevraagd aan haar, maar we hoeven ons geen zorgen te maken.
===============

Bijdrages van ChatGPT op Tweakers worden over het algemeen niet toegestaan, en dit kan resulteren in een lage waardering of verwijdering van de post. Tweakers heeft strikte regels rondom het gebruik van AI-gegenereerde inhoud. Posts die duidelijk afkomstig zijn van tools zoals ChatGPT kunnen worden gemarkeerd door moderators en gebruikers, omdat ze niet voldoen aan de richtlijnen voor originele content en eigen inbreng op het forum.

Als een bericht als een AI-gegenereerde bijdrage wordt herkend, kan het mogelijk met een lage score (-1 of 0) worden gewaardeerd of zelfs worden verwijderd. Dit hangt af van hoe de moderatoren en gebruikers de relevantie en kwaliteit van de post inschatten.

[Sylvia]

Als leek dacht ik ook dat het een goede uitleg was maar heb ik het zeker niet gewaardeerd. Sterker nog, ik vind het werkelijk stuitend dat, op een techsite, wordt geantwoord met een AI-gegenereerd stuk tekst.

Ben blij dat jij even duidelijk benoemd wat er nou NIET goed is aan dat stuk AI tekst…

En dat geeft, m.i., dan ook direct aan dat “AI” totaal (nog) niet betrouwbaar is (zoals het nu te pas en te onpas wordt ingezet) maar al wel wordt gebruikt als zijnde “Heilige graal”. Zeer gevaarlijke ontwikkeling, zeker voor de leken onder ons.

[slijkie]

Eens, maar wat ook zo is, "normale" mensen kunnen ook vanalles neerplempen, heel verhaal. Dan komt er ook geen disclaimer met "potentieel onjuiste informatie".

Zoals gezegd, ik snap het, maar dat kan ik, jij of andere ook geven? De comments van mensen eronder zullen mij/jou of in bovenstaand geval het AI antwoord dan toch corrigeren? Ik snap het niet helemaal.

[DrPoncho]

Hehe even een LLM'tje er tegenaan gegooid?

[jzn21]

Is inderdaad wel heel duidelijk een LLM. Maar goed, als het de boodschap helder overbrengt en gecontroleerd is door een mens, dan is dat wat mij betreft helemaal prima. Veel mensen schrijven zo warrig, dat een LLM al gauw een stuk beter is.

[Blokker_1999]

Niet echt want er staat letterlijk iets in dat ook niet in het nieuwsbericht staat.

[Gubbel]

Eens, maar zou prettig zijn als mensen dit wel aanmerken in de reactie.

[breadje]

Niet geheel ontopic, maar de reactie van repel-ehv is voor mij juist de reden waarom die LLM reacties zo slecht zijn. Het is een gigantische brij van woorden die niets toevoegen aan het punt. Ergens denken al die taalmodellen dat je heel, heel veel overbodige woorden en herhalingen moet gebruiken. Het had een veel betere, en fijnere reactie geweest als het kort en bondig was. En vooralsnog kunnen mensen (als ze even tijd steken in hun reactie) dat veel beter op dit moment.

[hiostu]

Je kunt ook aan een LLM vragen of hij het opnieuw kan schrijven maar dan een stuk beknopter. En soms vraag je het dan nog een keer. Dan wordt het vaak wel stuk beter. Ook kun je een LLM vragen of hij het voor een specifiek publiek kan schrijven. Dan legt de LLM sommige zaken minder uitgebreid uit.

[ronaldmathies]

Is jouw reactie dan ook door een LLM geschreven? Ik kort het even in met hetzelfde resultaat:

Niet geheel ontopic, maar de reactie van repel-ehv is voor mij juist de reden waarom die LLM reacties zo slecht zijn. Het is een gigantische brij van woorden die niets toevoegen aan het punt. Het had een fijnere reactie geweest als het kort en bondig was. En vooralsnog kunnen mensen dat veel beter op dit moment.

[Horatius]

... Er staat niet hetzelfde, is zelfs slechter.

De LLM heeft een bijzin verwijderd welke zeer relevant was. Nu staat er "fijnere reactie", wat raar is. Met de bijzin erbij slaat het wel ergens op en heeft het meer inhoud.

Daarnaast heeft het de spelfout overgenomen had moest was zijn.

Ook heeft het de text tussen de haakjes verwijderd wat ook gewoon belangrijk was.


Je copy paste doet mij duiden dat je niet 2x hebt nagelezen wat er nou echt staat maar gewoon klakkeloos de LLM output copy paste.

[William_H]

Ik vind het wel meevallen qua AI toon. Of het is een hele goede AI, maar ik lees toch wel dat dit (deels) geschreven is door een mens.
De tussenkopjes verraden inderdaad dat er een LLM is gebruikt, want nogal typische teksten.
En dan vallen de paragrafen wel weer heel erg mee, want ik vind LLM's vaak nog heel breedsprakig praten, en op een vreemde manier. Bijna, en dit gaan mensen hier waarschijnlijk weer niet leuk vinden, bijna zoals sommige autistische mensen kunnen praten over een onderwerp.

[Horatius]

Tja waarschijnlijk heeft de LLM dit artikel gekregen met een prompt. Een kind van 7 kan ook zinnen overschrijven.
Dan lijkt het natuurlijk of het door een mens geschreven is, versie 1 was dat ook, dat is immers het artikel.

[Phobophile]

Oh jemig, dat had ik dus niet eens in de gaten. Dat verandert de waarde van zo'n post behoorlijk voor mij.

Ik vond het al gek dat er een hele alinea uit het artikel geciteerd werd, maar dat iemand hier gewoon een AI reactie gaat neerplempen had ik niet verwacht.

[!GN!T!ON]

Zie dit, ook op tweakers, steeds meer. En ik ben bang dat dit standaard gaat worden dat de comment sectie vol worden gezet met LLM gegenereerd materiaal die vaak nog onjuist is ook nog. Als het er dan tenminste nog bij word gezet of uberhaubt nagelezen, maar ik heb het idee dat drie kwart een vraag in zo'n LLM gooit en klakkeloos CTRL-C, CTRL-V doet.

[TheMaurice]

Zou een goed idee zijn om een "three strikes and you're out" systeem in te voeren. Waarbij je een strike krijgt als je LLM content plaatst zonder dat erbij te vermelden.

[Phobophile]

Helemaal mee eens!

[t link]

ik pik hier allerlij dingen uit die niet kloppen, AI heeft dingen weer klakkeloos overgenomen en laat weer zien een erg slecht te zijn in dingen correct uitleggen. bijvoorbeeld: de bug heeft niks te maken met de integratie van de SDK, dat is de bug niet.

[Reactie gewijzigd door t link op 22 oktober 2024 09:42]

[Goderic]

Spearrin noemde het gebruik van de closedsource-SDK een "bug" die zal worden opgelost. Bitwarden gaf later ook via sociale media aan dat het bedrijf zich blijft inzetten voor opensourcelicenties.

Zo lees ik het toch niet, dat de build faalt zonder de closed source SDK is een bug, maar het gebruik is echt wel niet per ongeluk. Dat is duidelijk met de legale uitleg die hij er bij geeft. Je ontwikkelt ook niet "per ongeluk" een closed source SDK.

Wat die SDK dan precies doet en hoe die verder ontwikkeld zal worden is me wel niet duidelijk. Gaan ze de weg van Gitlab op met closed source enterprise features? Wordt de open source code slechts een schil die niet werkt zonder de SDK? Of nog iets anders?

[Firesphere]

Ze "gaan" niet de weg van Gitlab op, ze zijn al op die weg. Zoals de CTO zelf aangeeft:

Everything that we do has not been FOSS for many years now. We have several business/enterprise products that we sell under a proprietary source available license. Essentially an open core model. We have no plans to change that strategy.

De closed SDK die per ongeluk een vereiste is geworden is de bug. Maar het uberhaupt hebben van die SDK is niets bijzonders, inderdaad gelijk aan wat GitLab doet. En een hele zut andere bedrijven, inclusief Linux distributie bouwers.

Het is een begrijpelijke operatie. Jammerlijk, in mijn mening, maar begrijpelijk.

[SilentLucidity]

Belangrijke toevoeging is wel altijd dat de opensource gemeenschap roept dat ze de code kunnen controleren, maar in de praktijk zeer weinig dat ook daadwerkelijk doen. Ik geloof overigens ook dat het vaak niet luiheid maar onkunde is, dat geld voor mij tenminste. Al ontwikkel ik al geruimte tijd software, ik heb een keer de broncode van VLC media player bekeken. Nou, zonder context is dat toch best pittig.

[Jeanpaul145]

Dat komt met omdat software development skills alléén je niet zo ver komt.
Wat software dev skills echt potent maakt is domeinkennis (domain knowledge). In het geval van bv VLC heb je dat niet (want je weet niet zo veel over hoe codrcs werken bijvoorbeeld), en dan wordt 't flink moeilijk om de code te begrijpen inderdaad.

Vergelijk het maar met de 2e kamer: die lui kunnen wetten maken (software dev) en daar zijn ze vrij goed in, maar weten verder niets van niets (0 domein kennis, gemiddeld genomen) en dus laten de resultaten zich vaak raden.

[Reactie gewijzigd door Jeanpaul145 op 22 oktober 2024 10:35]

[EraYaN]

Controle in deze is ook vooral de controle over het "gebruik" van de code, dus als iemand er mee aan de haal gaat sta je niet met lege handen. Bedrijven hebben recent nog als eens gekkigheid uitgehaald bij projecten (elastic, redis, terraform etc) om dat stukje controle weg te halen, daar is goeie open source licentie een goed schild tegen dat je ten minste die laatste versie dan kan blijven gebruiken, wat voor gekke ideeën er ook in de nieuwe licentie zitten.

[SilentLucidity]

Niet vooral hoor, je hoort veel roepen dat open source veiliger is omdat iedereen de broncode kan controleren. KAN inderdaad. Er heerst een soort verwachting dat iemand anders dat dan wel al gedaan heeft, dan komt er een betaalde audit en blijkt er toch wel eens een en ander mis. Maar, wat jij zegt is ook zo.

[Argantonis]

Wat een complete WAANZIN dat dit AI-generated stukje tekst met +3 wordt gewaardeerd.

https://github.com/bitwarden/sdk-internal/ is gewoon publiek in te zien code. Wat het aangekaarte probleem is, is de licentie, en dit heeft dus NIKS te maken met de stukjes tekst die hier zijn gegenereerd zoals:

"Veiligheid: Iedereen de code kan inspecteren en controleren op mogelijke kwetsbaarheden, fouten of zelfs achterdeurtjes."

[iqcgubon]

De redactie van Tweakers hoeft zich voorlopig nog geen zorgen te maken over hun job.

[tedades]

De AI reactie was misschien niet goed maar de hele discussie werd gestart omdat iemand post dat er belangrijke dingen ontbreken in het artikel.

[atthias]

met andere woorden als bitwarden vorige week een mailtje de deur uitgedaan over het hoe en wat en waarom, had dit waarschijnlijk een flink deel van de onrust gescheeld?

bedankt voor deze heldere uiteenzetting een +2 van mij

[sjongenelen]

Tsjah, het is niet zo netjes dat ze dat niet hebben gedaan - want ze weten wel waar ze mee bezig zijn

[atthias]

dat is het ook zeker niet nee mee eens

[RobertMe]

De onrust is er natuurlijk om twee redenen. Dat deze wijziging uberhaupt is gedaan en het feit dat het "ook nog eens" stiekem is gedaan. Als er over gecommuniceerd was vooraf was de onrust waarschijnlijk niet veel kleiner geweest, aangezien de "dat het gebeurt" natuurlijk veel groter is dan de communicatie er omheen.

[William_H]

Ik weet niet of je dat zo kan stellen.
Verwachtingsmanagement is tegenwoordig binnen de IT een groot goed. En dat is hier zeker niet goedgegaan.

[atthias]

ook waar natuurlijk lijkt er terecht op dat het feit dat het gebeurd erger word bevonden dan de communicatie of het gebrek daaraan erover

[Paddy99]

Ik ben het hier helemaal mee eens. Wat is de consequentie?

Ik denk dat het zelf ontwikkelen van een app op basis van Bitwarden nu erg lastig maakt, maar dit is echt een slechte educated guess. Medetweakers, wie weet hier mee van?

[Yucko]

dit heeft toch geen invloed op gebruikers van Vaultwarden, of wel soms?
Ik bedoel je maakt nog steeds gebruik van de officiële Bitwarden client in Windows, iOS, etc.

[RobertMe]

Het kan wel betekenen dat ze in de toekomst naar een (meer) gesloten model gaan waarbij dan ook mogelijk de Vaultwarden server niet meer compatible is met de Bitwarden clients. Nu was die garantie er natuurlijk sowieso al niet, maar het kan best zijn dat de Vaultwarden devs in de open source client code "afkijken" hoe de client met de server communiceert en dus hoe ze bepaalde zaken op de server zouden moeten afhandelen. Met een gesloten client kan dat dus niet meer. En zou het puur op semi willekeurige reverse engineering aankomen waarbij ze alleen zien welke request er naar de server gestuurd wordt maar ze geen idee hebben wat ze moeten antwoorden.

En v.w.b. Vaultwarden verder: Dani Garcia, de oprichter en nog steeds maintainer, heeft intussen op zijn GitHub profiel staan dat hij "onderdeel is" van de Bitwarden organisatie oftewel hij werkt intussen waarschijnlijk bij Bitwarden. Dat hoeft uiteraard geen probleem te zijn (wellicht wil Bitwarden Vaultwarden wel gaan inzetten als self hosted oplossing (ondanks dat ze al 2 mogelijke oplossing daarvoor hebben)), maar het kan net zo goed ook negatief zijn voor Vaultwarden.

Dan moeten we maar gaan hoprn dat "onze" mede-Tweaker Vaultwarden draaiende houd

[BlackDex]

Als een van de main developers van Vaultwarden kan ik aangeven dat Dani 0 restricties opgelegd heeft gekregen betreft Vaultwarden. En hij kan soms zelfs dingen al eerder fixen in Vaultwarden doordat hij interne kennis heeft, zoals de nieuwe native mobile apps welke diverse wijzigingen nodig hadden om te kunnen werken.

Verder heeft deze hele License verhaal ook geen invloed op Vaultwarden voor nu.
Zolang we de web-vault (welke onder GPLv3 valt) kunnen blijven bouwen zie ik geen problemen.

Verder zal Vaultwarden compatibel blijven met Bitwarden, en daardoor zullen de clients dus ook gewoon blijven werken.

Er zijn al heel lang diverse features die Bitwarden bied welke Vaultwarden niet kan bieden, zoals de Secrets Manager. En een aantal andere Enterprise/Bitwarden Licensed features.

[Mars Warrior]

Dani Garcia zit al sinds vorig jaar bij Bitwarden qua ontwikkelrechten aangezien hij destijds al commits kon doen op de source code

Wat ik verder niet helemaal snap: die sdk-internal staat gewoon op Github, dus hoezo is deze nu closed-source?

[RobertMe]

Dani Garcia zit al sinds vorig jaar bij Bitwarden qua ontwikkelrechten aangezien hij destijds al commits kon doen op de source code

Daar was ik niet bekend mee. Maar is en blijft IMO dan toch een bijzondere ontwikkeling (maar hoeft anderzijds niet perse iets te betekenen).

Wat ik verder niet helemaal snap: die sdk-internal staat gewoon op Github, dus hoezo is deze nu closed-source?

Waarschijnlijk een gevalletje "klok horen luiden maar niet weten waar de klepel hangt"? En gewoon alles onder de open source noemer gooien. Terwijl het gaat om "free, as in speech", dat de internal SDK niet heeft (maar wel "free, as in beer" en dus inderdaad ook open source).
En zelf heb ik de "ophef" voornamelijk opgevangen en me niet er in verdiept. En nouja "sdk-internal" straalt niet uit dat het open source is.

[Jerie]

Zo bijzonder vind ik de ontwikkeling niet; eerder gezond. Iemand bouwt iets moois (volledig compatibele server) in een toekomstbestendige programmeertaal. Zou je die in je ontwikkelteam willen? Ik zoi het zeker overwegen.

[3raser]

Closed-source op basis van het licentie model. De code is dus niet vrij te gebruiken.

[Hemingr]

Bitwarden begon als een mooi FOSS project. Geen fratsen, gewoon een mooie tool. Daarna ineens een subscription voor essentiele functies. En nu deze dreck. Enshitification op en top.

[PaulHelper]

Niet helemaal mee eens. Wilde je dat alles gratis bleef, want ook al kunnen kosten laag zijn met miljoenen gebruikers telt dat toch op.
Servers moeten draaien. Als je er zo op tegen bent is het mooie van open source dat je vaultwarden pakt en zelf kan hosten.
Alle functies met je eigen host kosten en beveiliging beter of slechter laat ik in het midden.
Zolang bitwarden open source blijft vind ik het mooi. Ik vind de gratis variant nog steeds meer dan bruikbaar. En nog steeds ongeveer de heilige graal wat betreft security tests en alle platformen die je eigenlijk maar wil.
Als jij een mooier alternatief weet dan hoor ik het altijd graag.

[Tassadar32]

Dat is dus het gevaar hier: Bitwarden word zonder het stukje met restrictievere voorwaarden niet meer bruikbaar (of mist functies) in een self-hosted omgeving. Dit dwingt mensen dus om backenddiensten bij Bitwarden af te nemen.

[PaulHelper]

Uhm, deels ja maar als het een stukje is en alle andere platformen zijn wel werkend zonder zo'n stuk, dan is de core dus nog steeds open en bruikbaar of bewerkelijk voor dingen als werkende forks. Op het moment dat je het niet kan gebruiken zonder de closed source stukken heb je inderdaad wel meer een probleem. Maar dan zijn ze denk ik in 1 klap een heel aantal gebruikers kwijt dus dat zou simpelweg een domme zet zijn.

[Ascathon]

Ik betaal om het project te steunen.
Maar wat krijg je extra? TOTP? Please, stop dat niet bij je wachtwoorden. 1TB storage, nou zoveel (geen) attachments heb ik niet bij mijn wachtwoorden.
En wat extra two step mogelijkheden, maar gratis is deze tool echt gewoon volledig bruikbaar hoor.
En realiseer ook, stel premium dingen in en je betaald een keer niet ... Heb je ook geen toegang meer tot deze features, data gelocked.

[blorf]

Dat iets een "SDK" nodig heeft is op zich al een rode vlag. Doe eens gewoon een listing van alle mogelijke function calls in plaats van een afgebakend pad presenteren en verwachten dat ontwikkelaars binnen de touwen blijven lopen. Daar zit altijd iets niet nader genoemds achter.

[iqcgubon]

Daarna ineens een subscription voor essentiele functies

Welke essentiele functies ontbreken er dan? Ik gebruik het al jaren gratis. En als ik features mis kan ik het zelfs zelf hosten.

Open source software != free software

[zordaz]

Niet mee eens, je kunt nog altijd Vaultwarden draaien. Vergelijk dat maar eens met concurrent Lastpass. Dat is pas een voorbeeld van Enshittification. Je kunt daarnaast ook alles exporteren, mocht je naar iets anders willen overstappen.

[Reactie gewijzigd door zordaz op 22 oktober 2024 14:54]

[Zoijar]

Ja, ik heb die "bugs" ook wel eens op m'n werk, dat ik per ongeluk ineens een heel closed source pakket integreer en opneem in een release Lijkt Meta wel. Ik bedoel, dit is natuurlijk ook nauwelijks te ontdekken in een code review.

[Reactie gewijzigd door Zoijar op 22 oktober 2024 09:31]

[valhalla77]

Subscription voor een aantal tools vind ik niet erg zeker gezien de 10 dollar per jaar die men hiervoor vraagt.

Probleem is echter dat heel veel for-profit orgs die zich bezig houden met Open Source software op een gegeven moment ook gaan kapitaliseren. Daarbij is er een Venture Capital die geïnvesteerd heeft in Bitwarden. Neem daarbij de look en feel van de website die heel sterk naar profit marketing is omgebouwd. Dat zijn al signalen dat het hier niet bij gaat blijven. Ook heb ik sterk het vermoeden dat men meer op enterprise gaat focussen met de features die ze in de tussentijd hebben geïntroduceerd.

Voor gebruikers die open source hoog in het vaandel hebben staan, denk ik dat ProtonPass een logisch alternatief gaat zijn. Maar het zou me niet verbazen dat meer mensen weer richting keepass gaan, al is dit met de syncthing nieuws van gisteren ook problematisch (vanuit een balans tussen security en convenience). Ander alternatief zou Vaultwarden kunnen zijn als je wilt self-hosten. Maar ook hier hoe lang duurt het voordat hier ook problemen gaan ontstaan vanwege de niet vrije gedeeltes van de SDK.

[Reactie gewijzigd door valhalla77 op 22 oktober 2024 11:26]

[mkvrs]

Titel is niet helemaal correct, de SDK is niet closed source (https://github.com/bitwarden/sdk-internal)
Het probleem is de restrictieve license die aan dit project is gekoppeld

[Namret]

Inderdaad, de code is open source, maar niet vrij te gebruiken (de 'F' in FOSS).

[Telin]

Dit is grotendeels afhankelijk van iemands persoonlijke interpretatie van opensource.
Persoonlijk vind ik het toch enigszins "misleidend" om het Bitwarden project opensource te noemen terwijl het dus blijkbaar afhankelijk is van componenten waarop stevige licentie beperkingen zit.
Technisch zal het best allemaal opensource zijn maar het past niet echt in het FOSS gedachtengoed waarop veel mensen hebben besloten om voor Bitwarden te kiezen.

[CAPSLOCK2000]

Het bedrijf heeft later via sociale media nogmaals gezegd dat het 'toegewijd blijft aan het opensourcelicentiemodel' en dat het hier gaat om een packing-bug.
(...)
Correctie, 13.13 uur - Aanvankelijk stond in de titel van dit artikel dat de gebruikte sdk 'closed source' is. Dat klopt echter niet. De broncode van de sdk is openbaar, hoewel deze een licentie bevat die gebruikers verbiedt om de sdk te gebruiken in combinatie met andere software dan Bitwarden, of voor het ontwikkelen van eigen sdk's. Dit is verbeterd.

Dit illustreert weer mooi waarom ik zoveel mogelijk over "vrije software" heb, ook al klinkt dat een beetje vreemd in het Nederlands. Het mogen lezen van de broncode is mooi, maar niet waar het echt om gaat voor mij. Het gaat voor mij om mijn vrijheid, dat we niet gevangen raken in geheime algoritmes die ons leven sturen zonder dat we weten hoe ze werken of hoe we hoe we ze kunnen veranderen. Broncode lezen helpt bij het eerste deel maar als je de software niet kan veranderen is dat maar van beperkt nut. Als de leverancier het wel kan is het vooral een wassen neus.

Steeds vaker voelt het alsof onze eigen apparaten ons als vijand zien. Een typisch voorbeeld is DRM/kopieerbeveiliging, die is er niet voor eindgebruikers maar voor de media-industrie. Wat je verder ook over kopieren denkt, het is duidelijk niet in mijn belang als mijn computer niet luistert naar mijn opdrachten maar wel naar die van een ander.

Ik wil mijn computers en software kunnen vertrouwen. Ik loop er 24/7 mee rond, tot in de slaapkamer en badkamer. Het is het meest krachtige gereedschap dat ik ken en ik wil er volop gebruik van kunnen maken.
Gesloten systemen kan ik niet vertrouwen en dus kan ik ze niet volop gebruiken, want nogal frustrerend is voor een techneut als mij.

Het is jammer dat er zo weinig aandacht is voor softwarefilosofie. De Free Software filosofie komt uit de jaren '80 van de vorige eeuw maar is nog steeds het enige werk dat nadenkt over de relatie tussen gebruikers en software vanuit het oogpunt van de gebruiker.
Alles wat daarna komt gaat uit van de belangen van de ontwikkelaar/leverancier. In plaats van rechten zijn er voorwaarden en eisen. Er is niet zo zeer sprake van een filosofie als wel van een verdienmodel. Niet langer gaat het om mensen te helpen met goede software maar over het ontwijken van verantwoordelijkheid en het maximaliseren van de winst.

Denk nu niet dat ik tegen commercie ben want dat klopt niet, maar ik vind dat de belangenafweging nu veel te eenzijdig is. Door te doen alsof het alleen maar om geld gaat doen we de maatschappij te kort omdat aspecten als vrijheid en privacy volledig uit beeld verdwijnen. Dat proberen we nu weer een beetje recht te zetten met wetten als de GDPR en DMA/DSA maar voorkomen is beter dan genezen, we zullen nog decennialang last hebben van de lidtekens.

Misschien is de Free Software filosofie wel verouderd want de softwarewereld is sindsdien totaal veranderd en een miljoen keer groter geworden en software is van een niche-product gegaan naar iets dat iedereen heeft en gebruikt, zakelijk en prive, maar ik ken geen enkel alternatief. Niks dat gebruikers voorop stelt, niks dat heeft nagedacht over de grotere consequenties van software voor de wereld.

Ik hoop van harte dat iemand me nu wijst op een moderne sofwarefilosofie die ik gemist heb. Er lopen inmiddels wel meer softwarefilosofen rond in de wereld, je kan het zelfs studeren, maar die lijken zich vooral met andere zaken bezig te houden.

[Thijzer]

Licentie aanpassen op termijn...

Dit gebeurt jammer genoeg vaker, zeker als een ooit startende open-source project met goede bedoelingen, populair wordt omwille van zijn open-source karakter en community, ineens ficale stappen zet, die dan leiden tot verkeerde contacten|inzichten, die dan leiden tot hebzucht|greed.

Het probleem is echter vaak, de reden waarom de "Home Assistant" de "Open Home Foundation" om zijn gebruikers, en community te garanderen dat dit nooit zal|kan gebeuren.

Dusja, ergens vrees ik dat de Bitwarden kader nu wel van de open-source muurtje mag.

=> open-source is dead
Er zijn veel mensen die denken dat open-source niet werkt, dat het ten dode opgeschreven is, en dat de mensen die anders denken naief zijn. Nu kan ik je vertellen moest open-source niet bestaan, dan zou de hele tech bubble niet hetzelfde zijn, lees troep. Misschien was tweakers een flash site. javascript zou nog altijd slechter zijn dan ActiveX. De smartphone zou helemaal niet zo efficient werken zonder (curl,sqlite,apache).

Ik zou niet in IT werken, wat ik dank mijn job en kennis aan open-source.

Wat ik zie, en dit zie ik vaker terugkomen, is dat er geen waardering meer is voor al deze legacy, Mensen hechten er geen belang meer aan, we zijn techno-moe denk ik. Vroeger toen alles nog moest gebouwd worden was er zoveel hype en appreciatie voor de vooruitgang dankzij open-source.
Of mis ik mij, als ouwe knar achter mijn keyboard op linux desktop. Ik zeg niet dat het vroeger beter was, maar ik heb alles leren apprecieren omdat ik heel wat technologische stappen hebben gezien en mogen meemaken...