On 4 August 2011 15:22, Rob Weir <[email protected]> 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. Ross [1] http://webodf.org/
