Re: Assigning copyright?

From: james_in_denver <james_in_denver_at_hotpop_dot_com>
Date: Tue May 11 2004 - 10:10:04 CDT

On Mon, 2004-05-10 at 18:34, Edward Cherlin wrote:
> On Monday 10 May 2004 11:33, Arthur Keller wrote:
> > At 2:18 PM -0400 5/10/04, David Mertz wrote:
> > >Along the lines of Arthur's source code questions, and my
> > > comments on Linux, FSF, etc, I wonder about copyright
> > > assignment.

It really seems like that Apache License model is the best approach for
this situation. It centralizes authority and responsibility for
development and release to a body of developers who manage as a group
those processes.

>
> > It might make sense for the EVM2003 to be assigned to the FSF.
> > Perhaps the UC-developed system should be assigned to the OVC
> > with a "performance clause" otherwise it defaults to the FSF.
> > Of course, we have to be willing to agree with whatever they
> > do with the rights, or otherwise have that in the agreement
> > assigning the rights.
> >
> > Another possibility is for UC to retain the copyrights (or
> > assign to another entity), but allow use of the software for
> > any purposes provided that the interface specifications
> > (presumably maintained by the OVC) are adhered to.
>
It appears that OVC needs a copyrite in the not too distance future, and
that the code be released under that copyrite, with OVC maintaining
"ownership"/"stewardship" of that code. Grants or licenses to use or
modify the code may be granted to other parties, again, very much like
the Apache model.

> Somewhat more permissive language is in order: The code is usable
> for any private purpose, and modified versions may be
> distributed with a clear statement that the modifications are or
> are not certified for election use. We will have to decide on a
> policy on licensing of certified variant code for use in
> elections (Yes/No/We'll decide when we see it) allowing for the
> fact that other countries may need to make modifications, and
> election laws will change.

It would be a government entity that would be responsible for certifying
software as valid for election purposes, not the OVC.

I think that this is an important reason for OVC to maintain ownership
and licensing of the software. In this way OVC can avoid the possibility
of competing with variations of it's own software. Without this it would
be trivial for a developer outside OVC to make a small enhancement,
without OVC approval or validation, and then submit that for
certification in a location that OVC was already certified in. This
needlessly increases the number of "vendors" submitting for
certification and dilutes the OVC "brand". This fragments the "product"
line and places a burden on the certification authorities to choose one
OVC product over a slightly different OVC code, but not OVC released,
package. Better to keep a slightly tighter grip on the reins.

Just some thoughts and obversations.

James Acomb
>
> > This exercise might seem a waste to some, but it helps me
> > justify whatever choice we make to the UC administrators.
> >
> > Best regards,
> > Arthur

==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Mon May 31 23:17:34 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:16 CDT