Re: Formal CFV: General Resolution to Abolish Non-Free
I responded to this on debian-project because it is the appropriate
place to discuss meta-project issues like this, and the debian-devel
thread has degenerated, as debian-devel threads tend to do.
John, I would like to see the removal of non-free software from
Debian, but I think that the resolution you have drafted is
problematic for several reasons. I would not like to have a
resolution going up for vote that I and others who support the removal
of non-free cannot vote in support of. I would not want a precedent
set which would make removing non-free more difficult.
Luckily the project secretary has said he hasn't seen the appropriate
number of signed seconds and does not consider this an officially
accepted resolution. This gives us time to revise this some more.
> 1. That text of Section 5 be modified to read: "We acknowledge that
> some of our users require the use of programs that don't conform to
> the Debian Free Software Guidelines. While we will not distribute
> such software itself, we have created areas in our archive for
> packages that help install or otherwise requre this software. The
> software in these areas is not part of the Debian system, although
> it has been configured for use with Debian." The title of
> Section 5 shall be modified to read: "We will support users of our
> system who develop or run non-free software."
This implies that contrib is staying in an unadulterated form, and that
Debian would still have software that recommends non-free software.
This would mean a considerable number of broken packages on the Debian
archives, where we presently have none (in a theoretical sense). I
think it's important for the Debian archive to be self-contained, and
this would not allow that. I also think that what Debian needs is to
be free of any mention of non-free software, and retaining packages in
contrib which rely upon specific non-free packages, as opposed to
virtual packages like "jdk" or "jvm" or similar things does not
fulfill that requirement.
You might recall RMS participating in a long discussion about this
issue a year or so ago, and by the end we had a pretty good scheme for
accomplishing this. the debian-devel archives would be a good place
to check. The gist of it was to remove contrib and main from the
Debian archive, and to remove any mention of non-free software from
the Debian web pages and any other official documentation. The
handling of contrib and non-free would be done by non-Debian/SPI
resources, tho Debian developers are obviously able to do whatever
they want.
I think that approach, the removal of contrib and non-free, coupled
with some technological advancements (which could mean more code, or
perhaps just some guidelines and informal standards for repository
maintenance and packages) would allow the Debian project itself to be
just Free Software, but provide a mechanism for those who need/want
non-free software to integrate with the Debian system smoothly. In
the process, we would also be making some ground towards
decentralizing the Debian package pool (in the abstract sense, not in
the specific sense of the "package pool" proposal).
As the current resolution stands, I don't think it goes far enough in
removing support/recommendation of non-free software, cuts up the
Debian archive at an awkward point, and does not address the very real
concerns about Debian's ability to integrate other package pools in a
reasonable manner, either from separate Free Software parties, or from
non-free parties.
> B. That the non-free areas be removed from current Debian archives,
> and that all packages so placed there in accordance with the
> definition in Policy section 2.1.4 be removed from the Distribution
> and archives. The introduction into the Debian Distribution or the
> Debian archives of any package meeting the non-free definition in
> Policy section 2.1.4, or failing the Debian Free Software Guidelines,
> shall be forbidden.
I think it's important that the Debian archive, or any other resources
officially associated with Debian, or funded with Debian/SPI dollars
not be used to support or recommend non-free software. It's
particularly important at this juncture when most GNU/Linux systems
have accelerated their integration with non-free software, and/or
directly contribute and promote non-free software from third-parties
at the expense of Free Software alternatives.
However, this should not be taken as a suggestion that Debian isolate
itself from it's user community, or other parties. In fact, I think
that the removal of non-free/contrib from Debian is contingent upon a
solution to the issues of users integrating third party repositories
with Debian proper. I would suggest that this problem be tackled
prior to the formal introduction of a resolution to remove
non-free/contrib from the Debian archives and other Debian resources.
Not only would it allow us to get rid of non-free/contrib, but it
would take Debian to the next level in terms of making the most of the
resources the Internet provides for decentralized collaboration.
I see the issue of pool integration as having the following sticking
points:
1. Inter-archive namespace mgmt and dependency tracking.
2. Identification of package source and other metadata about it's
archive of origin to facilitate the reporting of bugs to the
appropriate source, and managing the set of archives one pulls
packages from.
3. Package signature checks and trust networks for
developers/packagers.
4. Directory services for package archives to facilitate the search
for third party archives.
5. Quality control guided by trust relations and reputation, as well
as lintian checks.
I don't think all of these problems need be "nailed" prior to the
removal of non-free/contrib, but I do think that it would be dishonest
for the project to remove non-free/contrib with addressing these in a
way that would minimize the distress to our users, many of whom have
become very dependent upon Debian's current archive architecture.
--
Craig Brozefsky <craig@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---
Reply to: