>
> jars generated off of current master contain no LICENSE, NOTICE, or other
> metadata
>
We should fix this. This may be an issue.
suggested approach of overapproximating
>>
>
The purpose of quoted sentence above ("A part of...") is to qualify when a
particular portion applies. It contains extra content in some cases, sure,
but such content is qualified that it may not apply / can be ignored. (More
specificity welcome.)
Of course, anybody is welcome to go above and beyond and maintain this
content per module, per distribution, per source jar, per test jar, per
source test jar, etc. This would be ideal, but I don't remember seeing
anybody doing it at this granularity. (Obviously, when shading, contents of
jar and source jar differ in this regard for the same module.) Also,
welcome to find a different balance, perhaps a more reasonable one.
Did you look through all our jars or is that just a sample?
>>>>>
>>>>
Perhaps noteworthy: please don't generalize the fix to other circumstances
(if they are any, or if such come up). This fix applies to this type of
bundling of MIT-licensed and (some) BSD-licensed content *only*. There are
many quirks between different license combinations, which file to modify,
and in what way -- this space is quite deep. When in doubt, please ask here
to get the changes reviewed by senior folks (or referred to other
authoritative ASF resources).
A friendly nearby project recently has gone through public shaming because
they got this wrong. Thanks for working hard to avoid a situation like that
for us!
