[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Group Copyright

I'm snipping the normal John Galt obstructionism, off-topic political
commentary, and attempts to confuse issues, and responding only to the
real questions.

John Galt <galt@inconnu.isu.edu> writes:

> >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.

The status of unorganized groups is in great legal limbo.  Sure,
courts do the best they can when confronted with the situation, but if
you want to avoid hassle, the best thing to do is *avoid hassle* and
not just shove it around.  If you think dealing with a long
contributors list in copyrights is hassle, then surely you don't want
the extra hassle of dealing with the status of an unorganized group in

> 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.

Um, that's not really true.  The hassle of corporation law is really
quite awful; there are a lot of books promising "incorporate yourself
now" as the great solution to lots of things, and in practice, it's
strikingly bad.  But it's not so horrible you shouldn't ever do it.
It's just that to do it right requires considerable legal expertise.
If you don't do that, then there is real risk of doing it wrong.  And
the point of this whole exercise is to avoid hassle.  The hassle of
dealing with a badly-maintained corporation or badly-setup corporation
is considerable (go ask the NetBSD project).  

Since the goal in this discussion was to avoid hassle, you only do
that if you are careful to get the corporation set up *right*, and not
just set up and hoping its right, and trusting the court to settle it
out later.

> >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.

Well, by assignment I mean actual legal assignment.  I read (3) and
(4) as informal changes in what you put in the copyright statements
and not legal transfers of copyright.  

As is usual, when you get to the meat of the issue, you suddenly stop
giving arguments.  Why exactly is it sub-optimal to assign to a
third-party you trust, especially (as with FSF assignments) you don't
lose any of your rights in the process?


Reply to: