Let me say that differently. Since past software has been centrally controlled and administered, it was assumed, that the license-holder of a database owns the data in the database, as well as controlling whatever user accounts and permissions exist for accessing it. Even the most open of organizations (like Wikipedia, who lets you download copies of their databases) can still terminate user accounts or purge spammy advertisements from their database, because it runs on their centrally controlled servers.

Think of your corporate email account. The company you work for can change your password, lock you out of your own email, and they own messages sitting on their server. They control both the identity and the data.

However, what happens when software no longer runs on a central server, but each person publishes data to their own local storage first? Then when that data is intended to be shared, gets published to a shared space (DHT) from your local store. Since Holochain is structured this way, by default each user controls their own data, and via our key management app, they control their own identity, even across any and all Holochain applications. So if a corporation wanted to run a Holochain application under centralized control, instead of generating your own app keys and revocation keys, a corporation would do that and maintain control the revocation keys, so that they could kick you off the system at any time.

On Holochain, to accomplish the old pattern of centralized control that is assumed by software licenses of the past, you essentially have to strip away each user’s control of their own cryptography by owning their keys. This seems like a very different category of USAGE of the software, than Holochain’s native design where users control their own data and identity, thus it merits a different class of license. This isn’t about whether you can copy or change the software, but about how you structure the cyrptographic relationship to users and data generated by the software.

Introducing the Human Commons License

If people run your Holochain app as network of autonomous humans, where each one manages the keys that control their data and identity, then you are operating a “human commons” and operate under that classification as Holochain apps are intended to operate.

However, If you structure the management of keys for the people running your hApp such that you can revoke their keys to the hApp or if you have required them to agree to be stripped of their ownership of data they’ve authored, then this is a commercial classification of the software (not autonomous humans, not a shared commons among them).

We’re still sorting out some of the details for each classification. For example, in the Human Commons case, the software license may be fully free and permissive (like MIT license?), where the commercial usage may be more restrictive (like GPL) such that you’re at least contributing new code back into the commons if you’re taking away people’s identity and data.

However, this classification may be more important to the apps running on top of the Holochain software, than the effect it has on your rights to Holochain. Distinguishing these different usage types at the underlying level lets apps more effectively choose how they want to charge customers. Consider an app like P2P Slack where everyone controls their own data and identity, in contrast to one where a corporation owns the data and user accounts. The builder of that hApp may want to give it freely to those operating a commons, and charge for usage in the corporate case.

New Distinctions in Licensing

Whether you agree with our explorations of increasing restriction on commercial use or not, the point of this article is to call out the importance of distinguishing the fundamentally new patterns of data ownership and identity as part of software licensing concerns for truly P2P software.

In addition to the topic of control of your own data and identity, authored by you and stored on your own device, is the matter of data shared to into a shared space (in Holochain this means published to that apps DHT). For this we look to licenses like Open Data Commons for models there.

What else should we be considering to get licensing of P2P apps right?

Thanks to Eric Harris-Braun. Some rights reserved

The post Licensing needs for Truly P2P Software appeared first on P2P Foundation.

important update, 2018/02/06: a new version of the proposal, completely rewritten to take into accounts recent developments and feedback, is HERE.

Preface

A percloud (permanent/personal cloud) is my own vision of a “REALLY usable, all-in-one alternative to Facebook, Gmail, Flickr, Dropbox…”.

I made the first percloud proposal in 2013. Very soon, however, I “froze it”, for lack of time and resources, and did not do any real work about it, for reasons I have explained in detail elsewhere. Then, at the beginning of 2017, several things happened, including but not limited to:

• The percloud proposal was mentioned here, causing several people to contact me to discuss the idea in detail, showing to me that it may still have some value
• In parallel, the Free Knowledge Institute, of which I am a Board Member, had started some work in Barcelona on a collaborative/community cloud platform
• Other groups have started to work on similar platforms on their own, and invited me to participate
• I did some homework to catch up with the “latest” developments in this space, and discovered that things look much better than they did in 2013

What I mean with the last bullet is that, thanks to projects like Sandstorm, Cloudron and several others, building what I call a “percloud” should, indeed, be easier than in 2013. “Easier” does not mean “easy” though, and I have realized several things.

First, integrating and polishing the several software components, until they are actually usable by non-geeks is still nothing one could do on his spare time (not me for sure, anyway). Second, personal clouds will be easily adopted by non-geeks ONLY if they are offered as a managed service: this means there must be web hosting providers that offer really turn-key perclouds.

Third, a real pilot/field trial of the percloud is needed. Because on one hand, we need many, ordinary Internet users to use the package, and tell us geeks if it works for them or not. On the other, we need to give wen hosting providers some real world usage data of these personal clouds, so they can figure out how much it would cost to offer them as a service.

Taken together, all these things have lead me to put together the proposal below.

Important: as I said, I’m already discussing similar cloud platforms with several groups. But I do not see this proposal in competition with the others. This is all Free as in Freedom software, and the more is shared and reused, the better! Much of what is proposed below may be directly reused in those projects, or similar ones, if not co-developed together.

Now, please look at the proposal, share it as much as you can, give feedback and, since this page may be updated often in the next weeks, follow me on Twitter to know when that happens. THANKS!

Percloud proposal, 2017 edition

Percloud definition and features

Purpose: personal, permanent, basic, online web presence and communication, that does replace {facebook+gmail+dropbox} today. Very little or nothing more. The target user is the average user of facebook, gmail, instagram, dropbox, google drive and similar services, who seldom, if ever, visits the rest of the Web. The goal is to make it possible to these people to get outside today’s walled gardens, as soon as possible. Once that happens, it will be much easier to move the same people to more advanced platforms. Advanced users for which this service is too little/too limited still need something like this for all their own non-geek contacts, if they want their communications to stay private.

Services offered

(regardless of which software implements them…)

ONLY the very basic ones, that everybody would surely need, e.g.:

email, blogging, calendar and address book, basic social networking, online bookmarks, save web pages to read them later, online file storage (personal files, pictures galleries).

common essential features of all services

• Inclusiveness (“equal opportunities cloud”?): the percloud must be an accessible service even for the many people who, these days, have a smartphone, but NOT broadband, fixed/safe residence, reliable electricity… (think students, but also refugees, migrants, homeless…)
• Available as a service (PEAAS, Percloud As A Service): even many target users who could run their own hardware server at home will prefer the convenience of not having to worry about any additional device
• Federation (where applicable): that is automatic notification of relevant events among different perclouds (e.g.: user A uploads a public picture or status update, her contacts see a notification about it in THEIR clouds, and can comment it, and be notified of each other comments…
• Social Connectivity with Facebook, Twitter, Gplus… and interface to online storage services like e.g. Dropbox… Google Drive
  • here “social connectivity” means a) possibility to automatically publish a status update also to Facebook, Twitter etc… and b) fetching Twitter timelines or Facebook notifications with systems like these http://www.techrepublic.com/blog/linux-and-open-source/how-to-access-facebook-from-the-command-line/ and showing them INSIDE the percloud interface. Interface to storage like Dropbox is the same as in owncloud/nextcloud
  • PURPOSE: the target users will NOT move to this if it means burning bridges with their friends already on Facebook, etc.. No way.
• As little choices and configuration options as possible: “You can have any color as long as it’s black.” For the target users, this is a feature, not a limitation
• ARCHITECTURE:
  • 100% server-based. A permanent online home, and important data, cannot live on a smartphone or laptop, which may be stolen, or run out of charge every moment.
  • in practice: micro-vps: bare-bone Linux with all and only the services listed above, that can run on raspberry pi, normal PC, virtual hosting in a data center… also because of…
  • HIGH performance, i.e. RAM and CPU requirements as low as possible. Reasons: a) a really personal cloud of this type has very low needs anyway; b) only if it is possible to host MANY of these VPSes on one physical server it is viable to offer this as a managed service. Ideally hosting one percloud in a data center should not cost more than a few USD/month
  • REAL, almost turn-key portability from server to server. This includes automatic set up, at creation time, of own domain name, e.g. “marco-percloud.com”, so that even when changing server all connections with the rest of the world stay the same. There is no real freedom or data ownership if one cannot move her own data from one physical place to another without losses or disruptions of communications.
• MANAGEMENT:
  • complete separation of user interface and admin interface
  • remote administration also possible via command line
  • reason of 2 previous requirements:
  • PAAS providers can only afford to offer the service if administration (creation, software updates etc…) of many perclouds can be fully automatized *if admin is a separate account, it is possible to manage or give perclouds as “gifts” to minors, senior citizens, or everybody else who would like to use a percloud, but cannot or does not want to manage it themselves
  • automatic daily backup to other server
• USER INTERFACE:
  • Accessible from any modern Web browser, from any device (i.e. NOT locked to phone numbers or anything like that)
  • But REALLY usable on smartphones! Many target users only use their smartphone for any digital service, and will not accept something that THEY find hard to use on their preferred device

Possible base software platform:

• barebone GNU/Linux distribution (debian? TBD) +
• SUBSET of the cloudron.io environment with ONLY these applications and 3rd party additions
  • owncloud or nextcloud (online file storage, picture galleries, office suite too?)
  • Lychee (photo management)
  • SoGo or Radicale? calendar and contacts
  • Wallabag (“Read later”/personal web archive service
  • RocketChat
  • Rainloop for webmail (but see “3d party SW” too, below)
  • Ghost for blogging (static blogging with markdown editor is simpler and safer than wordpress, and should require less RAM. See performance above)
  • Wekan or Kanboard?
  • Piwik
  • 3rd party software, i.e. packages not in cloudron today, but that would be nice to have IMO:
  • movim.eu (social networking like that is crucial, IMO)
  • mailpile for webmail?
  • shaarli (nice online bookmark application)
  • SSL key management for web and email servers
  • GPG signatures management

Note on interface integration and “real time interactivity”

The several components of a personal cloud as proposed here would share user authentication, and communicate with each other, as smoothly as possible. However, they cannot have a completely homogeneous look and feel as, say, the several features of a Facebook account. Such an integration is simply outside the scope of this proposal, because the only (but crucial) purpose of the percloud is to test and offer something actually usable, as soon as possible: see the “we need it SOON” part of this post, which is even valid now than it was in 2014, to know why.

As far as “real time interactivity” goes, the percloud must offer federation, that is let “friends” who own different perclouds see what each other has published, comment it, get notification, chat, and so on. However, percloud-based social networking does not even try to achieve the same numbers and levels of interactions and notifications of Facebook or similar platforms. This is a feature, not a bug. Facebook bombards people with real time notifications (“Jim tagged you”, 3 years ago you posted this”…) because it exists to… make people stay as much as possible inside Facebook. A percloud, instead, exists to let you interact with your contacts when you need or feel like it. It does not need to be so invasive and stressful.

Looking for sponsors

The contacts and discussions I had at the beginning of 2017 convinced me that a percloud available as soon as possible may still have a lot of value. The same activities also showed me that it should be done quite differently than what I imagined 4 years ago.

In order to build a percloud and test it “in the field”, together with the cloudron developers, it is necessary to have sponsors for: * adding the missing parts * integrating and documenting everything * CRUCIAL: deploy and manage a “large” scale field test/pilot in which e.g. 1000 people are given one percloud for free, for 12 months, in exchange of giving feedback on usability, etc… and allowing basic monitoring of percloud usage (e.g. number of posts and visitors per month, etc). Without this, i.e. without knowing for sure how the actual target users react to the percloud, we cannot make it succeed

As far as hosting goes, the test perclouds may be hosted on lightsail or similar platforms. But it would be great if community-oriented hosting or connectivity providers like guifi.net or mayfirst.org wanted to participate. If you know of any organization or group of organizations who may be interested in sponsoring such an activity, please let me know.

Further suggested reading, added on January 30th, 2018

• The fix for Facebook is NOT a different PLATFORM

• The percloud is still only a proposal. For everybody

• My proposal to integrate the percloud with the Eelo operating system for smartphones

• My posts on Mastodon, online identity and the need to put INDIVIDUALS before “platforms“

Photo by kndynt2099

The post Proposal: the Percloud, a permanent/personal cloud that is a REALLY usable, all-in-one alternative to Facebook, Gmail, Flickr, Dropbox… appeared first on P2P Foundation.

Following the links from Slashdot I discovered this interview to the arkOS developer and even more projects in the same space that I didn’t know: buddycloud, Personal Clouds and unhosted.

After a look at those projects and a few email and tweets exchanges, including the explicit question “why not just help the FreedomBox Foundation, instead”, I came to two conclusions.

First, I’m happy that all these projects exist. On one hand, they prove very well my point that now is THE moment for personal clouds. On the other hand, they make my own work much easier and more likely to succeed (if it does start, see below) because they are already doing parts of it.

In the second place, just because of what I read about those projects, I still believe that there is space and need for the percloud as a separate effort. Before explaining why, let’s deal with the FreedomBox question (which was already a FAQ anyway…):

Q: why not just help the FreedomBox Foundation, instead?

• because @FreedomBoxFndn itself seems uninterested, and that’s PERFECTLY fine, of course!!
• because it’s a bit like asking “why don’t help Debian to become Ubuntu, instead of forking it?”
• I have no problem to help whoever is working towards certain goals. That’s why I explicitly said since the beginning that all my work would be “Free as in Freedom” code and documentation. However, at this point my only feasible way to help is to get paid to do the percloud “phase 1” myself

What about those other projects?

arkOS is “a Linux-based operating system… designed to run on a Raspberry Pi – a super-low-cost single board computer – and ultimately will let users, even of the non-technical variety, run from within their homes email, social networking, storage and other services”. It also seems a very flexible, general purpose environment, not a locked-down (=much simpler to use) one. Buddycloud is (emphasis mine) “a set of tools, open source software and protocols to help you build a completely new kind of social network.” Unhosted is about “serverless”, “client-side”, or “static” web apps. “Personal Clouds” is, if I understand correctly, a great, complete ecosystem of web apps, (tools to enforce) user-controlled Terms of Service agreements, network services etc…

The percloud, instead…

The percloud is just another GNU/Linux distribution, and this is a good thing. It will certainly be possible to run it also on a Raspberry Pi, or any other computer hosted at home, but I do not want to tie it to any specific hardware device. I want to build one single blob of software that can run on everything from data centers to home computers, with the smallest possible set of external constraints or dependences.

ICT experts will tell you that only a cloud running on computers you physically control can provide the greatest possible privacy, or that stuff like buddycloud or “Personal Clouds” could become much more complete and scalable than the percloud. Let me say one thing: they would all be right!

In my opinion, however, a really portable, software-only, relatively “quick and dirty” percloud as I am proposing shoud still be done and widely adopted for (at least) these reasons:

1. If somebody is sleeping in a burning house, you don’t wait until another house, at least as good as that one, is ready: you wake them up and tell them to get out NOW, to take shelter in whatever refuge you can set up in a hurry. PRISM and friends prove that we should really start to deploy realistic countermeasure soon. We can’t wait until greater but complex platforms or, even worse, actual alternative Internets like this are ready.

2: It is certainly not done on purpose, but ANY version of “running your cloud on some hardware you own and keep at home” is limited to minorities. We can celebrate Raspberry Pi for being “so cheap” (terribly relative term, don’t you think?) all day, but the reality is that only people with affordable and reliable electricity and flat rate broadband and reasonably high confidence that their home hardware wouldn’t be stolen or sequestrated could use arkOs as proposed. And that’s not even the biggest issue, because…

3: in my opinion the real, or at least the most urgent problem, is social and psychological, not technical. While the real solutions to PRISM-like issues are not technical, we can’t get there unless a lot of average Internet users are willing/prepared/able to get there. We need awareness and confidence much more than “platforms”.

Today, most average Internet users can’t see at all how replacing with something open the corporate walled gardens in which they currently live could ever be within their reach. Or why they should want it in the first place. I want to prove to how many of those users as possible, as soon as possible, that they can live online outside those walls. Why should they care if their first “refuge” may not be everybody’s ultimate, perfect digital home, since they could leave it whenever they wish for something better, without losing their data?

Let average Internet users get something that is really easy to use and, in many cases, perfectly adequate as-is for all their needs and skills. Do that, and they will all become both able and, often, willing to move to other, more complete solutions when they (both the solutions and the users…) are ready. But tell the same people that they have to either buy/configure/use extra hardware, or that they have to enter more than a handful of configuration parameters and they’ll NEVER get started.

This is why the percloud, by design, won’t be some ultra-flexible environment able to do whatever cloud computing you may want. It will, instead, be the simplest possible replacement for the main cloud activities that the majority of cloud users needs, with as little as possible initial configuration.

Final note for software hackers:

Software hackers who already run their own servers won’t need a percloud, but they should still recommend it to all their non-hackers friends. It would be the most realistic way to make sure that all email and other content they exchange with those friends does not end up on some centralized server that makes centralized, large scale surveillance much easier.

Of course, nothing of this will happen…

(not from me, at least) if you don’t whatever you can to fund phase 1 of the percloud. Thanks for your support!

The post The real problem that my p2p/personal cloud wants to solve, and why it’s still necessary appeared first on P2P Foundation.