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: Draft IP Review Plan for OpenOffice
Date Thu, 17 Nov 2011 21:26:18 GMT
On Thu, Nov 17, 2011 at 4:13 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>
> On Nov 17, 2011, at 12:46 PM, Rob Weir wrote:
>
>> On Thu, Nov 17, 2011 at 3:30 PM, Dennis E. Hamilton
>> <dennis.hamilton@acm.org> wrote:
>>> Good point, Dave.
>>>
>>> I think one important consideration around this Opt-in provisions is also whether
the download is something that is authenticated in some manner or is at the user's risk.  I
don't quite know how that gets dealt with.  It may be that some arrangements for acquiring
extensions and templates from third parties should be decoupled enough to avoid confusion
that these are in any way authenticated for use with an Apache OpenOffice distribution.  A
separate downloading tool or even web page might be preferable for general sources of extensions
and templates, something that takes overt attention to use.
>>>
>>
>> I see a few categories:
>>
>> 1) Downloads of AOO-released software that occurs automatically, in
>> the background.  This should be rare, if at all.  You could make the
>> argument of doing this with security patches, but industry best
>> practice is not to do this by default, but to allow user to opt-in to
>> automatic updates.  This is not an issue for the project right now
>> because OOo doesn't do automatic updates.
>>
>> 2) Application-prompted downloads of additional modules.  For example,
>> we notice that you are installed with Italian locale, and don't have a
>> spell checker, we raise a dialog and ask "Would you like to install
>> dictionary XXX"?  We might be able to do this if we had some sort of
>> click through license for the user.  But I don't think -- from a
>> policy perspective -- we want to do this.  Why?  What if there are two
>> different Italian dictionaries with different licenses, or the same
>> license but different authors?  Which do we chose?  I don't think we
>> want to be in the business of pre-selecting 3rd party partners for our
>> users.
>
> AOO prompted downloads of non-ASF hosted and Category X licensed additional modules is
exactly what I think AOO should do. In your scenario we want languages to have multiple choices.
If there are two (or five) then both (or all) are offered. I believe that we need to have
a policy to allow 3rd parties to create plug-in Language Packs, Extension and Templates. To
exclude this limits AOO to being a reference implementation. This is really another thread.
>

I'm OK with that.  This is what I was thinking of as #3 below.  So
saying, "You do not have a dictionary installed, would you like to see
a list of 3rd party dictionaries?" is fine.  You then can launch a
browser or have an in-app extension browser.  But we're not choosing
among the alternatives.  We're inviting the user to do this.  Of
course, a 3rd party could take AOO, modify it and constrain the
choices further, bundle dictionaries, etc.

>>
>> 3) Application-integrated browsing of extension repositories -- I
>> think this should should be fine, so long as the user can see and
>> agree to the underlying license.
>>
>> 4) User find and downloads an extension via a web browser or some
>> other means external to the OpenOffice app.  Nothing we can really do
>> at that point. It is entirely in the user's control.  They are
>> responsible for the license terms of whatever extension they download.
>>
>> 5) Third party customizes OpenOffice to do any of 1-3 above.  Again,
>> it is outside of our control.  We need to worry about what we control.
>>
>>
>>> This also raises some issues about how authentication is established for the
desirable cases of easy opt-in.  For some cases, I can see the distribution including a list
of sources and keys that can be used to authenticate a download.  (How that is authenticated
is an interesting matter also.  Some sort of anti-tampering provision may be needed, perhaps
with an additional level of indirection -- so that it is not easy to tamper with the release:
 It may be that the list of authentic sources and keys is itself downloaded in a secure manner
and kept current by the run-time, allowing for additions and revocations.)
>
> You are advocating that an ecosystem of Language Packs, Extensions, and Templates have
two states - authenticated downloads and unauthenticated downloads. This is also another thread.
>
>
>>>
>>> There are some established procedures by which an Apache Release is authenticated
and verifiable.  This needs to be extended to binaries produced and distributed from the
project.  It will not be possible for individuals who make their own builds from source to
counterfeit that authentication of their binaries.  (They can offer their own authentication,
of course.  That's always possible, though impersonation of Apache OpenOffice is frowned-up,
to say the least.)
>
> All Apache Release Candidates (binary and source) are signed by the Project Release Manager.
If a PPMC member votes +1 to release they are affirming that they have checked the signatures
on EVERY artifact. (A +1 vote affirms many other checks as well, RAT is our friend.) If any
of the signatures are incorrect a PPMC member is EXPECTED to vote -1. In that case the artifacts
are recreated and the VOTE is restarted. Projects will often script the signing of artifacts.
>
> Regards,
> Dave
>
>>>  - Dennis
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Dave Fisher [mailto:dave2wave@comcast.net]
>>> Sent: Thursday, November 17, 2011 11:40
>>> To: ooo-dev@incubator.apache.org
>>> Subject: Re: Draft IP Review Plan for OpenOffice
>>>
>>>
>>> On Nov 17, 2011, at 11:16 AM, Rob Weir wrote:
>>>
>>> [ ... ]
>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>>>
>>> Thanks. This is a good reference.
>>>
>>> Here's an area where we either already know the answer or need clarification.
>>>
>>> We've recently had the subject of language packs with various licenses and copyrights
including category X.  If point 5 of Source Release:
>>>
>>>> 5. We may also have a build flag that permits the inclusion of weak copyleft,
category-b licensed modules (e.g., MPL).  When this flag is used, it could trigger the automated
download of such modules.  But this should require an explicit, informed choice from the
user.  They need to know that they are enabling the inclusion of non-Apache modules that
have a different license.
>>>
>>> If this statement is rewritten for Binary releases to allow informed installation
of a Language Pack whatever it's host, license and copyright might be - as long as on installation
choices were clearly visible and the user explicitly opts in or out.
>>>
>>> This same IP framework could be used for Extensions and Templates - an area in
total limbo with no volunteers active.
>>>
>>> These three areas are important to users and users would benefit if the whole
"ecosystem" co-operated.
>>>
>>> Regards,
>>> Dave
>>>
>>>
>>>>
>>>> Regards,
>>>>
>>>> -Rob
>>>
>>>
>
>

Mime
View raw message