On Tue, Jun 28, 2011 at 7:17 PM, Alexandro Colorado <j...@openoffice.org> wrote: > On Tue, Jun 28, 2011 at 6:05 PM, Jean Hollis Weber <jeanwe...@gmail.com>wrote: > >> Sam, >> >> To make sure I understand your answer to Rob, could you please clarify >> for me: >> >> What about user-oriented documentation (user guides, tutorials, etc, as >> listed by Rob)? >> >> Or was that covered by your answer at the bottom of your note, about >> making a concrete proposal for presentation to legal-discuss? I couldn't >> tell if that applied only to things for inclusion in an official release >> (Rob's item 2), or if it applied also to things not included in a >> release but provided on the AOOo website or wiki (Rob's item 1). >> >> I am asking, of course, because the independent ODFAuthors group, which >> has been producing the OOo user guides, would like to continue doing do >> for AOOo, while remaining independent. >> > > Sorry for jumping in but it seems there is an missunderstading between Rob > and the ODFAuthor project. I think the ODFAuthor was in the position of many > quasi-independent groups like the OOo NGOs and others. >
It is possible that I an confused, but I think I am mainly concerned about fragmenting the project into many "quasi-independent" groups. I'm not absolutist in this, but I can see clear risks. Let me give you an extreme example. Suppose we decided to stop writing word processor text alignment code, Instead we relied on group A, which owned and developed left alignment code, group B which did all the center alignment work and group C did the right alignment code. (OK, the example is ridiculous technically, but bear with me please) Because, in this fanciful example, the Apache project had other groups own essential portions of the project, this means that anyone who tries to put together an actual product based on Apache OOo would need to access the three alignment libraries produced by groups A, B and C. This is true whether one was making an open source release, or a proprietary release. Whoever tries to release a version of OOo binaries, if they wished to have a viable product (from a user perspective) would need to negotiate with groups A, B and C, in terms of functionality, schedule, support, localization support, etc., as well as license. Compare that to a situation where the core alignment code is all in the Apache OpenOffice project, under the Apache 2.0 license. That gives downstream users of our releases, open source and commercial, the maximum flexibility to repackage the release. They can add code, subtract code, do whatever they want. But we don't send them to track down dozens of 3rd party dependencies owned by other organizations. Another example, with translations. Suppose the translation files for OOo were owned by a bunch of different groups and were not part of the Apache project, under the Apache license. Then, if someone wanted to take the AOOo sources and make a special version, say a Portable Apps version, or a special educational version, or whatever, then they would need to negotiate access with external groups for their translation files. I think we need to be careful about this kind of fragmentation since they prevent downstream consumers of our releases from making effective use of our releases. It hurts the downstream ecosystem. I think we should have a clear idea of what the essential, core OpenOffice product is, and ensure that those parts of it are developed in the AOOo project, under the Apache 2.0 license, and under PMC oversight. Of course, there may be parts that are not essential, core release components, and those could be done anywhere. In fact, we should encourage extensions, additional documentation, plugins, etc., as part of the overall eco system. That is a good thing. But we need to have a clear idea of what the core is as well, and ensure that the core is developed in one place. > ODF provided a quasi official documentation effort. I say quasi, because it > wasnt really integrated with the documentation.openoffice.org group. AFAIK > there is no documentation.openoffice.org group anymore. At least I havent > seen much people step in from that group. So the default fallback in the > ODFAuthors. > > However there is the use of the name as independent source. I think that is > on the clear, and was never an issue there. However the actual question is > regarding if this will be a fully official effort or not, and if it is, then > how can we make it possible. For example Apache have their own license for > documentation, but ODFAuthors actually have a different goal with the docs > than Apache. > > > >> >> Thanks! >> >> --Jean >> >> On Tue, 2011-06-28 at 12:58 -0400, Sam Ruby wrote: >> > On Tue, Jun 28, 2011 at 12:27 PM, Rob Weir <apa...@robweir.com> wrote: >> > > >> > > 1) Are there any required license issues that we need to heed related >> > > to our website? Assume for sake of argument that we're talking about >> > > web site content that never becomes part of a release. So user >> > > guides, tutorials, as-is document templates that users could download, >> > > 3rd party plugins, additional 3rd party translation packs, user >> > > forums, etc. Is there any requirement that these all be harmonized on >> > > Apache 2.0 and compatible licenses? Or can we have a mix of licenses >> > > to that content, hosted by Apache in a sufficiently sand boxed >> > > environment? >> > > >> > > In other words, are the project's websites and all that we host at >> > > Apache required to be under an Apache-compatible license? Or can we >> > > have copyleft "extras" that we host, with caveats, but do not build >> > > ourselves or include in our releases? >> > >> > We generally don't host third party plugins, be they copyleft, >> > proprietary, or even under the Apache License. One place that such >> > could be placed is: >> > >> > http://code.google.com/a/apache-extras.org/hosting/ >> > >> > > 2) If an existing independent group wishes to remain independent, and >> > > develop documentation or translations, or other similar modules, and >> > > then contribute it to the Apache OpenOffice project for inclusion in >> > > an official release, can this be done? Assume that the work is made >> > > available to us under a compatible license, so it is (in that sense) >> > > allowable in a release. >> > > >> > > Is there any mechanism for an Apache project to routinely accept and >> > > release such modules? Or would this require an SGA/Incubation >> > > proposal each time? Or is there any streamlined way of doing this? >> > >> > If there is an acceptable concrete proposal on how to deal with this >> > was presented to legal-discuss what the likely outcome of that >> > discussion would be is a narrowly crafted exception allowing this. >> > >> > I do not see cc-by as a likely red flag. >> > >> > I would like to see some evidence that project members are able to >> participate. >> > >> > I would also like to see some evidence that project members endorse this. >> > >> > Certainly, other topics may come up in the discussion, but those would >> > be areas I would seek to provide concrete answers to before posting to >> > legal-discuss. >> > >> > > I'm not arguing that #1 or #2 is a good idea or not. But some >> > > conversations seem to be leading to these directions, so I think it is >> > > worth clarifying exactly what is allowed. >> > > >> > > Thanks! >> > > >> > > -Rob >> > >> > - Sam Ruby >> >> >> >> >> >> > > > -- > *Alexandro Colorado* > *OpenOffice.org* Español > http://es.openoffice.org >
