[Savannah-hackers-public] Re: Assigning a 'co-copyright' to the FSF?

[Jos Boersema]

>Hi folks,
>
>First, Josh, thank you for your interest in GNU.

Thank you (plural) for making GNU!

>About the "co-copyright".  When something is dubbed an official GNU
>package, it is entirely up to the author whether to assign the copyright
>to the FSF.  If the author does choose to do that, the FSF grants back
>all rights.  The result is that only the FSF holds the copyright
>(otherwise any legal issues would become very complex), but the author
>can do anything they want with their work.

Sounds good to me.

>                                            This is discussed in the
>maintainers' guide, http://www.gnu.org/prep/maintain.
>The FSF won't accept copyright on packages that are not official
>GNU packages.  The way something gets officially dubbed is by going
>through our evaluation process.  Our little form to start that going is
>at http://www.gnu.org/help/evaluation.html.
>
>If you do want to go down that road, one important question we'd like
>your view on would be what sede offers that gnu.free doesn't, and
>whether gnu.free should be improved instead of having a separate
>package.  As you can imagine, from the standpoint of a coherent system,
>we prefer not to have two programs doing the "same" thing.
>
>Hope this helps clarify the issues.  Questions/comments welcome.

Unfortunately this may be an "ugly" subject, because I might want to
talk GNU.FREE down, in order to `get it out of the way'. If the following
hurts anyone's feelings: sorry!

First of all I'm inclined to ask the question: if the GNU.FREE developers
have halted the development of GNU.FREE out of principled reasons, and
discourage usage of GNU.FREE, then:

1. Can it be claimed that GNU.FREE is a _democracy-program_ ? Or does it
   currently perform the function of _a technical illustration_ of a system
   that the developers do not believe works adequately enough to recommend
   usage. In other words: does GNU.FREE belong in the area of "failed
   attempts to do X", rather then actually "do X". If true, GNU.FREE should
   perhaps not be regarded as "occupying the `democracy-program' niche
   in the GNU system, and sede and GNU.FREE do not actually conflict.
         To reverse: perhaps GNU.FREE needs to make the case for why it must
         hold on to the democracy niche, when it claims it doesn't actually 
work.
         The nature of the failure seems to be in the design, not something
         easily fixed.

2. There is no development of GNU.FREE, although it might be
   possible to re-implement the sede design, within GNU.FREE.  I would
   be wondering then: why not directly invest in sede, rather then re-make
   GNU.FREE to re-implement sede. I don't know enough about GNU.FREE to
   determine whether it provides a better technical base for the sede
   design, then sede itself. However, I think that the sede design is
   pretty good, and has a lot of potential.

   A working program seems to be a better starting point for future
   development, and sede is not just a few lines of code to illustrate
   a concept. My hopefully not buggy line-counting script says sede
   contains 26,283 lines of code (25% C), and 36,953 lines of documentation.
   It has already been tested by people who are wanting to use it for
   future voting, and it worked to their satisfaction. It has all been
         developed by one person, if more people started working on it, it
         could be a complete solution quite soon. Sede has a very extensive
         Todo list with a lot of technical details ready for implementation.
         Sede is written 25% in C, the rest is shell-script which should be
         moved to C. This will provide a quick program, which is important
         for voting systems (potentially handling billions of votes). GNU.FREE
         seems to be written in Javascript, at least not C.

I should stress that it is not my words that GNU.FREE failed. It is
the GNU.FREE team which has decided that they have failed. Although it
is true that they prefer to declare the entire field of e-democracy a
field where everyone "will have to fail". I interpret that more limited,
because my program is not a failure (to my knowledge, even if I factor
in why I think GNU.FREE failed). I can't help but think about the
days before humanity broke the sound-barrier: people said it was
impossible, especially those that failed. But the failure wasn't the
impossibility of the goal, the failure was more limited. Ultimately,
with enough failures, eventually someone gets lucky. I think I stumbled
on something that works with sede ... a lucky shot if you will.

I am under the impression that GNU.FREE has decided to end development
on their project, because it required authentication of people over
the Internet, and this in turn would require the Internet to be
re-designed to remove anonymity. If true, GNU.FREE developers have
helped pave the way for sede, because sede is a democracy program
which needs the internet to be anonymous, rather then the non-anonymous (to
protect anonymity of votes). A non-anonymous Internet is a technical
obstacle for my program. The GNU.FREE team seems to have taken the
`high moral road' to sacrifice their project for the good of a free and
anonymous Internet. That is my impression, at least. Obviously,
GNU.FREE and sede have the same goals, and I would enjoy it if the
GNU.FREE people came to work on sede. They clearly want to do work toward
the end of having a working democracy program. If it didn't work with
GNU.FREE because of its system design problem, this could be another
chance and make it happen in the re-match ! They have not sabotaged
GNU.FREE although they regard it as dangerous, so I'm sure they won't try
to sabotage sede either ...

I see the GNU.FREE developers as companions of sede, because they
work to keep the Internet anonymous. That GNU.FREE didn't work, should
perhaps be attributed to the original designers of the system, not
the GNU developers who took over the GNU.FREE effort (info from site).
Sede was always targeted to be a GNU program.

It might be useful to take these things up with GNU.FREE developers,
and see what they think about it. Maybe they agree.

>  GNU Software Evaluation
>
>   [image of the Head of a GNU] 
>
>    Table of contents
>
>     * Offering software to GNU
>     * What it means to be a GNU package
>     * Questionnaire
>     * Helping evaluate software for GNU
>     _________________________________________________________________
>
>    Offering software to GNU
>
>   If you have written software which you would like to offer to the GNU
>   Project, thank you very much! This information explains how to submit
>   the package, so that we get the information needed and can evaluate it
>   as soon as possible.
>
>   The questionnaire below will probably take some time to complete.
>   Therefore, we've written it as preformatted text, so you can copy to
>   your system and fill it out. When you're done, please email it to
>   address@hidden (as plain text).
>
>   If you can't answer all the questions, or if the program does not
>   fulfill all of the items mentioned, don't worry, that does not mean we
>   will reject it. It's common for a program to be evaluated when it's
>   not quite ready. If the program is basically good, but certain things
>   are missing, we'll just point out what needs to be added.
>
>   We can also evaluate a program at an early stage of development; but
>   in that case, we may want to judge your ability to complete the
>   program based on other projects you have already done.
>
>   GNU is not simply a collection of useful programs. We started the GNU
>   Project with a specific overall goal: to create a free software
>   operating system, the GNU System. To keep the GNU system technically
>   coherent, we make sure that the parts fit well together. So the
>   evaluators judge programs based on how well they fit into the GNU
>   system, as well as on their quality, usability, and the other
>   characteristics you would expect. Based on the evaluators' report,
>   Richard Stallman (the Chief GNUisance) makes the final decision on
>   whether to accept the contribution.
>
>   Thus, becoming a GNU maintainer is a somewhat formal process, since
>   affiliating with the GNU project as a maintainer means you must agree
>   to work (within the confines of the maintenance) with the GNU
>   project's mission for software freedom.

Sede will take a level of exception to that, when it unnecessarily
interferes with neutrality. However, the technical aspects of sede
require the Internet to be anonymous, the source to be open and
freely downloadable by all voters as part of the result-verification
procedure, that voters be able to make minor modifications to the
source (for testing/verification), without the need to release it publicly
(which would destroy their anonymity):

  Voters who want, can run sede on remote results, and create on their local
  host exactly similar results, thus verifying result integrity.

>   So, in addition to the questionnaire, please read the GNU policies in
>   the Information for Maintainers of GNU Software as well as the GNU
>   Coding Standards. A summary of the major policies given below, but
>   please also look through the full documents.
>
>   Thanks again for your interest in GNU.
>
>    What it means for a program to be a GNU package
>
>   Here's the explanation, from rms, of what it means for a program to be
>   a GNU package, which also explains at a general level the
>   responsibilities of a GNU maintainer.
>
>   Making a program GNU software means that its developers and the GNU
>   project agree that "This program is part of the GNU project, released
>   under the aegis of GNU"--and say so in the program.
>
>   This means that we normally put the program on ftp.gnu.org (although
>   we can instead refer to your choice of ftp site).
>
>   This means that the official site for the program should be on
>   www.gnu.org, specifically in /software/PROGRAMNAME. Whenever you give
>   out the URL for the package home page, you would give this address. It
>   is ok to use another site for secondary topics, such as pages meant
>   for people helping develop the package, and for running data bases.
>   (We can make an exception and put the web pages somewhere else if
>   there is a really pressing reason.)
>
>   It means that the developers agree to pay attention to making the
>   program work well with the rest of the GNU system--and conversely that
>   the GNU project will encourage other GNU maintainers to pay attention
>   to making their programs fit in well with it.
>
>   Just what it means to make programs work well together is mainly a
>   practical matter that depends on what the program does. But there are
>   a few general principles. Certain parts of the GNU coding standards
>   directly affect the consistency of the whole system. These include the
>   standards for configuring and building a program, and the standards
>   for command-line options. It is important to make all GNU programs
>   follow these standards, where they are applicable.
>
>   Another important GNU standard is that GNU programs should come with
>   documentation in Texinfo format. That is the GNU standard
>   documentation format, and it can be converted automatically into
>   various other formats. You can use DocBook format or another suitable
>   format for the documentation sources, as long as converting it
>   automatically into Texinfo gives good results.
>
>   If a GNU program wants to be extensible, it should use GUILE as the
>   programming language for extensibility--that is the GNU standard
>   extensibility package. For some programs there's a reason to do things
>   differently, but please use GUILE if that is feasible.
>
>   A GNU program should use the latest version of the license that the
>   GNU Project recommends--not just any free software license. For most
>   packages, this means using the GNU GPL.
>
>   A GNU program should not recommend use of any non-free program, and it
>   should not refer the user to any non-free documentation for free
>   software. The campaign for free documentation to go with free software
>   is a major focus of the GNU project; to show that we are serious about
>   it, we must not undermine our position by recommending documentation
>   that isn't free.
>
>   Occasionally there are issues of terminology which are important for
>   the success of the GNU project as a whole. So we expect maintainers of
>   GNU programs to follow them. For example, the documentation files and
>   comments in the program should speak of GNU/Linux systems, rather than
>   calling the whole system "Linux", and should use the term "free
>   software" rather than "open source". Since a GNU program is released
>   under the auspices of GNU, it should not say anything that contradicts
>   the GNU Project's views.
>
>   For a program to be GNU software does not require transferring
>   copyright to the FSF; that is a separate question. If you transfer the
>   copyright to the FSF, the FSF will enforce the GPL for the program if
>   someone violates it; if you keep the copyright, enforcement will be up
>   to you.
>
>   As the GNU maintainer of the package, please make sure to stay in
>   touch with the GNU Project. If we come across a problem relating to
>   the package, we need to tell you about it, and to discuss with you how
>   to solve it. Sometimes we will need to ask you to work with other
>   maintainers to solve a problem that involves using multiple packages
>   together. This probably will happen less than once a year, but please
>   make sure we can contact you in case it does happen.
>
>    Questionnaire for offering software to GNU
>
>* General Information
>** Do you agree to follow GNU policies?

Yes.

>   If your program is accepted to be part of the GNU system, it means
>   that you become a GNU maintainer, which in turn means that you will
>   need to follow GNU policies in regards to that GNU program.
>   (Summarized below, see maintainers document for full descriptions.)
>
>** Package name and version:

sede 1.16

I am starting the move toward GNU compliance, but version 1.16 does
not fully comply.

>** Author Full Name <Email>:

Johannes Harm Boersema <address@hidden>

>** URL to home page (if any):

www.xs4all.nl/~joshb
(BTW, I prefer this site not to be linked to in relation to sede, because
 it may contain some things that certain voter would disagree with.
 I'm making neutrality into a religion, if you don't mind :-)

>** URL to sources (if any):

http://sede.sourceforge.net
http://www.xs4all.nl/~joshb/sede

>** Brief description of the package:

A simple but extensive Unix style text-console program to run voter
verified elections / referenda. It allows a much higher power transfer
to voters then any other system known (to me), including:
- the freedom to vote whatever you want to vote
- the freedom to explain your vote
- the freedom to re-process all results on your local host, verifying the
  integrity of the results
- the freedom to decentrally organize questions and vote on these 
  questions, using the centrally organized voting process, and still
        be able to vote on the questions asked by the central organization.
        Effectively making anyone willing the vote-administration.
- the freedom to have your ballot encrypted as you like
- the freedom to have it send to your using whatever platform (not all
  data-channels are equally suported right now, though, but ranging from
        postal, to telephone, website, email-voting... all these should be
        concurrently featured in a vote, and can be individually assigned)
- the freedom to vote fully anonymous (double blind)
...

(See site, front page.)

>* Code
>** Dependencies:
>    Please list the package's dependencies (source language, libraries, etc.).

25% is in C (plain C).
The rest is in Zshell script, which contains calls to:
cat chmod cp date dc echo ed false file grep head ln ls lynx mailx
(mutt) mkdir mv read rm sed sort tail tar tee test true uniq wc gzip.

>** Configuration & compilation:
>    It might or might not use Autoconf/Automake, but it should meet GNU
>    Standards.  Even packages which are written in interpreted
>    languages and thus do not require compilation, such as Perl, Python,
>    and PHP, should follow these standards, because it gives installers a
>    uniform way to set installation directories, etc.  Please see:
>    http://www.gnu.org/prep/standards/html_node/Configuration.html
>    http://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html

It probably does not (completely) comply yet. But it does unpack
correctly, has ./configure;make install, has user-only installation.

>** Documentation:
>    We recommend using Texinfo (http://www.gnu.org/software/texinfo/)
>    for documentation, and writing both reference and tutorial
>    information in the same manual.  Please see
>    http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html

I have not written an info manual yet. It has only a nroff manual.
I will write another manual later, and maintain both concurrently,
because I like the man(1) format.

>* Licensing:
>   This is crucial.  Both the software itself *and all dependencies*
>   (third-party libraries, etc.) must be free software in order to be
>   included in GNU.

Program does not use unfree software.

>   Please see http://www.gnu.org/philosophy/license-list.html for a
>   practical guide to which licenses are free (for GNU's purposes) and
>   which are not.  Please give specific url's to any licenses involved
>   that are not listed on that page.

Working on this, some details.

>* Similar projects:
>   Please explain what motivated you to write your package, and search
>   at least the Free Software Directory (http://www.gnu.org/directory/)
>   for projects similar to yours.  If any exist, please also explain
>   what the principal differences are.

What motivated me in the first place, was noticing in real life,
that (apart from having spare time to fill) there was no "voting
on the Interent going on". I found this odd and undesirable, a Bad
Thing in general. I concluded that there were no successful democracy
programs in existence, and hence that one was needed (that I needed one
at least). You might say it is a program for voters, by a voter. This
may be reflected in the maximum power transfer to ordinary voters,
away from the distrusted vote-administration. Voting can certainly be
a tiring affair, if one has to march through varies cities to get a
point across. There are also political reasons.

Competition:

The principle difference between GNU.FREE and sede, is that GNU.FREE
does not work according to its author(s), and sede does work according
to its author(s). There are also technical differences, but rather then
becoming an expert on GNU.FREE, I'd rather spend my time on developing
sede. I have always made a point not to investigate other efforts, so
that I might not fall in the same (logical) traps.  Nobody is likely
to use GNU.FREE if its authors say it shouldn't be used, therefore
GNU.FREE might as well not be in the GNU collection. I'm not seeing
it as a voter, had I seen it, sede would probably never have been
developed ... and people currently interested in perhaps using sede,
would be using GNU.FREE instead. GNU.FREE is not filling this void,
perhaps sede can (eventually, or even quit soon; who knows, I can only
do my best).

Sede takes the issue of `neutrality' extremely serious. GNU.FREE does
not appear to do so right now, but this is something that GNU.FREE could 
fix.

>* Any other information, comments, or questions:

Take your time, and I will take mine in implementing the needed
changes to make sede a GNU program. Hence, eventually sede will meet
every standard required/recommended for GNU programs. I really want
sede to be a GNU program, and am prepared to compromise any aspects
to any extend to make it GNU.  Sede needs a surrounding system like
GNU, which is exclusively open/free/gratis (in practice gratis) etc etc,
so that voters have a trusted, accessible and anonymous system to
vote from.

Readyness:

Sede does not appear to be ready right now in meeting all necessary
details, although it is a good way in the right direction IMHO.

jos