You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Sharan F <sh...@apache.org> on 2016/06/10 12:33:34 UTC
Request for clarification of Release Policy regarding external jar
files
Hi
We need some confirmation regarding what is included in an Apache
release. Essentially we want clarification of what the policy is with
regard to dependencies such as external jar files.
In the the Guide to Release Management During Incubation (DRAFT)
http://incubator.apache.org/guides/releasemanagement.html#check-list
under section 3.6 in the 'Release Check List' it says:
/"*3.6 Release consists of source code only, no binaries.*/*//**/Each
Apache release must contain a source package
<http://www.apache.org/dev/release-publishing.html#valid>. This package
may not contain compiled components (such as "jar" files) because
compiled components are not open source, even if they were built from
open source."/*
On the Release Creation Process page
http://www.apache.org/dev/release-publishing.html#valid under the 'What
is a Valid Release Package' section it says:
/*"... the fundamental requirement for a release is that it consist
of the necessary source code to build the project. Optionally, a
release may also be accompanied by compiled binaries for the
convenience of users."*/
Based on these statements our understanding is that:
* projects must publish "source releases"
* "source releases" do not contain binaries
* projects may also publish "binary releases"
* "binary releases" can contain binaries compiled from source code
created by the project or binaries from external projects
Please can you confirm that our understanding of the policy is correct
(or not).
Thanks
Sharan
RE: Request for clarification of Release Policy regarding external jar files
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Sharan Foga [mailto:sharan@apache.org]
> Sent: Wednesday, June 15, 2016 03:09
> To: legal-discuss@apache.org
> Subject: Re: Request for clarification of Release Policy regarding
> external jar files
>
> Hi Alex
>
> To respond to your query, it's the PMC that's looking at doing it - no-
> one else, and it if we did do it, it would be as a you say, a direct
> follow on of the source release process.
>
> Thanks
> Sharan
>
> On 2016-06-14 16:57 (+0200), Alex Harui <ah...@adobe.com> wrote:
> > Hi Sharan,
> >
> > Maybe I'm misinterpreting your last sentence, but while I guess it is
> true that the convenience binary doesn't have to go through the same
> process in that the VOTE doesn't have to occur, but because of
> statements in the release policy like: "In all such cases, the
> binary/bytecode package must have the same version number as the source
> release and may only add binary/bytecode files that are the result of
> compiling that version of the source code release", it means to me that
> the convenience binary is a follow-on action (by individuals) from a
> source release. So, whatever sources an individual uses to generate the
> binary release must have first been approved as a source release via the
> usual process. I don't know that a PMC can enforce those rules on a
> third-party or the RM, but I think the PMC is supposed to try to make
> sure that approved source releases are available for binary release
> providers.
> >
> > IOW, a vote and vetting of a source package had to occur at some point
> before the binary release is produced from it, and in the vetting of the
> source package, checking of LICENSE and NOTICE for the binary release
> generally occur since they can be different from the source release.
[orcmid]
FWIW and FYI, the Apache OpenOffice project does concurrent voting on a release candidate and the official (project-approved and -provided branded) binaries that will be distributed for that release, all prepared from the candidate. In addition to the source release, there is an AOO Toolkit (for those who build extensions or operate the runtime as some sort of service), the different localized and platform versions of installers, and also the different language packs that users can add for language-based customization of installed distributions.
The focus on providing end-user desktop software is the key factor here.
The review process can uncover defects/regressions in the binaries that cause the release candidate to be withdrawn and a new one prepared.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Request for clarification of Release Policy regarding external jar files
Posted by Sharan Foga <sh...@apache.org>.
Hi Alex
To respond to your query, it's the PMC that's looking at doing it - no-one else, and it if we did do it, it would be as a you say, a direct follow on of the source release process.
Thanks
Sharan
On 2016-06-14 16:57 (+0200), Alex Harui <ah...@adobe.com> wrote:
> Hi Sharan,
>
> Maybe I'm misinterpreting your last sentence, but while I guess it is true that the convenience binary doesn't have to go through the same process in that the VOTE doesn't have to occur, but because of statements in the release policy like: "In all such cases, the binary/bytecode package must have the same version number as the source release and may only add binary/bytecode files that are the result of compiling that version of the source code release", it means to me that the convenience binary is a follow-on action (by individuals) from a source release. So, whatever sources an individual uses to generate the binary release must have first been approved as a source release via the usual process. I don't know that a PMC can enforce those rules on a third-party or the RM, but I think the PMC is supposed to try to make sure that approved source releases are available for binary release providers.
>
> IOW, a vote and vetting of a source package had to occur at some point before the binary release is produced from it, and in the vetting of the source package, checking of LICENSE and NOTICE for the binary release generally occur since they can be different from the source release.
>
> -Alex
>
> From: Sharan F <sh...@apache.org>>
> Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>, "sharan@apache.org<ma...@apache.org>" <sh...@apache.org>>
> Date: Tuesday, June 14, 2016 at 12:26 AM
> To: Jim Jagielski <ji...@jaguNET.com>>, "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
> Subject: Re: Request for clarification of Release Policy regarding external jar files
>
>
> Hi Jim
>
> We thought that we understood it but Marvin's response shows otherwise.
>
> I don't think we were far off, essentially the main difference being that we thought that a compiled binary of a release with its dependencies was also a release (since it has to have the same version number as the release). The confusion I think might have been caused by the definition of what is release.
>
> \u201cReleases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list.\u201d
>
> so it looked to us like we could also publish optional \u201cbinary releases\u201d, whereas Marvin talks about the release process and the strict governance associated with that, and a convenience binary (binary release) doesn't have to go through that same process.
>
> Thanks
> Sharan
>
>
> On 13/06/16 18:43, Jim Jagielski wrote:
>
> What parts of:
>
> http://www.apache.org/legal/release-policy
>
> require clarification?
>
>
>
> On Jun 10, 2016, at 8:33 AM, Sharan F <sh...@apache.org> wrote:
>
> Hi
> We need some confirmation regarding what is included in an Apache release. Essentially we want clarification of what the policy is with regard to dependencies such as external jar files.
> In the the Guide to Release Management During Incubation (DRAFT) http://incubator.apache.org/guides/releasemanagement.html#check-list under section 3.6 in the 'Release Check List' it says:
>
> "3.6 Release consists of source code only, no binaries. Each Apache release must contain a source package. This package may not contain compiled components (such as "jar" files) because compiled components are not open source, even if they were built from open source."
>
> On the Release Creation Process page http://www.apache.org/dev/release-publishing.html#valid under the 'What is a Valid Release Package' section it says:
> "... the fundamental requirement for a release is that it consist of the necessary source code to build the project. Optionally, a release may also be accompanied by compiled binaries for the convenience of users."
> Based on these statements our understanding is that:
> \u2022 projects must publish "source releases"
> \u2022 "source releases" do not contain binaries
> \u2022 projects may also publish "binary releases"
> \u2022 "binary releases" can contain binaries compiled from source code created by the project or binaries from external projects
> Please can you confirm that our understanding of the policy is correct (or not).
> Thanks
> Sharan
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Request for clarification of Release Policy regarding external
jar files
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jun 14, 2016 at 9:57 AM, Alex Harui <ah...@adobe.com> wrote:
> Hi Sharan,
>
> Maybe I'm misinterpreting your last sentence, but while I guess it is true
> that the convenience binary doesn't have to go through the same process in
> that the VOTE doesn't have to occur, but because of statements in the
> release policy like: "In all such cases, the binary/bytecode package must
> have the same version number as the source release and may only add
> binary/bytecode files that are the result of compiling that version of the
> source code release", it means to me that the convenience binary is a
> follow-on action (by individuals) from a source release. So, whatever
> sources an individual uses to generate the binary release must have first
> been approved as a source release via the usual process.
>
As a practical matter, it isn't always possible to build the package
without some minor correction or adjustment. In those cases, any
adjustments required should be in appropriate docs pages, or patches should
be available for download. Nothing in an ASF-branded binary may be
'concealed' from the user who wishes to replicate that binary build, and
these instructions must be as clear as the PMC can provide.
I don't know that a PMC can enforce those rules on a third-party or the
> RM, but I think the PMC is supposed to try to make sure that approved
> source releases are available for binary release providers.
>
Of course it can. That's the value of the Trademarks that Apache hold for
the foundation and specific PMCs.
In general, third parties are receptive to polite requests, but there is an
escalation path. We try not to use it. Perhaps that third party wants to
retitle their package "Packager Superpackage, based on Apache Foo", or
perhaps they want to call their distribution "Apache Foo", and remove what
doesn't correspond to our release. It's best to be flexible and bring the
issue to the trademarks@ group in the event things can't be resolved
amicably.
IOW, a vote and vetting of a source package had to occur at some point
> before the binary release is produced from it, and in the vetting of the
> source package, checking of LICENSE and NOTICE for the binary release
> generally occur since they can be different from the source release.
>
While it isn't strictly necessary to have 3 +1's for such convenience
packages, it is quite valuable to announce those packages and solicit
review, just to ensure the correct LICENSE, NOTICE and other aspects of the
binary correspond to the sources and follow all of our conventions. Extra
eyes never hurt.
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Alex Harui <ah...@adobe.com>.
Hi Sharan,
Maybe I'm misinterpreting your last sentence, but while I guess it is true that the convenience binary doesn't have to go through the same process in that the VOTE doesn't have to occur, but because of statements in the release policy like: "In all such cases, the binary/bytecode package must have the same version number as the source release and may only add binary/bytecode files that are the result of compiling that version of the source code release", it means to me that the convenience binary is a follow-on action (by individuals) from a source release. So, whatever sources an individual uses to generate the binary release must have first been approved as a source release via the usual process. I don't know that a PMC can enforce those rules on a third-party or the RM, but I think the PMC is supposed to try to make sure that approved source releases are available for binary release providers.
IOW, a vote and vetting of a source package had to occur at some point before the binary release is produced from it, and in the vetting of the source package, checking of LICENSE and NOTICE for the binary release generally occur since they can be different from the source release.
-Alex
From: Sharan F <sh...@apache.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>, "sharan@apache.org<ma...@apache.org>" <sh...@apache.org>>
Date: Tuesday, June 14, 2016 at 12:26 AM
To: Jim Jagielski <ji...@jaguNET.com>>, "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: Request for clarification of Release Policy regarding external jar files
Hi Jim
We thought that we understood it but Marvin's response shows otherwise.
I don't think we were far off, essentially the main difference being that we thought that a compiled binary of a release with its dependencies was also a release (since it has to have the same version number as the release). The confusion I think might have been caused by the definition of what is release.
“Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list.”
so it looked to us like we could also publish optional “binary releases”, whereas Marvin talks about the release process and the strict governance associated with that, and a convenience binary (binary release) doesn't have to go through that same process.
Thanks
Sharan
On 13/06/16 18:43, Jim Jagielski wrote:
What parts of:
http://www.apache.org/legal/release-policy
require clarification?
On Jun 10, 2016, at 8:33 AM, Sharan F <sh...@apache.org> wrote:
Hi
We need some confirmation regarding what is included in an Apache release. Essentially we want clarification of what the policy is with regard to dependencies such as external jar files.
In the the Guide to Release Management During Incubation (DRAFT) http://incubator.apache.org/guides/releasemanagement.html#check-list under section 3.6 in the 'Release Check List' it says:
"3.6 Release consists of source code only, no binaries. Each Apache release must contain a source package. This package may not contain compiled components (such as "jar" files) because compiled components are not open source, even if they were built from open source."
On the Release Creation Process page http://www.apache.org/dev/release-publishing.html#valid under the 'What is a Valid Release Package' section it says:
"... the fundamental requirement for a release is that it consist of the necessary source code to build the project. Optionally, a release may also be accompanied by compiled binaries for the convenience of users."
Based on these statements our understanding is that:
• projects must publish "source releases"
• "source releases" do not contain binaries
• projects may also publish "binary releases"
• "binary releases" can contain binaries compiled from source code created by the project or binaries from external projects
Please can you confirm that our understanding of the policy is correct (or not).
Thanks
Sharan
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Sharan F <sh...@apache.org>.
Hi Jim
We thought that we understood it but Marvin's response shows otherwise.
I don't think we were far off, essentially the main difference being
that we thought that a compiled binary of a release with its
dependencies was also a release (since it has to have the same version
number as the release). The confusion I think might have been caused by
the definition of what is release.
\u201cReleases are, by definition, anything that is published beyond the
group that owns it. In our case, that means any publication outside the
group of people on the product dev list.\u201d
so it looked to us like we could also publish optional \u201cbinary
releases\u201d, whereas Marvin talks about the release process and the strict
governance associated with that, and a convenience binary (binary
release) doesn't have to go through that same process.
Thanks
Sharan
On 13/06/16 18:43, Jim Jagielski wrote:
> What parts of:
>
> http://www.apache.org/legal/release-policy
>
> require clarification?
>
>> On Jun 10, 2016, at 8:33 AM, Sharan F <sh...@apache.org> wrote:
>>
>> Hi
>> We need some confirmation regarding what is included in an Apache release. Essentially we want clarification of what the policy is with regard to dependencies such as external jar files.
>> In the the Guide to Release Management During Incubation (DRAFT) http://incubator.apache.org/guides/releasemanagement.html#check-list under section 3.6 in the 'Release Check List' it says:
>>
>> "3.6 Release consists of source code only, no binaries. Each Apache release must contain a source package. This package may not contain compiled components (such as "jar" files) because compiled components are not open source, even if they were built from open source."
>>
>> On the Release Creation Process page http://www.apache.org/dev/release-publishing.html#valid under the 'What is a Valid Release Package' section it says:
>> "... the fundamental requirement for a release is that it consist of the necessary source code to build the project. Optionally, a release may also be accompanied by compiled binaries for the convenience of users."
>> Based on these statements our understanding is that:
>> \u2022 projects must publish "source releases"
>> \u2022 "source releases" do not contain binaries
>> \u2022 projects may also publish "binary releases"
>> \u2022 "binary releases" can contain binaries compiled from source code created by the project or binaries from external projects
>> Please can you confirm that our understanding of the policy is correct (or not).
>> Thanks
>> Sharan
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Jun 13, 2016 at 9:43 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> What parts of:
>
> http://www.apache.org/legal/release-policy
>
> require clarification?
Not so much clarification, but rather lecture notes may be required.
Some of it is part of the FAQ on that very same page. But, for example,
the point about LICENSE and NOTICE for convenience binary artifacts
is not part of that FAQ.
Thanks,
Roman.
P.S. 'cuz you know, without lecture notes your question is like
saying: "What part of E=MC^2 requires clarification?" ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Request for clarification of Release Policy regarding external jar files
Posted by Jim Jagielski <ji...@jaguNET.com>.
What parts of:
http://www.apache.org/legal/release-policy
require clarification?
> On Jun 10, 2016, at 8:33 AM, Sharan F <sh...@apache.org> wrote:
>
> Hi
> We need some confirmation regarding what is included in an Apache release. Essentially we want clarification of what the policy is with regard to dependencies such as external jar files.
> In the the Guide to Release Management During Incubation (DRAFT) http://incubator.apache.org/guides/releasemanagement.html#check-list under section 3.6 in the 'Release Check List' it says:
>
> "3.6 Release consists of source code only, no binaries. Each Apache release must contain a source package. This package may not contain compiled components (such as "jar" files) because compiled components are not open source, even if they were built from open source."
>
> On the Release Creation Process page http://www.apache.org/dev/release-publishing.html#valid under the 'What is a Valid Release Package' section it says:
> "... the fundamental requirement for a release is that it consist of the necessary source code to build the project. Optionally, a release may also be accompanied by compiled binaries for the convenience of users."
> Based on these statements our understanding is that:
> • projects must publish "source releases"
> • "source releases" do not contain binaries
> • projects may also publish "binary releases"
> • "binary releases" can contain binaries compiled from source code created by the project or binaries from external projects
> Please can you confirm that our understanding of the policy is correct (or not).
> Thanks
> Sharan
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Sharan F <sh...@apache.org>.
Hi Mark
Thanks for the response (and lurking too!). I'll also wait for the
official answer so that I can use it as a reference.
Thanks
Sharan
On 10/06/16 14:40, Mark Thomas wrote:
> On 10/06/2016 13:33, Sharan F wrote:
>> Hi
>>
>> We need some confirmation regarding what is included in an Apache
>> release. Essentially we want clarification of what the policy is with
>> regard to dependencies such as external jar files.
>>
>> In the the Guide to Release Management During Incubation (DRAFT)
>> <http://incubator.apache.org/guides/releasemanagement.html#check-list>http://incubator.apache.org/guides/releasemanagement.html#check-list
>> under section 3.6 in the 'Release Check List' it says:
>>
>>
>> /"*3.6 Release consists of source code only, no binaries.*/*//**/Each
>> Apache release must contain a source package
>> <http://www.apache.org/dev/release-publishing.html#valid>. This package
>> may not contain compiled components (such as "jar" files) because
>> compiled components are not open source, even if they were built from
>> open source."/*
>>
>> On the Release Creation Process page
>> <http://www.apache.org/dev/release-publishing.html#valid>http://www.apache.org/dev/release-publishing.html#valid
>> under the 'What is a Valid Release Package' section it says:
>>
>> /*"... the fundamental requirement for a release is that it consist
>> of the necessary source code to build the project. Optionally, a
>> release may also be accompanied by compiled binaries for the
>> convenience of users."*/
>>
>> Based on these statements our understanding is that:
>>
>> * projects must publish "source releases"
>> * "source releases" do not contain binaries
>> * projects may also publish "binary releases"
>> * "binary releases" can contain binaries compiled from source code
>> created by the project or binaries from external projects
>>
>> Please can you confirm that our understanding of the policy is correct
>> (or not).
> (Just a lurker, not an official answer from someone on the legal PMC)
>
> The four statements above are all correct.
>
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Mark Thomas <ma...@apache.org>.
On 10/06/2016 13:33, Sharan F wrote:
> Hi
>
> We need some confirmation regarding what is included in an Apache
> release. Essentially we want clarification of what the policy is with
> regard to dependencies such as external jar files.
>
> In the the Guide to Release Management During Incubation (DRAFT)
> <http://incubator.apache.org/guides/releasemanagement.html#check-list>http://incubator.apache.org/guides/releasemanagement.html#check-list
> under section 3.6 in the 'Release Check List' it says:
>
>
> /"*3.6 Release consists of source code only, no binaries.*/*//**/Each
> Apache release must contain a source package
> <http://www.apache.org/dev/release-publishing.html#valid>. This package
> may not contain compiled components (such as "jar" files) because
> compiled components are not open source, even if they were built from
> open source."/*
>
> On the Release Creation Process page
> <http://www.apache.org/dev/release-publishing.html#valid>http://www.apache.org/dev/release-publishing.html#valid
> under the 'What is a Valid Release Package' section it says:
>
> /*"... the fundamental requirement for a release is that it consist
> of the necessary source code to build the project. Optionally, a
> release may also be accompanied by compiled binaries for the
> convenience of users."*/
>
> Based on these statements our understanding is that:
>
> * projects must publish "source releases"
> * "source releases" do not contain binaries
> * projects may also publish "binary releases"
> * "binary releases" can contain binaries compiled from source code
> created by the project or binaries from external projects
>
> Please can you confirm that our understanding of the policy is correct
> (or not).
(Just a lurker, not an official answer from someone on the legal PMC)
The four statements above are all correct.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Sharan F <sh...@apache.org>.
Hi Marvin
Thanks very much for the clarification.
Thanks
Sharan
On 10/06/16 16:04, Marvin Humphrey wrote:
> On Fri, Jun 10, 2016 at 5:33 AM, Sharan F <sh...@apache.org> wrote:
>
>> We need some confirmation regarding what is included in an Apache release.
> The canonical page for Apache Release Policy is here:
>
> http://www.apache.org/legal/release-policy
>
>> Based on these statements our understanding is that:
>>
>> projects must publish "source releases"
> Yes.
>
>> "source releases" do not contain binaries
> Yes.
>
>> projects may also publish "binary releases"
> This is not accurate. Third parties (most often the release manager) may
> provide compiled packages. The colloquialism typically used to refer to these
> packages is "convenience binaries".
>
> http://www.apache.org/legal/release-policy#compiled-packages
>
> The Apache Software Foundation produces open source software. All releases
> are in the form of the source materials needed to make changes to the
> software being released.
>
> As a convenience to users that might not have the appropriate tools to
> build a compiled version of the source, binary/bytecode packages MAY be
> distributed alongside official Apache releases. In all such cases, the
> binary/bytecode package MUST have the same version number as the source
> release and MUST only add binary/bytecode files that are the result of
> compiling that version of the source code release and its dependencies.
>
> The Foundation does not endorse binary packages because such packages are
> opaque and cannot be audited by a PMC.
>
> Over the last few years (post-Snowden), the extent to which security depends
> on audited source and certified repeatable builds has become ever more clear.
>
>> "binary releases" can contain binaries compiled from source code created by
>> the project or binaries from external projects
> See the quote above for constraints on what may go into convenience binaries.
> Untrusted jar files (from wherever) are allowed. They must represent
> compilation of open source dependencies, but no verification step is
> required -- i.e. there is no policy requirement that anyone actually validate
> that dependency binaries actually derive from specific source code.
>
> Security-conscious consumers will naturally take such matters into account
> when deciding how best to consume our products.
>
> Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Sharan F <sh...@apache.org>.
Thanks Roman - I didn't know this (but do now!)
Thanks
Sharan
On 12/06/16 03:26, Roman Shaposhnik wrote:
> On Fri, Jun 10, 2016 at 4:04 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>> On Fri, Jun 10, 2016 at 5:33 AM, Sharan F <sh...@apache.org> wrote:
>>
>>> We need some confirmation regarding what is included in an Apache release.
>> The canonical page for Apache Release Policy is here:
>>
>> http://www.apache.org/legal/release-policy
>>
>>> Based on these statements our understanding is that:
>>>
>>> projects must publish "source releases"
>> Yes.
>>
>>> "source releases" do not contain binaries
>> Yes.
>>
>>> projects may also publish "binary releases"
>> This is not accurate. Third parties (most often the release manager) may
>> provide compiled packages. The colloquialism typically used to refer to these
>> packages is "convenience binaries".
>>
>> http://www.apache.org/legal/release-policy#compiled-packages
>>
>> The Apache Software Foundation produces open source software. All releases
>> are in the form of the source materials needed to make changes to the
>> software being released.
>>
>> As a convenience to users that might not have the appropriate tools to
>> build a compiled version of the source, binary/bytecode packages MAY be
>> distributed alongside official Apache releases. In all such cases, the
>> binary/bytecode package MUST have the same version number as the source
>> release and MUST only add binary/bytecode files that are the result of
>> compiling that version of the source code release and its dependencies.
>>
>> The Foundation does not endorse binary packages because such packages are
>> opaque and cannot be audited by a PMC.
>>
>> Over the last few years (post-Snowden), the extent to which security depends
>> on audited source and certified repeatable builds has become ever more clear.
>>
>>> "binary releases" can contain binaries compiled from source code created by
>>> the project or binaries from external projects
>> See the quote above for constraints on what may go into convenience binaries.
>> Untrusted jar files (from wherever) are allowed. They must represent
>> compilation of open source dependencies, but no verification step is
>> required -- i.e. there is no policy requirement that anyone actually validate
>> that dependency binaries actually derive from specific source code.
>>
>> Security-conscious consumers will naturally take such matters into account
>> when deciding how best to consume our products.
> To pile on top of Marvin's excellent answer (and at the risk of
> stating the obvious,
> at least the obvious to longtimers): remember even for binary
> convenience artifacts
> you're still on the hook to make sure your NOTICE file is correct.
> Most of the time
> your NOTICE file for binary convenience artifacts will be larger than
> your NOTICE
> for the source release.
>
> Thanks,
> Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Request for clarification of Release Policy regarding external
jar files
Posted by sebb <se...@gmail.com>.
On 12 June 2016 at 02:26, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> On Fri, Jun 10, 2016 at 4:04 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>> On Fri, Jun 10, 2016 at 5:33 AM, Sharan F <sh...@apache.org> wrote:
>>
>>> We need some confirmation regarding what is included in an Apache release.
>>
>> The canonical page for Apache Release Policy is here:
>>
>> http://www.apache.org/legal/release-policy
>>
>>> Based on these statements our understanding is that:
>>>
>>> projects must publish "source releases"
>>
>> Yes.
>>
>>> "source releases" do not contain binaries
>>
>> Yes.
>>
>>> projects may also publish "binary releases"
>>
>> This is not accurate. Third parties (most often the release manager) may
>> provide compiled packages. The colloquialism typically used to refer to these
>> packages is "convenience binaries".
>>
>> http://www.apache.org/legal/release-policy#compiled-packages
>>
>> The Apache Software Foundation produces open source software. All releases
>> are in the form of the source materials needed to make changes to the
>> software being released.
>>
>> As a convenience to users that might not have the appropriate tools to
>> build a compiled version of the source, binary/bytecode packages MAY be
>> distributed alongside official Apache releases. In all such cases, the
>> binary/bytecode package MUST have the same version number as the source
>> release and MUST only add binary/bytecode files that are the result of
>> compiling that version of the source code release and its dependencies.
>>
>> The Foundation does not endorse binary packages because such packages are
>> opaque and cannot be audited by a PMC.
>>
>> Over the last few years (post-Snowden), the extent to which security depends
>> on audited source and certified repeatable builds has become ever more clear.
>>
>>> "binary releases" can contain binaries compiled from source code created by
>>> the project or binaries from external projects
>>
>> See the quote above for constraints on what may go into convenience binaries.
>> Untrusted jar files (from wherever) are allowed. They must represent
>> compilation of open source dependencies, but no verification step is
>> required -- i.e. there is no policy requirement that anyone actually validate
>> that dependency binaries actually derive from specific source code.
>>
>> Security-conscious consumers will naturally take such matters into account
>> when deciding how best to consume our products.
>
> To pile on top of Marvin's excellent answer (and at the risk of
> stating the obvious,
> at least the obvious to longtimers): remember even for binary
> convenience artifacts
> you're still on the hook to make sure your NOTICE file is correct.
> Most of the time
> your NOTICE file for binary convenience artifacts will be larger than
> your NOTICE
> for the source release.
Even more so the LICENSE file.
Not all bundled dependencies will require a notice entry, but all will
have a license.
The license text must be included in the LICENSE file itself or in a
local file linked from it.
It's good practice to list the dependencies and their versions in the
LICENSE file, e.g.
Includes the following under the XYZ license (see licences/XYZ.txt)
foo version 1.2.3
bar version 4.5.6
This serves two purposes - makes it easy for the consumer to find the
licenses for all the bundled code.
And makes it easy for the project to ensure all the necessary licenses
have been included.
The version is needed because licenses may change.
> 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
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Jun 10, 2016 at 4:04 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Fri, Jun 10, 2016 at 5:33 AM, Sharan F <sh...@apache.org> wrote:
>
>> We need some confirmation regarding what is included in an Apache release.
>
> The canonical page for Apache Release Policy is here:
>
> http://www.apache.org/legal/release-policy
>
>> Based on these statements our understanding is that:
>>
>> projects must publish "source releases"
>
> Yes.
>
>> "source releases" do not contain binaries
>
> Yes.
>
>> projects may also publish "binary releases"
>
> This is not accurate. Third parties (most often the release manager) may
> provide compiled packages. The colloquialism typically used to refer to these
> packages is "convenience binaries".
>
> http://www.apache.org/legal/release-policy#compiled-packages
>
> The Apache Software Foundation produces open source software. All releases
> are in the form of the source materials needed to make changes to the
> software being released.
>
> As a convenience to users that might not have the appropriate tools to
> build a compiled version of the source, binary/bytecode packages MAY be
> distributed alongside official Apache releases. In all such cases, the
> binary/bytecode package MUST have the same version number as the source
> release and MUST only add binary/bytecode files that are the result of
> compiling that version of the source code release and its dependencies.
>
> The Foundation does not endorse binary packages because such packages are
> opaque and cannot be audited by a PMC.
>
> Over the last few years (post-Snowden), the extent to which security depends
> on audited source and certified repeatable builds has become ever more clear.
>
>> "binary releases" can contain binaries compiled from source code created by
>> the project or binaries from external projects
>
> See the quote above for constraints on what may go into convenience binaries.
> Untrusted jar files (from wherever) are allowed. They must represent
> compilation of open source dependencies, but no verification step is
> required -- i.e. there is no policy requirement that anyone actually validate
> that dependency binaries actually derive from specific source code.
>
> Security-conscious consumers will naturally take such matters into account
> when deciding how best to consume our products.
To pile on top of Marvin's excellent answer (and at the risk of
stating the obvious,
at least the obvious to longtimers): remember even for binary
convenience artifacts
you're still on the hook to make sure your NOTICE file is correct.
Most of the time
your NOTICE file for binary convenience artifacts will be larger than
your NOTICE
for the source release.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Sharan F <sh...@apache.org>.
Hi Alex
I'll give you some context as to why I asked the question.
We recently kicked off what we hope to be a large effort to tidy up and
significantly re-factor our trunk. As as part of that work we wanted to
explore better ways to handle any external dependencies so before we got
any further into our discussions, we wanted to check that we had the
correct understanding of the options available.
Thanks
Sharan
On 10/06/16 18:23, Alex Harui wrote:
>
> On 6/10/16, 7:04 AM, "Marvin Humphrey" <ma...@rectangular.com> wrote:
>
>>> "source releases" do not contain binaries
>> Yes.
> Where binaries == compiled source. AIUI, you can have other "binaries"
> like images and fonts in the source package. IIRC, bundling compressed
> sources is discouraged as well.
>
>>> projects may also publish "binary releases"
>> This is not accurate. Third parties (most often the release manager) may
>> provide compiled packages. The colloquialism typically used to refer to
>> these
>> packages is "convenience binaries".
>>
>> The Foundation does not endorse binary packages because such packages are
>> opaque and cannot be audited by a PMC.
> All true, but AIUI, if the 3rd party is a release manager, the RM is
> allowed to distribute those binary packages from Apache servers.
>
> I'm curious as to what scenario Sharan is dealing with.
>
> -Alex
>
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Alex Harui <ah...@adobe.com>.
On 6/10/16, 7:04 AM, "Marvin Humphrey" <ma...@rectangular.com> wrote:
>
>> "source releases" do not contain binaries
>
>Yes.
Where binaries == compiled source. AIUI, you can have other "binaries"
like images and fonts in the source package. IIRC, bundling compressed
sources is discouraged as well.
>
>> projects may also publish "binary releases"
>
>This is not accurate. Third parties (most often the release manager) may
>provide compiled packages. The colloquialism typically used to refer to
>these
>packages is "convenience binaries".
>
>The Foundation does not endorse binary packages because such packages are
>opaque and cannot be audited by a PMC.
All true, but AIUI, if the 3rd party is a release manager, the RM is
allowed to distribute those binary packages from Apache servers.
I'm curious as to what scenario Sharan is dealing with.
-Alex
Re: Request for clarification of Release Policy regarding external
jar files
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Jun 10, 2016 at 5:33 AM, Sharan F <sh...@apache.org> wrote:
> We need some confirmation regarding what is included in an Apache release.
The canonical page for Apache Release Policy is here:
http://www.apache.org/legal/release-policy
> Based on these statements our understanding is that:
>
> projects must publish "source releases"
Yes.
> "source releases" do not contain binaries
Yes.
> projects may also publish "binary releases"
This is not accurate. Third parties (most often the release manager) may
provide compiled packages. The colloquialism typically used to refer to these
packages is "convenience binaries".
http://www.apache.org/legal/release-policy#compiled-packages
The Apache Software Foundation produces open source software. All releases
are in the form of the source materials needed to make changes to the
software being released.
As a convenience to users that might not have the appropriate tools to
build a compiled version of the source, binary/bytecode packages MAY be
distributed alongside official Apache releases. In all such cases, the
binary/bytecode package MUST have the same version number as the source
release and MUST only add binary/bytecode files that are the result of
compiling that version of the source code release and its dependencies.
The Foundation does not endorse binary packages because such packages are
opaque and cannot be audited by a PMC.
Over the last few years (post-Snowden), the extent to which security depends
on audited source and certified repeatable builds has become ever more clear.
> "binary releases" can contain binaries compiled from source code created by
> the project or binaries from external projects
See the quote above for constraints on what may go into convenience binaries.
Untrusted jar files (from wherever) are allowed. They must represent
compilation of open source dependencies, but no verification step is
required -- i.e. there is no policy requirement that anyone actually validate
that dependency binaries actually derive from specific source code.
Security-conscious consumers will naturally take such matters into account
when deciding how best to consume our products.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org