Acronym help, please

From: Jerry Lobdill <lobdillj_at_charter_dot_net>
Date: Fri Apr 21 2006 - 05:44:54 CDT

Hi,

I'm new here. Though I have 30 years experience in software
engineering (military systems) I don't have a complete command of
your acronyms. Could someone put me in the picture? IP? BSD? VSPR?

I'm in Texas and am going to be your OVC defender here. We are in
trouble in this red state and are far behind you guys in working the
political problems. I want to follow and understand what you are doing in CA.

Thanks,

Jerry Lobdill

>Message: 1
>Date: Thu, 20 Apr 2006 13:02:48 -0700
>From: "Joseph Lorenzo Hall" <joehall@gmail.com>
>Subject: Re: [OVC-discuss] AB 2097 -- Proposed Amendment
>To: "Arthur Keller" <voting@kellers.org>
>Cc: Open Voting Consortium discussion list
> <ovc-discuss@listman.sonic.net>
>Message-ID:
> <928946aa0604201302j2850b7dby97fa9723e77ae4ef@mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On 4/20/06, Arthur Keller <voting@kellers.org> wrote:
> >
> > >* Why just UC?
> >
> > The main advantage of specifying UC is that it avoids the long delay
> > from creating an RFP, posting it, selecting bids, and awarding a
> > contract. If our goal is to have something ready for the 2008
> > primary election (March or June 2008), we'll need to start as quick
> > as possible.
> >
> > In consideration of this issue, I suggest changing the date to March
> > 31, 2007. That adds 3 months to the time to get a system ready, and
> > allows the legislation to appropriate or obligate the funds as
> > necessary for the 2007-2008 fiscal year (which starts July 1, 2007).
>
>That makes sense... I'll have to think more about this.
>
> > >It would be better if businesses were included and it
> > >specified that the work would have to be done under a license that
> > >meets the requirements of the bill (public disclosure). Also, who
> > >gets the copyright assignment? The contractor or the SoS? (In general
> > >the government isn't allowed to have copyright but can be assigned
> > >copyrights in works... you'd definitely want an IP lawyer's opinion on
> > >this instead of mine. :) ).
> >
> > I suggest that the IP ownership be determined by the contract let by
> > the SoS and be specified by the RFP. My preference is a BSD-style
> > license plus the requirement that all derivative works must be
> > published on the Internet. I know that others have differing
> > preferences.
>
>I guess what I was getting at is that many open source groups have
>decided to have all contributors sign contributor aggreements that
>assign copyright in their works to a central entity. This ensures
>that one entity can defend the IP in case of a suit (say someone
>accuses the final product of containing something that they claim is
>their IP)... and it ensures that you don't have to track down all the
>individual contributors if you need to enfore the license terms (say a
>company takes the IP and puts it in something that violates the terms
>of the license).
>
> > >* It's unclear if the contractor would be writing software for *all
> > >systems* where a vendor didn't comply or would be writing software for
> > >just a single COTS platform (like the OVC design).
> >
> > Good point. If only one existing vendor complies, should the SoS
> > contract to expand the choices available anyway? If a county is
> > using equipment from a vendor that doesn't comply, should that county
> > be limited to the reduced number of vendors that do comply, if any.
> > Or should the SoS try to maintain competition by procuring an open
> > source system.
>
>I'm just not sure... I'll have to think more. A prize seems
>interesting too... put up a deadline for a fully functional system and
>a couple hundred grand (twice what the Australian eVACS system was
>procured for).
>
> > >* I'm on the fence about the federal certification part. First,
> > >regardless if this is a smart thing to do, doesn't HAVA require
> > >federal certification for systems used in federal elections? I think
> > >so (although there's no fed. election in 2007). Second, it's unclear
> > >to me whether or not federal certification is a useful thing anymore.
> > >Obviously, systems (the TSx) have made it through the fed. cert.
> > >process when they were blatantly non-compliant. The standards
> > >themselves aren't that good; for example, it's not that you'd want to
> > >ban interpreted code altogether (HTML, Java, etc.), what you want is
> > >to make sure that the software that is tested doesn't change between
> > >the test/audit and the election. That requirement will be in the VVSG
> > >until the next revision of the standards... which won't go into affect
> > >until 2010 at the earliest. However, there's some useful things that
> > >happen at the federal level that, say, the CA SoS would be poorly
> > >positioned to test (shake and bake testing, etc.) and I can't imagine
> > >academics like Wagner, Jefferson and Bishop will be available to do
> > >source code audits indefinitely in the future.
> >
> > There's an opportunity to create standards through VSPR, but that's
> > not been done yet. I'd like to see it happen.
>
>Yeah, I almost forgot about VSPR.
>
>--
>Joseph Lorenzo Hall
><http://josephhall.org/>
>
>
>
>------------------------------
>
>Message: 2
>Date: Thu, 20 Apr 2006 13:59:11 -0700
>From: Arthur Keller <voting@kellers.org>
>Subject: Re: [OVC-discuss] AB 2097 -- Proposed Amendment
>To: joehall@pobox.com
>Cc: Open Voting Consortium discussion list
> <ovc-discuss@listman.sonic.net>
>Message-ID: <p06230937c06da2487b89@[10.0.0.51]>
>Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
>At 1:02 PM -0700 4/20/06, Joseph Lorenzo Hall wrote:
> >On 4/20/06, Arthur Keller <voting@kellers.org> wrote:
> > > I suggest that the IP ownership be determined by the contract let by
> >> the SoS and be specified by the RFP. My preference is a BSD-style
> >> license plus the requirement that all derivative works must be
> >> published on the Internet. I know that others have differing
> >> preferences.
> >
> >I guess what I was getting at is that many open source groups have
> >decided to have all contributors sign contributor aggreements that
> >assign copyright in their works to a central entity. This ensures
> >that one entity can defend the IP in case of a suit (say someone
> >accuses the final product of containing something that they claim is
> >their IP)... and it ensures that you don't have to track down all the
> >individual contributors if you need to enfore the license terms (say a
> >company takes the IP and puts it in something that violates the terms
> >of the license).
>
>Open source does not necessarily mean provided by volunteers. It
>could also mean developed by an entity with employees that makes the
>results available through some appropriate license. The general
>public might feel much better about a controlled software development
>process by UC employees and contractors than by a collection of
>volunteers with differing motives.
>
> > > >* It's unclear if the contractor would be writing software for *all
> >> >systems* where a vendor didn't comply or would be writing software for
> >> >just a single COTS platform (like the OVC design).
> >>
> >> Good point. If only one existing vendor complies, should the SoS
> >> contract to expand the choices available anyway? If a county is
> >> using equipment from a vendor that doesn't comply, should that county
> >> be limited to the reduced number of vendors that do comply, if any.
> >> Or should the SoS try to maintain competition by procuring an open
> >> source system.
> >
> >I'm just not sure... I'll have to think more. A prize seems
> >interesting too... put up a deadline for a fully functional system and
> >a couple hundred grand (twice what the Australian eVACS system was
> >procured for).
>
>Your points are well-taken. The Australian system doesn't do all
>that California voting systems need to do.
>
>Regarding the effect of prizes, consider DARPA's Autonomous Vehicle
>Grand Prize. I wouldn't say that any of the vehicles produced is
>production grade. Fully functioning does not mean production grade.
>There are some who think that some of the commercial products, while
>possibly fully functioning, may not really be production grade.
>Furthermore, prizes don't ensure that a system is secure or reliable.
>
>That's why I suggest a software development procurement effort that
>involves the application of state-of-the-art software engineering
>techniques to maximize reliability and cracker-proof.
>
>Many of the developers of Linux-Apache-MySQL-PHP and related
>components are contributed (paid for as employees of friendly
>companies) because they see the greater benefit of such general
>purpose computing infrastructure, from which they derive financial
>gain. Few companies derive financial gain from voting system
>software, so the idea that an IBM or an Oracle would donate employees
>to the cause, as they do for LAMP components, does not make sense.
>
>While bug fixes and small components are often contributed by pure
>volunteers, it's rare for ongoing major development to be done
>entirely by unpaid volunteers who are not given release time for such
>work by their employers.
>
>How would you feel if a certain political party were to decide that
>they would pay for the development of open source voting machines?
>Would that make you feel confident in the result?
>
>There are lots of design choices that can be made, and those really
>should be made in a fishbowl and not presented as a fait accompli.
>
>Consider the design choices that went into the California Statewide
>Voter Database, and how names much match precisely to the letter,
>including spaces, with no allowances for Michael vs. Mike, or married
>vs. maiden names, or certain ethnic names with multiple words (is
>that a middle name or part of the last name?) or transliterated
>spellings that vary. Should those choices have been made in the
>open, where they could be debated publicly as they as designed and
>subsequently implemented?
>
>Best regards,
>Arthur
>
>--
>-------------------------------------------------------------------------------
>Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA 94303-4507
>tel +1(650)424-0202, fax +1(650)424-0424
>
>
>------------------------------
>
>Message: 3
>Date: Thu, 20 Apr 2006 20:45:49 -0700
>From: Ron Crane <voting@lastland.net>
>Subject: Re: [OVC-discuss] AB 2097 -- Proposed Amendment
>To: Open Voting Consortium discussion list
> <ovc-discuss@listman.sonic.net>
>Message-ID: <4448556D.6030008@lastland.net>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Alan Dechert wrote:
> > People are concerned what happens if vendors refuse to comply.
> >
> > Currently, Sec 2, (4)(f) says,
> >
> > A public review process shall be in place by
> > June 30, 2007. In the event that a vendor of a
> > system certified before June 30, 2007, refuses to
> > comply with the disclosure requirements, his or
> > her system shall be decertified. The Secretary
> > of State shall ensure that a suitable replacement
> > be available.
> >
> > Here's what I'm thinking ....
> >
> > A public review process shall be in place by June 30, 2007. If,
> by February
> > 1, 2007, the Secretary of State is for any reason dissatisfied with vendor
> > compliance progress with provisions of this measure, the Secretary of State
> > may contract with any or several campuses of the University of
> California to
> > create voting system software to run on existing voting system hardware or
> > replacement COTS hardware. In this case, the Secretary of State
> will forego
> > the federal certification process normally required.
> >
>This seems like a good plan, though, if no vendors comply, the timing is
>likely to end up being very tight. But I suspect that some will comply
>-- though in a highly legalistic manner. This re-raises my prior set of
>amendments (attached), which are intended to make it more difficult for
>vendors to hide stuff that we ought to know. As writ, vendors will drive
>trucks through the existing bill's "voting system specific" language,
>among other things. For example, Diebold probably will argue that its
>touchscreen-input code is not "voting system specific" because "we use
>the same code in our ATMs". Once this occurs, years of litigation will
>ensue, during which voters will be no better off than they were before
>the bill's enactment. Let's try to make the bill as tight as possible
>within the constraints of legislative politics.
>
>-R
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: ovc-open-source-bill-A3.doc
>Type: application/msword
>Size: 52736 bytes
>Desc: not available
>Url :
>http://lists.sonic.net/mailman/private/ovc-discuss/attachments/20060420/086ee6c6/ovc-open-source-bill-A3.doc
>
>------------------------------
>
>_______________________________________________
>OVC-discuss mailing list
>OVC-discuss@listman.sonic.net
>http://lists.sonic.net/mailman/listinfo/ovc-discuss
>
>
>End of OVC-discuss Digest, Vol 18, Issue 8
>******************************************

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Tue May 2 21:06:53 2006

This archive was generated by hypermail 2.1.8 : Tue May 02 2006 - 21:06:54 CDT