I have created a small and helpful project that I'd like to upload to a public repository and share under the FreeBSD license. What are the common steps I should make to apply the license to my code? I mean, what are the technical actions that should be done to apply the chosen license. More specifically:

Should I put the licensing information in the header of every file?

If yes, should I put the whole license text or there is an acceptable short version?

Should I have a specific file (e.g. in the root directory) that deals with the licensing? Is putting the license text in it enough?

If a project is a cooperative effort by various people on-line, that are not part of any organization, what should be written in the copyright clause?

5 Answers
5

IANAL so all this is just my point of view as a software developer who gone through similar questions as well:

1.) Should I put the licensing information in the header of every file?

Yes, you can do so. This ensures easily that it's visible on top of each file who wrote the code in there and under which terms it is available. Such a per-file-method is quite easy to handle in the beginning. However, it is not the only way to document authorship, copyright and licensing. And not to forget: Write on top of each file to which work it belongs (This file is part for MySoftwareX, Written by XYZ, Copyright bla bla ...).

2.) If yes, should I put the whole license text or there is an acceptable short version?

The FreeBSD license does not have a short version but it is already quite short. As "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer." the most straight forward thing would be to put everything in. If you later on find out, that this is not practically for your project you could change that by searching and replacing over multiple files quite easily, see next point as well:

3.) Should I have a specific file (e.g. in the root directory) that deals with the licensing? Is putting the license text in it enough?

This is very common to do, yes. I would even say, it's recommended to have a file called COPYING or LICENSE inside the root of your package that documents the authorship, copyright and terms for the work. Instead of having the license text and disclaimer in each file you can then put the authorship and copyright into the files only and add a "See COPYING" so to spare the redundant texts as it's obvious to what it belongs to and the COPYING file is actually part of your package and is always available with the code.

As you have a central COPYING file then, changes of it can be centrally monitored, something that the per-file-method can not.

4.) If a project is a cooperative effort by various people on-line, that are not part of any organization, what should be written in the copyright clause?

A copyright clause should contain the name of the copyright owner and optionally the year.

If the code is a combined work by many authors, all authors own the copyright. That's because multiple persons have created works on their own with their own copyright and then a larger work is build upon these multiple works to form a new work as a whole. As the new work (that project that is a cooperative effort by various people) contains other works, the rights related to those works are still effective.

However, if contributors have given a written statement that the project does get the copyright of their works as well and the project is allowed to change the copyright of other works given, then the project is able to give the new, bigger work, under the project's own copyright. But this needs a written statement (hand written signature) by each contributor.

So it depends on many things and this can mean a lot of work for you. If you did not kept track of authors and their contributions, then you need to find out first. Sometimes projects do a shortcut here and write "Copyright by it's contributors." which at least show that there are many. But strictly spoken this does not help if you don't know about the copyright of the contributions given. For example: A user gave some code he does not have the copyright of (e.g. because he wrote it while he was at work), so if you want to do this correct, the project needs to know the authorship and copyright of each contribution.

As projects somtimes just start and then grow without ever thinking about that, there are some tools that help to check each contribution in a FLOSS project, for example FOSSology.

So depending on how well contributions in the project have been documented (for example GIT does this pretty well by default, each change has the authors name and email documented with it), it's possible to actually find out about all authors/contributors/copyrights/usage-terms in the end.

As with the full license text it would be a little too much to document many authors in each file, another common way is to create a file called AUTHORS next to COPYING that contains all authors.

A copyright statement can then contain the two or three most prominent authors (e.g. often in a project there are one or two coders who do the main work) and then add "and many more (See AUTHORS).":

/**
* This file is part of ApplicationZero - Paint nulls on the screen.
*
* Written by Bustin Jieber, Gady Laga and others (see AUTHORS).
*
* Copyright (c) 2010-2011 by the authors. Some rights reserved, see COPYING.
*/

That's just an example of how things could look like. You can even add some more stuff into it to better express the projects needs or culture but the main point would be to document the very basics:

What is this file/code part of?

Who has written it?

Who owns the copyright?

What are the terms of use (commonly known as licensing or rights)?

How to do this always depends on a projects needs, but I hope I could show some ideas that are quite common. Keep in mind that this is mostly for documentation so that users of the software are able to learn about authorship and how they can make use of the software on their own. Like the programmer next door who might want to reuse and improve a super-cool subroutine and send you the patches later on.

If the project did not kept track so far about the contributions the project hopefully will have a software version control system or similar that did kept track, so it's more easy to now find out about the ownership of the code from the past properly. That can be a daunting job, but the longer you wait, the more hard it will become.

Just saying so, not that I think that project would do so: Writing a wrong or misleading copyright statement into the code just because "it's not known better" is infact not very helpful in the end as others might rely on it and this would destroy the faith in the product.

Instead I would somehow document problematic areas and to make visible what the project did so far to solve those problems and what prevented them to fully solve each issue(s). E.g. someone did a contribution four years ago but the email address she left is not available any longer so it's harder to contact the author to ask her about the copyright and such stuff. Keep that documentation at least within your project so it's documented that you're keeping track of stuff and you're acting in good faith. Often there is a friend of a friend and things get solved in the end quite well.

If the project knows about parts of the program that are not expected to be solveable or could not be solved within a certain period of time so far, those parts should then be removed from the software. That's the current and as well any other, older version the project still distributes. From a projects perspective that can be quite a show stopper, so should collectively make decisions how to handle these delicate points, e.g. to have a replacement plan. As it's not forbidden to learn from code that is/was publicly available, it's an option to rewrite parts of the program from scratch to start over independently.

But that's leaving the scope of your questions now I think. Good luck with your project and if you're really in doubt about things, organize in your project some help with people more connected to the law. They most often can better answer questions and for open source projects there are some mailinglists and initiatives that provide some support and help. You can ask for lawyers there as well which often are performing well on such issues.

@Denis I'm sorry, copyright assignment does NOT depend on how the project is structured. Individual contributors retain copyright unless explicitly assigned, typically through the use of a CLA. This is not a matter of opinion. IANAL TINLA.
–
Rein HenrichsMay 22 '11 at 22:56

2

@Michael - "C-family" language isn't an analogy, it's a simple literal fact - Javascript is in the same family as Java, C++ and C. And if all the server does is send a copy of a file through a pipe, that isn't enough IMO to call the content "program output". Otherwise, if someone hacks your system and steals the source for your C CGI handler, they're still getting "program output" from your server. Which side of a server you sit on has little relevance to copyright law - an exact copy is an exact copy, irrespective of how that copy was made.
–
Steve314May 23 '11 at 3:12

1

@Michael - BTW - it is possible to embed comment blocks in HTML. Probably CSS too, though I don't know for sure. The issue is the same one that I pointed out for Javascript - unwelcome file size implications. That's probably enough reason to not embed the license in every file that may be served over the internet. Still doesn't make it "program output" in any meaningful sense. One thought - a single copyright notice is sufficient for a whole book. You don't repeat the notice for every chapter, page or paragraph, except when different terms apply for some specific photo or whatever.
–
Steve314May 23 '11 at 3:28

1

@Steve314 The program runs on the server, correct? I'm not arguing that you can or cannot embed comments in HTML, CSS, or JavaScript. They are output by the program to the browser acting as a client. FWIW, I went through this very thing years ago with one of my projects, which is an official FSF project and the decision was that we did not need to include comments in the output - which are the files sent to the browser. You can certainly add them if you want - I felt it was more important not to download 10 copies of license declarations per logical request.
–
Michael DeanMay 23 '11 at 13:47

Copyright says that people can't copy or distribute your code (or any derived works) without permission. A license is just a formal way to detail the conditions under which they have such permission. So long as you make clear that you are indeed giving such permission, the exact details don't matter that much.

To make it as clear as possible, you want to include the license with the code. Common practice is to have a LICENSE.txt file in the root directory of the project. You also want to make it clear exactly what code is covered (this may be unclear if you include code from others with a different license). This is why some people recommend putting the license in each source file. Typically all code in a given file has the same license. If the license is short and sweet, this is reasonable. If not, it might be better to just put a reference in the file: "The code in this file is licensed .... See the file LICENSE.txt for details." A reference to an online version only is probably not a good idea. What happens if it changes?

If software is written by a group, each member of the group owns their own contributions, unless they assign copyright ownership elsewhere. It's common practice to have a list of such contributors in a file CONTRIBUTORS.txt in the root directory of the project, perhaps describing who has done what.

The real question here is: what are the steps necessary to make your license enforceable. Experience and relevant case law has shown that a LICENSE file in your project's root is sufficient to establish and uphold your license agreement. You do not need to put the license in every file, although certainly you could do so. You could also put the name of the license and a reference to the license file (ex. "This project is licensed under the MIT license. See LICENSE for more information."), although this doesn't seem to offer any actual legal enforceability above including the LICENSE file itself.

As to copyright ownership, as mentioned in a comment to another question, copyright assignment does not depend on how the project is structured. Individual contributors retain copyright unless explicitly assigned, typically through the use of a CLA. This is not a matter of opinion, it is a matter of law. (Check the copyright laws in your jurisdiction, ofc)

Otherwise, copyright information must be maintained in such a way that the copyright ownership of any line of code is immediately apparent. This usually means that individual files (or blocks of code) contain explicit copyright information, as necessary. You can also include some type of "Copyright X unless otherwise indicated" verbiage if copyright is mostly assigned to a single entity.

If retaining copyright ownership of your open source project is important (for instance to give you the freedom to unilaterally change the licensing terms), you should use a CLA from the beginning. Experience has shown that acquiring copyright assignment after the fact is a tedious and frustrating process. Be aware, however, that a CLA constitutes a barrier to entry for potential contributors.

IANAL TINLA. This is not a legal forum. You should not consider any information provided here to be legal advice and should always consult an actual lawyer.

Sorry, what's your point here? Do you have any idea how litigation or text files work?
–
MarcinMay 27 '11 at 13:02

@Hakre: They can send you a letter back. Or, you could include a copy of the licence on the CD. Or, indeed, you could attach it to your covering letter. You're still not demonstrating that this is a problem for the copyright owner.
–
MarcinMay 27 '11 at 13:22

I was more looking for the user than the copyright owner. The copyright owner could benefit as well because as we know, websites go down after the short period of some years while copyright last for much more years. It's just fragile.
–
hakreMay 27 '11 at 13:35

@hakre: Sure, you can do that if you don't want to confer any licence. I bet you think the only acceptable way is to put the full licence in every file, because that is the only way you can guarantee that the user definitely knows what the licence is. I think it's pretty clear that most people don't want to do that.
–
MarcinMay 27 '11 at 13:40

@hakre: but what if one file is exported elsewhere? Then any notice referring to the license.txt would actually be misleading. If we can use URIs for our xml namespaces, then URIs are robust enough for our licences.
–
MarcinMay 27 '11 at 13:49