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