incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Non-Apache maintenance release for OOo 3.3?
Date Fri, 18 Nov 2011 19:55:35 GMT
On Fri, Nov 18, 2011 at 2:11 PM, Dennis E. Hamilton
<dennis.hamilton@acm.org> wrote:
> I think something important is being overlooked in the position about release
> using the OpenOffice.org name.
>
> There is clear interest in having a maintenance release.  It might not even be
> technically difficult.  Wanting to also fold it into the OpenOffice.org
> release lineage is the problem.
>
> An OpenOffice.org 3.3.1 maintenance release is *not* going to be an Apache
> release, and not using any Apache code or licenses, I surmise.  It will be on
> the OpenOffice.org 3.3 code base that is available under LGPL.  So it is a
> derivative work, but not of Apache-licensed code.
>
> In some sense, that is even more reason, under normal conditions, to deny
> identification of that maintenance result with the OpenOffice.org name.
>

We currently allow downloads of the legacy LGPL code under the name
OpenOffice.org.  These are not Apache releases, but their use of that
name, and the links to these downloads from the OpenOffice.org website
are done by our permission.  If we did not want any non-Apache, LGPL
code downloaded from our domain, under the name OpenOffice.org, then
we could disable that immediately.

Of course, no one is proposing that we do disable the downloads of the
legacy versions of OOo.

>From allowing that, to allowing a maintenance release of 3.3 to be put
under the same name and same mirrors with the same license as the
others, this does not seem like a huge stretch.

-Rob

> The tension is that it is closer to an OpenOffice.org 3.3 maintenance release
> than anything that will ever appear as Apache OpenOffice version-whatever.
> And more timely.  The question is under what conditions can this be allowed to
> be identified as part of an OpenOffice.org 3.3.x progression?
>
>  - Dennis
>
> MUSINGS
>
> It seems to me that it is more straightforward to consider that the
> OpenOffice.org line has ended.  The only thing possible, now, are derivatives
> of the LGPL OpenOffice.org code base (such as LibreOffice is already), other
> existing peers of OpenOffice.org, and the reset that Apache OpenOffice
> represents (and its eventual derivatives too).
>
> In that regard, it would be more appropriate for the proposed 3.3.1
> maintenance release to be identified as a derivative (e.g., Team OpenOffice
> 3.3.1).  It can make nominative use of OpenOffice.org in regard to it being a
> maintenance derivative of OpenOffice.org 3.3 and that aspect is settled.
> Other trademark issues can be resolved with Team OpenOffice and, meanwhile,
> the derivative can be a clean release with splash screens, About dialogs, and
> other insignia that do not employ Apache trademarks and symbols in any way
> beyond non-confusing nominative usage.  There is now no confusion about the
> roots of the release and its independence from Apache.
>
> On the OpenOffice.org site, it should be possible to identify the existence of
> this derivative and link to a Team OpenOffice page that indicates its
> availability, solicits funds, or whatever, as a recognized peer.  It is
> possible to link to LibreOffice in the same manner, and also other members of
> OpenOffice.org lineage and, other support for the ODF document format as well.
> The emergence of Apache OpenOffice and the steps toward incubator releases can
> also be featured, obviously.
>
> That, apart from complications concerning localizations and other downstream
> support of the 3.3.1 including user support and bug reporting against the
> release, would seem to be that.  There is also the LGPL requirement that the
> source code of the release be available.
>
> I suspect that there is a desire for closer coupling than that.  The problem,
> of course, is that the Podling can do nothing with the OpenOffice.org 3.3 LGPL
> code base.  And my understanding is that binaries of such code shall not be
> distributed via Apache sites either. The Apache OpenOffice code base is not
> usable instead; it is not even being positioned for maintenance release of an
> OpenOffice.org 3.3.1 equivalent. Probably the only case would be the unlikely
> possibility of Oracle undertaking such a release (meaning that updates would
> all be under Oracle SCA though).
>
>
>
> -----Original Message-----
> From: Shane Curcuru [mailto:asf@shanecurcuru.org]
> Sent: Friday, November 18, 2011 09:06
> To: ooo-dev@incubator.apache.org
> Subject: Re: Non-Apache maintenance release for OOo 3.3?
>
> On 2011-11-18 11:16 AM, Stefan Taxhet wrote:
>> Hi Don, all,
>>
>> Am 17.11.2011 15:34, schrieb Donald Harbison:
>>> On Thu, Nov 17, 2011 at 9:14 AM, Stefan Taxhet<stx123@gmail.com> wrote:
>>>> Am 17.11.2011 02:23, schrieb Rob Weir:
> ...snip...
>>>> What is your proposal for the name of your release? Please make a
>>>> proposal
>>> for what you wish to name your release.
>>
>> Rob described the two options very concise. The preference would be to
>> release "OpenOffice.org 3.3.1" with consent of the home of development
>> work for future releases.
> ...
> The Apache Open Office PPMC is the only organization that should be
> releasing a software product using just the name "OpenOffice.org".
> Apache trademark policy is clear that third parties are *not* allowed to
> use Apache brands in confusing or infringing manners on software products.
>
> We offer broad guidelines for using a "Powered By" style of naming for
> third party software products that are either built on top of, extend,
> or otherwise use Apache code but add your own code to your product:
>
>   http://www.apache.org/foundation/marks/faq/#products
>
> Note that we'd certainly consider permitting other phrases besides the
> "Powered By" phrase, like "Built Using", etc. (but not "Distribution" or
> "Release" or other similarly non-specific phrases).  This allows third
> parties to create their own, independently branded products while still
> allowing third parties to show the obvious relationship to the
> underlying Apache product.
>
> -Shane
>

Mime
View raw message