
Ask HN: When vendoring for an OSS project, how do you handle licenses? - nvader
This question seems almost too simplistic to ask, but I wanted to check with HN what the current best practice was.<p>The context: I&#x27;m considering vendoring a couple of dependencies, both under the MIT License, in a project I intend to also publish under the MIT License.<p>One of the requirements of the MIT License is that the original licenses must be preserved and accompany all copies. Is it sufficient if I preserve them within the src&#x2F;vendor&#x2F; folder? Or do I need to concatenate both their licenses to the LICENSE file in the root folder of my project?<p>I intend to deliver this project as a source download only, if that makes a difference.<p>Finally, how do people who vendor projects with different (and perhaps incompatible) licenses deal with it?
======
nvader
To add further information to my own question: it would appear that the
kubernetes project performs this a third way.

The top-level license file is their own Apache license, but their GODEPS
folder contains a file, LICENSES, that is very long, and built up by
concatenating all the licenses of their source projects.

[https://raw.githubusercontent.com/kubernetes/kubernetes/mast...](https://raw.githubusercontent.com/kubernetes/kubernetes/master/Godeps/LICENSES)

~~~
nvader
One last comment and I'll stop talking to myself[0]. But that LICENSES file is
so long, it just scrolls and scrolls!

[0] Not a promise.

------
pink_dinner
Just AAron Swartz it: don't follow the license at all and do what you want.

