The issue on legal-discuss is LEGAL-104, at <https://issues.apache.org/jira/browse/LEGAL-104>.

Created attachment 76897 [details]
PDF Version of the Change-Tracked HTML

This is a PDF version that may be easier to access, since Bugzilla is shy about delivering HTML into browsers.

An editable version is also needed, but there should be only one in one place.  I will see if legal-discuss has a preference for change-tracked-document format before I provide that.

I recommend:that eliminate the distinction between code and non-code contributions. ALv2 works should be fine for all contributions. I don't think we want to create a distinction that is made nowhere else at Apache.

Also, would it be simpler to start with a bare-bones ToU and then add what is necessary?  There is a lot in the legacy ToU that might have been appropriate for a multinational corporation with their risk profile and standard practice that is overkill for us.  Nuclear and biological weapons, etc.

@Rob

The advantage of a ToU is that it makes clear the difference between incoming and outgoing licenses.  The ALv2 is an outgoing license statement, even the example is an outgoing statement.

So to tell people they are offering that license is fine, but there needs to be an incoming way of doing it.

The current (Oracle) ToU do that reasonably well and the incoming license is very close to the way an iCLA or SGA does it (those both being incoming agreements).  I prefer retaining that because it is clearly good enough for Apache and it is consistent with previous contributions.  

If we say, "contributions from here on out" we haven't said what outgoing is for material contributed earlier and both those contributors and new users may be surprised to find that use of the site is seemingly so heavyweight.

Finally, some version of the proposed structure, however whittled down, needs to respect that there is presently material on the site that is not offered under that license, and this proposal deals with that by using the same clear language.  

The current incoming terms use ALv2 for code contributions and a generic permission for anything else.  If it is all made ALv2 there is a lot more wording and terms for someone to figure out because the outgoing ALv2 is a lot to swallow.  The Patent portion is particularly weird for non-code.

I'm not saying we should not have ToU.  But let's not overly-complicate it by adding non-Apache, non-approved terms to it.

Incoming is AlV2.  Period.  We should tie that to new user registration as well, to ensure that they accept that as ToU before they have the ability to contribute.

Outgoing is Alv2 unless otherwise stated.  Since we're not removing any existing copyright statements or licenses, this is not ambiguous.

Remember, the goal should be to preserve our ability to migrate (new) contributions into releases, via documentation, inline help or whatever.  So we need new content to be ALv2, or other category-a.

Have you read the incoming ToU?  Compare it with your own iCLA agreement.

 I notice that my last comment was never responded to.  *Clearly* the original incoming license agreement placed no limitation on the reuse of the material in an ALv2-licensed work.  It also had the advantage of being the same as the earlier incoming terms for non-code, so we didn't have to deal with before and after.  

The problem of outgoing licenses on existing material is a different matter, and that can only be resolved by preserving provenance and then dealing with it as well as possible.

Question? can we close this issue?