In this case we're just talking about the name of the .tgz archives that are distributed for download. I agree we would not want to change the Maven coordinates.
On Thu, Jun 2, 2016 at 9:28 AM, Marcin Tustin <mtus...@handybook.com> wrote: > Changing the maven co-ordinates is going to cause everyone in the world who > uses a maven-based build system to have update their builds. Given that sbt > uses ivy by default, that's likely to affect almost every spark user. > > Unless we can articulate what the extra legal protections are (and frankly I > don't believe that having or not having apache in the maven co-ordinates or > jar filenames makes a jot of difference - I'm happy to be proved wrong) I'm > strongly negative on such a change. > > Marcin > > On Thu, Jun 2, 2016 at 9:35 AM, Sean Owen <sro...@gmail.com> wrote: >> >> +dev >> >> On Wed, Jun 1, 2016 at 11:42 PM, Justin Mclean <jus...@classsoftware.com> >> wrote: >> > Anyway looking at the preview I noticed a few minor things: >> > - Most release artefacts have the word “apache” in them the ones at [1] >> > do not. Adding “apache” gives you some extra legal protection. >> >> As to why just 'spark' -- I believe it's merely historical. My >> understanding of the trademark policy from discussions over the past >> month is that software identifiers like Maven coordinates do not >> strictly require 'apache'. I don't imagine that's hard to change; I >> don't know if it causes some disruption downstream or what. Hence it >> has just stood as is. >> >> > - The year in the NOTICE file is out of date. These days most NOTICE >> > files have a year range. >> >> I can change that to "Copyright 2014 and onwards" for completeness, yes. >> >> > - The NOTICE file seems to contains a lot of unneeded content [3] >> >> Which are unneeded? I created it a long while ago to contain what it >> needed, and have tried to prune or add to it as needed. I could have >> missed something. This is covering all the binary artifacts the >> project produces. >> >> > - The NOTICE file lists CDDL and EPL licenses, I believe these should be >> > in the LICENSE/NOTICE file for the binary distribution and not the source >> > distribution. CDDL and EPL licensed code are category B not allowed to be >> > bundled in source releases. [2] A LICENSE / NOTICE should match to what is >> > actually bundled into the artefact. [4] >> >> These category B artifacts are not included in source form. Yes, these >> entries are for the binary distribution. There is one NOTICE file for >> both binary and source distributions. I think this is simply because >> it's hard to maintain both, and not-wrong to maintain one file that >> covers both. >> >> > - The source release contains a number of jars. (Looks like they are >> > used for testing but still…) >> >> Yes the ones I'm aware of are necessary -- like, they're literally >> testing how UDF jars get loaded by certain code paths. I think that's >> not what the prohibition against jars in source distros is trying to >> get at. It's not distributing functional code in binary-only form. >> >> > - The LICENSE may to be missing a few things like for instance moderizr >> > [5] >> >> I agree, good catch. This is MIT-licensed and it's not in licenses/. >> I'll fix that. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org >> For additional commands, e-mail: dev-h...@spark.apache.org >> > > > Want to work at Handy? Check out our culture deck and open roles > Latest news at Handy > Handy just raised $50m led by Fidelity > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
