And exactly that file in the Edgent and PLC4X project are copies of my original
code (My PR wasn't accepted till then)
So IANAL, but if you copy the file from one of those, it should be ok ...
correct?
It was code written by someone with a signed ICLA, committed to an Apache
project.
Chris
Am 14.02.19, 07:19 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Does it help, that I wrote that file and submitted it in a pull request to
eliminate the binary jar needed prior to my change? ... Guess that's also an
additional reason why there's an Apache header on it :-)
Outlook für Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Mick Semb Wever <m...@apache.org>
Sent: Thursday, February 14, 2019 7:05:02 AM
To: general@incubator.apache.org
Subject: Re: the case of the maven wrapper
> As binaries are not allowed in source repos, the maven wrapper
> introduces a small java source file which bootstraps the tool. This
> has Apache license headers on it.
Takari is an Apache licensed codebase.
My understanding is that there is a requirement to include it in the
NOTICE.txt file.
Furthermore, Takari contains no copyright. Is this of concern?
http://www.apache.org/dev/licensing-howto.html
https://www.apache.org/legal/src-headers.html
> As a part of Zipkin's first attempt to vote a release on the general
> list … asking for it to be in the NOTICE box.
One of the tings I've noticed is that the vetos on a podling's first
release can be a bit harsh.
I do really love the "community over code" motto, and i would hope to see
the incubator being a leader in displaying the warmth and inclusion that leads
to a healthy and enjoyable community.
On releases I would rather see such vetos replaced with comments that are
feedback, while still obvious that they are an issue that is expected to be
fixed by the next release (and before graduation). I think this would be warmer
feedback, and permit a more incremental approach to getting to the standard of
release required for graduation.
Momentum and results is an important motivator, and there's a lot to learn
about the ASF requirements on the podling's journey to graduation.
> It feels we are just
> adding things to it and as an end user, I'm not sure how this would
> add clarity.
An apache release is first aimed at someone who builds the source artefact.
Even if this isn't the popular use-case.
This also highlights the value in having the takari wrapper in place.
> Even if it did, I'm concerned that we are jumping to a
> enforcement remediation when no-one seems to be doing it at all.
I've seen this unfairness bite a bit already.
Feedback that the incubator provides to podlings should be in context of
the broader precedence in the ASF.
If it's something that's not being strictly adhered to by graduate
projects, it would make a world of difference to podlings if they saw everyone
was getting pulled up on the violation. Otherwise it comes across as podlings
are required to meet a standard well above the graduate projects, and that
becomes a real deterrence for many to entering Apache.
This would add some burden to the Incubator. Surveys of graduate projects
would be required to see such precedence on issues. And resulting feedback to
graduate projects can also be tricky, nobody likes to feel that they are being
picked on. IDK, but maybe this feedback can go to the board, and the board can
pick one issue per quarter and request projects address them by their next
board report.
regards,
Mick
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
