Re: Integrating package.el

[MON KEY]

Joakim Verona writes,
> A well made package system might also conceivably make it easier to
> acquire papers right?
>
> For instance, it might be more prestigious to have ones package in the
> FSF repos.
>
> Also, digital signatures might be legally binding at some point. (I think
> they are in Swedenalready, we have a national system for it anyway)

I don't get why the licensing/assignment need necessarily be an issue.
For example, I was issued a `.pdf' file for my assignment.

The file name has format: `<LASTNAME>.<NUMBER>.EMACS.pdf'

Following the letterhead on pg 1 are the lines:

,----
|                                       SURNAME-UID  <--BLOCK-1
|                                         RT NNNNNN  <--BLOCK-2
| ASSIGNMENT - GNU EMACS                             <--BLOCK-3
`----

 Following that, the opening paragraph reads:

,----
| For $1 and other good { boilerplate elided }
| hereinafter "FSF", <MY-FULL-NAME>, hereinafter      <--BLOCK-4
| "DEVELOPER", hereby agrees as follows:
`----

The bottom of page two has two signature blocks:

,----
|      Thank you for the contribution!
|
| Signed:
|
| __<MY_SIGNATURE>__
|                                                    <--BLOCK-5
| __<DATE_SIGNED>___
|
|
| Accepted by the Free Software Foundation
|
| __<EXECUTIVE_DIR_SIG__
|                                                    <--BLOCK-6
| __<DATE_SIGNED>_______
|
`----

The scan also has an inked date stamp which appears in the manner of a Bates
number.

:NOTE The above template is recent, obv. older such docs may differ.

While I'm quite sure the FSF has facilities to OCR/digitize this type of content
in bulk it is surely outside their purview to extend such facility (and time
required to do so) to the Emacs project or any other GNU project FTM.

That said, Joakim's has developed dragbox.el which using GOCR should already be
capable of the following:

o Extracting digital images key portions of the document Blocks 1-6,

o Extracting OCR'd conversion of Blocks 1-4,

The `Bates Date stamp' (BLOCK-7) would prob. need to be manually identified and
extracted as these most likely appear skewed, incompletely inked, and
arbitrarily placed for the majority of assignment papers. Regardless, Joakim's
dragbox.el already provides adequate facilities for accommodating a manual crops
of BLOCK-7 as well.

With such extractions, the digital image portions of Blocks 1-7, and the OCR'd
conversion of Blocks 1-4, a `sanctioned repository maintainer' would
key-sign/encrypt
each block (or the entire bundle) of extracted content for:

o The package author(s);

o The Emacs-devels;

This encrypted bundle could be and distributed with the package or retained
separately.  In either case, the bundle would receive a Unique ID which would be
included in the header commentary of each file distributed with the package.

Assuming all the elements of this regime are technically possible what are the
benefits it would provide that other approaches wouldn't:

o It promotes user awareness of, and re-assures the user benefits of, using a
  suite of congruent and consistently licensed packages.

o It promotes and encourages package authors to acquire assignment _papers_ in
  addition to incorporating boilerplate license terms in package/library
  headers.

o Once an authors assignment papers have been processed per above it provides a
  mechanism whereby package authors can readily integrate new libraries with a
  sanctioned repository without additional overhead. IOW assuming no change of
  employment, surname, etc. an author simply notifies the repository maintainer
  that a new package exists and that said new package should fall under the
  existing Unique ID umbrella.

o Changes in assignment status e.g. withdrawal of assignment, change of
  employment, contact address, surname, etc. can be more readily propagates
  through the system. The repository maintainer is notified and alters the scope
  of the Unique ID umbrella accordingly; this alteration is made known to users
  and devels upon next synchronization.

o It can be integrated with existing assignment papers dating back to ???.

o It reinforces the existing practice that assignment papers need be signed on
  physical media (e.g. _paper_).

o It allows upstream Emacs-devels to verify assignment should they elect to
  incorporate a package or portions of code therein with less burdensome
  overhead.

o It may remove some of the initial immediate overhead Emacs-devels face with
  regards incorporation of new features in the absence of existing assignment
  papers. IOW going forward new packages/authors will presumably already have
  acquired papers and these papers will already have been converted processed.

o It may ease management of existing/future assignment papers w/re upstream
  Emacs-devels, i.e. by breaking up the assignment document into discrete
  elements Blocks 1-7 could be databased in any number of ways including xrefs
  across multiple authors/packages, verification of date and timestamp
  incongruities etc.

Assuming the above are points are indeed beneficial what are the detractors:

o It places a burden on package authors that may not have been there before;
  namely, acquisition of assignment papers.

o For new authors there is a time-delay between the initial creation of
  package/source and any sequencing of assignment papers, digitization,
  propagation etc. required before a package can become part of a
  repository. IOW An author can publish code with a GPL header to github,
  bit-bucket, launchpad, etc. in seconds.

o It places a significant burden on `sanctioned repository maintainers' to
  accomplish the initial digital conversion and subsequent propagation to
  appropriate parties.

o It may place a burden on FSF if it has to process more assignment papers.

o It doesn't (currently) address the issue of older assignment papers that are
  in a different format, are lost, out of date, etc.

o It doesn't accommodate purely digital code signing models.

o It doesn't accommodate alternative licenses (philosophical negative).

o It places a burden on users to grok the benefits/rationale of what in other
  situations would be considered an esoteric approach, i.e. One can _fax_ a
  contract that is binding but authors/contributors of a premier piece of
  software must make available hand signed media.

o None of this exists yet.

Personally, I believe there is a net gain for package authors when there is a
cost of entry to a project.  AFAIK Right now there isn't a cost of entry because
there isn't really an entry point and what little there is places the burden on
CYD, Stefan, et al to manage the assignment but that this generally takes a
backseat to other more pressing concerns... So, some neat stuff lingers because
it is a chore to manage the paperwork (real or metaphorical).

Likewise, I believe there is a net gain for community package repository
maintainers when there is some cost of entry to accept/process a package. There
are many examples of projects which maintain `unofficial repositories' of third
party tools. Those that provide a degree of oversight seem to be more
trustworthy and propagate more reliable code than those that to quote Dennis
Hopper in the movie Blue Velvet, "F**k anything that moves". When package
authors understand that some legwork is required of them in order to play they
may be more apt to contribute more robust and tested code (as contributions
aren't worth the trouble otherwise) where this is the case repository
maintainers will benefit from less need to troubleshoot, and less need for
frequent integration of code changes.

Most likely there will continue to be more than one model of Emacs community
developed and distributed packages. These will either compete for
attention/resources or each will offer appropriate paths to increased
integration with Emacs.  In a competitive environment (read forking) environment
the repo with the _most_ packages will thrive i.e. "Worse is Better" even
if/when it isn't.  In a cooperative/integrated/tired community repository
environment the repo with the best, cleanest, most open, code will achieve a
higher "status" than her fast and loose neighbor.

IOW repository maintainers have no incentive to adopt the above assignment
clearing regime where a competing repo environment is afforded an equal status
by the upstream Emacs-devels. However, where there is some upstream endorsement
preference for a particular _regime_ then disparate repo maintainers and
package authors can participate with, promote, and adopt this regime (or not)
according to their particular philosophy, time restraints, personalities, etc.

/s_P\