2

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?

Improve this question
6
  • Whats the reason for putting the licence in the code? do you mean on every file or just one in the root dir?
    – Ewan
    Dec 10, 2018 at 10:39
  • 4
    It seems your question is primarily about your company's internal policies. Maybe those policies are necessary, maybe not. But we as outside bystanders don't have the necessary context to tell.
    – amon
    Dec 10, 2018 at 12:15
  • 1
    There is always the option of having a very small boiler plate that indicates the path to the longform information, that would centralise all of it?
    – TurtleKwitty
    Dec 10, 2018 at 15:38
  • @amon To a degree, yes, because interpretation is internal company policy. However the company is doing this because of international (primarily US) laws, and fear of being sued, sanctioned or even inprisoned. That fear is common for all companies.
    – Andreas
    Dec 11, 2018 at 9:41
  • 1
    @Andreas in that case any solution should be discussed with your company's legal counsel rather than randos on the internet who don't understand which precise legal requirements you are subject to. E.g. while I am somewhat familiar with international copyright (no, you don't need extensive copyright headers and disclaimers in each file) I am clueless when it comes to US export control.
    – amon
    Dec 12, 2018 at 13:13

1 Answer 1

Reset to default
4

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.
Improve this answer
1
  • Agreed. Voting answered for point 3 as xprt ctrl and classification cannot be centralized for the project. I also need some guard against losing the license along the way because of "accidents" - user error or ignorance. Git hooks should work if the hooks are implemented by a private proxy Git server, and the metadata carried by the lifecycle tool accessible by the server... Maybe I'm lazy, are there examples of wide-spread software using mentioned strategies? Hopefully at least one of above mentioned strategies are "to big to fail" - if MS/Google/IBM/etc does it, so can I.
    – Andreas
    Dec 11, 2018 at 10:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.