8

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 (...)
 *
 */
4
  • How do (plan to) use version control software? If you plan two repositories anyway having a single licence in each seems the easiest.
    – ph0t0nix
    Jan 11, 2016 at 23:54
  • @ph0t0nix good question! I guess I will need one 'private' repository which includes the source code and internal files, and a public one (maybe on Github) which mirrors only the source and documentation files. I am new to Git so this is a technical question which I will ask on a different stackexchange site
    – mjn
    Jan 12, 2016 at 6:45
  • 1
    nice update. I think adding the lines about the option of a commercial licence are a good addition. Clearly stating the closed option is another way to bring 'the alternative' to people's attention.
    – ph0t0nix
    Jan 12, 2016 at 10:05
  • GPL and AGPL are viral in nature and will cause you headaches because you can't move any changes in the AGPL version to the proprietary version. If you are going to dual license, it is best if you choose a non-viral license or even create your own. Jun 18, 2022 at 12:16

2 Answers 2

4

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.

1
  • Very helpful links, much appreciated! Licensing of code contributions is a very important aspect in this field.
    – mjn
    Jan 12, 2016 at 10:55
1

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>
 */
1
  • Space is cheap. But duplicating source files introduces an opportunity for bugs to enter the system and, as a result, has the potential to diminish the value of the software.
    – vhs
    May 29, 2017 at 5:51

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.