Licensing of software meant for the commons, and clauses for protecting user data

Perhaps this is one of those situations where modern ideologies of individualism are being challenged by the intersection of social reality and network tech? Maybe individual user accounts are not the way to serve these communities? What if a whole family, village, or [insert social unit here] used a shared account, to which each group member has a unique key? That way if one member loses their device, other group members can verify them on their new device.

@Josh Fairhead Thanks for the Cliff's Notes of all this research. There's so much to take in; it's handy to have a synopsis I can digest quickly. It seems that, although it starts decentralised global ledgers as an assumption, the DID specification is flexible enough to handle messier things like Holochain, Secure Scuttlebutt, Corda, and perhaps even Dat and IPFS. Here's a DID method document for Holochain's DeepKey: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/did:hc-method.md

@Danyl Strype yes, that's exactly how DeepKey is meant to work, so I'm thoroughly on board with community stewardship of people's identities. (In actual fact it's halfway between individual and group control -- the individual still creates their own unique key, but then they empower their community (or a subset of the community) to verify changes to their keys on their behalf.) Dark Crystal is different tech-wise but identical in spirity -- you lean on your community to support you, your identity, and your data.

@pospi could you unpack your scenario that requires central issuance and control of keys? If I understand it correctly, I don't think it and Holochain would be well matched to each other, but I want to make sure I get you before I make that claim. What's the central need -- is it the need to ensure robustness in the midst of people losing their devices and not having a lot of technical savvy?

The important thing is that the participant is always the first authority over their own cryptographic key -- as long as that's satisfied, I think you could bend the spirit of the CAL while still honouring the letter of the law.

Things that come to mind, based on your inquiry:

• What about having the participant create their initial key, and designate this central authority as someone with equal power? You could probably do this without modifying DeepKey, as you say -- just have a threshold of 1 for both m and n. Here's how it currently works with DeepKey:

  1. Alice creates a root seed on her device.

  2. From the root seed, Alice creates a revocation seed and backs it up to paper or USB. This revocation seed has full authority to revoke and reissue any keys for Alice. Then she creates a revocation key from her seed.

  3. Alice also creates her first device key from the root seed. She publishes it to DeepKey, then publishes the public half of her revocation key as the first authority for revoking and reissuing keys for her.

  4. Alice designates other people who have m:n signing authority.

  5. Alice drops her device in a pond and has to buy a new one. First, she creates a new device keypair and publishes it.

     • If she still has her revocation seed backup, she inputs her seed into her new device, which recreates the private half of her revocation keypair. With this key, she signs and publishes the revocation of her old key and the recreation of her new one.

     • If she's lost her backup, she contacts at least m of her n friends and asks them to create and sign a revocation of her old key and a recognition of her new key.

• Instead of a paper backup, what about passphrase-encrypting the revocation seed and publishing it to the DHT? In this scenario you use the herd as your backup. This would require you to fork DeepKey and add this functionality, and the weakness is that it's only as good as your (crappy) password because everyone can download your seed and try to brute-force it.

• Or, you could use something like Dark Crystal and shard your seed among your friends. This assumes that your use case can rely on strong social connections, which might be a romanticised assumption generated by my western brain.

Welcome, lurkers! :)

I'm not familiar with the details of the CAL, but it is the subject of intense controversy, leading to Bruce Perens quitting the OSI over it (Perens was the author of the Debian Free Software Guidelines and the Open Source Definition). I note that the FSF have not yet published an assessment of the CAL. The FSF approach to novel licenses looks only at whether or not they fully respect users' software freedoms, and it's well worth having a browse through the list of licenses the FSF has rejected, and reasons why:

https://www.gnu.org/licenses/license-list.en.html#NonFreeSoftwareLicenses