www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: Bundling and LICENSE
Date Thu, 07 Apr 2016 06:52:30 GMT
Hi,

> When you say "you can't turn a blind eye" does that mean we must vote to cancel the release?

It's really going to depend on what the issue is. I really can’t see there's going to be
one rule to fit all situations. Have a look at releases on the incubator as a guide, in some
cases it’s fine to fix it the next release  (e.g. having too much in NOTICE or missing a
couple of headers) in others (e.g. including GPL code or including a jar in a source release)
it’s most likely that a new release candidate will be required. A lot of issues do occur
there with bundling 3rd party code and not looking at the contents of that code in detail.

> Because if there is no allowance for judgement, then a person who does not trust the
L&N can effectively force those who want to trust the L&N to not be able to trust
the L&N by exposing them to potential issues.

Again this is going to depend on a lot of factors. I’m more likely to trust something from
a large company with a legal team or something that has a public IP review and ICLAs than
something from a random repo on github with drive-by committers. But anytime you bundle 3rd
party code you should at least look at what’s inside it and make sure it doesn’t contain
anything odd. Reviewing commits may not be enough here as you could accidentally bring in
a GPL dependancy or include something of doubtful IP or perhaps include something not compatible
with Apache. (As some Apache compatible licences are compatible with GPL but the reverse isn’t
true.)

You can alway ask the PMC for help, it’s certainly not just up the release manager. You
might also want to note this [1], i.e. the whole PMC in general and the Chair in particular
is responsible for a release being compliant with Apache policy. [1]

> My interpretation of the Apache way would be that PMC members could have the option say
to someone who does not trust the L&N and finds an issue:  "Hmm, well, I choose to trust
their top-level documents.  Maybe it is a clerical error on the part of the third-party. 


Even if it is a clerical error on part of the 3rd party, to be safe I’d follow the guiding
principal [2]. The LICENCE/NOTICE should reflect what is actually bundled. Erring on the side
of a little more is at worse a documentation issue that can be corrected in later releases
if need be.

> Yes, that puts the onus on the person reporting the issue to do the work or recruit someone
to do the work

So by extension an IPMC member voting on a release should be responsible for fixing any issue
that find rather than the PPMC? I can’t see that would encourage more people to review releases.
I think [1] is important here. The PMC should be capable of dealing with any license issues
that come up, when they come up, and decide what the best course of action is. Most of these
issues are easily dealt with and just involve a few simple modifications to LICENSE and NOTICE.

Thanks,
Justin

1. http://www.apache.org/dev/release-publishing#release_manager <http://www.apache.org/dev/release-publishing#release_manager>
2. http://www.apache.org/dev/licensing-howto.html#guiding-principle <http://www.apache.org/dev/licensing-howto.html#guiding-principle>


Mime
View raw message