Re: [GNUnet-developers] AGPL is up to us, says RMS

[ng0]

carlo von lynX transcribed 9.1K bytes:
> It is up to us to decide whether we want GNUnet to be easily 
> abusable like Android, or offer at least Affero style protection 
> to its users. I raised the worry and Christian first asked RMS 
> for an opinion before we'd bring it here. After some debate, RMS 
> concluded that he'll leave it to us to decide as we are the
> experts on the advantages vs the disadvantages of AGPL applied
> to GNUnet, while he says no obvious hindrance.
> 
> The threat scenario is as follows: imagine we do indeed establish
> a secure mail system (pEp) or an entire distributed social network
> (secushare) running over GNUnet, and indeed start nibbling at
> Google's or Facebook's leadership in the respective areas.
> 
> For purveyors of insecure devices such as iPhones, Windozes and
> many Androids it would make sense to offer access to the big new
> social networking hype via the cloud. pEp's or secushare's effort
> would be seriously damaged if the fastest user experience of
> GNUnet comes Google-branded.
> 
> Imagine if encrypted telephony like provided by gnunet-conversation
> ends up being a thing that is included into Siri. "Siri, call up
> Christian Grothoff." Christian would have no way to know that the
> gnunet-conversation is actually being gatewayed in the cloud and
> all of the communication is going directly into XKEYSCORE.
> 
> If cloud-based gnunet nodes are obliged to provide a link to
> their actual source code, we can devise ways to exclude them from
> the network and disincentivate SaaS business models. If they do
> use vanilla gnunet codebases indistinguishable from legitimate
> nodes, we can devise ways that proprietary apps cannot be inter-
> faced with gnunet.
> 
> Christian had a technical worry, that it would be troublesome
> for each GNUnet node to offer a download of its source code. But
> the license text actually speaks of *users* of that GNUnet node. The
> "Corresponding Source" does not need to be advertised to surveillance
> authorities, ISPs or other by-standers. It also does not need to be
> shared with GNUnet nodes that we don't trust, since we are not letting
> them use us. It only needs to be "prominently offered" once we intend
> to communicate with a node and let its users use us, maybe because we
> want to reach out for a specific person on it.
> 
> This is interesting for the DHT use case for example. If a gnunet node
> is being used exclusively for DHT lookups, then we don't need to share
> our source code with that node since there is no user on that node
> using us. That node however must share its source code string with us,
> since we have a user who is making that DHT lookup.
> 
> I would assume that once a trust relationship has been established to
> consider an outside entity a "user" rather than malware, the node can
> then offer an http or gnunet-fs link to the respective source code
> implementation in form of a simple text string on the suitable network
> layer. The hash code is sufficient to obtain the correct source. AGPL
> does not require each device to provide the files physically itself.
> 
> In the case of secushare, that could be very high: after the negotiation
> of a "friendship" (or generally, the authentication of somebody being a
> specific human). Only then contacts begin to legitimately be "users" of
> a contact's node.
> 
> In the case of several other gnunet services, people may need to be
> considered "users" even if they anonymously make use of routing or
> file sharing services, so the source code identificator string would
> become available once it is likely there is a "user" and we intend to
> offer services to them.
> 
> So the ideal placement of this feature may even vary according to the
> choice of services being run. Should the distributed social network
> become all-encompassing, then we simply do not need to offer anonymous
> services to strangers, bots and malware. We can offer anonymous
> services to known humans instead. Not all interactions among gnunet 
> nodes do however qualify as "users using services". Things like network
> size estimation are automatic and excempt from the AGPL requirement.
> We can declare that some protocols are NOT intended for users to
> actively use but rather intended to do their job automatically.
> Revocation is an obvious candidate for that.
> 
> Surveillance authorities can be assumed to participate. They can
> find out which versions are running on the DHT. They can request version
> strings from inbetween nodes in a CADET circuit whenever they are
> granted a circuit to somewhere. They can however be banned from the
> network by the logics of game theory that you implemented in gnunet-fs
> and such. And they can be refused the version string of a node that
> isn't accepting their CADET connection, for example if it is a private
> person's node and the authority doesn't know the shared secret needed
> to establish the circuit.
> 
> So what is an accurate threat evaluation here? Authorities can scan 
> backbone nodes for source code versions. They can not do so with end
> user nodes. Also, it isn't obvious to me if authorities can correlate
> node version strings with physical IP traffic – would they actually
> be able to draw a picture of gnunet nodes if only a subset of them
> has a known IP number?
> 
> I am of the impression that the danger of experiencing a google
> gnunet cloud is a much greater threat than having some heavy duty
> backend servers expose their version strings.
> 
> If the person you are trying to reach out for is sitting with her
> smartphone in my dining room, I am fine that your CADET may pick
> a route passing through *my* smartphone. But if you're an authority
> scanning the network, you shouldn't even know of our smartphones.
> Imagine a GNUnet with a billion participants. Isn't it reasonable
> to expect that "user" nodes on the edges of the routable universe
> will become less likely to be selected for CADET routing, or is it
> something that we have to code later?
> 
> In any case, after the analysis so far I would highly recommend
> to switch to Affero GPL ASAP to disincentivate the SaaS-ification
> of GNUnet later in human history and instead start discussing the
> possibility of a RAGPL (Reproducible AGPL) or a DGPL (Distributed
> GPL).
> 
> "Reproducible" means a legal requirement for all binaries derived
> from the code to be deterministically reproducible from source 
> code, this way creating a technical and legal hindrance to 
> shipping binary backdoors via Linux distributors, Google Android
> and others. I brought this up at the FSFE anniversary celebrations
> and I think it sparked some discussion there.
> 
> Keep rocking the CADET, folks.
> 
> Btw, secushare prototype in the making!
> 
> 
> -- 
>   E-mail is public! Talk to me in private using encryption:
>          http://loupsycedyglgamf.onion/LynX/
>           irc://loupsycedyglgamf.onion:67/lynX
>          https://psyced.org:34443/LynX/
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

Okay, since no one replied so far:

I share the concerns and my wishful license is one where the sourcecode
must additionally be reproducible.

Even though I commited very little in core code, but more on the system
side and currently in fixing up the documentation:
I support the change to AGPL3.