www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Simplfying requirements for LICENSE and NOTICE
Date Wed, 10 Feb 2016 12:34:58 GMT
On 10 February 2016 at 12:08, Jim Jagielski <jim@jagunet.com> wrote:
> In general, I think we when we run into situations like this,
> we forget to emphasize the *reasons* behind the process, and
> instead focus on the after-effects of following the process.
> In other words, we don't do enough to explain what LICENSE
> and NOTICE are for, to educate people what is expected in
> each, and why they exist (and are different) and instead,
> try to come up w/ rules and logic-paths that address any and
> all situations.

+1000!

I've been saying this for ages - we need to document the
rationale/assumptions behind the processes.

i.e. what we are trying to achieve through the use of the processes.

This makes it easier for users to understand why the processes exist
(and therefore accept them, even if they seem onerous).
Also if there are ambiguities in the process description these should
be much easier to resolve.

Furthermore, if parts of the underlying rationale were ever to change,
it would be much more obvious how to amend the processes.

When I first started working in computing, each project might have a
small set of Foundation Assumptions, which documented unchanging
aspects of the project.
For example, I think one was that a telephone number consisted of at
most 20 digits (this was in the days when such things mattered!).
The designers could then refer to this when creating file layouts etc.

I think it would be useful if the ASF did the same for the Foundation
as a whole.

>> On Feb 9, 2016, at 8:43 PM, Roman Shaposhnik <roman@shaposhnik.org> wrote:
>>
>> On Tue, Feb 9, 2016 at 5:32 PM, Alex Harui <aharui@adobe.com> wrote:
>>>
>>>
>>> On 2/9/16, 5:03 PM, "shaposhnik@gmail.com on behalf of Roman Shaposhnik"
>>> <shaposhnik@gmail.com on behalf of roman@shaposhnik.org> wrote:
>>>>
>>>>> At the least, they contain extraneous information, which might be legal
>>>>> but violates
>>>>> Apache policy[2] and is the sort of thing you have gotten quite quite
>>>>> animated
>>>>> about in the past[3].
>>>>
>>>> Well, this is taking it a bit too far I think. Here's the analogy --
>>>> personally I get
>>>> animated about lack of unit tests and test coverage all the time. This is
>>>> really
>>>> one of my hot button issues. But will I bully the project into improving
>>>> their
>>>> test coverage? Abso-freaking-lutely NO!
>>>
>>> But there is no Apache policy around unit tests and test coverage.  There
>>> is policy around L&N and while there is no vetoing of releases, policy
>>> non-compliance is quite often used to convince the RM to cancel a release
>>> vote.
>>
>> Honestly, I think we get hung up on the letter of the policy too much lately.
>>
>> The important thing to me is that we seem to be all agreeing on the spirit
>> and, luckily, we have a few individuals who are working tirelessly to keep
>> the standard of doing a good job really high.
>>
>> Methinks we're good. In fact, I'm 100% sure we're way better than most
>> of the popular ALv2 licensed code bases developed outside of the foundation
>> (which is no reason to rest on our collective laurels, of course).
>>
>>> One question I've puzzled over is how serious certain kinds of
>>> non-compliance really are.  For example, supposedly the release vote is
>>> only about the source package, but the license how-to extends the policy
>>> to the convenience binary, and the source header policy further requires
>>> L&N in jars within the convenience binary.  I know of one project that got
>>> through incubation without the mentors ever examining the convenience
>>> binary package.  How can policy control convenience binaries if there is
>>> no vote or other required approval mechanism required of the PMC?  Can we
>>> just say that problems found in the convenience binary are just things to
>>> be fixed in the next release?  That would also be a simplification, IMO.
>>
>> Well, I've said it once and I will say it again: we're all doing our best
>> effort here. To be really sure you need heavy machinery (BlackDuck
>> and the like) that corporations employ when big legal liabilities are
>> at stake.
>>
>> Honestly, there's NO WAY you know what kind of code came to you
>> from places like Stackoverflow, etc. unless you scan and you scan well.
>>
>>> So I think that leaves us with taking more attempts at better doc.
>>
>> Sure. That's always appreciated. E.g. this is awesome:
>>   https://nifi.apache.org/licensing-guide.html
>>
>> Just don't get too hung up on policing the projects, etc.
>>
>> Thanks,
>> Roman.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>

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


Mime
View raw message