Are there accepted alternatives to having boilerplate (e.g. copyright, OSS, xport ctrl, classification) in the sourcecode itself?

Question

An increasing amount of effort is being put in keeping company code "boilerplate" header up-to-date according to classifications and templates from an external application, leading to "source code changes" and retesting because of updating tens-of-thousands of files' copyright. And now and then the license template changes.

It is costly and demotivating because company life cycle management tools also carrying the information, making it redundant. But are there any widely accepted alternatives?

If the source code is in a repo (e.g. git/mercurial), could the repo itself carry the boilerplate? Can boilerplate be appended to code at checkout: cat copyright.txt license.txt source.code?

Are there filesystems that allow files to carry this information? Source code and/or binaries?

Other solutions?

Answer 1

From the perspective of a developer, those header comments are 100% pure junk. Every time I open a file, I have to scroll past all of that nonsense to get to the actual code. So yes, there is a widely accepted alternative: don't put header comments in source files.

Of course, life isn't that simple: it's not just developers that get to decide these things. Your company may mandate them for commercial or legal reasons. So then it becomes a case of you having a conversation with those other parties over how to reach a compromise between minimising the junk, versus meeting those commercial and legal needs. The obvious choices are:

1. Put all of this information in a single LICENCE file in the root directory of your project and have no header comments in the individual source files. This is a commonly used approach for many projects on GitHub for example. If you can adopt this approach, it's by far the best alternative. It keeps your source files clean and means only one file need change when the rules change.
2. Put all of the common information in a single file and then put a reference to that one file in all of your header comments. This doesn't completely remove the need for headers, but it keeps them small and avoids the need to modify the source files when the licence details change.
3. Use scripts to strip the headers out of the source files on checkout and eg use git hooks to reinsert them on check in. This is a risky strategy as it relies on everyone having the same scripts and reliably running them, and on the scripts correctly identifying the header when removing them. Also it doesn't address the need to change source files when the contents of the headers change. But if neither of the previous two options are viable in your case, this may be the only option available to you.