Traffic Control Podling Bundled Dependencies

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

Hello Apache Legal-

  The Traffic Control incubator 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 duplicating (copying) 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 approach allowed:
- Do not commit a copy of the goose source into 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). This source will be dynamically downloaded from bitbucket/github at release time.
- Our Build/Install process will build from this version of goose instead of retrieving it from Internet
- If we choose to produce convenience binaries, we will 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.

Our goal is not to fork the goose project (although the owner has given permission to do so[1]). Rather we want to ensure the availability of that source code so that our release package is always usable in the future.
We are also proposing the above behavior for goose and all of its dependencies, some of which are still actively developed.

Thanks,
Eric

[1]https://bitbucket.org/liamstask/goose/issues/58/is-this-project-dead

Re: Traffic Control Podling Bundled Dependencies

[Chris Mattmann <ma...@apache.org>]

Hi,

 

I believe this is entirely fine from a legal perspective due to the reasons you state below. The fact
that the code is all Cat A, you have permission to fork the code (so the community aspects aren’t
being stepped upon), and that you have thought through dynamic inclusion in source (and not 
polluting your repos), and that you have considered a way to avoid internet connections while 
making sure to update the appropriate LICENSE(s) and NOTICE.txt information tells me that this
has been well thought through and will work fine.

 

One thing I ask – can you please file a Legal JIRA [1], and I will comment similarly and resolve the 
issue there? Please copy through this information on that ticket.

 

That way we have a clean archive/record of the decision.

 

Thank you.


Cheers,

Chris Mattmann (new Legal VP)

 

[1] http://issues.apache.org/jira/browse/LEGAL

 

 

 

 

From: "Eric Friedrich (efriedri)" <ef...@cisco.com>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, May 16, 2017 at 5:57 PM
To: "legal-discuss@apache.org" <le...@apache.org>
Subject: Traffic Control Podling Bundled Dependencies

 

Hello Apache Legal- 

 

  The Traffic Control incubator 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 duplicating (copying) 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 approach allowed:
- Do not commit a copy of the goose source into 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). This source will be dynamically downloaded from bitbucket/github at release time.
- Our Build/Install process will build from this version of goose instead of retrieving it from Internet
- If we choose to produce convenience binaries, we will 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.

Our goal is not to fork the goose project (although the owner has given permission to do so[1]). Rather we want to ensure the availability of that source code so that our release package is always usable in the future. 

We are also proposing the above behavior for goose and all of its dependencies, some of which are still actively developed. 

Thanks,
Eric

 

[1]https://bitbucket.org/liamstask/goose/issues/58/is-this-project-dead