What should go into license/ folders? (important)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

What should go into license/ folders? (important)

Dawid Weiss-2
I'm porting jar checksums to gradle and it's a bit like trying to
reconstruct this from scratch:

https://en.wikipedia.org/wiki/The_Tower_of_Babel_(Bruegel)#/media/File:Pieter_Bruegel_the_Elder_-_The_Tower_of_Babel_(Vienna)_-_Google_Art_Project.jpg

We have dangling files, references to JARs no longer used... It's a mess.

I'll clean it up but I need to know the following so that its consistent:

1) Do we include checksums and licenses of JARs that are only part of
the build? For example, solr-ref-guide has a number of esoteric
dependencies that are not really part of the "distribution".

2) Do we include checksums and licenses of JARs that are only used in
tests? JUnit, mocks, etc.

3) Should Solr include all licenses (and checksums) of Lucene
dependencies or can we exclude them and only focus on Solr's own
dependencies? Lucene dependencies are still verified and have licenses
but only under lucene/licenses (not in both projects).

My picks are:

1) no, we don't include non-code (build-only) dependencies under licenses/.
2) yes, we include checksums of test JARs (so that we can be sure
builds are running the same stuff on different machines),
3) no, Solr's licenses/ folder should only include Solr's own
dependencies. Lucene license files (and possibly JAR checksums) can be
added to Solr distribution package but don't have to be stored/
versioned/ verified twice.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: What should go into license/ folders? (important)

Kevin Risden-3
https://www.apache.org/legal/release-policy.html#licensing-documentation

Based on reading the above, I think we need to have licenses and notices for everything that ends up in the distribution unless they are downloaded separately. 

So based on that I agree with your 3 answers.

Kevin Risden


On Fri, Dec 13, 2019 at 8:34 AM Dawid Weiss <[hidden email]> wrote:
I'm porting jar checksums to gradle and it's a bit like trying to
reconstruct this from scratch:

https://en.wikipedia.org/wiki/The_Tower_of_Babel_(Bruegel)#/media/File:Pieter_Bruegel_the_Elder_-_The_Tower_of_Babel_(Vienna)_-_Google_Art_Project.jpg

We have dangling files, references to JARs no longer used... It's a mess.

I'll clean it up but I need to know the following so that its consistent:

1) Do we include checksums and licenses of JARs that are only part of
the build? For example, solr-ref-guide has a number of esoteric
dependencies that are not really part of the "distribution".

2) Do we include checksums and licenses of JARs that are only used in
tests? JUnit, mocks, etc.

3) Should Solr include all licenses (and checksums) of Lucene
dependencies or can we exclude them and only focus on Solr's own
dependencies? Lucene dependencies are still verified and have licenses
but only under lucene/licenses (not in both projects).

My picks are:

1) no, we don't include non-code (build-only) dependencies under licenses/.
2) yes, we include checksums of test JARs (so that we can be sure
builds are running the same stuff on different machines),
3) no, Solr's licenses/ folder should only include Solr's own
dependencies. Lucene license files (and possibly JAR checksums) can be
added to Solr distribution package but don't have to be stored/
versioned/ verified twice.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]