Re: IPO of an Open Source Project

On 12/21/2012 04:23 AM, Andrew Miller wrote:
> Since you brought up regulations... is there a summary of Web 
> Payments from a legal point of view?

Nope, haven't had the time to do so yet. It's also a fairly complex area
depending on exactly what part of "payments" you're talking about.

> When do I become legally liable for a payment?

In general, when you enter into an agreement (verbal or non-verbal) to
exchange a product or service for your money. This can happen in a
variety of ways:

* You click a payment link and enter your payment details into the form
  and then click pay.
* You sign up for a service and sign a contract or execute a
  click-through agreement to pay for any charges incurred as you use
  the service.
* You pre-pay for a service or product.

The list goes on. Each item above can usually be challenged in a court
of law. So, there is no hard-and-fast rule for when you become legally
liable to pay.

For example, does knowingly viewing an illegally acquired DVD at a
friend's house make you liable for payment for the actual product? Does
it make your friend legally liable for two counts of copyright
infringement since both you and he watched the DVD?

> Does the presence of a "digital signature" make the difference 
> between liable and disclaimable?

The presence of a digital signature makes it much easier to verify that
the person that executed the signature on the digital contract had
access to the software or system that made the signature. Now, that
person could still claim that it wasn't them and was their cat that
accidentally made the purchase by walking across the keyboard.

So, while a digital signature isn't foolproof, it is much better than
nothing, and better than a hand-written signature (in most cases).

Digital signatures are also easily machine verifiable, meaning that you
don't have to pull in a handwriting/signature analyst to verify the
signature. Machines can't determine liability (yet), but they can
certainly determine disclaim-ability, as you point out above.

> And is this legal liability the essential difference between 
> "intents" and "payment"?

If we're strictly speaking about PaySwarm, it depends on a variety of
factors.

With the basic PaySwarm spec, payment means that you are provided a
digital contract for an asset for sale and you decide to pay, or not
pay, for it on the spot. The liability depends on the terms of the
contract, but in general, you don't assume any liability since your
payment is sent before the product or service is rendered. The liability
assumed is typically by the seller to deliver the product/service to you.

With payment intents, there are some use cases that we're looking at
that don't make you liable for payment and some that do. We are
designing "Payment Intents" as way to signal "I would like to fund", not
"I will fund". This is a bit different from the models that exist out
there already (ignoring equity and debt-based crowdfunding). Namely:

1. All-or-Nothing crowd-funding models
2. Always-Paid crowd-funding models

With All-or-Nothing funding models, sites like KickStarter make you
assume a liability when you promise to fund a project. When you say
"Yes, I want to fund this project", you are giving KickStarter the right
to pull funds from your credit card if the project reaches its goal. You
are liable for payment if the project reaches its goal.

The same is true for Always-Paid crowdfunding models, except for that
case has the crowdfunding platform pull the funds from your credit card
immediately. Your liability is very limited (the time it takes to
process your credit card). If you can't make the payment, your liability
is typically forgiven.

Kickstarter does a 1-phase collection effort by charging all the credit
cards it has on file and forgiving the liability for the funders whose
credit card was rejected. This has a down-side where not all funds that
were promised will actually make it to the project being funded. That
is, if 20% of the credit cards are rejected, then only 80% of the money
is delivered to the project.

PaySwarm's Payment Intents do a 2-phase collection effort. The first
pass is to contact all of the PaySwarm Authorities that have people that
intended to fund the project and say something like "I'm performing
collection for this Payment Intent, move all of the funds associated
with it into escrow for the next 15 minutes". If the total of the funds
across all PaySwarm Authorities exceed the amount in the agreement, then
the second phase collects all of the funds and disburses it to the
crowdfunded project. This guarantees that the project will always hit
the goal it setup on the website.

If it turns out that a number of funders cannot pay, or some of the
PaySwarm Authorities are down, then the second pass doesn't happen and
the amounts are eventually released from escrow.

We think we're going to allow the crowd-fundee to collect at any point
that they hit their goal in the all-or-nothing model, and then the fund
will work like an always-paid model from that point onward. So, the
benefits of the PaySwarm Payment Intents over the current state of
crowd-funding is:

1. The solution is decentralized, is an open standard, and works across
   any number of PaySwarm Authorities and websites.
2. There is no long-term liability created for the funder when
   crowdfunding via PaySwarm.
3. The project is guaranteed to get 100% of the funds they wanted to
   raise (minus PA fees).
4. The project can collect money as soon as they hit their target,
   switching all future payments to be immediately collected.

> Or, is this not part of the design spec, but rather part of a 
> secondary/subsequent process that we can't formally anticipate?

The mechanism for collecting funds is part of the spec design. However,
the liability aspect can vary depending on the license/agreement offered
by the project raising funds. I'm sure this response raised more
questions than it answered :), so feel free to follow up with more
questions on the parts that are not clear.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Problem with RDF and Nuclear Power
http://manu.sporny.org/2012/nuclear-rdf/

Received on Friday, 28 December 2012 23:12:25 UTC