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.
