Re: Help from Mentors

[Gino Bustelo]

We are correcting our LICENSE bundling to mirror what you've sent.

Now, on NOTICE file, we are going by the statement at
http://www.apache.org/dev/licensing-howto.html#mod-notice

>However, elements such as the copyright notifications embedded within BSD
and MIT licenses need not be duplicated in NOTICE

On Fri, Apr 8, 2016 at 12:51 PM, Hitesh Shah  wrote:

> Another useful doc which was being worked on as part of Kudu going through
> the same pains of its first release:
>
> https://docs.google.com/document/d/1eftfjrWpOG-dRkw9dZWRfcj3p_qCeE5xC-G0Y5j29Ck/edit
>
> — Hitesh
>
> On Apr 8, 2016, at 9:03 AM, Gino Bustelo  wrote:
>
> > I'm reading
> https://github.com/zeromq/jeromq/blob/master/COPYING.LESSER#L91 and
> > seems to me that we need to ship our bin distros with copies of the LGPL
> > license. What is you all read?
> >
> > On Thu, Apr 7, 2016 at 6:00 PM, Gino Bustelo  wrote:
> >
> >> @hitesh
> >>
> >> Awesome summary. This helps a ton. It confirms what we about to do with
> >> License/Notices files.
> >>
> >>
> >> Thanks
> >>
> >> Gino B.
> >>
> >>> On Apr 6, 2016, at 6:07 PM, Hitesh Shah  wrote:
> >>>
> >>> Will take a look.
> >>>
> >>> Some general comments in the meantime:
> >>>  - version should have incubating. tar balls should be versioned and
> >> have incubating as part of their names ( this seems to be getting
> addressed
> >> in the pull request )
> >>>  - the main LICENSE and NOTICE are for a source release. This means if
> >> there are any files part of the source release ( javascript, fonts, etc
> )
> >> which are checked in as part of the codebase that have a different
> license
> >> should be checked to see if any updates are needed to the main LICENSE
> and
> >> NOTICE files.
> >>>  - Based on the thread (
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E
> >> ), this will be the only one release allowed with the LGPL dependency.
> In
> >> addition, based on the thread, a sentence added to the DISCLAIMER that
> >> Toree depends on X which is licensed using Y and does not conform to
> Apache
> >> License v2 would be needed. See Bertrand’s reply to the thread.
> >>>  - jars should have a LICENSE and NOTICE ( seems like this is being
> >> addressed in the pull request too )
> >>>  - If there is a plan to publish binary-release.tar.gz and the other
> >> tarball as convenience artifacts as part of the release, they will need
> >> their own LICENSE and NOTICE files depending on what each of them are
> >> bundling. This is usually where most podlings trip up.
> >>>
> >>> thanks
> >>> — Hitesh
> >>>
>  On Apr 5, 2016, at 3:10 PM, Gino Bustelo  wrote:
> 
>  Thanks Hitesh... would you be available to take a look at all we are
>  covering in the  PR #13 <
> >> https://github.com/apache/incubator-toree/pull/13>.
>  Would be great to get an idea if we are going in the right direction
>  regarding LICENSE/NOTICE files and what is needed extra due to LGPL
>  dependency.
> 
>  I think once we got signing done... all the pieces are in place to
> >> create
>  all the assets that will be released.
> 
> > On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah 
> wrote:
> >
> > For snapshot versions, I believe build tools are allowed to publish
> to
> >> the
> > snapshot repo as needed. jenkins builds already support this and I am
> > guessing travis should have similar provisions.
> >
> > For releases ( with a disclaimer as binary artifacts are not
> considered
> > part of an official release), the binary convenience artifacts would
> be
> > publish via dist.apache.org. The general approach is to publish an
> RC
> >> to
> > dist.apache/dev , get it voted upon by the community/PPMC ( followed
> >> by an
> > IPMC vote on general@incubator ) and then move to /release after the
> >> vote
> > is successful. As part of the RC creation, the release manager would
> >> do an
> > appropriate mvn deploy ( this will go into a staging repo ) and also
> >> push
> > the bits to dist.apache.org - both of which need to be signed.
> >
> > Will need to check more on travis and whether a tool can publish bits
> >> as
> > all releases are meant to be signed by someone from the PPMC and
> using
> >> a
> > tool would imply providing your secret keys to the tool.
> >
> > — Hitesh
> >
> >> On Apr 5, 2016, at 7:23 AM, Gino Bustelo  wrote:
> >>
> >> We are getting close to completing work to our build scripts (PR #13
> >> ) to make the
> >> project
> >> follow the Apache release criteria that we've been able to find
> >> through
> >> search. Mainly auditing license headers, POM content, jar generation
> >> with
> >> NOTICE/LICENSE files, etc.
> >>
> >> At this point we need someone with experience that can verify all
> the
> > steps
> >> we've d

Re: Help from Mentors

[Hitesh Shah]

Another useful doc which was being worked on as part of Kudu going through the 
same pains of its first release:
https://docs.google.com/document/d/1eftfjrWpOG-dRkw9dZWRfcj3p_qCeE5xC-G0Y5j29Ck/edit

— Hitesh

On Apr 8, 2016, at 9:03 AM, Gino Bustelo  wrote:

> I'm reading https://github.com/zeromq/jeromq/blob/master/COPYING.LESSER#L91 
> and
> seems to me that we need to ship our bin distros with copies of the LGPL
> license. What is you all read?
> 
> On Thu, Apr 7, 2016 at 6:00 PM, Gino Bustelo  wrote:
> 
>> @hitesh
>> 
>> Awesome summary. This helps a ton. It confirms what we about to do with
>> License/Notices files.
>> 
>> 
>> Thanks
>> 
>> Gino B.
>> 
>>> On Apr 6, 2016, at 6:07 PM, Hitesh Shah  wrote:
>>> 
>>> Will take a look.
>>> 
>>> Some general comments in the meantime:
>>>  - version should have incubating. tar balls should be versioned and
>> have incubating as part of their names ( this seems to be getting addressed
>> in the pull request )
>>>  - the main LICENSE and NOTICE are for a source release. This means if
>> there are any files part of the source release ( javascript, fonts, etc )
>> which are checked in as part of the codebase that have a different license
>> should be checked to see if any updates are needed to the main LICENSE and
>> NOTICE files.
>>>  - Based on the thread (
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E
>> ), this will be the only one release allowed with the LGPL dependency. In
>> addition, based on the thread, a sentence added to the DISCLAIMER that
>> Toree depends on X which is licensed using Y and does not conform to Apache
>> License v2 would be needed. See Bertrand’s reply to the thread.
>>>  - jars should have a LICENSE and NOTICE ( seems like this is being
>> addressed in the pull request too )
>>>  - If there is a plan to publish binary-release.tar.gz and the other
>> tarball as convenience artifacts as part of the release, they will need
>> their own LICENSE and NOTICE files depending on what each of them are
>> bundling. This is usually where most podlings trip up.
>>> 
>>> thanks
>>> — Hitesh
>>> 
 On Apr 5, 2016, at 3:10 PM, Gino Bustelo  wrote:
 
 Thanks Hitesh... would you be available to take a look at all we are
 covering in the  PR #13 <
>> https://github.com/apache/incubator-toree/pull/13>.
 Would be great to get an idea if we are going in the right direction
 regarding LICENSE/NOTICE files and what is needed extra due to LGPL
 dependency.
 
 I think once we got signing done... all the pieces are in place to
>> create
 all the assets that will be released.
 
> On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah  wrote:
> 
> For snapshot versions, I believe build tools are allowed to publish to
>> the
> snapshot repo as needed. jenkins builds already support this and I am
> guessing travis should have similar provisions.
> 
> For releases ( with a disclaimer as binary artifacts are not considered
> part of an official release), the binary convenience artifacts would be
> publish via dist.apache.org. The general approach is to publish an RC
>> to
> dist.apache/dev , get it voted upon by the community/PPMC ( followed
>> by an
> IPMC vote on general@incubator ) and then move to /release after the
>> vote
> is successful. As part of the RC creation, the release manager would
>> do an
> appropriate mvn deploy ( this will go into a staging repo ) and also
>> push
> the bits to dist.apache.org - both of which need to be signed.
> 
> Will need to check more on travis and whether a tool can publish bits
>> as
> all releases are meant to be signed by someone from the PPMC and using
>> a
> tool would imply providing your secret keys to the tool.
> 
> — Hitesh
> 
>> On Apr 5, 2016, at 7:23 AM, Gino Bustelo  wrote:
>> 
>> We are getting close to completing work to our build scripts (PR #13
>> ) to make the
>> project
>> follow the Apache release criteria that we've been able to find
>> through
>> search. Mainly auditing license headers, POM content, jar generation
>> with
>> NOTICE/LICENSE files, etc.
>> 
>> At this point we need someone with experience that can verify all the
> steps
>> we've done. Also, it is not clear to me what the process is to getting
> all
>> the assets published for a release vote. Several question are:
>> 
>> 1. Can publishing of assets be automated using Travis? Including maven
>> publish, and binary package distribution.
>> 2. Where do we publish binary packages? Not talking about JARs,
>> rather a
>> package with libraries and scripts to start/run Toree.
>> 
>> Any help is appreciated...
>> 
>> Thanks,
>> Gino
>>> 
>> 

Re: Help from Mentors

[Hitesh Shah]

Thats actually required for any bundled dependency that has a non ALv2 license 
even the permissible ones such as BSD, MIT, etc ( not only LGPL ones ). The 
top-level license file is meant to call out the licenses for all the things 
that are being bundled. 

To summarize for the license files - depending on what is being bundled, the 
license file for the bundle should have either the full contents of the 
non-ALv2 licenses or pointers to the full text within the bundle itself ( 
cannot be a url). The Notice file is a trial-and-error at best to try and go 
through each dependency and figure out if the notice file needs updates. This 
is needed with the CDDL license for example ( based on looking at other 
projects ) as it requires a pointer to the actual source code for the CDDL jar 
that is being bundled ( 
https://tldrlegal.com/license/common-development-and-distribution-license-(cddl-1.0)-explained
 )

https://github.com/apache/spark seems to have a good handle on the 
license/notice files which could be used as helper guidelines. Although not 
really the best example to follow, you can take a look at 
https://github.com/apache/tez/tree/master/tez-dist/dist-files to see what we 
have done for the binary artifacts. We have the jars listed in the license file 
for now to aid a helper script to ensure that we are covering all the bundled 
artifacts. https://github.com/apache/lens/tree/master/bin-dist-files is another 
good example. 

thanks
— Hitesh

On Apr 8, 2016, at 9:03 AM, Gino Bustelo  wrote:

> I'm reading https://github.com/zeromq/jeromq/blob/master/COPYING.LESSER#L91 
> and
> seems to me that we need to ship our bin distros with copies of the LGPL
> license. What is you all read?
> 
> On Thu, Apr 7, 2016 at 6:00 PM, Gino Bustelo  wrote:
> 
>> @hitesh
>> 
>> Awesome summary. This helps a ton. It confirms what we about to do with
>> License/Notices files.
>> 
>> 
>> Thanks
>> 
>> Gino B.
>> 
>>> On Apr 6, 2016, at 6:07 PM, Hitesh Shah  wrote:
>>> 
>>> Will take a look.
>>> 
>>> Some general comments in the meantime:
>>>  - version should have incubating. tar balls should be versioned and
>> have incubating as part of their names ( this seems to be getting addressed
>> in the pull request )
>>>  - the main LICENSE and NOTICE are for a source release. This means if
>> there are any files part of the source release ( javascript, fonts, etc )
>> which are checked in as part of the codebase that have a different license
>> should be checked to see if any updates are needed to the main LICENSE and
>> NOTICE files.
>>>  - Based on the thread (
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E
>> ), this will be the only one release allowed with the LGPL dependency. In
>> addition, based on the thread, a sentence added to the DISCLAIMER that
>> Toree depends on X which is licensed using Y and does not conform to Apache
>> License v2 would be needed. See Bertrand’s reply to the thread.
>>>  - jars should have a LICENSE and NOTICE ( seems like this is being
>> addressed in the pull request too )
>>>  - If there is a plan to publish binary-release.tar.gz and the other
>> tarball as convenience artifacts as part of the release, they will need
>> their own LICENSE and NOTICE files depending on what each of them are
>> bundling. This is usually where most podlings trip up.
>>> 
>>> thanks
>>> — Hitesh
>>> 
 On Apr 5, 2016, at 3:10 PM, Gino Bustelo  wrote:
 
 Thanks Hitesh... would you be available to take a look at all we are
 covering in the  PR #13 <
>> https://github.com/apache/incubator-toree/pull/13>.
 Would be great to get an idea if we are going in the right direction
 regarding LICENSE/NOTICE files and what is needed extra due to LGPL
 dependency.
 
 I think once we got signing done... all the pieces are in place to
>> create
 all the assets that will be released.
 
> On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah  wrote:
> 
> For snapshot versions, I believe build tools are allowed to publish to
>> the
> snapshot repo as needed. jenkins builds already support this and I am
> guessing travis should have similar provisions.
> 
> For releases ( with a disclaimer as binary artifacts are not considered
> part of an official release), the binary convenience artifacts would be
> publish via dist.apache.org. The general approach is to publish an RC
>> to
> dist.apache/dev , get it voted upon by the community/PPMC ( followed
>> by an
> IPMC vote on general@incubator ) and then move to /release after the
>> vote
> is successful. As part of the RC creation, the release manager would
>> do an
> appropriate mvn deploy ( this will go into a staging repo ) and also
>> push
> the bits to dist.apache.org - both of which need to be signed.
> 
> Will need to check more on travis and whether a tool can publish bits
>> as
> all releases are m

Re: Help from Mentors

[Gino Bustelo]

I'm reading https://github.com/zeromq/jeromq/blob/master/COPYING.LESSER#L91 and
seems to me that we need to ship our bin distros with copies of the LGPL
license. What is you all read?

On Thu, Apr 7, 2016 at 6:00 PM, Gino Bustelo  wrote:

> @hitesh
>
> Awesome summary. This helps a ton. It confirms what we about to do with
> License/Notices files.
>
>
> Thanks
>
> Gino B.
>
> > On Apr 6, 2016, at 6:07 PM, Hitesh Shah  wrote:
> >
> > Will take a look.
> >
> > Some general comments in the meantime:
> >   - version should have incubating. tar balls should be versioned and
> have incubating as part of their names ( this seems to be getting addressed
> in the pull request )
> >   - the main LICENSE and NOTICE are for a source release. This means if
> there are any files part of the source release ( javascript, fonts, etc )
> which are checked in as part of the codebase that have a different license
> should be checked to see if any updates are needed to the main LICENSE and
> NOTICE files.
> >   - Based on the thread (
> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E
> ), this will be the only one release allowed with the LGPL dependency. In
> addition, based on the thread, a sentence added to the DISCLAIMER that
> Toree depends on X which is licensed using Y and does not conform to Apache
> License v2 would be needed. See Bertrand’s reply to the thread.
> >   - jars should have a LICENSE and NOTICE ( seems like this is being
> addressed in the pull request too )
> >   - If there is a plan to publish binary-release.tar.gz and the other
> tarball as convenience artifacts as part of the release, they will need
> their own LICENSE and NOTICE files depending on what each of them are
> bundling. This is usually where most podlings trip up.
> >
> > thanks
> > — Hitesh
> >
> >> On Apr 5, 2016, at 3:10 PM, Gino Bustelo  wrote:
> >>
> >> Thanks Hitesh... would you be available to take a look at all we are
> >> covering in the  PR #13 <
> https://github.com/apache/incubator-toree/pull/13>.
> >> Would be great to get an idea if we are going in the right direction
> >> regarding LICENSE/NOTICE files and what is needed extra due to LGPL
> >> dependency.
> >>
> >> I think once we got signing done... all the pieces are in place to
> create
> >> all the assets that will be released.
> >>
> >>> On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah  wrote:
> >>>
> >>> For snapshot versions, I believe build tools are allowed to publish to
> the
> >>> snapshot repo as needed. jenkins builds already support this and I am
> >>> guessing travis should have similar provisions.
> >>>
> >>> For releases ( with a disclaimer as binary artifacts are not considered
> >>> part of an official release), the binary convenience artifacts would be
> >>> publish via dist.apache.org. The general approach is to publish an RC
> to
> >>> dist.apache/dev , get it voted upon by the community/PPMC ( followed
> by an
> >>> IPMC vote on general@incubator ) and then move to /release after the
> vote
> >>> is successful. As part of the RC creation, the release manager would
> do an
> >>> appropriate mvn deploy ( this will go into a staging repo ) and also
> push
> >>> the bits to dist.apache.org - both of which need to be signed.
> >>>
> >>> Will need to check more on travis and whether a tool can publish bits
> as
> >>> all releases are meant to be signed by someone from the PPMC and using
> a
> >>> tool would imply providing your secret keys to the tool.
> >>>
> >>> — Hitesh
> >>>
>  On Apr 5, 2016, at 7:23 AM, Gino Bustelo  wrote:
> 
>  We are getting close to completing work to our build scripts (PR #13
>  ) to make the
> project
>  follow the Apache release criteria that we've been able to find
> through
>  search. Mainly auditing license headers, POM content, jar generation
> with
>  NOTICE/LICENSE files, etc.
> 
>  At this point we need someone with experience that can verify all the
> >>> steps
>  we've done. Also, it is not clear to me what the process is to getting
> >>> all
>  the assets published for a release vote. Several question are:
> 
>  1. Can publishing of assets be automated using Travis? Including maven
>  publish, and binary package distribution.
>  2. Where do we publish binary packages? Not talking about JARs,
> rather a
>  package with libraries and scripts to start/run Toree.
> 
>  Any help is appreciated...
> 
>  Thanks,
>  Gino
> >
>