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