openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: Access to wiki
Date Sat, 06 Aug 2011 20:46:13 GMT
On Thu, Aug 4, 2011 at 12:19 PM, Ross Gardler
<rgardler@opendirective.com> wrote:
> On 4 August 2011 15:22, Rob Weir <apache@robweir.com> wrote:
>> The other set of concerns I had was with respect to content license.
>> Today we seem to have a mix of 4 different licenses for contributed
>> content, as well as content that does not have any evident license
>> attached to it.  I realize cleaning up the past is nearly impossible,
>> But is there anything we can do better going forward?
>>
>> In particular, please note that I'd like to encourage IBM
>> contributions of documentation to the project, along with our Symphony
>> work.  For example, we have doc related to enterprise deployment and
>> this is applicable to OpenOffice as well as Symphony.  But if we
>> contribute this under Apache 2.0 and then it is edited by anonymous
>> (or pseudonymous) users who have not signed the iCLA, then our
>> contributions can be immediately contaminated by unlicensed (or
>> incompatibly licensed) changes, making it impossible for us to use
>> future revisions of own doc.  As you can imagine, that would make it
>> very difficult for us, or any other corporation, to collaborate on
>> documentation.
>
> It is for this reason that content that is intended to be part of an
> official Apache release needs to be managed under an iCLA.
>
>> So that's the essential trade-off.  If we require iCLA for substantial
>> content contributors, then you will cause some contributors to stop
>> participating  But if you don't require an iCLA, then you will inhibit
>> participation from corporations.  And note that this is true for all
>> reusable content in the project.  So code, help, documentation and
>> translations.  If we want participation from corporations then we need
>> to have the means to establish and maintain the pedigree of the
>> contributions under a consistent license (or set of compatible
>> licenses).
>
> An approach that works well in some other projects is to use the CMS
> for official documentation. This means that write access is limited to
> those with an iCLA on file. A wiki is made available for user
> generated content where anything goes.
>
> Contributions to the wiki are still under the Apache License V2 and
> thus the committers looking after the wiki can make a judgement call
> with respect to including content from the wiki in the official
> documentation.
>
> This is no different to accepting and applying a patch to code. The
> committer has to make ask herself "does this patch contain significant
> IP, because if it does I need to get an iCLA before applying it".
> Furthermore when the committer finds themselves thinking "hey, this is
> the fifth significant patch from Joe that I've applied with no
> changes" they should propose them as a committer.
>
> The difference between managing code patches and wiki documentation
> tweaks is the fact that the content will diverge over time. So a
> strategy would be needed for dealing with that.
>

You are making a distinction here that is an important one, but it is
not one that has been made in OpenOffice.org previously.  Remember,
with OOo there was no "community" website and a separate "official
project" one.  There was no site for "official released documentation"
and another for "community documentation".  It was one and the same.
So the doc that is up on OpenOffice.org contains all of our core
documentation as well as all of our community documentation.  So
comments on the distinction between the two kinds of websites are
helpful to a point, but don't really show a clear way forward.

As for what comprises a "release" for web-hosted documentation, I
think we need to ponder that a bit more.  Go back to the reason why
Apache cares about releases: quality, license, consensus.  These
concerns are just as true for documentation sets that are made
available to end users on the web, in documentation releases
synchronized to code releases.   This is another example of where the
choice of technology should not be the determining factor, at least
not over other factors like quality, license (== the rights of users
and downstream consumers) and consensus.

There is also the possibility that I'd like to enable, of making
documentation wiki snapshots available as official project releases,
for downstream consumers to modify and release.  This could be done
via wikis, or as export from the wiki to HTML, PDF, ODF, etc.  The
ability to copy and modify is useful as well for larger deployments
who could host and customize the wiki doc according to their internal
needs.

I think what might work is for us to have different zones in the wiki,
or even different wikis, where we can cleanly segregate the official
doc which we consider part of the release from other doc.  As the
contributed doc matures, we could migrate into the core doc set.
Overtime, the core doc set would improve in quality and depth.  But we
still have a way for anyone to contribute material on the community
wiki under Apache 2.0 (or compatible) licenses.

> Ross
>
> [1] http://webodf.org/
>

Mime
View raw message