2

I am working on a (GitHub) project that I want to open-source with BSD 3-clause license and I am using some code parts and files from Apache 2.0 licensed projects. So I have three questions:

  1. Is this possible? Is Apache 2.0 license allows the use in BSD 3-clause projects? (This looks like a basic question but somehow I couldn't find any answer for this.) If it is not possible should I just use the Apache 2.0 license?
  2. I have some files taken from an Apache 2.0 licensed project (not the whole project) and I modified those files. As far as I understand, I need to indicate my changes at the beginning of those files. So how should my boilerplate notices be? Is the following correct? Or should I put the Apache 2.0 notice to the top and add BSD's and my modifications?:
//BSD 3-clause boilerplate notice
//A summary of my modifications
//Apache 2.0 boilerplate notice of the original project
  1. I have a submodule inside my project which is an Apache 2.0 project that I forked and made some changes. Again, what should I do for this?

2 Answers 2

2

Both BSD-3-clause and Apache-2.0 are permissive Open Source licenses. They permit combining code under these licenses with other code, especially also with each other. Both licenses would continue to apply for their respective parts, so it would not be quite correct to state that your project would be BSD-3-clause licensed.

In practice, the license conditions from the Apache-2.0 subsume all BSD-3-clause conditions so that to comply with both licenses, recipients (not you) would have to mostly comply with the Apache-2.0 license, and only add a copy of the BSD-3-clause notice to Apache's NOTICE file.

You don't have to choose the Apache-2.0 license for your contributions, but it would maybe simplify license compliance a bit for other people.

When you modify Apache-2.0 covered code, “You must cause any modified files to carry prominent notices stating that You changed the files”, but you don't have to describe the changes. This might be as simple as adding a copyright line in the file header. But since you want to license your modifications under a different license, your idea of prepending the new license notice is entirely appropriate. Here is how I would write such a license header:

foo.c is part of ExampleProject
<https://example.com/myproject>

  Copyright 2022 How_To

  Redistribution and use in source and binary forms, ... (rest of BSD-3-clause)

This code is based on OriginalProject
<https://example.com/original>

  Copyright 2021 Original Authors

  Licensed under the Apache License, ... (rest of Apache-2.0 header)

In such headers, it is common to put the most recent notice on top.

When you are not modifying Apache-2.0 covered code but are merely distributing unmodified copies, then things are simpler. Different scenarios:

  • A Git submodule is not a copy but merely a link. I don't think that adding an Apache-2.0 covered submodule would trigger any license obligations.

  • If you include a copy of the Apache-2.0 covered code into your project (for example, if you create a tar archive of your source code including the submodule), then you must comply with the Apache-2.0 license. Which here, just means including a copy of the Apache-2.0 license and the NOTICE file, if present. The upstream project likely already has this, but check to make sure. If you have a LICENSE or README file, I would add a note to mention that the code in a particular folder is governed by a different license, and where to find it.

  • If you distribute non-source versions of the software (such as pre-compiled executables) then you must comply with the licenses of all included components. This usually means including license notices (and the NOTICE files, if present) alongside the software in a ZIP archive or similar. Other software might have a help menu entry to show the notices, or have a --version command line flag that explains where to find the full license. As a rule of thumb: wherever you give notice of your license + copyright, you should also mention the license + copyright of other components as well.

However, you do have forked/modified the project you're including as a submodule. Then you have to give notice of your changes in the forked/modified version. Instead of adding the BSD-3-clause notice header, you might instead add a copyright line with your name to the files that you touched. These modifications don't change anything when it comes to including the sub-project into your larger project.

So to summarize the answers to your questions.

  1. Can you include parts from Apache-2.0 software in your project? Yes, but then your code will not be BSD-3-clause only.

  2. How should you mark modified Apache-2.0 covered files? Your idea of adding your own license notice on top of the Apache-2.0 notice is on the right track.

  3. How can you handle licensing for a submodule that you forked from another project? With respect to the contents of the submodule, modifying an Apache-2.0 covered project is equivalent to including Apache-2.0 covered parts into your code: you have to give notice that you made modifications, but are otherwise free to decide. In practice, keeping the Apache-2.0 license for those parts would be easiest. When bundling or compiling your software together with the submodule it's pretty much the same story, but it would be good to ensure that recipients know which parts are governed by which license.

1

This is a bunch of questions which we need to look at in their parts.

i) the BSD-3 license is not the most recent version. You should consider the BSD-2 license. This will help with the re-use of your code, as in several projects this is the preferred BSD-style license.

ii) The Apache 2 license has restrictions, which are stricter than any BSD license. Therefore you cannot just copy code from an Apache 2 project and insert it into your BSD-licensed files. That would be a violation of the Apache license. Instead you could license your entire project under the Apache 2 license. You can, however, mix files under BSD-2 or BSD-3 licenses with other files under the Apache license in your project. This is messy and depreciated, but not forbidden.

iii) for the requirements w.r.t. the notice files there is a nice answer here

iv) For the sub-module which is forked from an Apache project, I suggest you keep everything in the Apache license. This is by far the most obvious and easiest path forward.

5
  • 1
    I disagree with point (i) – both BSD-3-clause and BSD-2-clause are perfectly fine. Both are Open Source. Neither hinders reuse. It is misleading to refer to either as a “more recent” version, they are just different but equally valid variants of the same license. This is not like with the GPL family of licenses where the license steward discovered problems with an old version and wrote an updated license.
    – amon
    Apr 8, 2022 at 17:02
  • @amon I am aware of software projects, which have a published policy preferring BSD-2 over BSD-3 licensed code, but I am not aware of any project which published the opposite preference. This advantage is clearly stated as the rationale in i) above. I would be interested to learn if you have any information about projects with a BSD-3 preference. Apr 9, 2022 at 7:52
  • 1
    Could you provide an example, other than the FreeBSD community? Such a preference would be quite surprising, considering that license surveys indicate BSD-3-clause is about 2× to 3× more popular than the 2-clause variant. Large projects like Apache or Fedora don't care.
    – amon
    Apr 9, 2022 at 9:43
  • For example the NTPsec project states "Our preferred license for new code contributions is BSD 2-clause." But my statement was not about license popularity, my statement was about code re-use, and there BSD-2 is more versatile, as it can be re-used in BSD-3 projects, but it is not possible the other way around. Apr 9, 2022 at 16:48
  • @Martin_in_AUT why would 3BSD content not be reusable in a 2BSD project? Neither licence is a copyleft one.
    – MadHatter
    Apr 10, 2022 at 14:32

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.