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

Reply via email to