This page gives some information about contributing packages to TeX Live (TL), and ways to make integrating your package easier for the TL maintainers.
First, the package must be free (as in freedom) software, available under, for example, the LaTeX Project Public License or GNU General Public License. Please state this explicitly in your package's README and/or other documentation, as well as (ideally) in the source. Those licenses (and others) contain instructions for how to apply them to your code. The licensing conditions for TeX Live go into more detail.
Next, virtually all TL packages come from CTAN. This is by far the easiest place to update from. So, if you haven't uploaded your package to CTAN, please do that. (Aside from TL, it's a good thing in general for CTAN to hold as much as possible.)
Standard LaTeX packages with a .ins file, .dtx, README, etc., don't need any special treatment; they can just have all the files at the top level. The TL scripts (TL developers: these are in Build/cdbuild in the repository) will automatically translate the CTAN package into the TDS arrangement used in TL.
Many packages are more complex. If your package has many files in many different places, it is easiest for TL if you distribute it as subdirectories of a texmf/ tree, with your files in the TDS places. Then all the scripts have to do is copy your tree.
As a rule of thumb for LaTeX packages, only .dtx and .ins files go in source/; by default, auxiliary files go in doc/. For packages that include fonts, please include .tfm files and .map files.
Feel free to browse the TL sources to see how other packages are installed. The package TPM files give manifests, which is another way to see what goes where.
However, large complex distributions are simpler to install if they can simply be copied into TeX live without changes. That is, what is uploaded to CTAN is already in the TDS layout. See, for example, the lm and vntex packages.
If your package includes source files that actually have to be compiled into binary executables, such as C or C++, it is by far best to use the GNU configuration standards, typically via Autoconf or Automake. In particular, building in a directory other than the source directory (which is supported by default with the autotools), is our standard working method.
Also, if your program needs to search for files, use the Kpathsea library. Or, if your package is written in a script language such as Perl or Python and needs to search for files, you can use the kpsewhich executable.
Finally, please make any executables do something reasonable with the
options --help and --version. Again, see the
GNU standards.
If you have any questions or suggestions, please email tex-live@tug.org.