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): <http://listarchives.documentfoundation.org/www/discuss/msg07409.html> [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 remark.]
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 contributors. 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 openoffice.org 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 [mailto:[email protected]] Sent: Thursday, August 04, 2011 09:19 To: [email protected] Subject: Re: Access to wiki 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/
