incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Draft IP Review Plan for OpenOffice
Date Thu, 17 Nov 2011 21:13:21 GMT

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.

> 
> 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