Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 85C1169C6 for ; Wed, 3 Aug 2011 01:18:04 +0000 (UTC) Received: (qmail 68440 invoked by uid 500); 3 Aug 2011 01:18:04 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 68368 invoked by uid 500); 3 Aug 2011 01:18:03 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 68358 invoked by uid 99); 3 Aug 2011 01:18:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Aug 2011 01:18:03 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jeanweber@gmail.com designates 209.85.210.175 as permitted sender) Received: from [209.85.210.175] (HELO mail-iy0-f175.google.com) (209.85.210.175) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Aug 2011 01:17:55 +0000 Received: by iyj12 with SMTP id 12so418620iyj.6 for ; Tue, 02 Aug 2011 18:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; bh=mI2n5SgTDVfKVlJaVw2+oLOEJUA6o5vCTx58jaWQ4Xg=; b=VuybbtXrgCl07KipMQsvuhJWWeHgFln51B8UlZhh10DL8IPtMxrsPAi9W8OH2mMif7 B9Bi3KqkRcu6D1eV1Bsh6JIHqombtlp81as3wSjR5oFWi8YoYmXkfLaBIknYg4RAOfb0 QbHeBKgtVQLAm4XzmWvwmsdunhJTQyAcuydSk= Received: by 10.42.140.65 with SMTP id j1mr4819105icu.512.1312334254660; Tue, 02 Aug 2011 18:17:34 -0700 (PDT) Received: from [192.168.2.4] (124-171-222-136.dyn.iinet.net.au [124.171.222.136]) by mx.google.com with ESMTPS id b6sm212211ibg.31.2011.08.02.18.17.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 18:17:34 -0700 (PDT) Subject: User guide licensing (was: Refactoring the brand) From: Jean Hollis Weber To: ooo-dev@incubator.apache.org In-Reply-To: References: <008a01cc4ee7$ca79e5e0$5f6db1a0$@acm.org> <4E3476BB.8050506@gmail.com> <4E35D47F.6030308@gmail.com> <20110801081049.21190@gmx.net> <4E36BB1E.1050404@ellisons.org.uk> <4E36D9E8.7020303@ellisons.org.uk> <012401cc5091$132df240$3989d6c0$@acm.org> <4E372589.9050100@gmail.com> <4E3745A4.1050404@ellisons.org.uk> <1312247462.2068.46.camel@jean-laptop15> <00f001cc5121$133d8030$39b88090$@acm.org> <1312331550.2110.18.camel@jean-laptop15> Content-Type: text/plain; charset="UTF-8" Date: Wed, 03 Aug 2011 11:17:28 +1000 Message-ID: <1312334248.2110.52.camel@jean-laptop15> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Tue, 2011-08-02 at 20:43 -0400, Rob Weir wrote: > On Tue, Aug 2, 2011 at 8:32 PM, Jean Hollis Weber wrote: > > On Tue, 2011-08-02 at 10:52 -0400, Rob Weir wrote: > >> On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton > >> wrote: > >> > -1 > >> > > >> > I don't understand why there is continued pressing that things not in a release have to be treated as if it requires the same treatment as the content of a release. I thought we had worked a high-level sketch of the user documentation case with Jean Hollis Weber some time ago on this list. > >> > > >> > >> That was something else entirely, ODFAuthors.org, a site that is > >> external to Apache. We're not discussing that right now. What we're > >> discussing is the content at wiki.services.openoffice.org, which we > >> are planning to be part of the Apache OpenOffice project. Two > >> different things. > > > > *I* was talking about the docs produced by ODFAuthors, in my note quoted > > below, and I asked a question that was not answered; the answer was > > about the material directly edited on the wiki, not about the material I > > asked about. > > > > From licensing perspective it is the same, whether it is content in > wikitext or content in attachments to a wiki page. The thing that > would be different would be links to content on external sites. > > If that is not answering your question, maybe you should restate, with > a link to a specific example. The user guides are dual-licensed under CC-BY and GPL, and the past contributors have obviously agreed to those licenses. They have not agreed to the Apache license, and most of them cannot be found to ask if they agree. We can't just relicense the books under the Apache license. What you have said tells me that those books cannot be attachments on a Apache-OOo wiki page. Is that correct? If so, then we can host them elsewhere and link to them from the wiki. Does this also mean that the guides cannot be part of the official documentation set? That's okay with me (not sure what other contributors think), but it seems less than ideal for the project. Examples of the existing user guides can be downloaded from this page and pages linked to it: http://wiki.services.openoffice.org/wiki/Documentation/OOo3_User_Guides/OOo3.3_User_Guide_Chapters --Jean > >> > > >> > -----Original Message----- > >> > From: Rob Weir [mailto:apache@robweir.com] > >> > Sent: Tuesday, August 02, 2011 05:04 > >> > To: ooo-dev@incubator.apache.org > >> > Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding) > >> > > >> > On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber wrote: > >> >> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote: > >> >>> I'd look at it like this: The documentation that is needed for our > >> >>> users to be successful with our product, from end users, to admins, to > >> >>> application developers, that documentation is product documentation. > >> >>> If having it deleted or defaced, without us noticing it, would cause > >> >>> our users some harm, then it is product documentation. If the right > >> >>> to copy, modify and redistribute the documentation is essentially to > >> >>> successful creating and hosting a new port or translation, or even a > >> >>> commercial derivative or an open source fork, of the project, then it > >> >>> is product documentation. > >> >> > >> >> Leaving aside for the moment all the other user-doc type items on the > >> >> wiki, and looking specifically at the existing current set of user > >> >> guides (which are in ODT/PDF format, but made available for download > >> >> from the existing OOo wiki), I'm unclear how they will fit into this. > >> >> They are not currently under the Apache license, and we would never be > >> >> able to track down all the contributors to get them to agree to the > >> >> license and/or sign the iCLA. So are we talking only about future > >> >> updates to these docs? And if so, do you mean that every future > >> >> contributor to these guides during their production must sign the iCLA? > >> >> Or just that only someone with suitable access rights (committer?) can > >> >> put them on the wiki (in ODT/PDF format)? Or something else? > >> >> > >> > > >> > I'd like us to treat documentation like we do code. Not necessarily > >> > the same tools, but the same care for provenance, accountability and > >> > quality, namely: > >> > > >> > 1) We welcome "patches" and "contributions" from anyone, but these > >> > must be first reviewed and approved by a project committer before they > >> > become part of the documentation set. Any such contributions must be > >> > made under Apache 2.0 license. > >> > > >> > 2) Only project committers have direct write access to the > >> > documentation. This requires that they first sign the iCLA. > >> > > >> > 3) All contributions, whether from the public or from committers and > >> > tracked/logged, so we can accurately determine who made a given > >> > change. So no anonymous or pseudonymous patches. A user id that we > >> > can trace to a real email address is fine. > >> > > >> > With code this works by non-committer contributors sending patches > >> > (diffs) to the mailing list, where they are merged in and reviewed by > >> > a committer, and then checked into the repository. With > >> > documentation, using a wiki , we would need a different mechanism for > >> > achieving this. Luckily there are MediaWiki extensions to enable > >> > this. > >> > > >> > I'd like to preserve the immediate nature of editing on the wiki. > >> > That is its strength. But we need to find away to also get this under > >> > project oversight as well. I think we can do both, without too much > >> > annoyance to contributors. > >> >