Per their response to this issue, seems like this is a bug: While they do have some non-FOSS code in their `sdk` package, the client should still be buildable without the SDK:
> Hi @brjsp,
> 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.
The problem with that statement is what exactly does "in a way that maintains GPL compatibility" means, especially since they plan on moving more functionalities into the proprietary code, so the two "separate" components will be increasingly coupled together.
I'm not a lawyer, but I'm quite skeptical of the outcome. Is it really going to produce a valid GPLv3 licensed client? To me, it seems like the whole thing is just going to be a combined proprietary + GPLv3 license, which will contradict itself.
But again, I'm not a lawyer, so my understanding of this might be way off.
> Hi @brjsp, > 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.