License header for dual-licensed (AGPL or "non-free") source code

Question

For one of my products I plan to move from a commercial-only to a dual licensed license model: GNU Affero General Public License (AGPL) or a "non-free" license.

I can imagine two options for the license headers in the source files:

• two sets of source code files with different headers: the AGPL header for the open source version and a different header for the non-free version

• only one set of source code files, with both license blocks in the header

Advantage of option #1: the actual license type is clearly and immediately visible in the source file. With the second option, end users (developers) and their managers or clients could be confused, because they are not able to see what license type they are actually using in their project.

Advantage of option #2: having only one version of the source with a dual-license header block might have advantages (for example if a patch is released, it can be applied to both versions as the code is 100% identical). If I choose this method, the actual licensing type could also be made clear to the end user by including a license.txt file in the non-free release which contains license type and license holder data.

Should I go for the first or the second option? Or is there even a de-facto standard way for source code headers in case of dual licensing models?

---

Update: this is an example license header which I found in a source code file of the dual-licensed iText library. It contains the AGPL notice, followed the information about the commercial license.

/*
 * This file is part of the iText (R) project.
 * Copyright (c) 1998-2014 iText Group NV
 * Authors: Bruno Lowagie, et al.
 *
 * This program is free software (...)
 * You should have received a copy of the GNU Affero General Public License
 * along with this program (...)
 *
 * You can be released from the requirements of the license by purchasing
 * a commercial license. Buying such a license is mandatory as soon as you
 * develop commercial activities involving the iText software without
 * disclosing the source code of your own applications (...)
 *
 */

Answer 1

As I mentioned in the comments, I think it is a good idea to mention the possibility for a closed licence in the open code.

Whichever option you choose, in any case I wouldn't mention the type/name/exact text of the commercial licence explicitly in the open code. This will give you the option to use multiple closed licences (maybe for different clients). This, of course, assumes you own the copyright to the full code, otherwise you would need to confer with each copyright holder whenever you want to change the licences.

Something else to keep in mind is what you want to do with code contributed to the open source version. Should contributors sign a copyright transfer agreement, or do they retain the copyright on their code? This affects whether or not (and how) you can include those contributions into your closed code. I have been following the Bacula project (a set of backup tools) for several years and they have a page about this that maybe helpful.

Answer 2

It would seem to me to be sensible to have one set of source files, with a double header.

Duplicating the source files just so that you can have one set with one license and one with the other seems to me to be an unnecessary waste of space (both disk and amount-of-text space). It's far more conservative -and, I'd argue, therefore far clearer - to have one set with details of both licenses in the header.

You can always use some nice text formatting to make it clear which part is which.

/**
 * Copyright (c) 2016, the iText project. All rights reserved.
 *
 * This project is dual licensed under X and Y.
 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 * <insert license X text or header here>
 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 * <insert license Y text or header here>
 */