Word of Caution: A Copyright Notice is not a License

[Mario F.]

While the title of this post isn't exactly accurate (because copyright notices should link to the licenses they are founded on), it serves as a way to illustrate a (possibly common?) situation a friend of mine back in Portugal got himself into regarding the GPL.

It's a short story and a cautionary note to anyone still struggling with which GPL they should choose and how to properly apply this license.

To everyone else this won't be a surprise.

---

Ricardo is an electronics guru and a competent programmer. His project involves a small IO hand-device capable capable of communicating with the smart house system he installed at his home. He built the electronics and then programmed it. He incorporated the GPLv2 in his software for the first time. He's been mostly a MIT and Apache enforcer.

This was his copyright notice at the top of every source file, taken verbatim from the downloadable license. The relevant section to this discussion is in bold.

This program is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public Licenseas published by the FreeSoftware Foundation;
either version 2 of the License, or (at your option) any later version.

What happened with his copyright notice is that someone went on to fork his project and apply GPLv3 which puts some limitations on Tivoization which he certainly didn't intend to.

When we were discussing this issue over the telephone, at first I wasn't sure what the problem was. I was telling him that he explicitly allowed users to apply a later version of the GPL. It was his fault that this happened. If he didn't like it he could have always changed the copyright notice.

He kept on using the word "license", while I kept on using the words "copyright notice". It was only after a bit of this interchange that it finally dawned on me what had been the problem all this time.

Ricardo didn't know the difference between a license and a copyright notice. So when he read the following section right at the top of the GPLv2 license, he mistakenly took it to mean the whole of the text that follows on that page.

The GNU General Public License (GPL-2.0)

Version 2, June 1991

Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

He happily ignored the very large letters at the bottom of the page saying "END OF TERMS AND CONDITIONS" and took the remaining text as being also a part of the licensing mechanism.

He did remove the section "How to Apply These Terms to Your New Programs" from the license file and correctly included the copyright notice in each source file as advised. But he didn't change it, thinking in his head that this too was not allowed to be changed.

Well, it is. Very much so. That text in fact is just included as an aid. Some projects in fact make a point of removing the "or (at your option) any later version" excerpt from the copyright notice. The Linux Kernel is an example of just that, as you may learn if you read that Tivoization entry at wikipedia I linked above.

So, moral of the story:

1. Do not confuse copyright notices with the license text. If you are working with these canned licenses, know that the copyright notice text on all and every one of them is yours to make or change as you see fit.

2. If you are incorporating a license, for pete's sake READ the license! It's your license after all! Section 9 of the GPLv2 mentions this issue specifically and would have taught Ricardo what he only learned by error much later.

3. GPL (and its LPGPL laddie) is a license mechanism deeply tied to a doctrinal approach to software. Later versions of these licenses may remove barriers or create new barriers depending on to which side of the bed the GNU foundation woke up that day. If you asked me, when using the GPL, always remove that section of the text from your copyright notice.

[Yarin]

That's why I don't release anything under the GPL. For personal projects, a BSD or MIT like license is best.

[laserlight]

1. Do not confuse copyright notices with the license text. If you are working with these canned licenses, know that the copyright notice text on all and every one of them is yours to make or change as you see fit.

I believe that the copyright notice example in your post would be:
Copyright (C) 1989, 1991 Free Software Foundation, Inc.

Though it may be a little iffy since "Copyright (C)" might not be accepted in some jurisdictions, but on the other hand a copyright notice is not necessary in many jurisdictions to claim copyright.

What you are concerned with in this post is more of a notice informing the user of the license, where the license text is elsewhere. I think that in this case, this notice is itself an amendment to the license, i.e., it amends the GPLv2 by permitting the licensee to use a later version of the GPL. So, it is not so much that the "copyright notice text on all and every one of them is yours to make or change as you see fit", but rather one can choose to license one's software as one deems fit, within the law, hence one can license it under the GPLv2 only, or the GPLv2 or a later version of the licensee's choosing, and hence notify the licensee accordingly.

EDIT:
I'd say that this is also a license:

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

A "meta-license", if you will, in that it is a license from the Free Software Foundation, Inc. permitting the licensor and others to use the GPL text, with the proviso that the GPL text remains unchanged. Consequently, the licensor may amend the GPL separately as it is, after all, his/her copyright and hence his/her license (but once such an amendment is made, clearly the result cannot be called the GPL... but since the amendment permits the licensee to choose between the stated and future versions of the GPL, stating that the software is licensed under the "GPL", or "GPLv2 or later", would not be wrong).

Disclaimer: I am not a lawyer; this is not legal advice.

[Nominal Animal]

I prefer to license code under GPLv3. When I do so, I have the following copyright notice,

/*  ThisFile - ThisPart for ThisProject
 *  Copyright (C) 2013 My Name <my-email-address>
 *
 *  This program is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License version 3,
 *  as published by the Free Software Foundation.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/

near the beginning of each (copyrightable) source file, with LICENSE at the root of the project.

Because I do not believe interface descriptions are or should be copyrightable, I do not add the copyright notice to header files. If I remember, I'll also from now on add a note about this in the README file, also located at the root of the project.

I prefer the GPLv3 over GPLv2 exactly because of the additions related to patents and Tivoization, and over BSD and similar licenses because I much prefer fairness and reciprocation over freedom.

However, picking the license that suits the project best always depends on the project. It is a decision your mind and not your heart should make.

Although I don't think many of the examples I've provided here and elsewhere are copyrightable (because they are obvious or noncreative), I do assume and if asked, confirm they are either in public domain, or licensed under CC0 (as not all copyright jurisdictions have a concept of public domain, or allow releasing copyrights into public domain).

Library code is often best licensed under the BSD license for maximum use, but it does carry a risk. Someone with better social skills or just better funded, can fork your project, close it (make it proprietary), and use their skills or funding to convince the largest downstream users of the library to switch to the new fork. After adding extensions or otherwise making the fork incompatible with the original, it will be extremely hard for any downstream users to switch back to the original. This means that even if the code in the original project will still be free, the project will be dead as a doornail, and usually completely unable to compete on the merits. Embrace and Extend.

[laserlight]

Because I do not believe interface descriptions are or should be copyrightable, I do not add the copyright notice to header files.

However, that in itself does not mean that the content of those header files are not under copyright. I think the approach of declaring that content to be in the public domain, or licensing it under a very permissive license should such a declaration be invalid, would be suitable.

[phantomotap]

I am not a layer, and I do not offer legal advice.

Because I do not believe interface descriptions are or should be copyrightable, I do not add the copyright notice to header files.

O_o

You should really contact a lawyer specializing in Copyright/Author's Rights/Similar before you continue along that path. The act of creation alone places materials under Copyright/Author's Rights/Similar in many places regardless of your opinions. Your statement of belief is meaningless, again in many places, with respect to actual law. A declaration of intent to place a work under Public Domain/Similar isn't legal, again in many places, leaving the work solely under your Copyright/Author's Rights/Similar with no communicable means of license.

I wish a statement of such intent or opinion was sufficient, but you are better served making your intentions legally binding.

I am sure it would be a shame for someone to be unable to use your work because your desire for the code doesn't mesh with the law.

Soma

[Nominal Animal]

However, that in itself does not mean that the content of those header files are not under copyright. I think the approach of declaring that content to be in the public domain, or licensing it under a very permissive license should such a declaration be invalid, would be suitable.

A good point, and I agree.

For myself, it's more complicated. I want to rely on headers/interfaces being uncopyrightable. This goes back to me valuing fairness and reciprocality much more than freedom. Still, some kind of declaration near the beginning of each file is warranted.

[Mario F.]

Another thing to keep in mind is that the GPL is very circumspect on the matter of libraries. You may want to check if it allows you to declare a more permissive license for header files. Particularly if you consider that header files are merged into the source file at compile time.

The following is not legal advice...

Also keep in mind that header files, because they usually define the interface portion of the system (btw, you don't ever write inline functions or private members of a class?), they are an important part of the patent mechanism. Because they define What a system does, I believe they are highly susceptible to patent claims. Since you adopted GPLv3 also for the increase protection against patent claims, you may reconsider your approach of giving a more permissive license to header files.

[Nominal Animal]

If you are using GPL for a project, and are the copyright owner, of course you can specify a more permissive license for some of the files if you want. It is then up to the downstream developers which license they rely on for redistribution/derivatives; they just need to pick one. Like I said, this is extremely common in the Linux kernel.

The abstraction-filtration-comparison test is a commonly accepted method of comparing similarity in a copyrighted work. Ideas are not protectable, only expressions are; and expressions only if there is anything left after the abstraction and filtration steps.

If a header file describes only the interfaces, and those interfaces are dictated by interoperability with an existing implementation, the file contains nothing copyrightable (according to the current rules that certain multinational companies are now trying to change via courts). Even if "merged" with something else, that part still contains nothing copyrightable, so no copyright notice or a license is needed.

If you put protectable stuff like nontrivial code, inline functions or function-like macros in your header files, then it is no longer just an interface description, and you should consider licensing the header file using a more permissive license.

[Header files] define What a system does, I believe they are highly susceptible to patent claims.

Header files only define what a system can do, not how it does it. I find it difficult to see how you could construct a valid patent claim that only specifies the task and not how it is accomplished.

[c99tutorial]

I want to rely on headers/interfaces being uncopyrightable. This goes back to me valuing fairness and reciprocality much more than freedom. Still, some kind of declaration near the beginning of each file is warranted.

In that case, why not make your intentions clear to the reader? E.g. do I have to release my source code if I incoporate the library into my program (GPL) or do I just need to release the source of the library if I modified it (LGPL). Do I have to add a function or menu item to my program that informs people about the license (GPL) or not, etc etc.

That said, I personally think it's a little silly when I read somewhere that to be informed of the license terms you must visit the GNU web site. Think about it. Imagine signing a rental contract where it said "By signing this contract you agree to be bound by the terms found on our Web site www.foobar.com". Is including a LICENSE file with your software that clearly states the full terms really too much? GNU has certainly been writing licenses for a while but there's no reason to assume that this will be true for the life of your published software.

[Mario F.]

Header files only define what a system can do, not how it does it.

Again, I'll ask. You don't ever implement private members or inline methods/functions?

I also have a different outlook on interfaces. To me, these constitute the actual creative work involved in programming. To define a highly functional, extensible and easy to maintain public interface is where the true art of programming resides. And it is the most challenging task any programmer can face.

A successful interface is the healthy lifestyle that allows your bad coding habits to go unnoticed and make your system live for much longer.

The implementation details are on the other hand nothing more than the application of well known algorithms and ideas, code reuse and the programming language well documented own semantics and abstractions, which together amount to the equivalent of building a LEGO house with the schematics on the other hand.

I find public interfaces much more needed of copy(left/right) protection than the actual implementation. Unless, of course, I'm building an actual algorithm.

[laserlight]

That said, I personally think it's a little silly when I read somewhere that to be informed of the license terms you must visit the GNU web site. Think about it. Imagine signing a rental contract where it said "By signing this contract you agree to be bound by the terms found on our Web site www.foobar.com". Is including a LICENSE file with your software that clearly states the full terms really too much? GNU has certainly been writing licenses for a while but there's no reason to assume that this will be true for the life of your published software.

I think that is why the suggested notice says "You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>." That is, you should only need to refer to the license text locally, but if somehow it is missing, you may be able to refer a copy online.

[phantomotap]

I am not a layer, and I do not offer legal advice.

I also have a different outlook on interfaces. To me, these constitute the actual creative work involved in programming. To define a highly functional, extensible and easy to maintain public interface is where the true art of programming resides. And it is the most challenging task any programmer can face.

O_o

Leaving your opinion on creativity aside, how do you plan to resolve Copyright of an interface in the context of compatibility requirements?

Again leaving creativity aside, let's imagine a scenario: you have created a robust C library for cryptography primitives. You've wrapped, with some apparatus, every component of the interfaces generally required to do anything useful with a program. (For example, you provide a `dlopen' mechanism--not the same interface--with security though Web of Trust thus allowing users a level of "I trust this component." for arbitrary building blocks.) You choose to ship your cryptography primitives as a commercial library for developers and a free stack for various operating systems.

$): I, preferring the C++ language, wrap your components with idiomatic C++ constructs. I do not ship your components. I do not imply a commercial relationship with your company or otherwise misrepresent the requirements to obtain a license for the library components you ship. My code uses templates to program components during compilation, using elaborate "SFINAE" over everything, so that I do need to directly use your interfaces. Can my own code be protected by Copyright even though the transformation isn't really substantial? (To be clear, the implementation would be substantial. The implementation of "SFINAE" over so many interfaces would be a vomit inducing nightmare.) Do I need a license, from you, to ship my code? (I am necessarily including many components of your covered work, the interfaces, in my own code.) Is my code even legal without my having obtained a valid license?

$): The stack you provide, without fee, to users obviously implements many of the interfaces your library exports. The stack you provide only cover "Linux" and "Mac OS X" despite the library supporting "Windows" thus requiring each application targeting "Windows" to ship an internal stack. I, apparently having returned to "Windows" for this scenario, want a "Windows" implementation. You claim protection on the interfaces. You can ship the stack without a fee because you own the property. I can implement a "Windows" version the necessary primitives. I am not using any of your implementation in my implementation. I, in order for the stack to be successful, need to ship a stack and a component library for developers allowing their code to use my stack. My code is certainly not trivial. The only similarity between my stack and yours is the public interfaces. (The internal interfaces are also different.) I have, in our hypothetical context, used your protected work in the creation of my stack. Can my own code be protected by Copyright without prejudice? (Is your claim of protection sufficient to limit my rights in redistributing my stack?) Do I need a license, from you, to ship my code? (I can't, by definition, ship a compatible stack without exposing the same public interface.) Is my code even legal without my having obtained a valid license?

Soma

[Nominal Animal]

In that case, why not make your intentions clear to the reader?

That is why I said a declaration is warranted.

Do I have to release my source code if I incoporate the library into my program

Copyright law conventions haven't caught up to this, yet. The ones making the agreements are much more worried about how long after the death of a creator they can monetize their work.

This is also the reason I recommend a more permissive license for libraries.

That said, my own view is simple: If you dynamically link to a library, and there are more than one implementation of that library that the application can work with, then you are not making a derivative of said library and you are free to use any license for the application you want, regardless of the license of that library. If you statically link a library, you create a combined work, and can only license it with a license that is compatible with both the application and library licenses. If there is only one implementation of a dynamic library your application requires, the situation gets complicated; we have to consider things like whether the dynamic library is required for your application to operate, and so on.

The GPL FAQ contains the question "I'd like to incorporate GPL-covered software in my proprietary system. Can I do this?", which I recommend everyone to read. It says you cannot incorporate. Then it tells you how you can have the parts interoperate, so you can distribute them as separate parts, licensed under different licenses, to achieve pretty much the same end result.

Do I have to add a function or menu item to my program that informs people about the license (GPL) or not, etc etc.

Never with the GPL. There are other (more permissive licenses) that do require such, though.

For questions like this, the GPL FAQ is useful, because it's written by those who wrote the license, and vetted by actual lawyers.

That said, I personally think it's a little silly when I read somewhere that to be informed of the license terms you must visit the GNU web site.

You read wrong. You don't have to. Only if you cannot find the LICENSE file in the project.

There is a reason for this wording, and it has everything to do with copyright law. If someone "accidentally" edits the LICENSE file, they're only violating the copyright on that single file. However, when written this way, the copyright declarations state what the LICENSE file should contain, and if omitted, where another copy can be obtained. That way, you cannot relicense an entire project just by violating the copyright on a single file.

Imagine signing a rental contract where it said "By signing this contract you agree to be bound by the terms found on our Web site www.foobar.com".

That's exactly what you do when you agree to an EULA on most proprietary commercial software. I remember I had to, when I still used Windows.

(Typically EULAs contain wording that says that the provider can change the terms at any time, without having to notice you, which is basically the same thing. Except they don't even need to tell you where the terms are found.)

Again, I'll ask. You don't ever implement private members or inline methods/functions?

You must have missed the preceding paragraph of the part you quoted. I wrote, "If you put protectable stuff like nontrivial code, inline functions or function-like macros in your header files, then it is no longer just an interface description, and you should consider licensing the header file using a more permissive license."

The libraries I write are almost exclusively low-level C ones. Any inline functions -- say, matrix element accessors for example -- in them have thus far been trivial, non-protectable.

I have written some header-only source code files, to help with portability or with common tasks, and those I always license with a much more permissive license (typically CC0 or PD).

I find public interfaces much more needed of copy(left/right) protection than the actual implementation. Unless, of course, I'm building an actual algorithm.

Are you sure you're up to date on what is actually protectable and what is not?

A few years ago I had to study on this stuff a bit, and it really changed how I saw the protection of my own creative work. I'm not claiming I'm right, or that you do not know about copyrights enough. I only mean that it is common for programmers and software architects to have an incorrect understanding of how copyright law actually works, and consequently value wrong parts/features of their work product. Again, I only say this because I myself certainly did, and used to have very similar views to yours.

[Mario F.]

Are you sure you're up to date on what is actually protectable and what is not?

No one really is, no?

There is still an ongoing debate on whether header files can be subject to copyright or not in the US and many other jurisdictions. There's not even a legal precedent that could constitute a good basis for a legal discussion. Just last year Oracle was able to reverse the previous District Court decision in favor of Google.

What you have is opinions on the matter. The FSF has their own opinion which has you may understand doesn't make it law. What I am telling you is that I have my own and this opinion is that I'm actually inclined towards SSO (shock!).

In my (probably poor) defense i'll let you know this: Anything copyrightable can be copylefteable.

I only mean that it is common for programmers and software architects to have an incorrect understanding of how copyright law actually works

It certainly seems so.


---------------
@Phantomotap

You certainly present one of those corner cases that make copyright laws such a damn hatefully difficult subject. I completely agree that you should not be subject to my license in order to ship your API. The difficult part of all this is however how to properly word the legal lines that separate fair use from infringement when one starts defending SSO as I do. That is where my argument stops.

I agree that if such a line can't be drawn, the best option is to not use SSO (this goes for any other contentious copyright issue in fact). But I felt it was important for me to mention that I do consider SSO an important aspect to copyright law. We just can't seem to be able to define it in less broad terms that can allow for the eventual leeways, such as the one you presented.