You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pirk.apache.org by Tim Ellison <t....@gmail.com> on 2016/08/17 15:13:48 UTC
Re: Source JAR vs. Convenience binary JAR license files
On 17/08/16 16:08, Ellison Anne Williams wrote:
> I'm seeing the same LICENSE and NOTICE files used throughout NiFi - even in
> the nifi-assembly directory which is referenced here
> https://nifi.apache.org/licensing-guide.html
>
> Joe - Am I missing something here?
>
> I would echo Suneel and ask if (1) it is really a strict requirement for
> our sources jar and/or (2) if we are interpreting it correctly.
If we don't get a local answer, let's ask on general@incubator. The
Foundation policy seems clear enough to me, and I agree that it appears
that many projects are not following it -- so something is wrong.
http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
http://www.apache.org/dev/licensing-howto.html#binary
Regards,
Tim
> On Wed, Aug 17, 2016 at 10:55 AM, Suneel Marthi <su...@gmail.com>
> wrote:
>
>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
>> wrote:
>>
>>> On 17/08/16 11:40, ellisonanne wrote:
>>>> Github user ellisonanne commented on a diff in the pull request:
>>>>
>>>> https://github.com/apache/incubator-pirk/pull/65#
>>> discussion_r75099656
>>>>
>>>> --- Diff: LICENSE ---
>>>> @@ -199,4 +199,64 @@
>>>> distributed under the License is distributed on an "AS IS"
>> BASIS,
>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>>> implied.
>>>> See the License for the specific language governing permissions
>>> and
>>>> - limitations under the License.
>>>> \ No newline at end of file
>>>> + limitations under the License.
>>>> +
>>>> +
>>>> +===========================================================
>>> ============
>>>> +Apache Pirk (incubating) Subcomponents:
>>>> +
>>>> +The Apache Pirk project contains subcomponents with separate
>>> copyright
>>>> +notices and license terms. Your use of the source code for the
>> these
>>>> +subcomponents is subject to the terms and conditions of the
>>> following
>>>> +licenses.
>>>> +
>>>> --- End diff --
>>>>
>>>> I'm confused - how do we create different LICENSE and NOTICE files
>>>> for the different jars when they are built via the release plugin?
>>>
>>> I'm guessing it requires some pom foo beyond my feeble capabilities :-(
>>>
>>
>> I am not sure how u can package/not package license files in different
>> artifacts.
>> If this is a strict requirement, a good chunk of TLPs today are in
>> violation of this.
>>
>> Should we have Justin McLean or John D. Ament from IPMC review our
>> artifacts now?
>>
>>>
>>> Besides stating the obvious that :
>>>
>>> (1) we'd store the source LICENSE and NOTICE file in the project
>>> repository root, and place in there only the required information for
>>> code we are hosting in our repo and including in the source.jar. For
>>> Pirk as it is today, that will be a plain ALv2 text and simple notice.
>>>
>>> (2) we'd then have alternative LICENSE and NOTICE files for the
>>> convenience "exe" JAR in a subdirectory that are used to replace the
>>> top-level files when building the binaries. This would refer to the
>>> license/ directory containing the full text of the 3rd-party licenses.
>>>
>>> Maybe our friends from Apache NiFi can explain what they do, as they
>>> have the correct information in their release guide [1], and they are
>>> Maven-based too.
>>>
>>> A number of other projects I peeked into don't seem to be doing the
>>> right thing IMHO.
>>>
>>> [1] https://nifi.apache.org/licensing-guide.html
>>>
>>> Regards,
>>> Tim
>>>
>>
>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Joe Witt <jo...@gmail.com>.
Hello,
The link Tim provided to the licesning guide NiFi uses is definitely a
great place to start as it brings together a bunch of ASF policy
and/or guidance and applies it to the context of Apache NiFi, what we
release, and our bundling model.
Whether this is a strict policy or not is clear - yes. The basic gist is:
- For any artifact you publish it must have appropriate L&N.
The other basic gist:
- If it seems easy you're probably doing it wrong.
Officially Apache Software Foundation releases are 'source releases
only'. This is the top level L&N that all projects have and as TIm
mentioned that covers anything in your source tree (has nothing to do
with dependencies pulled it during the build or runtime).
Some projects only end up having this top level source L&N and it is
because they also only provide source and they don't publish the
artifacts. By not publishing any derived binary artifacts they are
not having to worry about this though for such cases consider that
community formation is dependent on people who can adequately take the
source and produce a workable build.
Some other projects who do produce convenience binaries (such as a
zip, tar.gz, jars published to maven) also only end up top level
source L&N. This either means they have no dependencies or they're
'doin it wrong'. I've found awareness and or consideration for L&N to
be uneven though there seems to be increasing awareness here. People
like Billie, Josh, Sean, myself and perhaps most notably Justin McLean
are are definitely helping in this arena.
Now, many projects do elect to provide convenience binaries and again
you have to account for the L&N of each artifact you produce. We have
L&N files all over the place in our codebase in NiFi. The Top level
L&N accounts for source and all others account for the binary artifact
that would be produced. There are *huge* differences between our
NOTICE at the top level source and in the nifi-assembly for example.
You can ensure that an overriden L&N ends up in your uber jar pretty
easily by placing it into the correct META-INF location of your source
tree. See here [1] for an example.
Finally, I'll add that it is possible we're not doing it correctly in
NiFi. We could be overdoing it, under doing it, etc. It is just not
easy and everyone ultimately will say "IANAL". The community
consensus of 'ok this looks about right is key here'. So lets just
keep iterating on it. The uber jar must have an L&N that accounts for
all the things that get bundled in it.
[1] https://github.com/apache/nifi/blob/6de738fd04f773ba6b05b3768c5214847b55cf50/nifi-nar-bundles/nifi-update-attribute-bundle/nifi-update-attribute-nar/src/main/resources/META-INF/NOTICE
On Wed, Aug 17, 2016 at 8:13 AM, Tim Ellison <t....@gmail.com> wrote:
> On 17/08/16 16:08, Ellison Anne Williams wrote:
>> I'm seeing the same LICENSE and NOTICE files used throughout NiFi - even in
>> the nifi-assembly directory which is referenced here
>> https://nifi.apache.org/licensing-guide.html
>>
>> Joe - Am I missing something here?
>>
>> I would echo Suneel and ask if (1) it is really a strict requirement for
>> our sources jar and/or (2) if we are interpreting it correctly.
>
> If we don't get a local answer, let's ask on general@incubator. The
> Foundation policy seems clear enough to me, and I agree that it appears
> that many projects are not following it -- so something is wrong.
>
> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> http://www.apache.org/dev/licensing-howto.html#binary
>
> Regards,
> Tim
>
>
>> On Wed, Aug 17, 2016 at 10:55 AM, Suneel Marthi <su...@gmail.com>
>> wrote:
>>
>>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
>>> wrote:
>>>
>>>> On 17/08/16 11:40, ellisonanne wrote:
>>>>> Github user ellisonanne commented on a diff in the pull request:
>>>>>
>>>>> https://github.com/apache/incubator-pirk/pull/65#
>>>> discussion_r75099656
>>>>>
>>>>> --- Diff: LICENSE ---
>>>>> @@ -199,4 +199,64 @@
>>>>> distributed under the License is distributed on an "AS IS"
>>> BASIS,
>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>>>> implied.
>>>>> See the License for the specific language governing permissions
>>>> and
>>>>> - limitations under the License.
>>>>> \ No newline at end of file
>>>>> + limitations under the License.
>>>>> +
>>>>> +
>>>>> +===========================================================
>>>> ============
>>>>> +Apache Pirk (incubating) Subcomponents:
>>>>> +
>>>>> +The Apache Pirk project contains subcomponents with separate
>>>> copyright
>>>>> +notices and license terms. Your use of the source code for the
>>> these
>>>>> +subcomponents is subject to the terms and conditions of the
>>>> following
>>>>> +licenses.
>>>>> +
>>>>> --- End diff --
>>>>>
>>>>> I'm confused - how do we create different LICENSE and NOTICE files
>>>>> for the different jars when they are built via the release plugin?
>>>>
>>>> I'm guessing it requires some pom foo beyond my feeble capabilities :-(
>>>>
>>>
>>> I am not sure how u can package/not package license files in different
>>> artifacts.
>>> If this is a strict requirement, a good chunk of TLPs today are in
>>> violation of this.
>>>
>>> Should we have Justin McLean or John D. Ament from IPMC review our
>>> artifacts now?
>>>
>>>>
>>>> Besides stating the obvious that :
>>>>
>>>> (1) we'd store the source LICENSE and NOTICE file in the project
>>>> repository root, and place in there only the required information for
>>>> code we are hosting in our repo and including in the source.jar. For
>>>> Pirk as it is today, that will be a plain ALv2 text and simple notice.
>>>>
>>>> (2) we'd then have alternative LICENSE and NOTICE files for the
>>>> convenience "exe" JAR in a subdirectory that are used to replace the
>>>> top-level files when building the binaries. This would refer to the
>>>> license/ directory containing the full text of the 3rd-party licenses.
>>>>
>>>> Maybe our friends from Apache NiFi can explain what they do, as they
>>>> have the correct information in their release guide [1], and they are
>>>> Maven-based too.
>>>>
>>>> A number of other projects I peeked into don't seem to be doing the
>>>> right thing IMHO.
>>>>
>>>> [1] https://nifi.apache.org/licensing-guide.html
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>
>>
Re: Source JAR vs. Convenience binary JAR license files
Posted by Billie Rinaldi <bi...@apache.org>.
Yes, we should have different L&N in different jars when necessary, and
this is possible to configure through maven. That said, I haven't done it
myself, so I'll have to track down some examples of other projects that do
this.
On Wed, Aug 17, 2016 at 8:13 AM, Tim Ellison <t....@gmail.com> wrote:
> On 17/08/16 16:08, Ellison Anne Williams wrote:
> > I'm seeing the same LICENSE and NOTICE files used throughout NiFi - even
> in
> > the nifi-assembly directory which is referenced here
> > https://nifi.apache.org/licensing-guide.html
> >
> > Joe - Am I missing something here?
> >
> > I would echo Suneel and ask if (1) it is really a strict requirement for
> > our sources jar and/or (2) if we are interpreting it correctly.
>
> If we don't get a local answer, let's ask on general@incubator. The
> Foundation policy seems clear enough to me, and I agree that it appears
> that many projects are not following it -- so something is wrong.
>
> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> http://www.apache.org/dev/licensing-howto.html#binary
>
> Regards,
> Tim
>
>
> > On Wed, Aug 17, 2016 at 10:55 AM, Suneel Marthi <suneel.marthi@gmail.com
> >
> > wrote:
> >
> >> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <t....@gmail.com>
> >> wrote:
> >>
> >>> On 17/08/16 11:40, ellisonanne wrote:
> >>>> Github user ellisonanne commented on a diff in the pull request:
> >>>>
> >>>> https://github.com/apache/incubator-pirk/pull/65#
> >>> discussion_r75099656
> >>>>
> >>>> --- Diff: LICENSE ---
> >>>> @@ -199,4 +199,64 @@
> >>>> distributed under the License is distributed on an "AS IS"
> >> BASIS,
> >>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
> or
> >>> implied.
> >>>> See the License for the specific language governing
> permissions
> >>> and
> >>>> - limitations under the License.
> >>>> \ No newline at end of file
> >>>> + limitations under the License.
> >>>> +
> >>>> +
> >>>> +===========================================================
> >>> ============
> >>>> +Apache Pirk (incubating) Subcomponents:
> >>>> +
> >>>> +The Apache Pirk project contains subcomponents with separate
> >>> copyright
> >>>> +notices and license terms. Your use of the source code for the
> >> these
> >>>> +subcomponents is subject to the terms and conditions of the
> >>> following
> >>>> +licenses.
> >>>> +
> >>>> --- End diff --
> >>>>
> >>>> I'm confused - how do we create different LICENSE and NOTICE files
> >>>> for the different jars when they are built via the release plugin?
> >>>
> >>> I'm guessing it requires some pom foo beyond my feeble capabilities :-(
> >>>
> >>
> >> I am not sure how u can package/not package license files in different
> >> artifacts.
> >> If this is a strict requirement, a good chunk of TLPs today are in
> >> violation of this.
> >>
> >> Should we have Justin McLean or John D. Ament from IPMC review our
> >> artifacts now?
> >>
> >>>
> >>> Besides stating the obvious that :
> >>>
> >>> (1) we'd store the source LICENSE and NOTICE file in the project
> >>> repository root, and place in there only the required information for
> >>> code we are hosting in our repo and including in the source.jar. For
> >>> Pirk as it is today, that will be a plain ALv2 text and simple notice.
> >>>
> >>> (2) we'd then have alternative LICENSE and NOTICE files for the
> >>> convenience "exe" JAR in a subdirectory that are used to replace the
> >>> top-level files when building the binaries. This would refer to the
> >>> license/ directory containing the full text of the 3rd-party licenses.
> >>>
> >>> Maybe our friends from Apache NiFi can explain what they do, as they
> >>> have the correct information in their release guide [1], and they are
> >>> Maven-based too.
> >>>
> >>> A number of other projects I peeked into don't seem to be doing the
> >>> right thing IMHO.
> >>>
> >>> [1] https://nifi.apache.org/licensing-guide.html
> >>>
> >>> Regards,
> >>> Tim
> >>>
> >>
> >
>