On Thu, Nov 17, 2011 at 4:13 PM, Dave Fisher <[email protected]> wrote: > > On Nov 17, 2011, at 12:46 PM, Rob Weir wrote: > >> On Thu, Nov 17, 2011 at 3:30 PM, Dennis E. Hamilton >> <[email protected]> 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:[email protected]] >>> Sent: Thursday, November 17, 2011 11:40 >>> To: [email protected] >>> 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 >>> >>> > >
