incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Terms of Service on Forums
Date Thu, 05 Jul 2012 18:01:55 GMT
On Thu, Jul 5, 2012 at 1:25 PM, Dennis E. Hamilton
<> wrote:
> Let's step back a little.
> The markup that I created was designed to morph the Oracle terms of service to one that
was similar but modified to use of ASF as the HOST and eliminate those considerations that
do not apply (e.g., the use of distinct projects on the web site) under ASF custodianship.
> This approach was so folks could compare with what was already in place and produce a
harmonious replacement.
> I'm not a lawyer and not prepared to say what is too much or too little.  I agree that
plain language statements are preferable.  My favorite document of this kind is, after all,
the Creative Commons Attribution Deed 2.0.
> However, there are some essential considerations, it seems to me:
>  1. Privacy should probably be separated as is commonplace on sites of this kind.  Privacy
should extend beyond what is done to support performance of the site and what the monitoring
is, to embrace more clearly what is done with anything that is considered personally-identifiable
information.  In particular, the reliance on email addresses being made visible as a policy
is something that users need to be aware of and why, and the need to be able to contact people
by the e-mail address provided is also a matter of concern.

What I have here is the minimum we need, mainly to satisfy Google, via
their Terms of Service on the use of Google Analytics.  If you want to
add more, feel free.

>     If there is any kind of promise to be careful with personal data, that needs to be
made in a way that the ASF can demonstrate diligence about and the ASF needs to be aware of
the obligation the promise represents.

My draft did not make any promise, so I don't see an issue.

>     Privacy statements should be dated and back versions should be accessible.

Yes, the ToU in general should be dated, etc.

>  2. The Terms of Use should be clear about what the HOST (the ASF) is granting generally
to users of the site and what contributors to the site are granting to the HOST and all Users,
absent any clearly-established special cases (licenses, contribution agreements, etc.).  The
outgoing license is a clear condition of a TOU and not having one for readers of general web
pages seems erroneious.  The actions that the HOST will take without notice and at its own
discretion need to be clear also.

Obviously I disagree.  IMHO, An explicit outgoing license is not at
all necessary in the ToU.  Any public website has an implicit license
that users can read it.  That's all we require as a general statement.
 For most websites in the world, that is all they have.

Beyond that, in a website like ours, with eclectic content under
various licenses, in some cases undetermined licenses, we cannot make
any simple, general and true statement about the outgoing license.

It might be possible to make some extraordinarily complex statement
about the outgoing license the website, but I don't see the value of
that.  In the end we're publishing software, not a website.

It should not necessarily for someone to copy the website and create
derivative works any more than it is necessary to copy posts from the
mailing list to do the same.

>     In this case, I think that the terms of use definitely need to be dated and back
issues available.


> <orcmid comments="more in-line below"/>
>  - Dennis
> -----Original Message-----
> From: Rob Weir []
> Sent: Wednesday, July 04, 2012 06:50
> To:
> Subject: Re: Terms of Service on Forums
> On Tue, Jul 3, 2012 at 11:11 PM, Dennis E. Hamilton
> <> wrote:
> [ ... ]
>> I created an issue that proposed a new terms of use that was consistent with the
Oracle ones for ASF and would have not made this problem worse, as far as I can tell.  That
was long ago and it went nowhere.  The JIRA issue is here: <>.
 Here's the connected issue on our Bugzilla: <>.
 I came to our Bugzilla because LEGAL-104 can't have attachments.  The attachment on the Bugzilla
provides a red-lined transformation of the Oracle ToU into one that could work for the forums,
wikis, and web pages now under ASF custodianship.
> OK.  I read that over.  IMHO it is still too much.   It is dressed up
> in chain mail armour, as befits a big corporation with the risk
> profile of a big corporation.  Large corporations are a magnet for
> petty lawsuits.   But the circumstances are different with the ASF.
> Our main concern is (or should be) clarity and helpfulness to the
> reader, not to protect our multi-billion dollar corporation.  I''d
> also entirely separate the outgoing license question.  This is not a
> ToU question.  That can be covered separate by a "license" link on the
> various websites, which might be simple in some case (incubator site
> is 100% ALv2) and less so on some legacy sites.
> <orcmid>
>   What do you mean by the incubator site?  I disagree about ALv2
>  for since the honoring of ALv2 is more
>  restrictive/intrusive than the incoming grant of legacy material
>  requires.  Furthermore, patent non-assertions were never collected.
> </orcmid>

The incubator site is the one at  Since that site is 100%
from Apache committers, submitted under iCLA, we can state
unequivocally that that site is ALv2.  Agreed?

> So a minimal approach might look something like this, which could be
> applied across all of our websites:
> ----------------------------------------------------------------------
> Consolidated Terms of Use for Apache OpenOffice Websites
> The Apache Software Foundation hosts several websites on behalf of the
> Apache OpenOffice project:
> -- under
> - under
> - under
> - under
> -- under
> By your use of these websites you acknowledge that you have read these
> Terms and agree to them.
> <orcmid>
>   I think it should apply to the site being accessed and from which the
>   ToU is linked. Also, the "By your use ..." without even a click-through
>   the claim of reading and agreement is about as corporate as it gets
>   and indefensible.
> </orcmid>

Defensible against what exactly?  What risk are you concerned about?

> 1. Privacy
> [ ... ]
> Additionally, some of websites  have a user registration systems that
> queries you for information such as name, password and email address.
>  This information is collected, stored and used in order to provide
> you a unique login and to associate that login with your activity on
> the website.  We endeavour keep this information private, but it may
> be revealed to a competent authority under a lawful order.
> By using this website, you consent to the collection of this data in
> the manner and for the purpose described above.
> <orcmid>
>   This might need to be separated for what the agreement is when people
>   register/subscribe and provide information solicited to accomplish
>   that.
>     This seems like too broad an umbrella for what happens when folks
>   register versus what happens when accessing sites versus what happens
>   when sending an e-mail somewhere.
> </orcmid>

It would be good to link to the ToU from any registration.  But note
that we don't always have that access where it is a shared Apache
service, for example CWiki.

Nothing in the ToU speaks about emails, so that is red herring.

> 2. User submitted content
> By submitting content to the website, you agree that this content may
> be hosted on the website, for the benefit of other website users.
> Additionally, you agree that your submissions may be edited, modified,
> translated, copied, within the website.  You warrant that you have
> sufficient rights to any content that you submit to the website
> necessary to grant the above license.
> <orcmid>
>   The "within the website" basically provides no outgoing license to
>   the contribution.  The Oracle ToU is not clear about that, but a

Correct.  Nothing more than the implicit one.

>   counterpart to the incoming license would be very good there.
>   I would not allow stipulation of broader licenses.  That makes this
>   all impossible and is sort of anti-community, it seems to me.
> </orcmid>

Why would a broader license be anti-community?  And remember, we can
never prevent a user from putting a broader license on a contribution.

> If you wish to offer a broader license, to allow 3rd parties to reuse
> your content outside of this website, then you may do so, provided the
> license is compatible with the above requirements.  Apache License 2.0
> is especially recommended.   Please mark the license prominently in
> your contribution.
> <orcmid>
>   To emphasize, this is too burdensome and it creates a problem around
>   permissible use and who determines what that is.  Having bits and

Burdensome for whom?

>   pieces under individual license notices makes no sense.

We already have that, with website, with our incubator
website, and even with other parts of Apache.  Take for example JIRA,
where an attachment can be marked as being a contribution or not.

If you read the iCLA you see that as a committer you have that ability
as well, to indicate in an email, or in subversion, or on the website,
whether or not something is a contribution.

So we're not starting from some pure world where we can assume a
single incoming license.

Another proof point for how this works is with the extensions and
templates websites.  They manage to have eclectic licenses.  So long
as they are each declared, there is no need for a default license or
to exclude per-item licenses.

>     It might be useful to have the conditions for submission to the
>   site be at a place where submissions can happen, and deal more with
>   what the outgoing license is in the absence of any notice to the
>   contrary.
> </orcmid>

If we were interested in enforcing ToU against a user, then yes, we
would make this bulletproof and put it in their face at registration
time and at the time of their contribution.  But I don't see us having
that need.  For us the ToU is more a set of notices that we want the
user to be aware, for their benefit and to avoid confusion.  We're
trying to be helpful.

> 3. Exclusions
> The websites at and
> are not operated by the Apache Software Foundation and are not covered
> by this Terms.
> 4. Changes to these Terms
> We may change these Terms from time to time.  When we make substantive
> changes we will also make an announcement on the ooo-announce mailing
> list.
> <orcmid>
>   These definitely need to be versioned and the older versions archived.
>   I favor having references back to the previous one in a chain
>   that anyone can chase.
> </orcmid>

That would be fine.


> ----------------------------------------------------------------------
> [ ... ]

View raw message