Re: Source licensing

From: Ed Kennedy <ekennedyx_at_yahoo_dot_com>
Date: Sun May 09 2004 - 23:51:44 CDT

Umm. Has anyone trademarked the OVC brand yet?

Thanks, Ed Kennedy
----- Original Message -----
From: "james_in_denver" <james_in_denver_at_hotpop_dot_com>
To: <voting-project@lists.sonic.net>
Sent: Sunday, May 09, 2004 8:03 PM
Subject: Re: Source licensing

> If it were up to me I would think about points 1..5 of the Apache
> License http://www.apache.org/LICENSE.txt. Obviously the verbage would
> change slightly, but the salient points are that it requires any
> derivative work to refer back to the copyright holder, and bars any
> other similar projects from using the OVC "brand" name without prior
> written approval.
>
> On Sun, 2004-05-09 at 21:13, David Mertz wrote:
> > On May 9, 2004, at 7:47 PM, Arthur Keller wrote:
> > > How about, closed proprietary source, published proprietary source,
> > > and free software?
> >
> > Those look like good phrases to me.
> >
> > > You mention a variety of "free" software. Which "free" software model
> > > should be used for the licensing/ownership of UC-developed software?
> >
> > I actually don't care nearly as much as a lot of people. If I were
> > making the decision all by myself, I'd probably say Public Domain (or
> > BSDish... the 'B' in there being UC-Berkeley, after all).
> >
> > But when we went over the discussion back in August, a lot of
> > developers felt strongly about the GPL's guarantee that proprietary
> > companies not be able to incorporate our code into derived,
> > closed/proprietary products. I'm certainly not against GPL either (or
> > EVMPL, which isn't much different, and hopefully compatible).
> >
> > Something like Karl suggests--registering service marks or trademarks
> > on "OVC compliant" or some logo--seems like a great idea to me. I've
> > never been through ISO 9000 myself, but most people seem to shudder at
> > those words :-). But he might be right about the political benefit of
> > that.
> >
> > Even if a proprietary vendor used our code, they couldn't win an "OVC
> > compliant" mark without meeting OVC standards. Obviously, those
> > standards would need to be non-discriminatory; they might involve
> > certification fees though. The real "value proposition" IMO should not
> > be using some lines of code developed in EVM2003/OVC-reference-design,
> > but in being able to claim OVC standards compliance legally.
> >
> > > Second, I wanted to make the distinction between VoteHere's approach
> > > to published software, and the OVC's approach (cases 2 and 3 above).
> > > Is such a distinction worthwhile? Thanks.
> >
> > I find pointing out the distinction between VoteHere's
> > "look-but-don't-touch-and-sign-the-NDA" and OVC's EVMPL to be quite
> > important. You've done a good job of describing the licensing space
> > above.
> >
>
==================================================================
= 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:29 2004

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