11

Can LICENSE file be removed from 3rd party BSD project that is merged with GPLed code? There are license headers in each file, but files will be modified, so BSD license in them will no longer be valid.

  • 5
    files will be modified, so BSD license in them will no longer be valid -- That's not how intellectual property works. If you modify the files they are still considered to be copyrighted by the original owners AS WELL AS YOU. If the original owners have not given permission for you to remove the license then you cannot remove them. If you keep modifying until there are ZERO traces of the original code the license would still be there. That's why you need clean-room implementations to avoid infringing copyright. Even for open-source copyright – slebetman Sep 5 '16 at 6:59
  • 3
    If the BSD license is no longer valid, how would you have the right to distribute the copyrighted expression in them that you didn't author yourself? The original authors only offered them under a BSD license. – David Schwartz Sep 5 '16 at 8:55
  • 2
    @DavidSchwartz I mean that it is no more BSD terms, because they contain GPL modifications. so these files are under combined BSD+GPL terms, and following mentioned BSD terms alone won't be sufficient. – anatoly techtonik Sep 5 '16 at 9:46
  • 1
    @anatolytechtonik Any protectable elements in those files that were originally licensed under the BSD license still are licensed under the BSD license. Any protectable elements added by authors who only licensed them under the GPL are licensed only under the GPL. The files aren't under any single license because they contain elements issued under different licenses and each element remains under its original license. Nothing is relicensed. Nothing changes licenses. – David Schwartz Sep 6 '16 at 0:37
  • 1
    @DavidSchwartz, yes but the question is about LICENSE file at the root of original project. – anatoly techtonik Sep 6 '16 at 0:50
18

The short answer is no. You cannot remove a BSD license notice, otherwise you are no longer licensed per the BSD (many variants) that all share the essential requirement to retain the copyright and license/notice texts in source and/or binaries.

If you look at a BSD variant text from wikipedia:

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.

When you combine BSD-licensed code with GPL-licensed code, you could possibly assert a GPL license for your modifications, but you cannot remove the LICENSE. And when you use BSD-licensed code in conjunction with GPL-licensed code, the source code redistribution requirements of the GPL would apply. But you could also still use the BSD-licensed code alone without the copyleft requirements.

I personally prefer to keep things clean and keep the BSD parts under BSD and the GPL parts under GPL.

You also asked:

The license notice still stays in every file, so the copyright with conditions is retained, but the main license for the project is now GPL, so the LICENSE file was removed. [...] I will need a separate answer how to properly merge those LICENSE files.

There are many ways you could consider to provide a efficient notification to my users. Some of these include:

  • You could create a top level LICENSE or COPYING file that would explain at a high level the various licenses in use, and keep separate files for each licenses, either in a top level dir or a doc or licenses dir, and point to these in my top level file.
  • You could merge it all in one big file (which could become somewhat hard to read and grok)
  • You could use a more structured approach like in Debian copyright files, or my own https://github.com/nexB/attributecode tool using a structured yaml or yaml-like description of the various licenses used.

Update

Following onto the question of "merging" (came here via this question ): In general, if the Copyright and license text is in every individual source file, can these be deleted and then merged into a single, separate LICENSE.txt file? Here's an example. It seems even disingenuous/misleading to leave a "Copyright Google" header from demo code on my customized (and perhaps poorly coded!) project, started from their tutorial.

Well if this customized code is derived from copyrighted code, whether you feel it is "disingenuous/misleading to leave a Copyright Google header" does not matter. This is this the right thing to do, period.

  • The license notice still stays in every file, so the copyright with conditions is retained, but the main license for the project is now GPL, so the LICENSE file was removed. – anatoly techtonik Sep 5 '16 at 9:58
  • 1
    @anatolytechtonik You can handle this anyway you want, but there is no reason to remove the LICENSE file especially for a binary distribution. I would move it to a docs or licenses directory for clarity though – Philippe Ombredanne Sep 5 '16 at 10:03
  • 1
    Thanks. I will need a separate answer how to properly merge those LICENSE files. – anatoly techtonik Sep 5 '16 at 12:00
  • Following onto the question of "merging" (came here via this question ): In general, if the Copyright and license text is in every individual source file, can these be deleted and then merged into a single, separate LICENSE.txt file? Here's an example. It seems even disingenuous/misleading to leave a "Copyright Google" header from demo code on my customized (and perhaps poorly coded!) project, started from their tutorial. – michael Dec 3 '17 at 6:21
6

According to Richard Stallman's page on combining licenses, "In a combination of programs under lax licenses, each part carries the license it came with. When the code is merged to the point that the parts can't be distinguished any more, that merged code should carry all the licenses of the merged parts. Since all the licenses are lax anyway, this causes no practical problem except that the list of licenses gets long."

One example of how the code might be "merged to the point that the parts can't be distinguished" is the making of an executable. So for instance, we cannot redistribute a GPL-ed program, supplying the users with the source code to the GPL-ed parts and give them only .o object files for the BSD parts.

Essentially, when it comes to the mingled form of the work, all the licenses applies, and the most restrictive one "wins". Meaning: in a compiled program with a mixture of BSD and GPL modules, the whole thing falls under the GPL.

However, users can still pick the BSD parts out of the source code, including any modifications unique to that program, and use them in accordance with just the BSD license that occurs in their respective comment headers.

(However, actually, in an executable, we can distinguish machine code that clearly originates from a BSD-licensed module, such the image of a specific function; it's almost certain lifting out that piece of machine code and using it in any way permitted by the BSD license doesn't infringe on the GPL-ed program. If a BSD-licensed inline function is integrated with GPL-ed code, then of course that is not true.)

Stallman also defines license compatibility, which is required in the first place if we want to create a combined work with differently licensed pieces: "In general we say that several licenses are compatible if there is a way to merge code under those various licenses while complying with all of them. The result, often, is a program with parts under various different compatible licenses—but not always.".

The original BSD license (with the "obnoxious advertizing clause") wasn't GPL compatible. Stallman "mostly eliminated this problem by convincing a dean, Hal Varian, to arrange for UC Berkeley to publish the “modified BSD license” (without the advertising clause) and rerelease the code of the Berkeley System Distribution under that", thus giving rise to the new BSD license without the clause, which is why now you can easily use BSD-licensed pieces in your GPL-ed code. Stallman cautions us not to actually talk this way about the BSD license; that is to say, to speak of the BSD license as if there were one. In this Q&A, it's clear we are referring to one of the new ones without the troublesome clause.

5

Only adding on Philippe's answer here: you could for instance edit the LICENSE file to add your own copyright and license notice on top and specify that the following copyright and BSD license notice only applies to the original code from ... which can be found unchanged at ...

But in no circumstance you can remove the original notice: the license text states very clearly that you must keep it.

2

You cannot remove the BSD license because the BSD license prohibits it. You can, however, add your own license to the file that covers your contributions. You can also add a notice that your contributions are not offered under the BSD license.

Anyone who wishes to distribute your file must comply with the BSD license with respect to those elements licensed under that license. And they must comply with your license with respect to those elements you added. You must also comply with the BSD license to continue to distribute the file.

Note that everyone who lawfully possesses a copy of your file will receive a BSD license for every protectable element placed under that license directly from the original authors of those elements. You cannot change this. So the BSD license will still be valid, it just will not extend to any protectable elements that you added. (Were this not so, you could not distribute the file to them!)

You can, of course, offer them whatever license you like for those protectable elements that you added to the files. You can also use a shrink-wrap agreement, clickthrough, or EULA to impose whatever additional terms courts are willing to enforce.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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