John Galt <[EMAIL PROTECTED]> writes: > 1) the list of thirty names
This is annoying, but works fine. > 2) the group/readme This is dangerous, because the group has no legal reality as a rule. It doesn't mean you lose copyright, certainly, but it injects a vest doubt into "who is the group". For example, if you write something, put it in the project, so that it's "owned by the group", and then stop participating in the group, there is now an anomaly. The group name no longer accurately reflects the actual authors of the code; would the court follow the current membership of the group or not? > 3) list two or three primary contacts (the Berne riff kind of means that > all thirty still have standing to sue). That's no good at all. All are still copyright owners, so you're deliberately misleading the people who get the code. Indeed, Debian relies all the time on the assumption that we are talking to the real authors when we talk to the authors listed on the code. Or maybe the court would deem this kind of thing as a defacto assignment to those "primary contacts" by all the other authors. I have no idea. Better to decide what you actually want and do that, than play dice. > 4) incorporate (some places incorporation requires some small number > [anywhere from 1 to 5] of incorporators, and a few bucks to the state: > Idaho requires one and $30, for example). Incorporation is more hassle than that. You are required to have annual corporate meetings, for example. And file a variety of reports. That corporation now has assets (and accordingly, income); as a result, it must file an inormational report with the IRS. Incorporation is a reasonable thing for larger groups, like NetBSD or maybe Apache. If Gnome weren't part of GNU, it would make sense there too. > 5) assign rights to a trusted third party or a third party that all agree > should recieve them. This is usually a winner. Note that number (4) and number (3) really boil down to this one. Except that it need not be a "third party"; it could just as easily be a lead developer on the project. The FSF is always a fine choice; by assigning code to the FSF you don't lose any of your rights at all over it. (The standard FSF assignment is not just a complete transfer of all rights.) Thomas
