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