adding @silverhook for legal review, as I am not a lawyer. I don't think that the restrictions that Wire has added would be considered permissable "additional terms" as per GPL3, section 7 but instead be a "further restriction".

I didn’t dive deep, but at a quick glance, I’d agree with @armijnhemel that this would go into the “further restrictions” territory. But also that these “further restrictions” fall away, if you modify the client in a way to not connect to Wire’s own servers.

It seems like a very mixed bag to me.

I work at Wire and have poked a collegue at the company who might be able to help with this question.

@toonn I've made a patch to fix some style issues and to make it easier to update manually

• https://gist.github.com/worldofpeace/d02bcda1ab44bb37e438335a46579232

@worldofpeace, I applied your patch, I'd originally grouped the makeDesktopItem with the other linux-specific dependencies but I don't feel strongly about that. Keeping the versions together does look like a definite improvement.

@toonn The client source code is only governed by GPLv3. The terms you quote apply to the usage of Wire servers, not the client server.

@toonn The client source code is only governed by GPLv3. The terms you quote apply to the usage of Wire servers, not the client server.

Although I agree that these terms only seem to be when the Wire servers are used (and not when your own server is used), they do read on the client code and are, I think, a "further restriction" according to the license.

I should have clarified: I work for Wire. The terms of use only govern Wire accounts (which is a prerequisite for using the Wire servers).
The source code is not affected by them.

I should have clarified: I work for Wire. The terms of use only govern Wire accounts (which is a prerequisite for using the Wire servers).
The source code is not affected by them.

But it is not "terms of use"! The README actually calls them "restrictions" :-)

"Additionally, if you choose to build an Open Source App, certain restrictions apply"

I absolutely understand why you would want these restrictions as rogue code could interfere with your operations, but the way it is currently worded it reads on the client code and thus could be seen as a "further restriction" according to the license.

Personally I would move these restrictions to general terms and conditions and just terminate people's accounts if they don't comply with those rules. GPL3, section 6 would already allow you to do this:

"Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network."

It might be worthwhile to talk to an experienced open source lawyer. I would be more than happy to give some suggestions for various jurisdictions (Germany, Switzerland, Italy, Spain, UK, etc.)

I should have clarified: I work for Wire. The terms of use only govern Wire accounts (which is a prerequisite for using the Wire servers).
The source code is not affected by them.

@raphaelrobert, thanks for the clarification. But if that is case, please make sure to clarify it in the license itself and official documentation, instead of an issue buried on a source code forge.

@silverhook I'm not sure what you mean exactly. The README file points to the license file directly for all source code licensing questions:

For licensing information, see the attached LICENSE file and the list of third-party licenses at wire.com/legal/licenses/.

@raphaelrobert, the relevant part of the https://github.com/wireapp/wire-desktop/blob/staging/README.md reads as follows (emphasis mine):

For licensing information, see the attached LICENSE file and the list of third-party licenses at wire.com/legal/licenses/.

If you compile the open source software that we make available from time to time to develop your own mobile, desktop or web application, and cause that application to connect to our servers for any purposes, we refer to that resulting application as an “Open Source App”. All Open Source Apps are subject to, and may only be used and/or commercialized in accordance with, the Terms of Use applicable to the Wire Application, which can be found at https://wire.com/legal/#terms. Additionally, if you choose to build an Open Source App, certain restrictions apply, as follows:

a. You agree not to change the way the Open Source App connects and interacts with our servers; b. You agree not to weaken any of the security features of the Open Source App; c. You agree not to use our servers to store data for purposes other than the intended and original functionality of the Open Source App; d. You acknowledge that you are solely responsible for any and all updates to your Open Source App.

For clarity, if you compile the open source software that we make available from time to time to develop your own mobile, desktop or web application, and do not cause that application to connect to our servers for any purposes, then that application will not be deemed an Open Source App and the foregoing will not apply to that application.

The parts emphasised in bold, seem to be connected to the license of the code, not the Terms of Service of the official Wire server(s). I agree that you clarification makes sense, but it is not (unambiguously) reflected in the README.md. The way it reads now is that it restricts the use of the code and splits the market into two, giving a different license to each part of the market.

It would be good to re-write the wording in order to clarify the distinction between the license of the code (GPL-3.0) and the terms of service that apply when a client connects to the official Wire servers.

Thanks for the feedback @silverhook! I guess we could make it more clear that the README is just an extract of the Terms of Use.

Thanks for the feedback @silverhook! I guess we could make it more clear that the README is just an extract of the Terms of Use.

Yes, this would, I think, suffice (as I already commented). It basically comes down to "if you mess with our operations, we will terminate your account" and that's perfectly fine. For the rest: what @silverhook said :-)

Ping @worldofpeace.

@grahamc at #64931 (comment) you said "this is very fishy".

I'm not sure what you meant by that and what to change, and @toonn changed their expression significantly f5beda5.

@worldofpeace, I made the changes in response to @grahamc's complaints. They didn't like the common // if darwin then darwin else linux), preferring inheriting the common attributes. (aside: I personally don't like the inherit mechanism because with can bring things in scope implicitly so you can't always tell where inheritted attributes are coming from.)

@grahamc also didn't like that all this derivation does is fetch the .app for darwin, preferring homebrew for this. But the linux derivation essentially does the same and I wrote this because I want to move away from brew. (Note there was some support for having this in nixpkgs despite "just fetching the .app.")

Did you discuss in private? Because he only left that comment here.

At any rate I'm sure the changes are fine, going to give it the last look over since it has been a week here for me.

We discussed in #nixos-dev or #nixos-chat, not quite sure. I could share the relevant parts of my logs if necessary. Note that these changes were made almost a week ago. I didn't ping until now because I figured people are busy and this isn't high priority anyway.

Thanks for clearing it up @toonn, it just confused me as to where the inspiration for these changes were coming from.

@GrahamcOfBorg build wire-desktop

@GrahamcOfBorg build wire-desktop

@toonn Can you squash your commits?
I'm not sure where to go with the history so I'll leave this up to you.

@worldofpeace, should we worry about the ofborg failure?

Oh, I just now noticed that.

I undid this change when merging staging-next into staging because of a merge conflict. Please open a new PR for staging to reapply the change.

Nevermind, it is in. However, there was a problem with evaluation, see 15564fb.

@FRidh, does this require further action? Would my original approach work better maybe? Then meta.platforms can be evaluated without running into this (if nix is lazy enough).