www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Proposal: Apache Third Party License Policy
Date Thu, 21 May 2015 15:55:46 GMT
I don't understand these hyperbolic hypotheticals, and would ignore them except that the thread
has been continued.

 - Dennis

  -- replying inline to --
From: Lawrence Rosen [mailto:lrosen@rosenlaw.com] 
Sent: Wednesday, May 20, 2015 10:36
To: legal-discuss@apache.org
Cc: Lawrence Rosen
Subject: RE: Proposal: Apache Third Party License Policy

`Dennis Hamilton wrote:
> At no point in this lengthy discussion has the AOO PMC come forward
> with any such request.  As a member of that PMC, I don’t believe 
> there is a consensus for such an exception to be requested.
> I may be mistaken, but the evidence of that would be a request to 
> legal@ specifying the exception to be made in the case of certain 
> Category B licenses and how it would be limited and carried out.

Dennis is right as long as we limit ourselves to tinkering, one tiny step at a time with hundreds
of Legal-JIRA issues, every time a project like AOO proposes an exception. That's how the
board has insisted we do it in the past, and that's why I keep trying to FIX this problem.

How long will our list of exceptions become before we decide this is foolish? 


  I clarified a specific situation that was being used as exemplary of something bigger and
that is not actually being raised in pursuit of an exception.  To use something that has not
happened as a launching pad for speculations about tinkering is odd for me.  

  So, OK, how long *is* the list of exceptions?  And where is that list?  (I accept that there
are good reasons for there not being such a list, since it is important to treat each supposedly-exceptional
case on its specific merits.)

  Let's not confuse the raising of questions and even requests for exceptions with the identification
of exceptions to default practices.  

Let's not confuse the desires of projects to make something easy and the slow comprehension
of ASF principles that trump the convenience of developers.  These seem to be natural occurrences
that attend the maturing of ASF projects. 

The TL;DR:

(An offer to create an Apache Project with a code dump was abandoned recently when the submitter
found that the ASF does not accept projects under such conditions. That this frustrated a
misguided expectation of the offering party is unfortunate but was not taken as a material
reason to alter ASF principles or practices.)

The questions I see on the JIRA are usually about the extent with which (after removing hypotheticals)
a specific situation would comply with ASF principles or not.  Sometimes it is found to be
principled. It is perhaps an exception case to a default practice in the case of GPL2-licensed
writing-aid plug-ins for AOO and the constraints that are observed in the incorporation of
such plug-ins as part of binary distributions.  I suppose it is an exception to the extent
that such coupling is, as a general practice, to be regarded as unacceptable by default. 
Sometimes it is found that certain steps are necessary to satisfy ASF principles.  Sometimes
the proposed action is deemed out of bounds.

These seem to be ordinary situations that arise in the effort that project teams make to align
themselves with principles of the ASF that govern Apache project source-code releases and
the provenance of the code in those releases.

There are also principles that apply when there is no license clash whatsoever.  For example,
as a general practice, it is not OK for an Apache Project to automatically cherry-pick ALv2
source code that is not source code of an Apache Project.  There is another general principle
that fixes (as opposed to adaptations) be submitted upstream to the original source, under
the license of that source.

(There has been some railing about the fact that some significant adopters of Apache OpenOffice
Project ALv2 source code do not follow such practices.  Yet it is a principle of the ASF that
there are no such expectations.  The good open-source citizenship of ASF projects is not conditioned
on the good citizenship of others.  It takes a while for a project to internalize that principle,
along with accepting that, for the ASF, forking of a project is a feature.  Although the differences
in behavior can be unpleasant for the parties who feel exploited, on either side of the equation,
the principles stand.) 

[ ... ]

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message