Re: Traffic Control Podling Bundled Dependencies

["John D. Ament" <jo...@apache.org>]

Eric,

Some thoughts, and I'll be honest this is a better discussion for
legal-discuss over general@incubator.

Generally speaking the ASF is cautious about hostile forks.  However, it
looks like the author is comfortable with forks of the project for this
notion (https://bitbucket.org/liamstask/goose/issues/58/is-this-project-dead).
The email you've sent uses "vendor" a few times and I'm not sure what the
meaning/use is in this setup, but it looks like you're talking about
duplicating it.  Its MIT licensed so using it would not be a problem from a
source code stand point.

Another way to look at this is to bring the project into Apache.  We
recently did that with Gossip and it worked well (though we did eventually
get the author to sign an SGA).  If we don't get an SGA, I would recommend:

- Not relicensing existing code, and avoiding changing existing code
wherever possible.
- Introducing new code as ASF based
- Making sure the LICENSE file correctly calls this out.

I would recommend against reusing the name goose.  While the source is
allowable, its not a transfer of the name.

John

On Mon, May 15, 2017 at 7:20 AM Eric Friedrich (efriedri) <
efriedri@cisco.com> wrote:

> Hi All-
>    The Traffic Control podling would like to use some third party open
> source code to help us manage some databases in our project (
> https://bitbucket.org/liamstask/goose/). This tool and its dependencies
> all fall into the Category A bucket (AL, MIT, BSD)
>
> Unfortunately, this tool appears to no longer be maintained and there is
> concern that the source may disappear at some point. Also, many of our
> users would like to build and install without requiring Internet access to
> retrieve and compile the goose tool.
>
> We have considered vendoring (duplicating) goose source in our code, but
> it is 375k lines of code and would require constant updating if the tool or
> its dependencies change.
>
>
> From a licensing and Apache release standpoint, is the following allowed:
> - Do not vendor goose source in the traffic control repo
> - In our source release artifact, include the source code for goose and
> all of its dependencies (and appropriate modifications to LICENSE/NOTICE).
> It will be dynamically downloaded from bitbucket at release time.
> - Build/Install process would build from this version of goose instead of
> retrieving from Internet
> - If we choose to produce convenience binaries, include the goose binary
> in the convenience package
> - If goose’s bitbucket repo is ever deleted, we can then import code from
> a previous release tarball into our repo for preservation.
>
> How have others in the incubator solved similar problems?
>
> Thanks,
> Eric
>

Re: Traffic Control Podling Bundled Dependencies

["Eric Friedrich (efriedri)" <ef...@cisco.com>]

Thanks John.
 
By vendoring I did indeed mean duplicating code for the purpose of guaranteeing availably and locking the particular revision in use. 

I’ll clarify and check in with legal-discuss

—Eric

> On May 16, 2017, at 3:56 PM, John D. Ament <jo...@apache.org> wrote:
> 
> Eric,
> 
> Some thoughts, and I'll be honest this is a better discussion for
> legal-discuss over general@incubator.
> 
> Generally speaking the ASF is cautious about hostile forks.  However, it
> looks like the author is comfortable with forks of the project for this
> notion (https://bitbucket.org/liamstask/goose/issues/58/is-this-project-dead).
> The email you've sent uses "vendor" a few times and I'm not sure what the
> meaning/use is in this setup, but it looks like you're talking about
> duplicating it.  Its MIT licensed so using it would not be a problem from a
> source code stand point.
> 
> Another way to look at this is to bring the project into Apache.  We
> recently did that with Gossip and it worked well (though we did eventually
> get the author to sign an SGA).  If we don't get an SGA, I would recommend:
> 
> - Not relicensing existing code, and avoiding changing existing code
> wherever possible.
> - Introducing new code as ASF based
> - Making sure the LICENSE file correctly calls this out.
> 
> I would recommend against reusing the name goose.  While the source is
> allowable, its not a transfer of the name.
> 
> John
> 
> On Mon, May 15, 2017 at 7:20 AM Eric Friedrich (efriedri) <
> efriedri@cisco.com> wrote:
> 
>> Hi All-
>>   The Traffic Control podling would like to use some third party open
>> source code to help us manage some databases in our project (
>> https://bitbucket.org/liamstask/goose/). This tool and its dependencies
>> all fall into the Category A bucket (AL, MIT, BSD)
>> 
>> Unfortunately, this tool appears to no longer be maintained and there is
>> concern that the source may disappear at some point. Also, many of our
>> users would like to build and install without requiring Internet access to
>> retrieve and compile the goose tool.
>> 
>> We have considered vendoring (duplicating) goose source in our code, but
>> it is 375k lines of code and would require constant updating if the tool or
>> its dependencies change.
>> 
>> 
>> From a licensing and Apache release standpoint, is the following allowed:
>> - Do not vendor goose source in the traffic control repo
>> - In our source release artifact, include the source code for goose and
>> all of its dependencies (and appropriate modifications to LICENSE/NOTICE).
>> It will be dynamically downloaded from bitbucket at release time.
>> - Build/Install process would build from this version of goose instead of
>> retrieving from Internet
>> - If we choose to produce convenience binaries, include the goose binary
>> in the convenience package
>> - If goose’s bitbucket repo is ever deleted, we can then import code from
>> a previous release tarball into our repo for preservation.
>> 
>> How have others in the incubator solved similar problems?
>> 
>> Thanks,
>> Eric
>>