-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
License is not FOSS-compatible. #898
Comments
There are no plans to adjust the SDK license at this time. We will continue to publish to our own F-Droid repo at https://mobileapp.bitwarden.com/fdroid/repo/ |
woah, that probably means that the whole bitwarden suite is not really open source... |
@kspearrin, indeed - there are evidently no plans, hence the issue. This is fairly significant, considering how much of your user base value the fact that BW is FOSS. @hobbes, I've filed an FR at https://community.bitwarden.com/t/bitwarden-is-not-foss/69734/1?u=rokejulianlockhart#:~:text=Bitwarden%20is%20not%20FOSS. |
Why you do not want to change the SDK licence? |
Thank you for continuing to publish those. It's one of the reason why I initially embraced Bitwarden. Section 3.3 is particularly concerning. There's ambiguity on whether Vaultwarden would be considered an implementation of Bitwarden. Additionally, regardless of whether it is or isn't - section 3.3 forbids use of this SDK if Vaultwarden were to no longer be considered an implementation of Bitwarden.
|
@hobbes It doesn't mean it's not open-source. It makes Bitwarden not free-as-in-speech. |
@Xiaoyu2006, the more accurate term for this repository would be “source available”, in contrast to “source unavailable”. Any additional distinctions like “open source” or “closed source” unfortunately differ in definition from situation to situation. Irrespective, ultimately, what we want from this issue is for BW to become FOSS, which means that its source code can be reused for any purpose (whether the author mandates accreditation or not) as https://fsfe.org/freesoftware/comparison.en.html#:~:text=Free%20Software%2C%20Open%20Source%2C%20FOSS%2C%20FLOSS%20%2D%20same%20but%20different explains. Consequently, a discussion of semantics isn't particularly useful, although I'm thankful for the specification. |
bitwarden/clients#11611 |
Unfortunately, misconceptions appear to abound here. In retrospect, the premise of this issue that I created is included. Hopefully the undermentioned quotations at least provide some clarity:
I understand this rationale, to an extent: Comment #3
However, to have such an important dependency of otherwise entirely FOS software be non-FOSS appears disingenuous when the advertisements explicitly state not that the software adheres to the GPLv3, but that it's FOSS. Bitwarden can utilize the legal definition instead, but to advertise software as FOSS when it's at best solely so in a technically legal sense shan't be thought of well by those who learn of it. I dare say that BW may have to cope with the Streissand effect from now onward. Lastly, I suggest that everyone subscribed here at least upvote the undermentioned response to the last aforementioned comment, so that we might gain some more clarity: Comment #2.1
|
@RokeJulianLockhart thanks for the clarification! |
This comment was marked as off-topic.
This comment was marked as off-topic.
is there no way to keep clients without the SDK as has been done all the time so they can be fully open source without needing this source available extra thing that makes some things kinda annoying? |
@My1, it's certainly possible if someone forks the client soon, and maintains that fork. Considering that the PR to implement the SDK was recent, I would be very surprised if the major refactor to implement the SDK's methods (replacing existent methods) couldn't be undone without losing near feature parity. However, the longer that the last commit without the SDK is left without maintenance in a fork, the more difficult that it becomes to revive it. Without a maintained fork soon, anyone who wishes to create a client that doesn't use the SDK may realize that it might be more trivial to write an entirely new client with a cross-platform language (like .NET Framework via C#, Java, or Python 3) and GUI toolkit (like Qt 6). |
You've effectively made it impossible for third parties to distribute any derivatives of your own GPL'd repositories which depend on the SDK code, especially where its contents have been obfuscated, according to the GPL (Section 1):
Continued (Section 6):
You cannot have your cake and eat it, do you want to release open source software or not? Historically, software that tries to sit on the fence in the middle has for the most part not endured, usually being superseded by software written under less bizarre models. In this case, there is not even a difficult to get past hardware dependence for these programs, which can easily be replaced readily with already existing, truly open alternatives. I at least know I shouldn't stake my own confidence in those who are unsure what they even want to happen with derivatives of their software. |
As Bitwarden has combined this work with the client applications into a combined work said to be distributed under the GPL-3, the license terms on the SDK as part of the clients corresponding source must be considered further restrictions as defined in the GPL, and as such the license is null and void as per section 7: If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term |
@julian-klode, have you read this comment by a developer involved, as aforecited? I ask because it appears to contradict what you have stated. |
The claim is rather absurd. While ultimately that's for judges to decide and I don't know precedent, the intent of the license is to allow two programs to communicate over standard interfaces without both needing to be GPL. Make no mistake, this is not what happens here, the SDK is directly embedded and called in shared memory, so as is the common understanding (and this is a very common case, to import one module into another) they constitute a combined work. You can find a detailed explainer in https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation |
If the are truly Seperate programs it's be a pretty weird architecture as the program needs a like api or whatever to connect to thw sdk which then in turn connects to the server, seems a very intentional thing to me. If it's just linked as a dll or whatever GPL's infecting iirc might get fun again |
This comment was marked as outdated.
This comment was marked as outdated.
the most commonly accepted definition for "open source" is the OSI OSD, which, similar to the FSF Free Software Definition, requires the freedom to (re)distribute derived works: |
This comment was marked as outdated.
This comment was marked as outdated.
@kspearrin, I forgot to mention this earlier, but this issue should be closed as "unplanned", not https://github.com/bitwarden/sdk/issues?q=reason%3Acompleted. |
The mobile client is again suitable for inclusion in F-Droid, per https://gitlab.com/fdroid/rfp/-/issues/114#note_cf629f7d0a0499cc0e57963e883018da5bfcc712. Shall hide #898 (comment) as resolved. Specifically, bitwarden/clients#11611 (comment) states (formatting-modified):
Summarily, solely this repository's contents – the secrets portion of the SDK – should now be non-FOSS, and are packaged separately to the rest of the SDK, which none of the clients reference anymore, consequently. An important improvement. Of course, if I've interpreted that comment correctly. |
Steps To Reproduce
Attempt to compile the package to enter it into the F-Droid repository, per https://gitlab.com/fdroid/rfp/-/issues/114.
Expected Result
It should utilize a FOSS-compatible license.
Actual Result
https://gitlab.com/fdroid/rfp/-/issues/114#note_1995138172:~:text=Given%20that%20Bitwarden%20SDK%20is%20not%20FOSS%20Bitwarden%20can't%20be%20included states:
Screenshots or Videos
No response
Additional Context
No response
Operating System
Linux
Operating System Version
cpe:/o:fedoraproject:fedora:40
, from https://download.fedoraproject.org/pub/fedora/linux/releases/40/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-40-1.14.isoBuild Version
Issue Tracking Info
The text was updated successfully, but these errors were encountered: