www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Simplfying requirements for LICENSE and NOTICE
Date Wed, 10 Feb 2016 12:08:52 GMT
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.

> 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

View raw message