[tor-project] The Tor Project Social Contract

[Mike Perry]

Nathan Freitas:
> On Tue, Aug 2, 2016, at 07:59 AM, Lunar wrote:
> > Hi!
> > 
> > Mike Perry:
> > > I hate to be late to the party, and I hate to start a libre/free/open
> > > flamewar, but I am concerned about the specific language "free of cost"
> > > with respect to our tools in Point #3.
> > > […]
> > > I see nothing wrong with paid versions of Tor tools, paid hardware, or
> > > paid access, so long as the implementations of security-critical
> > > components are open source and auditable. Maybe others disagree?
> > 
> > I disagree. :)
> > 
> > Wealth is already an important factor in one's ability to enjoy freedoms
> > of opinion, expression, and association. If we agree that you can't
> > really exercise these freedoms in the digital world without tools like
> > Tor, I think such access to these tools should not be restricted by
> > how much money you can spend on it.
> > 
> > While I agree that we should find ways to cover costs of production,
> > or that I think it's ok to sell hardware with Tor preinstalled,
> > I believe we should try to find business models that aim to balance the
> > wealth disparities of this world, because I want our work to help
> > balance power.
> 
> I agree with both of you in different ways. Requiring a user to be able
> to compile to get something free is not good enough. 

Yes, I definitely hear Lunar and Kate's concerns about monetary barriers
being real, and I think you're doing a great job getting us to synthesis
here, Nathan. Thanks!
 
> Some longer thoughts below, but I think the spirit of what we say should
> be "Always Free, but Pay What You Can". 

This is good. I am still a little wary about some edge cases around
"Always", especially when we start talking about hardware, but for
pure software, I think this makes sense. More below.

> Using Onion Browser as an example, it is great that Mike Tigas has been
> able to independently support his work on that project by charging a
> small fee for the open-source software he builds. However, it has also
> severely limited adoption, and pushed users to less trustworthy apps,
> because there are many people who don't have the ability to purchase
> apps on iOS due to not having a credit card or being in a country where
> paid apps are not supported (like Iran, I believe). With iOS, there is
> no way to sideload from a free app store without making your device
> insecure, so the only "free as in beer" and secure way to get Onion
> Browser is to know someone who has a Mac, is an iOS developer, and who
> is willing to link your device to their IDE setup.

Ok, I agree with you here. For pure software, I do vastly prefer the
"Always Free, but pay what you can" model, and agree that half-measures
on the "Free" part (such as free source code only) can have really bad
failure modes. To add another bad outcome to your text above: There are
a handful of free OnionBrowser rebuilds in the iOS app store, for
example, but none of them are kept up to date. This is a source of harm
to users who think the rebuilds are kept current, and you have me fully
convinced that it is not a great outcome.

> What I would like to see from Onion Browser, and from all Tor-related
> apps/projects/community members that choose to support this contract, is
> to offer a free version always, and then a pro/premium pay version, or a
> "pay what you can" option, that is functionality equivalent. That way,
> novice users will always have access without any impediments due to
> their economic situation. This is also a model that I would like to
> adopt for Orbot and Orfox, and any app store that offers a built-in,
> easy payment system. Again, users would not be required to use this, but
> for people who already opt-in and are comfortable providing their
> payment information, then it is an easy way for Tor projects to gain
> sustainable grassroots support.

Right. I especially don't want us to frown on people who effectively run
donations campaigns through app stores like you describe above. That
just seems silly.
 
> On the hardware front, we are already working with Copperhead to sell
> premium-priced Nexus phones flashed with their open-source OS, that may
> someday have Orbot built into it. Copperhead offers their ROM free of
> charge for anyone to flash to a Nexus device, but again, that is a very
> serious impediment for non-technical users. What I am trying to setup
> there is a "buy one, give one" program, or again, a "pay what you can"
> system, that is backed by those who can afford to donate money along
> with their purchases.

I don't know if I feel comfortable demanding that people who bundle Tor
in their hardware necessarily adopt a "buy one, give one" model to
adhere to the "Always free, but pay what you can" standard.

Here's another example: Let's say that some major IoT company decides to
use Tor onion services for authenticated, secure, and private device
control. Those devices aren't free, nor is the rest of the software they
run, but this company is more than willing to dedicate engineers and/or
money to improving Tor onion service scalability, and they upstream all
of their modifications to Tor itself.

If we define the social contract to frown on this type of behavior
because the actual product using Tor is not Free, are this company's
engineers not welcome at dev meetings? Should Tor not take funding from
this company?

If the consequences for violating these norms are exclusionary (such as
exclusion from dev meetings, certain mailinglists, team IRC meetings,
and/or community governance), then I think they should aim for the
largest acceptable union of our value systems on software development,
not the intersection. This will ensure that the maximum number of people
will ultimately end up using and benefiting from Tor.

As a related point: tor-core chose the MIT license, not a GPL-family
license, for similar reasons.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20160802/70f78ab3/attachment.sig>