incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: File headers for third party utility code
Date Tue, 05 Jan 2016 02:17:25 GMT
On Mon, Jan 4, 2016 at 3:02 PM, Roman Shaposhnik <> wrote:
> On Mon, Jan 4, 2016 at 2:50 PM, Todd Lipcon <> wrote:
>> Hi all,
>> I'm working on verifying licenses and copyrights, etc, in Apache Kudu
>> (incubating). There is one area I wanted to confirm the right way to
>> document in our LICENSE/NOTICE files:
>> Kudu makes use of a lot of open source utility code borrowed from (or
>> adapted from) other open source projects. In particular, we've borrowed a
>> lot of code from Chromium's "base" module[1] which is licensed under a BSD
>> 3-clause license[2]. We also have some code from Google Supersonic[3]
>> licensed under the Apache License[4]. The majority of this borrowed code is
>> under a 'gutil' directory in the Kudu tree[5]. We also have some small
>> amounts of code borrowed from LevelDB under the BSD license[6].
> I am in exactly the same boat dealing with Copyright statements of code
> borrowed from Postgres.
>> Given that all of the borrowed code is under the Apache or BSD licenses,
>> the inclusion of the code is completely allowable under the license terms.
>> The only question is the best way to document the inclusion to best follow
>> established ASF practices. My understanding is that we should:
>> 1) Maintain the original copyright notices and license headers in the files.
> Correct. Unless you're a copyright holder or an authorized representative
> of one, you're not allowed to touch existing copyright notices in files.


>> 2) In the cases that we've made non-trivial changes to the source, we
>> should additionally add the ASF copyright notice at the top of the file,
>> and amend the original copyright statement with the words "Some portions"
>> as we've done for example in[7].
> I don't think you need to do that, but you do need an ASF license header.
> I don't think ASF encourages "Portions Copyright ... ASF" statements
> on individual files.

See below...

>> 3) In all files (regardless of whether we've made changes), we should add
>> the Apache license header above any existing license headers, while
>> maintaining the existing one.
> Correct and it should also solve #2

Alex got to this link before I did, which answers the question more

As to where to draw the line between major and minor modifications, I don't
recall having seen a conversation about that on either general@incubator or
legal-discuss@apache in the last several years.  (Though maybe it happened and
memory fails.)  I suggest bringing this topic up on legal-discuss@apache.

>> 4) In the LICENSE file, we should make note of the included code and its
>> copyrights as we have done here[8].
> I tend to be in the camp that values simplicity of LICENSE file. IOW,
> this need to be a succinct communication of what an overall license
> for the source bundle is and that's ALv2.

Perhaps I'm misinterpreting, but this advice seems to be "The LICENSE file
should contain the ALv2 and nothing more."

The position that only the ALv2 should go into LICENSE is legally defensible,
but it contradicts both ASF Release Policy and other documentation such as the
Licensing How-To[1].

    When a package bundles code under several licenses, the LICENSE file MUST
    contain details of all these licenses. For each component which is not
    Apache licensed, details of the component MUST be appended to the LICENSE

I think it's important that the Incubator avoid offering guidance on such
matters which conflicts with policy, even if the position is defensible.
Arguing about this stuff is boring and time-sucking.  The more formulaic we
can make licensing, the less of a drain it will be on our volunteers.

> You do need to update NOTICE files accordingly though.

This is hard to disagree with, but ambiguous -- so please bear with me while I
restate with different emphasis...

There are a handful of things which need absolutely need to go in NOTICE.
Anything else needs to be kept out.

Here is a non-exhaustive list of things which people seem quite tempted to put
into NOTICE files but which don't belong there:

*   Details of non-bundled dependencies
*   Details of dependencies which are bundled with a convenience binary but
    not with the official source release
*   Details of bundled MIT-licensed dependencies
*   Details of bundled BSD2-licensed/BSD3-licensed dependencies
*   Details of bundled ALv2-licensed dependencies which do not themselves
    provide a NOTICE file.

Please folks, keep LICENSE and NOTICE correct but minimal, so that downstream
consumers are spared from having to deal with needlessly complicated

Marvin Humphrey


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message