incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Friedrich (efriedri)" <efrie...@cisco.com>
Subject Re: Traffic Control Podling Bundled Dependencies
Date Wed, 17 May 2017 00:46:24 GMT
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 <johndament@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
>> 

Mime
View raw message