On Sat, Jul 7, 2012 at 11:31 AM, drew <d...@baseanswers.com> wrote: > 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 > > +1 Drew
-- This Apt Has Super Cow Powers - http://sourcefreedom.com Open-Source Software in Libraries - http://FOSS4Lib.org Advancing Libraries Together - http://LYRASIS.org Apache Open Office Developer wolfhal...@apache.org
