[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gNewSense-users] New PFV Emacs mode (Re: What sucks about gNewSense?)

From: Bake Timmons
Subject: [gNewSense-users] New PFV Emacs mode (Re: What sucks about gNewSense?)
Date: Mon, 12 Nov 2007 13:41:14 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux)

"Kevin Dean" <address@hidden> writes:

> How was THAT for a loaded title? :P
> We spend a LOT of time with PFV and as we go along we find out now and
> then that we've got non-free software. Some scripts have been written
> to help automate these checks, but it still takes "too long".
> That got me thinking about the WEAKNESSES of gNewSense (and Free
> Software distros in general) and I figured that a realistic
> self-evaluation could help us improve the process of creating a Free
> Software distro.
> I've made a post on UTUTO's forums asking a bit about what THEY do
> (How do THEY identify binary blobs, for instance) and what weaknesses
> they have. Hopefully we might be able to identify common weakpoints
> and work together to solve them.
>  I don't believe that any package manager has built-in support for
> license issues and this is something that I think is a technical flaw
> that harms our distro - has anyone really thought about how much PFV
> needs to be "redone" for gNewSense 2.0? Perhaps something like
> liblicense is better to work out... Just brainstorming here.
> I don't know how to "find" binary blobs. I dont' know what they look
> like in the source, so I'm almost totally useless as to determining
> non-license freedom - Brian's Builder tools are very limited to the
> version of the kernel gNewSense uses and will have to be re-tooled to
> handle the newer versions that future versions will be built. Because
> of this, despite our PFV we're still not 100% sure that user's
> freedoms are fully protected.
> Everyone hopes that as more developers come on board, we'll be able to
> do more and more, but I'd personally like to look at this from another
> angle... How can we harness the skills that we have to best meet our
> goals? For instance, I'm willing to learn more about programming so
> that I can contribute more to the technical side. If we had tools to
> give to less technical people to harness Linus's Law, we may be able
> to do other things as well.
> What shortcomings do OTHER people see in the development process of the 
> distro?

Thank you for the criticism, just enough impetus for me to announce the
release of a PFV mode for Emacs, which I have attached to this email,
along with a file of "license name" shortcuts that can be inserted with
keystroke commands.

While I have not yet properly documented the mode, here is a short

In Emacs, give the command pfv-top, then paste in a PFV wiki page that
you wish to edit, such as

Emacs then draws a previewed table to fill out.  Function key F11 shows
a list of license names with shortcuts.  E.g.,

0: GPLv3+
1: GPLv2+
2: LGPLv3+
3: LGPLv2.1+
4: BSD License (revised)

So, pressing C-z 3 inserts "BSD License (revised)" at the cursor

The only things to fill out are just the names of the licenses and
whether the package is free (Yes/No).  (There are a several other
convenience functions, such as downloading package files and unpacking
them for inspection, but they still have a kink or two that need to be
ironed out.)

When done, just give the command pfv-tbl2markup

and your cursor shows up in a new buffer with converted markup
(including the correct current package URLs, etc.) which can be copied
and pasted into the wiki form.

We clearly have relied too much on the Debian copyright file, so I
suppose a big help would be an automated way of classifying or
clustering files in a package based on their license comments.

I just have installed the crm114 package: The Controllable Regex
Mutilator and Spam Filter.  More than a spam filter, it is like a super
grep that may be do a good job on this kind of task.  It already has
been used on a number of other classification/clustering tasks.  It may
hold particular promise for non-programmers perhaps.  Perhaps some
people have used a CLI a little and have played around with a few shell
commands, such as grep.  (However, programmers might also profit from
cmr114's unusual capabilities.)

That is the "guessing" piece, which we must not underestimate.  Consider
the licensing hodge-podge of just the Linux kernel alone.  The guessing
capability need not be too smart, since it could just be used to
automate, say, 90% of the work, with the 10% involving real thought.

What I take from your comment also involves an organization piece, which
I too very much symaptize with.  While the isolated files that we are
editing comprise a database of sorts, I think a queryable format would
be better, say a sqlite file.  Working with this kind of file would be
an easy intermediate step to, say, ultimately devising some enhanced
package manager features.

Thanks again for stimulating some thought on these things.

Attachment: pfv-mode.el
Description: PFV Mode

Attachment: license-choices
Description: license-choices

reply via email to

[Prev in Thread] Current Thread [Next in Thread]