The LPPL: ‘maintainer’ or ‘author-maintained’

The LaTeX Project Public License (LPPL) was written to allow development of LaTeX code in a way that is free as in speech while also making sure that LaTeX users get what they expect when they

\usepackage{foo}

Frank Mittelbach wrote an excellent overview of how the LPPL was developed for TUGBoat last year, where he discussed the balance between the rights of the coder and the rights of the person using the code!

The LPPL is designed to deal with packages which are both ‘maintained’ and ‘unmaintained’, and provides a way to allow new maintainers to take over unmaintained material. It also allows for packages to be ‘author-maintained’, which sounds similar to just ‘maintained’ but is significantly different.

Packages which are either ‘maintained’  or  ‘author-maintained’ have one or more people looking after it, and they are responsible for making changes to the code. The difference comes if those people disappear (as has happened recently with biblatex). With a ‘maintained’ package, it’s possible for a new person or team to make a public statement that they are going to take over, then after a delay they become the new maintainers. On the other hand, a package which is ‘author-maintained’ cannot be taken over by someone else.

Now, the LPPL is a ‘free’ license and so it is always possible to create a fork from an existing package. In general, you don’t really want to do that simply to keep updating an existing package: taking over maintenance is much clearer all round. For biblatex, we can’t do that as it’s ‘author-maintained’. So we’re going to have to formally fork the project, mark the ‘new’ version as distinct from the old (Philipp Lehman) version and ensure that both remain on CTAN: not ideal.

So I’d urge people to mark their LPPL code as ‘maintained’  rather than  ‘author-maintained’.  You never know what might happen, and ‘maintained’ status works pretty well.