On Thu, Jul 5, 2012 at 1:25 PM, Dennis E. Hamilton <dennis.hamil...@acm.org> 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. > Sure. > <orcmid comments="more in-line below"/> > > - Dennis > > -----Original Message----- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Wednesday, July 04, 2012 06:50 > To: ooo-dev@incubator.apache.org > Subject: Re: Terms of Service on Forums > > On Tue, Jul 3, 2012 at 11:11 PM, Dennis E. Hamilton > <dennis.hamil...@acm.org> 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: <https://issues.apache.org/jira/browse/LEGAL-104>. Here's the >> connected issue on our Bugzilla: >> <https://issues.apache.org/ooo/show_bug.cgi?id=118518>. 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 http://www.openoffice.org 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 http://incubator.apache.org/openofficeorg. 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 openoffice.org > > - under incubator.apache.org/openofficeorg > > - under cwiki.apache.org/confluence/display/OOOUSERS > > - under issues.apache.org/ooo/ > > -- under blogs.apache.org/ooo/ > > 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 openoffice.org 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 extensions.openoffice.org and templates.openoffice.org > 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. -Rob > ---------------------------------------------------------------------- > > [ ... ] >
