Instead of relying on a specific cloud service, why not generate a text file from for the todo list data and checkbox state and push/pull it to a git repo?
There is gitpython, a pure python implementation of git.
Instead of relying on a specific cloud service, why not generate a text file from for the todo list data and checkbox state and push/pull it to a git repo?
There is gitpython, a pure python implementation of git.
The SDK is not closed source, you can find the source here: https://github.com/bitwarden/sdk
It might not be GPL open-source, but it is not closed either.
Sure. To me “source available” is still closed-source, since looking into it might give companies an attack surface for you to have violated their copyright in the future. Happened with IBM in the past: https://books.google.de/books?id=gy4EAAAAMBAJ&lpg=PA15&pg=PA15&redir_esc=y#v=onepage&q&f=false
Let’s wait and see before we get out the pitchforks.
Sure. Bitwarden doesn’t owe us anything, but it is still sad to see this decision and better clarification and explanation could have alleviated the breaking of the trust here.
So you meant to say:
I would go as far as to say that Bitwarden’s main competitive advantage and differentiation is that it’s source is available.
That is not true, there are a lot of other password management software out there where the client source code is either open source or source available. For instance keyguard: https://github.com/AChep/keyguard-app?tab=License-1-ov-file#readme which is an alternative proprietary bitwarden client, where the source is also available. Also the Proton Pass client is under GPLv3.
I would argue that the main advantage of bitwarden compared to others is that it is open source and has an open source server for self-hosting (vaultwarden). Which of course makes it difficult in terms of business strategy with their VC funding. But maybe becoming a non-profit org and getting money from donors, the strategic funds of EU and other governments, etc. might be an alternative way.
Ok, lets take it step by step:
Thanks for sharing your concerns here. We have been progressing use of our SDK in more use cases for our clients. However, our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.
- the SDK and the client are two separate programs
I think they meant executable here, but that also doesn’t matter. If both programs can only be used together and not separate, and one is under GPLv3, then the other needs to be under GPLv3 too.
- code for each program is in separate repositories
How the code is structured doesn’t matter, it is about how it is consumed by the end-user, there both programs are delivered together and work together.
- the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3
The way those two programs communicate together, doesn’t matter, they only work together and not separate from each other. Both need to be under GPLv3
Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.
Not being able to build a GPLv3 licenses program without a proprietary one, is a build dependency. GPLv3 enforces you to be able to reproduce the code and I am pretty sure that the build tools and dependencies need to be under a GPLv3 compatible license as well.
But all of that still doesn’t explain what their goal of introducing the proprietary SDK is. What function will it have in the future? Will open source part be completely independent or not? What features will depend on the close-source part, and which do not? Have they thought about any ethical concerns, that many contributors contributed to their software because it under a GPL license? How are they planning on dealing with the loss of trust, in a project where trust is very important? etc.
None of that makes Bitwarden not open source.
Yes, it does, because it violates its own license GPLv3 by having proprietary build-/runtime dependencies.
If it was under a different, maybe more permissive, open source license, then maybe it would still be open source, but as of right now i likely breaks its own license terms.
Not only that, they specifically state this is a bug which will be addressed.
From what they state, they think that because executables that share internal information via standard protocols does somehow not break GPL3 terms compared to two libraries that share internal state via the standardized C ABI which does. And they seem to not consider that a bug, just the build-time dependency.
Well, then it would be nice to hear from them an explanation on why they decided to violate the GPLv3 on their client, by coupling it with proprietary code in a way that disallows building and/or usage without that proprietary component.
They would be insane to change that.
Yes. And i hope that they recover from it soon.
I would say a proper explanation includes the goal you want to achieve, not just the statement that you think that you are allowed to do something.
That “explanation” is unsatisfactory and likely wrong: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
So they either have to license their SDK under a GPLv3 compatible license, or switch the license of their client to a non-GPL one.
Their “explaination” only mentions why they think can do it, but not why they are doing it.
That is why we can’t have nice things. Everything needs to make a profit and cannot simply be good.
Infrastructure shoudn’t be required to make a profit. They are there for the public good. What’s next? Paying for sitting on public benches and entering public parks? Paying for the privilege to exit your house and use the public sidewalk? We already have to pay to use public toilets in some cases…
These things should be available to everyone for free and build and financed via general taxes.
Nobody? That was a general statement, sorry if that was unclear formulated. I just see many people that first set a label for themselves and then try to fit into it, instead of just doing what ever they want and just use them as a short hand to explain themselves.
Yes, and labels suck. Don’t limit your yourself involuntarily just to fit into one.
So similar to kakoune? I tried that for a while, but it was missing some features so I went back to vim/neovim.
I need to know vi anyway, because that is available everywhere (as part of busybox), so using vim/nvim for bigger systems just fits.
And they do that for while gaining 0 XP?
In my head canon the people are sometimes just rusty and forgetful, because even if someone lives 100 year, that doesn’t mean that they will remember everything or get better at stuff. That is why I think immortal beings that live aeons, can still be surprised or tricked. Being old doesn’t necessarily mean that people are wiser.
Sometimes people just need the right motivation to improve themselves.
What about Lua/Luajit?
In most scripting languages you have the interpreter binary and the (standard) libraries as separate files. But creating self-extracting executables, that clean up after themselves can easily be done by wrapping them in a shell script.
IMO, if low dependencies and small size is really important, you could also just write your script in a low level compiled language (C, Rust, Zig, …), link it statically (e.g. with musl) and execute that.
So generally the pro of coreboot is that it is open source, but the con is that it is open source.
What I mean by that, you can fix any issues yourself, however, if you are unable to do it yourself, you have to wait until someone does it for you and often what features are available and stable are a hit and miss.
Compared to proprietary bioses, the company has some kind of standardized process for developing the bios. So you often get want you would expect. However, if the money flow from the pc vendor to the bios vendor drys up, you, or the community of owners. will not be able to fix any issues.
Linux support should be the same, regardless if you choose proprietary or open source bios. But that depends on how well the coreboot was ported to the platform. So officially supported coreboot bioses are likely better than others.
Personally, if all other attributes are equal, would go with coreboot, because I like to support vendors that offer that choice, and IMO a open source solution, that you can review and build yourself is intrinsically more secure than a binary blob, where you have to blindly trust some corporation. But other security minded people might disagree, which is fine.
Well… cults with an exit are just groups of people.
Apple looks more like a cult, similar to Scientology. Linux user as well.
I would be careful about assuming knowledge based on age. Young people might use technology without understanding it, and old people might understand it and don’t want to use it.
Technology needs to be regulated, and I would not trust people with profit incentives to do so.
IMO, it is always important to investigate if a regulation wants to prevent a real issue or if they just mention some populist reasons for doing whatever they want.
No, it is consistent. Because it is not about the law itself, but about it being applied in a double standard. If a random person copies a product made by an industry, the law will punish them. If the industry copies work of random people, its fine and a sign of progress.
I would like a copyright to be nontransferable, bound to the individuals that created it, and limited for about 10 years or so (depending on what it is), to give the creators some way to earn a reward back, while also encouraging to create new stuff.
Well, if the text file uses git(hub/lab) flavored markdown, you can check/uncheck the boxes from the webui of git(hub/lab). No need to write an app for the apple device.
https://docs.gitlab.com/ee/user/markdown.html#task-lists
In gitlab you might need to edit the markdown file via an webeditor and create a commit this way.