Re: Group Copyright
On 20 Jul 2001, Thomas Bushnell, BSG wrote:
>John Galt <galt@inconnu.isu.edu> writes:
>
>> 1) the list of thirty names
>
>This is annoying, but works fine.
What are you trying to say here that hasn't already been said?
>> 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?
We've been over this, and my "randroid philosophy" is closer to the truth
than this claptrap. Unorganized groups are becoming closer to having
legal standing. Group membership can become a real problem, but I assume
that they'd be smart enough to make contingency plans around that.
>> 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.
I think that this is actually a de facto agency rather than an assignment,
there needs to be an actual action to assign rather than mere assenting to
an implicit contract.
>> 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.
Yeah, so? It's thorny, but it IS an option. BTW, most of the laws you
mentioned are for publically held companies, not closely held ones.
>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.
Incorporation is reaasonable for anything that a member wants to do the
paperwork on. I know of many people that have corporations to do nothing
more than hold title to their home.
>> 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.)
This is also the most sub-optimal, and 4 and 3 are assigning rights to a
actual stakeholder: I explicitly used third party here--one who is not by
definition a stakeholder.
>Thomas
>
--
Here is wisdom. Let him that hath wisdom count the number of the BSD: for
it is the number of a man; and his number is VI VI VI.
(ir-reve-rent-lations 13:17-19)
Who is John Galt? galt@inconnu.isu.edu, that's who!
Reply to: