[Dev] [Voting] Package freedom guidelines draft two

[Michał Masłowski]

> It is ridiculous to have an exception for GNU packages.  Given that
> GNU is normally freely-license, we need to match whatever exceptions
> they have.  Therefore, we need exceptions for:
>
>  * license works
>  * works of opinion

We have an exception for licenses.  These ND-like works remain:

0. separate works of opinion, e.g. RMS interviews, essays, sex jokes in
   the Emacs distribution
1. FDL cover texts
2. FDL invariant sections
3. copyright, license or attribution notices

0 and 3 are obvious to handle, I think 1 could be considered acceptable
attribution; 2 could have a separate exception based on how the FDL
defines these sections.

> And probably others.  If ever we decide that we need to blacklist a
> GNU package, that means that the policy that decided that is broken;
> not that we need to give GNU an exception.

There were real licensing problems in GNU packages, e.g. Emacs sources
not including sources of generated parsers, the Sun RPC issue of glibc,
or Enscript not including the license of Adobe font metrics, these are
fixed quickly.

> That applies to any time we want to make an exception for a package.
> Instead of making an exception, we need to fix the policy.

It might result in much more complex policies allowing some worse
decisions.  I don't know if it will be so in this case.

> Parabola has always *supported* and *preferred* free culture, but
> has always allowed in nonfree cultural works.  And quite frankly,
> enforcing this is unfeasible.
>
> That said, I do believe that we should formalize our support of free
> culture.

How would we formalize it?  The DFSG discourages forbidding distribution
of modified sources (i.e. only unmodified sources + patches), maybe this
should be stated similarly?

>> H. GNU FDL manuals with cover texts are not accepted.
>> 
>> I. GNU FDL manuals with cover texts but no invariant sections are
>> accepted.
>
> This would require us to modify GNU packages, which is neither
> feasable, nor something that I think policy should ask of us.

Debian does this, maybe we could use their sources, it still won't be
easy.

>> == Packages are built from source ==
>> 
>> All architecture-specific files in binary packages must be built from
>> source.  Architecture-independent files in a form that cannot be
>> easily edited must have a source included if they are software,
>> otherwise they should.  These files should be built from source by
>> automated scripts called by the PKGBUILD, to make modifying the
>> packages easier for users.
>
> Replace "easily edited" with "preferred format for editing" or
> whichever phrase the GNU GPL uses.
>
> I'm going to refer to files that don't meet this as "binaries", even
> if they are not actually binary, just to avoid wordyness.  A file that
> actually is in a binary format (such as a .XCF) does not count as a
> binary in this context.
>
> And, I STRONGLY object to a policy which allows for distributing
> binaries which are not generated in a PKGBUILD.  I will allow a policy
> which places them as low-priority bugs that do not require
> blacklisting while they are fixed; but they must be bugs, on a to-do
> list to fix.

This is too confusing, "binaries" can refer to:

- arch-specific noneditable binaries: your "binaries"?

- arch-specific editable binaries

- arch-independent noneditable binaries: your "binaries"?

- arch-independent editable binaries: "sources"

I don't want to write scripts to build all arch-independent editable
files in TeXLive built from more easily editable files.  (The only
similar cases in other packages that I know are files not used in binary
packages or compiled into other binaries, e.g. tables of generated
constants, parsers or configure scripts.)

>> == PKGBUILDs do not fetch nonfree sources ==
>> 
>> Use SRCBUILDs to make free source archives.  Do not remove nonfree files
>> in <code>build()</code>, removing recommendation of nonfree software is
>> acceptable.
>
> I'm not OK with locking us in to SRCBUILDs yet.  I think we still need
> to find a better (technical) solution.  Ideally, something like
> prepare(), but without the issues that were brought up in the previous
> thread.  In fact, I just hatched a solution in my head, but I've sent
> enough emails on this list about software that I only intend to write.

We need a solution that we will use, preferably a single one.
Developers should be able to find what to use from the guidelines.

> Now, what I would be OK with is:
>
>   Use a reproducable method to make free source archives.  Do not remove
>   nonfree files in <code>build()</code>, removing recommendation of
>   nonfree software is acceptable.
>
> I say "reproducable method" to avoid the "log in to a Debian box and
> do this" that ConnOS has used (for Iceweasel).  Nothing against them,
> but that makes my skin crawl.  I spent several days figuring out how
> to accomplish the same thing on Parabola (hence the awkard dpkg-source
> function formerly included in the PKGBUILD).

A "reproducable method" that can be used on a machine having no software
not provided by Parabola?

>> D. Non-head revisions of their VCS repositories are unsupported and
>> might contain nonfree software.
>
> Again, I agree, but would reword it.
>
>   Non-head revisions of VCS repositories are likely include bugs that
>   have since been fixed; including freedom and policy bugs.
>
>> E. Non-head revisions of their VCS repositories are unsupported and
>> might recommend works not compliant with these guidelines while not
>> including nontrivial nonfree works.
>
> I merged this into the above by adding "and policy".

If one revision has nonfree software (e.g. a patch containing unrar
source to be removed), option D makes cloning abslibre.git distributing
nonfree software, we might want to avoid this.

>> == Sources for all packages are provided by the repo server ==
>> 
>> Having only the PKGBUILD repositories, all binary packages, a source
>> archive downloaded from the server and no network access it should be
>> possible to build practically the same binary package as provided by
>> us.
>
> I'd change this to say that network cannot be required during any
> function defined in the PKGBUILD.  The other parts of it do not affect
> packagers, but are handled by server scripts.

A packager can start a build, manually fix after it fails and continue.
Or use a rePKGBUILD on an Arch-built package.

>> F. == Naming of replacement packages ==
>> 
>> 1. If the exact package name is needed, keep it.
>
> The exact package name is NEVER NEEDED.  When the exact package name
> is significant, this can be satisfied with
>
>     provides+=("old-name=${pkgver}")

It wasn't needed when AIF was used?

>> 3. If there is no "-libre" in the resulting name and the package of
>>    the current upstream is changed for these guidelines, append
>>    "-libre".
>
> No to this.  However based on your examples (gnustep-make), I think
> that you meant the correct thing.
>
> The current undocumented policy is good (but should be documented).
> That policy is:
>
>   If the source is modified significantly enough that the software in
>   the resulting package can be considered a fork of the original
>   software, append "-libre".
>
>   If the source is modified in insubstantial ways, keep the package
>   name as it is, and increment pkgrel by a value smaller than an
>   integer.

I didn't know this policy, seems ok.  Although naming it "a-libre"
implies "a is not libre".

>> 2. If the resulting package cannot be used instead of the original
>>    package, change its name so users will know this and other packages
>>    won't use it.
>
> I think that this is important; a few packages have broken in the past
> because this wasn't done.

It might need listing in F.  This implies not making the new package
provide the old one.

>> Many existing replacement packages have different names, they should
>> not be changed just for this rule.
>
> I'd change this to "they do not need to be immediatly changed"; the
> next time the package is updated, I think it does need to be changed.

Ok, then it should provide the old -libre package.

>> Blacklist of source packages
>> ============================
>> 
>> The aim is to rewrite blacklist.txt to list source packages and have the
>> binary packages to remove automatically found by dbscripts.
>
> I'm with you, but writing policy to software that doesn't exist yet is
> not OK (though it is something I am often tempted to do as well).

It's not a part of the policy, I wrote it in the same mail since this
policy will make blacklisting binary packages usually imply blacklisting
their sources.
-------------- 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/8d2d4069/attachment.sig>