NML Says

Open Source Development 6 - The Rest

References for this Part

Brasseur, V. M. Forge Your Future with Open Source 1st ed., Pragmatic Bookshelf, 2018

(Brasseur, V. M., 2018, chapter 8-)

Model Solutions Previous Lessons

Nothing to declare.

Vicky’s Book Chapters 8 through the rest

Re Chapter 10, Sect How to Apply A License

The site of reference for most FOSS questions: https://opensource.org has, for example https://opensource.org/license/BSD-3-clause this text should be copied into, a be the whole of a file called LICENSE in the root of the project. Only line 1 of the following must be adapted to show the actual copyright holder:

Copyright 2025- Niels Müller Larsen

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The root of the project obviously also has the essential README.md in the root directory. We have talked about it several times. It should be written in markdown as the suffix suggests, and somewhere it should contain something similar to:

## LICENSE

Copyright (c) 2025-present Niels Müller Larsen

Released under the BSD-3 License.

What about your code, and other files? Vicky (Brasseur, V. M., 2018, chapter 10) has a serious memento, and a strict opinion about this, quoted from the mentioned chapter:

You have a license file, so you’re done, right? Your project is licensed and you can move on to other tasks? Unfortunately, no. Like I said previously, this process isn’t as simple as slapping that license file into the repo. The next step is adding the copyright notices.

At a bare minimum, the copyright notice contains the word “Copyright” fol- lowed by the name of the copyright holder, the year the work was copyrighted, and a very brief license statement. This notice must be added to every file in the repository.

Yes, really. Every file.

The repository is composed of multiple files, which means that there’s a chance those files can and will be separated. If that happens and the copyright notice isn’t added to each file, then there’s no way for a file’s recipient to tell either who to credit for the work or, by virtue of that brief license statement, whether they’re legally allowed to use your work at all. Therefore, yes, you must have a copyright statement in each and every file. The task can be tedious, but, well… We’re in technology. You can probably figure out how to script this rather than do it manually.

This statement should be placed at the top of every file and be encased in the comment characters for the appropriate language. Here’s an example:

/*
Copyright © <year> <name of holder>

Licensed under 3-Clause BSD.

Please see LICENSE for more information.
*/

Many people complain that a copyright notice takes up a lot of space at the top of the file or otherwise complicates their development workflow, but in all my experience, I’ve not seen a case of a properly formatted copyright notice causing anything beyond a mild inconvenience, and even that is a rare occurrence. If you find that you notice and dislike seeing the notice in the files, most editors and IDEs have functionality or plugins for “folding” this text so it’s both out of sight and out of mind.

Some licenses, such as Apache, recommend that rather than place your own name in the copyright notice, you instead use the text Copyright The Authors, 2018, and then list the project authors in a file named AUTHORS. This can be a very efficient way to handle having multiple people holding copyright over a single project file. This approach works even if you’re not using the Apache license, so you may wish to consider it, if you have multiple contributors to the project or expect you will have multiple contributors soon after releasing it.

Exercises

Exercises