On Thu, 2012-07-05 at 14:01 -0400, Rob Weir wrote: > 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.
Howdy Dennis, Rob, etc I agree that it is common to see it as a separate page, but can't say that I know of a why, beyond convention. Using a a single TOU for _everything_ from the main site to the blog it would seem easier to move it into the common text, but the one thing I don't want to see is a privacy policy listed in two places ;) I don't have a big preference as to pp in the tou or a link to it. The text in the privacy section in Rob's proposal looks like a straight copy from http://www.openoffice.org/privacy.html with an addition of the paragraph to handle the wiki(s)/forums registration and would need then to update http://www.openoffice.org/license.html also. (I did not check if the stand alone privacy page is linked from anywhere else) > > > 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. OK > > > 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. > > IMO handle this by placing the license for a page on the page, and would not expand the text in the TOU proposal. So I suppose what that means is I would favor a standard footer for the different websites covered, using the current main sites footer as the template, over time. > > 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. A red herring? I don't think so - why should it only be valid if already there. The site references our mailing lists and certainly did, likely still does, IMO a comment on the public nature of mailing lists is really appropriate here. > > > > > 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. I would add one thing (word) here - we have the right to _remove_ any content, picky I know but I would say it directly. > > > > <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. OK > > -Rob Ok - well, I think that the current TOU page should be updated sooner rather then later now - it's been deferred long enough huh? *smile*. I think it is easier to start with simple and embellish as we see fit. so how about let's use this page: https://cwiki.apache.org/confluence/display/OOOUSERS/website-terms-of-use-draft fir a quick white board. Will start from a copy of Rob's text - add my two edits - and lets just work changes if folks have them, if none move it to the website page proper on Monday - sound good? //drew
