On Sat, Jun 23, 2018 at 4:47 AM Justin Mclean <jus...@classsoftware.com> wrote:
> See [1] it’s a good idea to have a different LICENSE and NOTICE for source > and binary (and lots of other projects do this). > Agree, this just never happened after I got the initial big overhaul of the LICENSE/NOTICE in place that got things to "not technically violating licenses". I'll take on trying to update them accordingly. > > While I think I got this right a long time ago, a) things can change, and > b) might have missed something. What in particular? (can reply on the PR) > > > The CDDL, CPL, MPL license lists and ALv2 headers at bottom. > CDDL, CPL and MPL are Cat B (looking at http://www.apache.org/legal/resolved.html#category-b here). The reciprocity requires notice, and so I would think NOTICE is the right place? The listing is to comply with this guideline: "Please include the URL to the product's homepage in the prominent label. An appropriate and prominent label is a label the user will read while learning about the distribution - for example in a README. Please also ensure to comply with any attribution/notice requirements in the specific license in question." ALv2 headers don't belong there. Those look like they were added incorrectly a while ago. > I would find it surprising that (for instance) JUnit is bundled in the > binary release but I’ve not looked so it could be correct. > If it's on this list, it's because it turned up one day when I dumped the transitive non-test dependencies of Spark using the Maven plugins. Someone out there may have a (bogus) non-test dependency on Junit. It may no longer be the case, as I do not see any junit classes distributed in the binary distro of Spark now. This should be removed I believe. > IMO they shouldn’t as there no exception for test code vs project code. If > your release contains compiled code then it fails the OSI definition of > open source for starters [2]. It also make it rather hard to correctly > review a release. This has come up a few times on various lists and every > time I seen the same answer i.e it’s not allowed. I’d suggest you ask on > legal discuss for advice re this. > It's not test code; test code would indeed have to be distributed as source as well. They are binary blobs, if you like, needed by test code, that happen to be JARs here and not JPEGs or .docx files or something. These help test handling of JAR files.
