incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: [DISCUSS] Expressing priorities about release reviews
Date Sun, 13 Jan 2013 19:24:53 GMT
On Sun, Jan 13, 2013 at 12:51 PM, Marvin Humphrey
<> wrote:
> On Sun, Jan 13, 2013 at 4:45 AM, Benson Margulies <> wrote:
>> 1. Why are podlings having so much trouble getting the legal metadata
>>    correct?
> *   Our documentation on legal metadata is ill-organized, voluminous, and
>     ultimately overwhelming.
> *   The NOTICE construct is fundamentally confusing.
> *   Few software developers have the patience, the temperament, and more than
>     anything else the raw hours to acquire a lot of expertise about licensing.
>> Adding all of this up, I've got a very modest proposal. Let's create a
>> checklist, put it prominently at the top of the relevant doc, and then
>> see if we can't improve the visibility of this.
> I am skeptical that the information necessary to build LICENSE and NOTICE can
> be expressed in a checklist.  The problem is that LICENSE and NOTICE still
> start as blank pages, and filling them in from scratch requires expertise
> which is costly to acquire.
> I suspect that a "LICENSE-o-matic" approach will yield better results, because
> it relieves the developer from having to conceive of a basic structure for
> LICENSE and NOTICE.  Here is some sample pseudocode for appending dependency
> information to NOTICE:
>     SUBROUTINE append_to_notice(notice, dependency):
>         # Only bundled dependencies get considered for NOTICE!
>         IF NOT dependency.bundled:
>             RETURN
>         IF dependency.license IS MIT_X11:
>             PASS   # No NOTICE requirement
>         ELIF dependency.license IS THREE_CLAUSE_BSD:
>             PASS   # No NOTICE requirement
>         ELIF dependency.license IS APACHE_LICENSE_V2:
>             IF has_notice_file(dependency):
>                 IF is_apache_product(dependency):
>                     ...
>                 ELSE
>                     ...
>         ELIF dependency.license IS FOUR_CLAUSE_BSD:
>             ...
>         ...
>         # Recurse for nested dependencies.
>         FOR nested_dependency IN dependency.nested_dependencies:
>             append_to_notice(notice, nested_dependency)
> For the beginning of such a document, see...
>     How-to guide for "Assembling LICENSE and NOTICE"
> PS: This thread was originally about how our hyper-focus on LICENSE and
>     NOTICE distracts us from more important concerns, both legal and social.
>     I agree with that assessment and regret contributing to the diversion once
>     more.

Let me start from the p.s.. I agree that we currently seem to spend a
depressingly large amount of time on these. However, I don't see how
to fix that by just telling ourselves that they are not very
important. I think we need to fix this by finding a way to make it
much easier to get them right. I'm all ears as to all possible ways to
accomplish this.

In terms of the other possible areas of attention, I sadly think that
this becomes the same old discussion about mentors. The people who are
supposed to be ensuring adequate supervision for what gets committed
are the mentors. If we continue to be unable to maintain adequate
levels of mentor involvement, we have a bigger problem.

Sebb's critique's of NOTICE and LICENSE are rarely at the level of
'hey, this would be the right license in the right file but it's an
MIT license so you don't need to bother.' More of the time, as I see
it, the critique is that one or both is missing altogether, or that
completely backwards contents are present in them.

I will add some comments to the JIRA.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message