incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Access to wiki
Date Thu, 04 Aug 2011 17:58:14 GMT
The appearance of this being a binary condition is becoming a point of ridicule and humor.
 Also, I think we are missing how powerful the social dimension is (plus the need to maintain
a sense of humor about it):
[The additional humor is about this comment being applied to an un-conference, something I'm
sure the commenter understood, yet the Apache association/stigma/ooo-dev thrash inspires the

I agree with what goes in releases.  There is no issue there.  Trying to make everything that
gets contributed be covered under the release requirement for the satisfaction of hypothetical
downstream corporate use, which is how this is very easy to spin, is not going to win us any

I much prefer us to deal with this on individual, specific, concrete cases.  As long as there
is permissive use for big chunks, we need to avoid solving problems that we intend not to
have, lest the law-of-unintended-consequences imposes an unaffordable tax.  With regard to
existing materials, we will have to simply deal with what those are.

This gets concrete by bringing the user-edited/-contributed portions of over
onto Apache infrastructure (to ensure its preservation and operation) and then looking at
the reality of what's there and what the adjustments need to be.

 - Dennis

PS: There is the prospect that CC-by is not acceptable to be a Category A license because
of some misguided provisions concerning modes of distribution/performance/use.
-----Original Message-----
From: Ross Gardler [] 
Sent: Thursday, August 04, 2011 09:19
Subject: Re: Access to wiki

On 4 August 2011 15:22, Rob Weir <> 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

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.



View raw message