corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Release_0.1
Date Thu, 13 Aug 2015 18:49:27 GMT
On 13 August 2015 at 20:32, Dennis E. Hamilton <>

> With regard to the question asked below,
> My only wish about the voting process is that there be enough time for
> anyone to vet the release candidate.  Also, votes should not be based on
> sentiment but by actually checking the release candidate in some way
> (verifying digital signatures and hashes, verifying the code installs in a
> fresh machine, verifying that whatever builds and tests by following the
> instructions works without incident other than limitations described in any
> README, etc.).  This is a [P]PMC responsibility, although it will be nice
> if others on this list also did so.
would 7 days be sufficient ?

> It is likely that members of the Incubator PMC will do the same.
This is a separate issue, not connected to our voting period. But
considering that we are 2 IPMC members (Dave and I) that are also PPMC, 1
IPMC member that are mentor (Daniel) and 1 IPMC (Justin) are controlling
the release in advance, I do not think that vote will be a problem.

> Possible Clarification
> ----------------------
> I think that if binaries are provided, the LICENSE and NOTICE files that
> install with the binaries must reflect the license conditions on everything
> (and only that) included in the binary distribution.  A README or related
> file and to acknowledge contributions and dependencies is useful for
> information that is not legally required in NOTICE.
We do not provide binaries. If you think of a compiled version of corinthia
it is not part of the release but made available e.g. by PPMC members.

> I don't understand "- If we only link to a third party library and do not
> include it in the license, we do not need to mention it anywhere (as is
> this is no legal issue)."  Do you mean "If we only link to a third party
> library and do not include it in the [source] code ..."?
I did did mean "LICENSE" file, but your wording is better. Justin made me
aware that if you only link to a library, and do not include it in the
source zip, it does not belong in LICENSE. We do not supply any third party
libraries in binary form (we supply a single in source form, and that is
mentioned in LICENSE)

> Also, if it is a mandatory dependency in order to build the released
> source into a functional result, license of the third party library still
> matters with regard to ASF policy (which goes beyond what is legally
> required).
Well is Justin tells me it has no legal effect and should not be mentioned
in LICENSE; then I do believe him (he wets 5-6 releases every month, so he
surely have more experience).

Anything that is included in the source, must be  described in
LICENSE/NOTICE, anything not included in the source does not belong in
LICENSE/NOTICE. If we were to document "in order to build the released
source in a functional result"; we should also include the tool chain.

> It would be very useful if Justin communicated here directly and we could
> resolve any nuances of understanding with him.
MIght be, but we will not take a license discussion in here. We discuss
whether or not the release will pass and when Justin tells me he is
prepared to vote +1 for the source zip then I am satisfied.

 I have not been discussing at all with Justin, but simply made the changes
he asked for, and I suggest we as podling do not question that judgement.
Whether or not link dependencies should be included in the LICENSE in
general is outside our scope.

jan i.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message