Skip to content
This repository has been archived by the owner on Feb 8, 2018. It is now read-only.

Edit TOS to decouple payins and payouts #4117

Merged
merged 41 commits into from
Dec 2, 2016

Conversation

mattbk
Copy link
Contributor

@mattbk mattbk commented Aug 30, 2016

gratipay/inside.gratipay.com#432 (comment)

I've started a private ticket with our lawyer about revising our Terms of Service to relax our open work requirement. In the interest of time/money, I think the way to proceed is take a stab at revising them ourselves, and then bring our revision to him for review.

Stub out a PR for changes.

Related milestones:

Todo

  • come up with an alias for Participants acting as contributors, so that we're never using "Participant" in a context-dependent way
    • Tried to address in 78edd79 by creating "Giver"
  • more clearly describe the differences between these various roles up from (and clarify that each is a Participant interacting with the platform in a different way)
  • revise the individual sections (e.g. the new 3-5) such that each is limited to describing the obligations of one role. So one section for Owners, one for Participant-contributors, and one for Members
  • rename "Owners" and "Members" to "Project Owners" and "Project Members." "Members" in particular is ambiguous -- since "members," "participants," and "users" could all potentially be used interchangeably in common speech, people may get confused trying to keep them straight when reading through the terms.
  • Probably use different language for the "Work" performed by the project and the work performed by Members for Projects
  • Run changes by @tieguy.
  • Propagate final version to terms-of-service.spt.
  • Email new terms and post as a news item. (Edit TOS to decouple payins and payouts #4117 (comment))

@mattbk mattbk added this to the Decouple milestone Aug 30, 2016
@mattbk
Copy link
Contributor Author

mattbk commented Aug 31, 2016

The way this reads to me is that TWYW is not required, only optional.

That leaves the open work descriptions. Are we loosening "open" to mean "transparent" (as in gratipay/inside.gratipay.com#432 (comment))?

Level 3: Open Payouts ← "open work" according to our current definition
Level 2: Transparent Payouts ← public payouts, but no self-onboarding
Level 1: Closed Payouts ← twyw, but private
Level 0: No Payouts ← no twyw; "team of one" or closed company or what have you

If so, how do we allow Level 0--is it enough that the goal of Gratipay is to encourage Level 0 Teams to increase openness?

@mattbk
Copy link
Contributor Author

mattbk commented Aug 31, 2016

If I get a chance I'll try to work Levels 1-3 in there, otherwise anyone else is welcome to try.

@@ -38,60 +38,59 @@ these Terms.
1. The Gratipay Model and General Rules

1. The Service is a platform to enable Teams of Gratipay Participants to
receive payments to fund Open Work. Open Work means that the Team provides
receive payments to fund **Open Work. Open Work means that the Team provides
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This definition of "Open Work" needs to be modified to include transparent work, or removed and "work" left in its place.

@mattbk
Copy link
Contributor Author

mattbk commented Aug 31, 2016

Are we loosening "open" to mean "transparent" (as in gratipay/inside.gratipay.com#432 (comment))?

Or do we drop "open" entirely, and leave that under brand fit, with the intention of later separately adding in official support for levels of openness for teams that are approved under brand fit? (gratipay/inside.gratipay.com#432 (comment))

@mattbk
Copy link
Contributor Author

mattbk commented Sep 1, 2016

Closing in. Need to define "Take-What-You-Want" payouts, or leave TWYW out and leave payout method open-ended.

@mattbk
Copy link
Contributor Author

mattbk commented Sep 1, 2016

82dddf1 due to

I was expecting to drop the open work requirement from the Terms of Service. After talking with Aaron I think it's going to be best to keep the ToS scoped to actual legal requirements, and leave extra-legal stuff out of the ToS, put it in the Team Review policy as needed.

from gratipay/inside.gratipay.com#432 (comment).

Which means we'll need to change team review (gratipay/inside.gratipay.com#802, gratipay/inside.gratipay.com#803) and the team application, as well as the front page tagline.

@mattbk
Copy link
Contributor Author

mattbk commented Sep 1, 2016

Need to define "Take-What-You-Want" payouts, or leave TWYW out and leave payout method open-ended.

I think we can leave TWYW out of the TOS, which allows for future support of other distribution methods.

@kaguillera
Copy link
Contributor

Looks good to me...do have to get it cleared by our legal department 😉 before we merge this??

@mattbk
Copy link
Contributor Author

mattbk commented Sep 14, 2016

do have to get it cleared by our legal department 😉 before we merge this??

Yeah, we said we'd send a version to look at. I think the idea is to get all the Decouple PRs ready to go and then merge them all at once (this milestone spans multiple repos, otherwise I imagine we could do it as one PR).

@kaguillera
Copy link
Contributor

I figured that we would have wanted to finish the Decouple PR before making this public...so I guess this is blocked for now then.

@chadwhitacre
Copy link
Contributor

Taking a look at this ...

@chadwhitacre
Copy link
Contributor

Rebased on latest master. Previous head was f8d5a22.

@chadwhitacre
Copy link
Contributor

Hmmm ... so "Teams" doesn't really fit anymore, is one thing. That made sense when we required open work, but for "teams of one" shouldn't we just call them something besides teams?

@chadwhitacre
Copy link
Contributor

Maybe "Project" instead of Team?

@mattbk
Copy link
Contributor Author

mattbk commented Sep 20, 2016

"Project" seems pretty standard and self-explanatory. Does it cover "teams of one" who do multiple things? E.g., "Alice's Truckstop, Shoe Repair, and Gumball Factory" isn't a "project," it's another type of entity.

@chadwhitacre
Copy link
Contributor

"Organization"? "Receiver"?

@chadwhitacre
Copy link
Contributor

When a team of one signs up, they don't want to sign up twice (Participant and Team). They want to sign up once and start accepting payments. Hmm ...

@chadwhitacre
Copy link
Contributor

Do we wanna get into #3852 here?

@chadwhitacre
Copy link
Contributor

On the other hand, we do have bbatsov with three four(!) teams:

http://gratipay.com/~bbatsov

https://gratipay.com/cider/
https://gratipay.com/rubocop/
https://gratipay.com/Prelude/
https://gratipay.com/Projectile/

That's a pretty clear "person" and "project" distinction.

@chadwhitacre
Copy link
Contributor

At one point I think I suggested "Brand" as the thing that receives money. Would that cover CIDER as well as Alice's TS & G?

@chadwhitacre
Copy link
Contributor

chadwhitacre commented Sep 20, 2016

The Participant is really about the legal entity, the "Alice Enterprises, LLC" that is DBA "Alice's Truckstop, Shoeshine, and Gumballs."

@mattbk
Copy link
Contributor Author

mattbk commented Sep 20, 2016

bbatsov seems to have made the explicit choice to [do what we intended and] make a team for each project.

We have at least a few people under "blocked by 432" like gratipay/project-review#122. Some of the comments on those teams have been "I don't even know if any of my tiny repos are going somewhere, so why set up a team for each one?"

In fact, we have $100k+ of project owners' money in escrow, and our best
understanding at this point is that that's not a problem in itself.
That'll be something we get to the bottom of with a specialist when the
time comes. For now these terms are simply inaccurate.
As it stood, we were referring to "each Project" before actually
defining the term.
@chadwhitacre
Copy link
Contributor

Alright, I made a pass through! Hopefully we are converging? :-)

Here's the diff with my latest changes. Amidst some tinkering, the two main changes to look for are:

  1. Further standardization of the "can {make,receive} payments ... because of ... and for no other reason" paragraphs.
  2. Removal of inaccurate terms regarding escrow. This is a rabbit hole we can't go down right now, but the terms as they stood were simply inaccurate to how we operate today.

Back to you @tieguy @mattbk! 🏀

@mattbk
Copy link
Contributor Author

mattbk commented Nov 29, 2016

I have no comments.

@tieguy
Copy link

tieguy commented Nov 30, 2016 via email

@chadwhitacre
Copy link
Contributor

I find the sentence that defines the Work to be quite awkward now.

Okay. Can we live with 9361562? I don't like saying just, "each Project" there, because we haven't yet introduced the concept of a Project at that point (have we?). "Each of what Projects?"

If you don't like "may only" in the discussion of making payments, can I suggest "solely"? ("solely because of their collaboration...", dropping the "for no other reason".

Hmm ... dcea849 and 2594b15 were an attempt to harmonize 3.ii and 5.i with 4.ii, based on your comment at #4117 (comment) but then also at #4117 (comment):

May also be more clear to switch from "exclusively because of..." to "because of ... , and for no other reason", but that's a matter of taste.

Am I missing a difference between 3.ii and 4.ii that explains why we wouldn't want them to be parallel with each other one way or another?

@tieguy
Copy link

tieguy commented Nov 30, 2016 via email

@chadwhitacre
Copy link
Contributor

@tieguy Gotcha. In that case, how about e549303? :-)

@chadwhitacre
Copy link
Contributor

Woo-hoo! Don't look now @tieguy @mattbk et al., but I'm pretty sure we just finished this PR! 🙀

@mattbk
Copy link
Contributor Author

mattbk commented Dec 1, 2016

Good job! Three months to the day. 😁

@chadwhitacre chadwhitacre changed the base branch from master to relax-open-work-requirement December 2, 2016 21:24
@chadwhitacre chadwhitacre merged commit 9203f09 into relax-open-work-requirement Dec 2, 2016
@chadwhitacre chadwhitacre deleted the tos-decouple branch December 2, 2016 21:24
@chadwhitacre
Copy link
Contributor

Congratulations @tieguy @mattbk! We've landed this PR! 💃

It's now merged into an integration branch under #4221, whence it will go into master and out into production.

Great work! 👏 😄

!m @tieguy @mattbk

chadwhitacre pushed a commit that referenced this pull request Dec 7, 2016
#4117 (comment)

- [x] A participant may give money to a Project..." this clause is the only mention of money in the entire document; other similar statements make reference to payments, not "money". Probably not a huge issue but maybe something to flag to the payments attorney, or just go ahead and make consistent.
- [x] "The Service is a platform to facilitate this agreement" - earlier, we say the Service is a platform to facilitate payments. I think we should drop/rewrite the first, since I presume this later, repeated phrasing about facilitating the agreement was tailored to address financial regulation concerns.
- [x] "Projects ... must be consistent" and "Gratipay reserves the right..." both seem like they should be in general terms, since they apply to other Collaborators as well, not just Project Owners.
- [x] The three sections titled "Obligations" should be retitled something like "Terms for Givers..." etc., since they contain things beyond obligations.
- [x] The Project is not a legal entity; would it be more accurate to say the agreement is with the Project Owner?
chadwhitacre pushed a commit that referenced this pull request Dec 7, 2016
#4117 (comment)
- [x] Is a Project Owner also a Collaborator? (I think yes, but not 100% clear.)
- [x] Is there an earlier action (before payment) that would make sense for Collaborators to form an agreement with the Project to collaborate? It's somewhat un-natural to say that accepting payment is what forms the agreement; usually the agreement precedes the payment.
chadwhitacre pushed a commit that referenced this pull request Dec 7, 2016
chadwhitacre pushed a commit that referenced this pull request Dec 7, 2016
chadwhitacre pushed a commit that referenced this pull request Dec 7, 2016
chadwhitacre pushed a commit that referenced this pull request Dec 7, 2016
chadwhitacre pushed a commit that referenced this pull request Dec 7, 2016
Per #4117 (comment). Now each item can be referred to by number/letter, rather than as a whole.
@chadwhitacre chadwhitacre mentioned this pull request Dec 7, 2016
21 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants