As a general point I would strongly suggest always including a license file in any and all source code. This is because there are a number of scenarios where even a private repository might be exposed. These include:
- Legal Requirements including future legislation
- The country where the repository is hosted getting invaded or taken over by a group with a very different view on "privacy"
- Changes in practices or the terms and conditions of company hosting the repository
- Accidental or deliberate failure of the security/privacy settings
- A computer with a checkout going for repair or being disposed of without being scrubbed first.
The license file should be a plain text file in the top level directory and called either
COPYING so that people know where to find it. It should contain an indication of your current position on the use/re-use of the code and can be:
- A Open Source License, e.g. MIT or CC
- A Commercial License
- A copyright statement & a "hands of this is mine & I don't want anybody to use it but don't blame me if you do and it all goes horribly wrong" statement.
Personally I recommend starting new projects with cookiecutter which will prompt you for which license to use as well as many other details that are often forgotten then ensure that all of the necessary files are created.
If your code relies on any Open Source components then one of the standard standard practices is to state so & which ones and to reference where to find the license files for those components. Some Open Source licenses request or require that you include their license file even in binary redistributions.
Generally On Redistribution
Note that "redistribution" is giving or passing the code, (even as linked binaries), to someone else - so if your code is being ever going to be used by someone other than yourself, or outside of your organisation if you are a company, then you are redistributing it! In the case of a company changes in ownership of the company may even trigger the redistribution clause, e.g. if a part of the company that uses some internally developed code dependent on Open Source components is sold to another company this can count as redistribution of that code. Likewise, if a business consists of several separate legal entities sharing your code between divisions may be considered redistribution (pointed out by @nekomatic in comments).
It is generally considered polite to acknowledge the contributions made by the Open Source community by mentioning the presence of their code within your package. It might also reduce the damage to your reputation & possibly pocket if it turns out that one or more of the Open Source components has bugs, errors or vulnerabilities.
Some of the standard places to include the licenses of dependent code, (Open Source or otherwise), include:
- In the Release Note, (possibly as an Appendix).
- A component licenses directory or zip file suitably named.
Of course specifically with python & some other languages the components or dependencies will normally contain license for that item as one or more of:
- The package metadata License entry.
COPYING file inside of the wheel file, (you can see this by various mechanisms).
- The same files inside of a zip or tar.gz file for source distributions.
Also you will most usually not be actually shipping the dependencies unless you are using a bundler such as
cxFreeze but rather will be referencing them for installation in one or more of:
So it can be argued that you are automatically including these licenses, (it is still nice to give acknowledgements of course).
However, it is important to remember that the licenses of these components may change between versions, (normally only on major version changes, e.g. 2.x.y to 3.0.0), so it is generally good practice to pin the version of the requirements to at least the current version number major component, this also guards against possible breaking changes of course.
Disclaimer: I am not a lawyer nor any kind of legal, or copywrite, practitioner in any country or jurisdiction let alone the OPs or the readers - I am attempting to reflect what my personal experience & opinion at this point in time suggests to be good practice. Accordingly I could be completely wrong in any given framework or time. So non mea culpa & caveat lector!