[Dev] [Voting] Package freedom guidelines draft two

Michał Masłowski mtjm at mtjm.eu
Tue Jan 8 16:56:24 GMT 2013


> I'd also say that the FDL exceptions are only OK in some situations
> (the situations RMS thinks are OK).  I believe that this is "invariate
> sections are OK only for secondary sections"; whatever that means.

This is explicitly stated in the FDL, documents with invariant primary
sections aren't properly licensed.

> These are/were bugs with the GNU packages, not places where our
> policies conflicted.

Many other cases are bugs in the packages that are fixed in future
versions (e.g. chromium-bsu, supertuxkart, syslog-ng).  I don't know if
we blacklisted a GNU package; gNewSense had enscript blacklisted for a
new contributor to fix it since it's easy.

> So:
>   I believe that a file may only be included in in a binary package if
>   it meets one of the following conditions:
>    1. It is "source code" as defined by the GNU GPL, version 2.
>    2. It is generated as the result of running a PKGBUILD.

Example: TeX hyphenation patterns.  They are made from lists of
hyphenated words using patgen (or a derived program) with appropriate
parameters (several numbers), the output is a list of patterns like what
$(kpsewhich hyphen.tex) lists.  Patterns can be edited to improve
hyphenation using the TeX algorithm, while only the word lists can be
used for development of different algorithms (until all important
dictionaries use TeX for their hyphenation).

I believe the word list would be the source code of the pattern files,
while these are not available for most languages (e.g. US or UK
English).  So if we include hyphen.tex in a package, it won't be
generated by running the PKGBUILD and it won't be the source code.

We should consider more than a single form of the work a source code
(depending on the expected use of the work) or accept editable generated
files.

(The same occurs with fonts, Inkscape SVGs or bitmap graphics.)

Or we could restrict the source requirement to software and
documentation (accepting generated HTML or troff?).

> A reliable/working build script is an important part of the "source",
> and we can't forget that just because it's convenient.  Arch doesn't
> build java packages from source because they don't have policies about
> strict source-availability; we do.

It is important.

> And in more than a few cases, I've discovered that a free-software
> Java program relies on a non-free package to be built.  Or even simply
> a hard-to-package program that we don't have.  If we can't build a
> package on our system, we have no business packaging it.

This is a good reason to build it from source.

> I agree, but I also don't think that
>  1. This needs to be discussed in *this* policy.
>  2. That we have found a good solution yet.
>
> I don't think that we should policyize this until 2 is met.

Ok, maybe the policy could be completed before solving this separately.

>> A packager can start a build, manually fix after it fails and continue.
>> Or use a rePKGBUILD on an Arch-built package.
>
> Alright, I see where you're coming from.  I just thought that your
> wording was unnecessarily confusing.

I thought the same not remembering these cases, this needs different
wording.

> I guess "only add -libre if the changes are freedom-related".  In the
> case of Iceweasel, most of the changes are freedom-changes.  If the
> changes are technical in nature, another identifier should be used to
> identify your fork.

Should we keep using -libre for Parabola branding?

> provides=($pkgname-libre) and replaces=($pkgname-libre) it.

With appropriate versions.

> Unrelated: the characters in your name break text-mode emacs in
> gnome-terminal. *sigh*. Why can't these things just work?

I had the same problem when using the YeeLoong console, GTK+ Emacs
doesn't have this issue (and has other advantages) so I haven't found a
different solution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130108/d61240f3/attachment.sig>


More information about the Dev mailing list