[FoRK] Open service analysis

Luis Villa <luis at tieguy.org> on Tue Oct 9 09:01:49 PDT 2007

Good to hear from you, Jared.

More inline.

On 10/8/07, Jared Rhine <jared at wordzoo.com> wrote:
> Luis Villa wrote:
> > No, no, bring them here. I think this is a very interesting space too
> > (though also count me as skeptical in the commercial-viability camp.)
> >
> > Note that in the broader world I'm working on an open services definition:
> > http://tieguy.org/blog/2007/07/22/evaluating-a-freeopen-service-definition-rough-draft/
> >
> > which has been discussed here before.
> >
> > Also, possibly of interest is the recent open-sourcing of connector,
> > which does calendaring/mail/document sharing/shared tagging stuff and
> > looks pretty nice (though I haven't actually installed it yet.)
> >
> > http://joyeur.com/2007/07/13/connector-and-slingshot-open-sourced-and-free

[Tangentially, I signed up yesterday a free Joyent account... it is a
little bizarre- very, very polished in many ways, but completely
broken in others. This is 2007. I should not need to refresh a webpage
to see if I have new mail.]

> This is an open call (to Luis Villa and other interested parties) to
> dive into the Chandler Project's claim to be running an open service:
>
> http://blog.chandlerproject.org/2007/08/30/chandler-hub-as-an-open-service/
>
> In particular, our terms of service and privacy policy:
>
>    http://chandlerproject.org/tos
>    http://chandlerproject.org/privacy

I'll note here that I don't much care about the privacy policy- in my
mind, if the rest of the service is really open, competition will do a
good job of taking care of the privacy policy. (Analogous to the
security policy of a Linux distro- the kernel's license doesn't
dictate that the distro must be secure; the process of competition as
a result of open source means that every serious distro has a good
security team, though.)

As far as the TOS:

> Our TOS and Privacy Policy came out longer than I originally hoped.

Happens to the best of us, and really, pretty good compared to most
peer agreeements.

Other thoughts:

* as noted below, point #13 should be changed so as to require
notification on your part, perhaps merely a good faith attempt to
registered email addresses.

* I would love to see a promise that you will make a good faith effort
to allow people to get their 'user content' back out of the service.
You can of course back out of that under #8, #9, and #13, so it
doesn't mean much, but ideally #13 has a notification requirement.

* to the extent that Chandler's tech allows forwarding, I would like
to see a promise that Hub will allow me to forward things unless I
violate the ToS. (For example, gmail lets me use luis at tieguy.org to
'hide' my use of gmail, and lets me forward luis.villa at gmail.com
elsewhere. I'd like to have the same ability with Chandler/The Hub,
and I'd like to have it explicitly spelled out that it isn't a
violation of the ToS to do so.) This protects my identity, as you've
already protected my data. (I admit I'm not sure yet how this would
read.) See previous point re #8, #9, and #13.

* in #3, I'd want to see instead of OSAF's reserved right to delete
data, I'd want to see OSAF reserve the right to take data out of
public availability, notify the user of intent to delete, and then
delete after a reasonable period. See previous points re #8, #9, and
#13.

> There appear to be good reasons for each section at least, so I wrote up
> the "summary" section at the top of each.
>
> The two documents aren't finely polished and I could use some eyeballs
> from people who enjoy ripping holes and finding contradictions in such
> documents.  We really do want them to be as consumer-friendly as we can
> without preventing us from actually running said service.

Completely understandable. For my part, if the principles I'm thinking
about prevent people from running a service, they're flawed. I've
already made more than a couple changes to them for that reason.

> One aspect of the terms that we've struggled with is the "users can
> request their data be wiped before a change in ownership" (which we did
> not add to our docs).  It seems like a great policy to add, but I'm
> concerned I don't understand all the implications of the data sharing
> model we have.  If you publish a calendar, and share it read-write with
> some friends, and your friends edit some events, who has the right to
> have that content deleted?

Really complex question. My usual thinking on this is that once you've
shared (either with the public or with friends) the data becomes part
of a public commons and you can't unilaterally retract/delete it- the
only thing you have an absolute right to delete is stuff you haven't
shared. But that thinking was developed with something like flickr
comments in mind, which aren't typically canceled in the way you might
regularly cancel an appointment. Not sure how my thinking interacts
with appointments that it would be nonsensical to make irrevocable.

> It also seemed like any "delete your data
> during an ownership change" term should be generalized to a "you can
> delete your data at any time" term.

Couple things here:

* I think 'delete at any time' is a good policy, but you also want to
specify that 'if there is a change in ownership who would change this
policy, you have X days (or whatever) to delete before the policy
changes.'

* same policy should apply to data export- if there is a change in
policy which would reduce my ability to export my data, I should have
X days to do the export before the policy changes.

>    http://tieguy.org/blog/2007/10/07/some-freeopen-services-links/
>
> I'm the author of the chandler-hub-as-an-open-service post he
> references, so I can state definitely that it's certainly not too late.
>   Luis, feel free to contact me directly, here on fork, or direct me to
> a more appropriate forum like okfn-discuss.

Cool. I think actually it might be interesting to talk about a bit
here- I'm pretty sure I can predict what every participant on okfn can
say, so a little variety in input can't hurt :)

Luis --verbose

More information about the FoRK mailing list