Thanks Jan, it is valuable to comprehend just how narrow individual exceptions are.
Comment in-line -----Original Message----- From: jan i [mailto:j...@apache.org] Sent: Sunday, June 28, 2015 14:53 To: dev@openoffice.apache.org; orc...@apache.org Subject: Re: Background to Cooperation: ASF/AOO Principles, Policies, Practices On 28 June 2015 at 19:49, Dennis E. Hamilton <orc...@apache.org> wrote: [ ... ] > An example of an exception that is specific to the Apache OpenOffice > project is the distribution of convenience binaries that have writing-aid > plug-ins bundled with them that are not themselves under a license that is > acceptable for source-code releases. There are a number of specific, > delimited provisions under which this action is found consistent with > Apache principles although it is an exception to a general policy. This > practice was only introduced after obtaining review and eventual > concurrence via the list on which legal and license questions are discussed. > > <orcmid> > The narrowness of the exception for these plug-ins is that they > contain no code, they deliver data in a general format that can > be used in a well-defined technique, and that they are completely > replaceable. Users can also install additional ones of their > choosing and remove/disable the ones that are provided in the > binary distributions as a convenience. It is also the case that, > if one inspects the plug-in (using a form of Zip package), one > would encounter all applicable license information and there would > be no confusion over the license that is specific to them material > conveyed by a given plug-in. > </orcmid> > I would be very careful about interpreting the above extract. The plugins do contains quite a lot of code, and some of them like the dictionaries are not really optional. We actually deliver plugins as part of our own exe, so we do distribute some of the plugins without a special license. But legal has looked at what we deliver and accepted it, so no need to detail that further. You also use the word "narrowness", as if these exceptions are written in stone, that is not the case, we can always ask for other exceptions if needed (whether we get them is a different matter). <orcmid> The specific *individual* exception is very narrow. That is what I meant. And exceptions always apply to specific cases. For example, the one I linked to is about a situation with Apache OpenOffice and it was asked with respect to writing aids, GPL dictionaries in particular. The title of the issue is "Aggregation of GPL dictionaries with Apache OpenOffice", < https://issues.apache.org/jira/browse/LEGAL-117>, and the question is, specifically "can Apache OpenOffice include GPL spell-checking dictionaries with its binary releases?." Of course there can be more exceptions, each reviewed and approved or disallowed with respect to individual cases. And the exception granted to AOO for the particular case is not an extension of policy. That is the point of my remarks here. On reflection, I also think that is why Sam Ruby did not discuss the prospect of other licenses being comingled in those [dictionary] plug-ins. That was not part of the request and legal was not about to expand the scope of LEGAL-117 scope beyond what was asked for. My observations about other mingled licenses at the time would best have gone back to the [P]PMC (the origin of the exception request). PS: I don't think legal has looked at what AOO delivers. They considered the request and assume that the [P]PMC requested what it actually needed and only what it actually needed and proposed to do. This is not a blanket exception for all manner of plug-ins having GPL licenses and it applies specifically to AOO binary distributions. </orcmid> rgds jan i. > [ ... ] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org