[okfn-discuss] Data that service users consider private, but want to publish from the service
francis at flourish.org
Mon Jul 21 15:42:50 BST 2008
OK. I suspect then that the wording of this will need clarifying in a
future version, as it sounds like it covers only private secret
"Whose data is open as defined by the open knowledge definition
(http://opendefinition.org/1.0/) with the exception that where the
data is personal in nature the data need only be made available to the
user (i.e. the owner of that account)."
But you're right, need to be careful of the YouTube runaround you give
below. If you have a list of things to consider carefully for
revisions to the definition this should be on it.
On Fri, Jul 18, 2008 at 01:44:27PM +0100, Rufus Pollock wrote:
> On 17/07/08 10:43, Francis Irving wrote:
>> How broad is as "personal in nature" for the purposes of part 1. of
>> the Open Software Services Definition? It seems to only include secret
>> data - for example personal emails, or my private calendar.
>> There seems to me a category of data which is personal/private, but
>> where the data is not secret. It is just the user only wants it
>> using in ways they control. For example:
>> 1) My own blogs posts are data that I'm happy to be publically viewable,
>> but could be sufficiently personal I don't want to give them away as
>> open data (e.g. I might want to tell a personal anecdote in context on
>> my website, but not want it to appear as lines in a broadway musical)
> Sure in that case you wouldn't be using an 'open' license (or even a
> 'non-commercial' type license for that matter).
>> 2) I might want to share photos of myself on a photo sharing site for
>> my friends and anybody in the world to look at there, but for privacy
>> reasons not want them to be taken and used as the next face of
> Sure and again you'd then want to steer clear of an open license.
>> Which leads to the more general question - if the users of a service
>> want to manage their own data with the service, but they want that
>> data to be neither open nor secret (but somewhere inbetween), can the
>> service still be OSSD?
> Hmmm. My first instinct is to say yes. However, i'm concerned this might
> allow end-runs around the intent of the definition. For example, what
> about YouTube. If I remember the ToS there basically give YT the right
> to redistribute but no-one else.
> Nevertheless, this an example where the material is user's material and
> so I think we should stick to the line that has been drawn. It is only
> if it data used as part of the service and *not* supplied by users that
> one has an obligation to make it openly available (remember that user
> data must be made available for users to extract in an automatable and
> complete manner though).
>> So for example I could fork gitorious (an open source code hosting
>> service http://gitorious.org/projects/gitorious), and allow secret
>> repositories, with a simple interface for getting your data out of
>> your private repository (git pull :). Call this fictional site
>> private-gitorious. I think it would comply with the OSSD.
> Yes I think it would.
>> Then suppose I fork gitorious, but let people host in public non-open
>> source software on it, but for which the source code is available
>> (e.g. Microsoft shared source style). Call this shared-gitorious. I
>> would still make the source code of gitorious open (I'd have to, by
>> the Affero GPL), and obviously people would be able to get their own
>> data. Indeed, anybody would be able to get anybody's data. Just
>> *other* people wouldn't be able to reuse it.
> Sure but I think we need to be clear here what is the service and what
> is the content. The service here is the gitorious. This service exists
> to *host* user material. That material is not actually part of the
> service but what the service supports (in this regard Wikipedia is
> different -- there the content/data is an essential part of the
>> In many ways private-gitorious is more "closed" than shared-gitorious,
>> yet it is, I think, more clearly OSSD compliant.
> I think both are compliant.
>> Apologies if you've covered this already.
> No, these are excellent questions. I'd be interested to hear others'
> take on these matters.
Stamp your MP! -- http://www.theyworkforyou.com/video/
More information about the okfn-discuss