Re: Group Copyright
John Galt <galt@inconnu.isu.edu> 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
Reply to: