4 ms·

CTO response: 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 su

by wooque 2y ago

CTO response: 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 code for each program is in separate repositories the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of 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.

ferbivore 2y ago
In other words: bitwarden/clients is GPLv3; any Bitwarden client as a functioning whole is proprietary; the CTO does not see a problem with this; issue locked.
- ferbivore 2y ago
  The SDK has now been relicensed as GPLv3, so it looks like the CTO did see the problem in the end.
  - notpushkin 2y ago
    With some proprietary bits, though. I assume it's for EE features?
    - ferbivore 2y ago
      Yes, for Secrets Manager. They've always had proprietary bits for enterprise features. It seems sensible enough as long as you can build a GPLv3 client without them.
mattdm 2y ago
It's not necessarily about being "one program". It's this part: "The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities." I get that it's really hard to make money as an open source company. (That's why I am one of your paying customers.) The exclusion you are putting on your SDK seems very similar to that of the "bitkeeper" version control software used for the Linux kernel for a short time. Look how that turned out.
- atanasi 2y ago
  FSF has published a commentary: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.html#MereAggregation GPL licenses have allowed so-called "mere aggregation", where separate programs are distributed together. Such programs don't have to be all covered by GPL. On the other hand, if parts are intimately tied to each other such that they are effectively a single program, GPL applies to the whole. The FSF commentary explains that the judgment depends both on the mechanisms and the semantics of the co-operation. Technical implementation details don't make programs separate if they are intimately designed to work together: "But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
  - chme 2y ago
    So they either have to license their SDK with a GPLv3 compatible license as well, or have to change the license of the client to a non-GPL one. In the latter case, IIUC their CLA (https://cla-assistant.io/bitwarden/clients https://cla-assistant.io/bitwarden/clients) allows to do change the license unilaterally. (Not a legal expert, so please correct me if I am wrong.) If so, then I feel strengthened again in my conviction that permissive licenses (as well as closed-source licenses) and CLAs are bad for both users and developers and should be avoided, if possible.
  - Sammi 2y ago
    You are siddstepping the issue and answering in bad faith and you know it. What do people actually want to hear from you?
    - notpushkin 2y ago
      Their answer actually sounds alright to me. What is your problem with it, exactly?
wanderfowl 2y ago
I find this response (and the class of responses like it) really frustrating, because it uses a (likely feigned) misunderstanding of the scope of the question to attempt to sidestep the real question. My question for the CTO would be, roughly: You've now answered "Do your lawyers think you can get away with this?". But the questions you're not answering directly, which I think underlie the 'concerns' you're appreciating our sharing, are things like... - Does the Bitwarden team see no ethical problems with making proprietary a project which many supported and contributed to explicitly because it was open source? - Given that password management is explicitly a high-trust enterprise, how does your organization intend to navigate the rupture of trust, and subsequent forks and waves of departure, caused by an open-to-proprietary rugpull? - Is there something that the community could do together which would help your company navigate through the dire situation you must be in to be considering something like this, without resorting to proprietarization? I know it's his job as CTO right now to be feigning concern, particularly in forums where you can't close the conversation, but the current approach is basically confirming the worst fears ("They believe they can legally do it, and see no problem with their actions"), and that seems like exactly the wrong vibe for a company whose bottom line depends on users trusting the code and the people updating it.

by wooque 2y ago

ferbivore 2y ago

In other words: bitwarden/clients is GPLv3; any Bitwarden client as a functioning whole is proprietary; the CTO does not see a problem with this; issue locked.

ferbivore 2y ago
The SDK has now been relicensed as GPLv3, so it looks like the CTO did see the problem in the end.
- notpushkin 2y ago
  With some proprietary bits, though. I assume it's for EE features?
  - ferbivore 2y ago
    Yes, for Secrets Manager. They've always had proprietary bits for enterprise features. It seems sensible enough as long as you can build a GPLv3 client without them.

mattdm 2y ago

It's not necessarily about being "one program". It's this part: "The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities." I get that it's really hard to make money as an open source company. (That's why I am one of your paying customers.) The exclusion you are putting on your SDK seems very similar to that of the "bitkeeper" version control software used for the Linux kernel for a short time. Look how that turned out.

atanasi 2y ago
FSF has published a commentary: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.html#MereAggregation GPL licenses have allowed so-called "mere aggregation", where separate programs are distributed together. Such programs don't have to be all covered by GPL. On the other hand, if parts are intimately tied to each other such that they are effectively a single program, GPL applies to the whole. The FSF commentary explains that the judgment depends both on the mechanisms and the semantics of the co-operation. Technical implementation details don't make programs separate if they are intimately designed to work together: "But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
- chme 2y ago
  So they either have to license their SDK with a GPLv3 compatible license as well, or have to change the license of the client to a non-GPL one. In the latter case, IIUC their CLA (https://cla-assistant.io/bitwarden/clients https://cla-assistant.io/bitwarden/clients) allows to do change the license unilaterally. (Not a legal expert, so please correct me if I am wrong.) If so, then I feel strengthened again in my conviction that permissive licenses (as well as closed-source licenses) and CLAs are bad for both users and developers and should be avoided, if possible.
- Sammi 2y ago
  You are siddstepping the issue and answering in bad faith and you know it. What do people actually want to hear from you?
  - notpushkin 2y ago
    Their answer actually sounds alright to me. What is your problem with it, exactly?

wanderfowl 2y ago

I find this response (and the class of responses like it) really frustrating, because it uses a (likely feigned) misunderstanding of the scope of the question to attempt to sidestep the real question. My question for the CTO would be, roughly: You've now answered "Do your lawyers think you can get away with this?". But the questions you're not answering directly, which I think underlie the 'concerns' you're appreciating our sharing, are things like... - Does the Bitwarden team see no ethical problems with making proprietary a project which many supported and contributed to explicitly because it was open source? - Given that password management is explicitly a high-trust enterprise, how does your organization intend to navigate the rupture of trust, and subsequent forks and waves of departure, caused by an open-to-proprietary rugpull? - Is there something that the community could do together which would help your company navigate through the dire situation you must be in to be considering something like this, without resorting to proprietarization? I know it's his job as CTO right now to be feigning concern, particularly in forums where you can't close the conversation, but the current approach is basically confirming the worst fears ("They believe they can legally do it, and see no problem with their actions"), and that seems like exactly the wrong vibe for a company whose bottom line depends on users trusting the code and the people updating it.