I am reporting this bug because Stefano Zacchiroli has called for a
"free-ness assessment" [2].  It is up to the package maintainer on how to
proceed.

*Summary:* Package
debian-reference<http://packages.trisquel.info/source/brigantia/debian-reference>advises
the user that non-free software is a solution to problems.

*Versions Used:*

   - Operating System: Trisquel 5.5
   - Package: debian-reference
(2.46)<http://packages.trisquel.info/brigantia/debian-reference>

*Steps to reproduce:*

(From the terminal)

   - sudo apt-get install debian-reference
   - debian-reference

(Program opens documentation in browser)

   - Click: HTML (multi files)
   - Click: 9.7.8. Non-free hardware drivers

(Documentation states:)

   - "Although most of hardware drivers are available as free software and
   as a part of the Debian system, you may need to load some non-free external
   drivers to support some hardwares, such as Winmodem, on your system."
   - ect.

*References:*

   - [1] List of software that does not respect the Free System
   Distribution Guidelines: debian-reference
   <http://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines#debian-reference>
   - [2] http://lists.debian.org/debian-project/2012/07/msg00016.html

Hi,

This bug report was unclear and very confusing for me at first ...  But
I think he is the one confused or misguided, now.  I am CCing project
and zak since they seems to be the source of his argument.

If the bug reporter wishes to kill everything about non-free from Debian
related documents and archive area, I can tell him to go to the source
:-) "Debian policy" (Sure this is in our "main" area which is the real
Debian system)

 2.2.3 The non-free archive area
http://www.debian.org/doc/debian-policy/ch-archive.html#s-non-free

If the bug reporter can convince Debian folks in debian-project to agree
to remove these writings on non-free in our policy and make Debian not
to have non-free area, I will reconsider this bug report.

I know FSF always wants to remove any trace from Debian associated
activities.  But this fine line of making "Debian" to mean "main" area
is a compromise we established in Debian.

So you are making me feel I am doing something DPL does not approve...
But I can not find which specific comment of Zak provides such rationale
for this strange bug report.  Please state it clearly.  Otherwise, I
will close this bug report very soon.

What is this Trisquel OS?  This seems derivative distribution.  I
maintain Debian so bug-ness should be based on Debian policy.
I see no problem with Debian policy.
  ^^^^^ OLD!
http://packages.qa.debian.org/d/debian-reference.html
  The latest version is 2.48

Usually, we expect bug report to the latest version.  Things has moved.

  9.7.6. Non-free hardware drivers
http://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_non_free_hardware_drivers

So what is the problem of debian-reference as Debian package.  I only
suggested possibility which is fact in written text.

Please understand the following are my understanding of handling
non-free packages.

 * RECOMMENDING/DEPENDING non-free package in the package dependency
   field is No according to Debian policy.
 * SUGGESTING non-free package in package dependency field is very
   much accepted.  (You may not like this but this has been so defined
   in Debian policy.)
 * MENTIONING fact on non-free package in the above context is never a
   problem.  Please pay extra attention to "may" in my text.  I
   carefully chose this "may" with reason.  I am not saying it is
   required nor recommended.  But we have fact on non-free driver HW
   which we need to live with.  Hiding fact will not make our life
   better or more free.  I do not think interfering with the FREEDOM of
   knowledge is good idea.  FSF which I supports is not such organization.

Please note our policy goes as follows:

 2.2.1 The main archive area
http://www.debian.org/doc/debian-policy/ch-archive.html#s-main
 * must not require or recommend a package outside of main for compilation
   or execution (thus, the package must not declare a "Pre-Depends",
   "Depends", "Recommends", "Build-Depends", or "Build-Depends-Indep"
   relationship on a non-main package)

You see it does not require not-to-list for "Suggests".  It talks about
non-free area so policy can not put plug on my mouth either.

I think this your summary is sloppy and unfair.  That is your opinion.
Please do not accuse me of things I did not.

Osamu

Hi!

Am 03.09.2012 15:14, schrieb Osamu Aoki:
[..]

Policy is the wrong point to start removing policy. non-free (and
contrib FWIW) are written down in social contract §5, so we would need
to change that first.


Best regards,
  Alexander

Hi,

Darn ... you are right.

After initial rejection feeling, I have a bit constructive message.

This bug report should have been filed as wishlist bug if FSF is seeking
to make a derivative work called trisquel while working with Debian.

Calling to change Debian itself at fundamental points such as social
contract §5 is not practical at this point.

For example, if package build environment has pre-defined and agreed
environment variable such as:

DERIVATIVE=(undefined) # debian build
DERIVATIVE=debian      # debian build
DERIVATIVE=ubuntu      # ubuntu build
DERIVATIVE=trisquel    # trisquel build

Then I can accept patch to skip including some parts of document for
trisquel build.  Even Debian policy document can emmbed such change as
long as document title changed to "trisquel policy" at the same time.

I think this is acceptable wishlist bug to my package.
Of course, I like to get patch for it :-) (Nah.... I can do it as long
as technical scheme is worked out.)

Regards,

Osamu

Hmm, my reading of this is: file the bugs, however, the maintainer still
has the final word on severity and/or status (fix, wontfix, etc.) as per
normal Debian Way (tm).

Kind regards,
Andrei

Andrei,

Thanks for your post too.  That is how I understood Stefano's post.
Hence, why I stated "It is up to the package maintainer on how to
proceed."

Osamu,

Sorry if I made you feel as though you were violating the DPL.  That is
not the intention.  The specific comment which lead to the reporting of
this bug was mentioned by Andrei.  You can find it in the first
paragraph of Zak's email[2] which states:

"I think we should either get Debian in FSF [free-distros list][1], or
document (from our POV) why Debian is not there. I'm looking for Debian
volunteers interested in the topic and willing to participate in a joint
Debian / FSF team that will work toward that goal without prejudices.
The ideal outcome is an agreed upon list of Debian "bugs" that need to
be solved, according to the usual Debian mechanisms, and with no special
treatment due to their "political" origin"

then in the "Next steps" section it states:

"If we want to advance on this topic --- and I think we should, for the
reasons mentioned above --- the needed exercise is to work with the FSF
to review the issues they claim apply to Debian. It will essentially be
a bug triaging exercise. Some of the bugs will be valid, some of them
will be not, and on some there will be disagreement between submitter
and "maintainer"." [Continues on...]

Also as far as what Trisquel is.  Trisquel is a Ubuntu derivative
endorsed by the GNU project, we are downstream of Debian.  We do
sometimes report freedom bugs we find upstream[1] if they apply to
Debian as well.  We will always fix the issue downstream if need be but
we prefer to get it fixed in Debian ideally because then in our opinion
many other distros benefit.

[1]http://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=trisquel&user=trisquel%40trisquel.info
[2]http://lists.debian.org/debian-project/2012/07/msg00016.html

Sorry, also to just clarify the bug and what the issue is.

If Zak wants to get the Debian project endorsed by the GNU project[1]
as of now Debian would have to abide by the Guidelines for Free System
Distributions [2].  This particular package is one such bug that would
threaten that endorsement because in the case of documentation:

"All the documentation in a free system distribution must be released
under an appropriate free license. Additionally, it must take care not
to recommend nonfree software."

So, to clarify.  This is not a bug/wishlist about the package violating
any Debian policy.  It is a bug/wishlist against Stefano's idea to get
Debian endorsed by the GNU project.

[1]http://lists.debian.org/debian-project/2012/07/msg00016.html
[2]https://www.gnu.org/distros/free-system-distribution-guidelines.html

Well, at that point you'd probably need to also change the name of at least
the binary package from debian-policy to $(DERIVATIVE)-policy, or it will
cause confusion to users down the road...

I'd be worried about packages named debian-policy hitting the web with
something that is not the Debian policy inside.

Maybe it is better to tell them to fork and rename debian-policy to
$(DERIVATIVE)-policy?  IMHO, it doesn't make much sense for the derivatives
to go through Debian to update a package with their own policy, anyway.

Hi,

Thanks. maybe I should have read link in detail so it is partially my
fault too.  Excuse me.

I think we need to be clear what stage of action is going on and what
actions are expected in each communication.  Let me go back a bit and
propose a bit slower steps.

I see.  Then all these bugs should be wishlist feature bug to start with.

I for one wishes to have GNU endorsement but before discussing it, we
need to assess gaps between Debian and GNU.  For future filing, please
consider to use something like the following to reduce friction
and use our unstable archive for bug tracking.

As I see this problem, this is one of the issue for "separation".

Does FSF consider to change above text to the following satisfactory?
repeating get FSF approval, I am OK for changing while keeping facts as
is.

But if you think issue still exist since this still give IDEA or
TEMPTATION to use such package for non-FSF purist, I will not do this
change nor hide existence of non-free packages.  (Seeing you listed APT
as non-free makes me worry.)

I wonder why GNU distribute many packages supporting and encouraging the
use of NON FREE Operating system such as Windows and proprietary Unix if
FSF takes such an hard line position.  At least, we have no more reason
to promote use of commercial UNIX.  (I for one think current support is
OK, though.  My problem is inconsistent stance.)  Fairly good portion of
code in autoconf.automake is support for old commercial UNIX which I see
no reason to give OS exception rationale.

I will appreciate to lower bar for qualifying endorsement which is par
with FSF's stance on handling of commercial UNIX.

Oh wait, as I see bug list:
http://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
(This list is somewhat confusing since these may not be packaged for
Debian or Debian may have newer package.)

But this lists package with artistic license.  OMG.  Well I know
Artistic license was problematic for but ...  Does Libreoffice in
unstable/testing still as problematic as killer factor?

I wonder if FSF takes such a hard stance on each small problem, why FSF
is not listing MONO related packages such as tomboy banshee ... which
FSF hates with reason as I understand.

I also wonder having GFDLed gcc documentation etc. with invariant
section in non-free OK for FSF.  This non-free is not the part of
official Debian distribution.

Osamu

1) Thank you for the tips regarding the Debian community.  I am new so
please excuse any faux pas I make.  I will surely preface any bug
reports with what you mentioned.

2) I can't speak on behalf of the FSF as I am an associate member (I
contribute financially) but am not an employee or spokesman so I can't
comment for them.  I personally don't think that change would be
sufficient but that is just my personal opinion.  What you mention is
actually the subject of discussion of this mailing list
(https://lists.alioth.debian.org/mailman/listinfo/fsf-collab-discuss).
We are currently waiting on John Sullivan to make an official statement.

3) (Small note - offtopic).  We don't consider apt to be non-free.  If
you are referring to this
(http://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines#apt).
 The issue isn't if the software is free or not it is that a file shows
users how to enable non-free repos which doesn't meet endorsement
criteria for a free system.  Telling a user how to install non-free
software does not make the program itself non-free.  Simple modification
(removal of instructions to use non-free repos) of this file would allow
it to fall within endorsement criteria

4) As far as the other things you mentioned.  The artistic (1.0) license
is a difference between debian and GNU project.  GNU project considers
it to be non-free while debian doesn't.  The opposite thing is true with
the documentation licenses.  GFDL is considered free by the GNU project
while non-free by Debian.  So if Debian decides to exclude that
documentation that is NOT a problem.  That is being discussed on the
fsf-collab mailing list I linked in section (2).  As far as the problem
with mono, my understanding is that is a patent problem not a freedom
issue.  That topic is covered in the free system guidelines link I
linked previously.  Basically a distro can include them or they can
exclude them, it is up to the distro.  Same thing with the documentation
licenses.  Lastly, I am unaware of the issue you raise with LibreOffice
so I can't really comment.

4) I will mark this bug as wishlist as you instructed.

[...]
[...]

There is another problem with the abovetext - it mixes up non-free
drivers and firmware.  I realise they're both software and we would like
them both to be free software; that's not what I'm arguing.  My point is
that it may lead users to confuse drivers and firmware (which leads to
misfiled bug reports, etc.).

The specific references to NDISWrapper and Winmodem also seem rather
outdated now.

Ben.

Hi,

Are you suggesting for me to replace
 s/hardware drivers/drivers and firmwares of peripheral devices/
 s/external drivers/external drivers and firmwares/

My text may have been a bit sloppy but my intent was to use "hardware
driver" in the broader sense including firmware loading driver code and
its data (i.e., firmware).  I understand in stricter sense, these words
are used as:

 * driver:  code running on the target architecture.
            binary windows XP driver following NDIS is non-free driver
            binary GPU driver offered as kernel module is non-free driver

 * firmware: code or data loaded on the peripheral device
             (These could be rendering code running on GPU,
             or FPGA/PLD netlist data, ...)

I understand that the current official Debian position is all these are
non-free if they do not come with the SOURCE.  (I personally think
requiring the source for FPGA/PLD netlist data is a bit awkward but I am not
here to argue for this point.)

Outdated in what sense.  I understand recent focus of NON-FREE driver is
GPU.  My understanding of GPU driver is:

* Intel GPU (including ones coming in the same chip as CPU):
  FREE driver supported by the vender
* ATI(AMD) and NVIDIA GPU:
  NON-FREE driver supported by the vender
  FREE driver (Tends to be less featureful than NON-FREE driver)

Or outdated because NDIS and Winmodem situation has changed?
I understand recent free atheros drivers are very good shape making
NDISwrapper is not needed for most popular hardwares.  That is true for my
case but I wrote this before such time and I was not sure if it is true
for others having different hardware.  For modem, I never bought
Winmodem nor I use POTS MODEM these days.  So this is carried over for
last 5-8 years.

Regards,

Osamu

Something like that.  Only, 'firmware' is a mass noun, which means it
doesn't have a plural form - you just say 'firmware', not 'firmwares',
no matter how much of it you are talking about.

Right.

Right.

The free driver for AMD GPUs (radeon) also needs to load non-free
firmware.

Both, really - firstly I think NDISwrapper and soft-modem drivers are
not commonly needed, and secondly the non-free GPU drivers are more
widely used (but less important, as there are free alternatives
available).

[...]

It seems that many PCs still come with POTS modems (all my laptops have
had them) and I imagine they would need a non-free soft-modem driver -
if I ever needed to use them.

But I suppose POTS modems are still widely used in some rural areas.

Ben.

Let me join the "I'm sorry club" :-) --- I'm sorry for the long delay in
replying to this.

It looks like you've already narrowed down the purpose of this kind of
bug, but let me clarify that I did not call for any kind of mass bug
filing (MBF). In fact, we have discuss this point on the
fsf-collab-discuss list on Alioth and recommended to discuss MBF there
before proceeding.

At the same time, this kind of bug reports predates the creation of the
collaboration group, and rightly so. Derivatives distributions such as
gNewSense have since quite a while started reporting similar bug reports
to Debian packages, (user)tagging them appropriately so that they're
easy to find a posteriori.  I don't think that each of those bug reports
needs a project-wide discussion, most of those bugs are fully within the
realm of individual maintainer decisions. Some will be different, for
sure, but I don't think that will be case for all of them. Let's look at
the specifics.

In this case, I think the discussion that needs to happen with Osamu, as
package maintainer, is on if and how non-free should be mentioned in the
developer-reference. That non-free is *hosted* on Debian servers is a
fact, as it is a fact that the Social Contract declares non-free (and
contrib) as not being part of Debian.  Considering the two aspects
together, I think the debian-reference can mention non-free, but should
take good care of clarifying the risks that the users take in picking
software from there (lack of freedom and, more practically, lack of
support from Debian, as we can't support stuff for which we don't have
the source code properly). Osamu: would you agree with that?

Grant: would that be enough to fix the "issue", in LibrePlanet's view?

If you don't, I would understand. But in that case please leave this bug
open and tag it as "wontfix", as the purpose of the bug reporting
exercise is to document this kind of issues and their current state in
Debian.

Many thanks in advance for your work,
Cheers.

Hi,

Thanks for your comment Stefano.  (I have made further efforts as below.)
  ^^^debian-reference

Yes.  I also re-thought about the whole thing again.  One of the problem
was that the section title had "non-free hardware ...".  This made the
tone and impression quite skewed.  Of course, my initial intent was
helping people looking for non-free firmware etc.  But I did not wish to
encourage non-free software.

Basically, I added new section in package management section:

 2.1.5. Debian is 100% free
http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_is_100_free
 (I included some of your comments there. SC4 and sc5 quoted there to be
  sure.  I also mention GFDL+invariant being non-free there.  I tried to
  avoid any critical comment to the position taken by GNU on
  GFDL+invariant.  I merely mention it so people will not miss it if they
  wish.  I once wrote reference to GNU's free guideline and stated they
  are essentially the same except the scope of software.  But I decided to
  mention scope of software just being wide foe Debian with the new
  update made now.)

Also rewrote old problematic "non-free hardware..." section title to:

 9.7.6. Hardware drivers and firmware
http://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_hardware_drivers_and_firmware
 (New content after Ben Hutchings's comment and additional checks.)

Please read them after next update cycle within few hours or so since I
added some changes.  If you have suggestion, let me know.

I hope this new tone of text makes it easier for both sides.  If this is
not good enough, I seek better text first.  So, more like "moreinfo"
first.

Regards,

Osamu

[…]

Many thanks for your work, Osamu! I went through the new text and I
agree that it implements the ideas we discussed in this bug report. As I
minor communication nitpick, I'd personally just add a couple more
things to the "100% free" pages: 1/ that we _recommend_ running only
free software from main (right now there is an _explanation_ of the
drawbacks of using contrib/non-free, which should be convincing enough,
but an explicit recommendation wouldn't hurt either), and 2/ that by
default only software from main is installed to respect user freedoms.

But as I said, that's only a minor nitpick.
Beside that, I think this is great progress, thanks!

Hi,
...

Good point.  Why start with excuses when we can start with more positive
statements.  Inspired by your comment, I expanded a bit as ...

----
2.1.5. Debian is 100% free software

Debian is 100% free software because of the followings:

  ● Debian installs only free software by default to respect user freedoms.
  ● Debian provides only free software in main.
  ● Debian recommends running only free software from main.
  ● No packages in main depend nor recommend packages in non-free nor contrib.
----

This should show up in few hours to the web.  Japanese translation finished.

Thanks.

Osamu

Ok, I will preface this by saying I do NOT speak for the FSF.  However,
in my personal opinion the new documentation does in fact clarify the
position of Debian but I don't think it does enough to fix the "issue"
from LibrePlanet's view.  Here are a couple examples of why I think that:

1) The new section 2.1.5 under the part about "Works that do not meet
our free software standards" states "Thus, although non-free works are
not a part of Debian, we support their use and provide infrastructure
for non-free packages (such as our bug tracking system and mailing
lists)."

2) Section 2.7.1 titled "How to pick Debian packages" states you should
pick your package based on "Component: main > contrib > non-free "

3) The documentation shows how to use these repositories.

Now if you look at the GNU GFSD (endorsement criteria) in the
Documentation section it states:

1) Additionally, it must take care not to recommend nonfree software.

2) What would be unacceptable is for the documentation to give people
instructions for installing a nonfree program on the system, or mention
conveniences they might gain by doing so.

I think these two situations conflict.  I think by saying "we support
their use and provide infrastructure for non-free packages" and stating
that when picking debian packages a non-free package is ok if something
in main or contrib is not available/good enough would violate the
documentation criteria from the GNU project.

I would do what you ask any leave this bug open and tag it as "wontfix"
but I'm not that skilled with the Debian bug tracker.  I know how to
mark it wontfix but I'm not sure how to leave it "open" at the same
time.  Sorry, Osamu maybe you could help out with that.  Thank you for
your time everyone.

Hi Grant, thanks again for following up and for acknowledging
progress. I agree that what you point out *might* be problematic, but I
think at this point we'd really need some sort of authoritative answer
to solve the "FSF-approved" part. In the meantime, I'm happy that we've
improved things no matter what, which is part of the beneficial
side-effects I was hoping to obtain with bug reports like this one.

Let me just drill-down a bit more in your analysis:
arguably different than recommending. In fact, with the new text by
Osamu we now recommend *against* using contrib/non-free and motivate
that recommendation.

This point might still be in cause, you're right. I guess we might go
down a bit more on this, but the barrier between mentioning that
contrib/non-free exist (that is somehow a direct consequence of the
Debian Constitution, IMHO) and "giving instructions" on how to install
software from there is very blurry in my opinion.  If someone has
wording suggestions on how to fix this, they're more than welcome.

Cheers.

Hi,

Excuse me sending a message without message.  Here is my good one.

The current text location for what we discussed has changed a bit.

http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_is_100_free_software
http://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_hardware_drivers_and_firmware

These link each other.

I just commited minor fix found by translator which should be available
in 6hours for Ch09.

Best regards,

Osamu

Hi,

Thanks for clarification.

It came to my attention since GNU folks reminded me of non-free issues
recently with #686481 which prompted me to think about this.
http://bugs.debian.org/686481

I record this fact by forwarding this there from debian-devel@l.d.o.

FYI: I once got a RC bug report for listing non-free package in
recommends several releases back.  Since non-free GFDL packages have
been dealt for good long time, I think, by now, no recommend dependency
to non-free package exists in our archive.   So I think it is purely
cosmetic issue of rc_policy.txt file.  Our archive should be no-problem
:-)

Osamu

I checked if there are any package in main depending on non-free/contrib

# Check first choice of | only
$ ./dep1.py |sort
RC: Package capi4hylafax recommends on isdnactivecards in contrib
RN: Package flexbackup recommends on afio in non-free

I filed serious bug report to them.  Should be resolved soon.

# Check any choice of |
$ ./dep2.py |sort
DC: Package conky depends on conky-all in contrib
DC: Package libphp-jpgraph depends on ttf-mscorefonts-installer in contrib
DN: Package clam-networkeditor depends on fglrx-glx in non-free
DN: Package fuse-emulator-common depends on spectrum-roms in non-free
DN: Package glchess depends on crafty in non-free
DN: Package globs depends on fglrx-glx in non-free
DN: Package libclam-qtmonitors1.4 depends on fglrx-glx in non-free
DN: Package libglw1-mesa-dev depends on libmotif-dev in non-free
DN: Package ocrfeeder depends on cuneiform in non-free
DN: Package rt4-apache2 depends on libapache2-mod-fastcgi in non-free
DN: Package xmhtml1-dev depends on libmotif-dev in non-free
DN: Package yagf depends on cuneiform in non-free

RC: Package capi4hylafax recommends on isdnactivecards in contrib
RC: Package libreoffice recommends on ttf-mscorefonts-installer in contrib
RC: Package vavoom recommends on game-data-packager in contrib
RN: Package flexbackup recommends on afio in non-free
RN: Package gscan2pdf recommends on cuneiform in non-free
RN: Package yatex recommends on ptex-jtex in non-free

Although not popular, 16 more packages having week but
depends/recommends dependency.  Hmmm....

Anyway, I keep this info here as reminder.

Osamu

PS: Anyway, arttached quick scripts were handy.  (Need to make this
cleaner.)

control: tags 686481 + moreinfo

For the moment, we did all we can by uploading 2.50 (now in stable).  So
if original bug reporter agree, I can close this.

But as I see this discussion, it is inconclusive. I need to wait for the
outcome at:
http://lists.alioth.debian.org/pipermail/fsf-collab-discuss/

It is a slow process but we need to wait for "moreinfo" there.

Osamu

This is about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686481

I have made major update of debian-reference (DR) in 2012 and 2022 to address
this bug report concerns and non-free-firmware. I realized this old bug is still
around for my package.  Let me reassess this bug.

The title of this bug by "SirGrant" is misleading at least for the current DR.
DR doesn't instruct *instruct* user to install non-free software.  DR only
provides  information on how to install non-free software.

Moreover, current DR explicitly mention in "2.1.6. Debian is 100% free software"
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_is_100_free_software
as:

   Users should be aware of the risks of using packages in the non-free, non-free-
   firmware and contrib areas:

   * lack of freedom for such software packages
   * lack of support from Debian on such software packages (Debian can't 
     support software properly without having access to its source code.)
   * contamination of your 100% free Debian system

So I think I am respectful for people not wishing to get close to non-free.

My message was a bit ambiguous in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686481#20 .

What I meant was I am happy to accept practical path for technical measures on
DR (not Debian Policy) which enable to keep quiet on even mentioning non-free in
DR as an optional build feature for particular distribution.  After 10+ years,
no productive proposal nor discussion has happened on this direction.

Also, in light of Debian CD including non-free-firmware these days, I think that
the level of *mention* in DR is appropriate.  So I can close this bug but for
avoiding future repeat of this discussion, I decided to keep this bug but with
changing this bug tag from moreinfo to wontfix.

Regards,

Osamu

PS: I am CCing people who participated on this bug.  I intentinally excluded
list address.

This is about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686481

I have made major update of debian-reference (DR) in 2012 and 2022 to address
this bug report concerns and non-free-firmware. I realized this old bug is still
around for my package.  Let me reassess this bug.

The title of this bug by "SirGrant" is misleading at least for the current DR.
DR doesn't instruct *instruct* user to install non-free software.  DR only
provides  information on how to install non-free software.

Moreover, current DR explicitly mention in "2.1.6. Debian is 100% free software"
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_is_100_free_software
as:

   Users should be aware of the risks of using packages in the non-free, non-free-
   firmware and contrib areas:

   * lack of freedom for such software packages
   * lack of support from Debian on such software packages (Debian can't 
     support software properly without having access to its source code.)
   * contamination of your 100% free Debian system

So I think I am respectful for people not wishing to get close to non-free.

My message was a bit ambiguous in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686481#20 .

What I meant was I am happy to accept practical path for technical measures on
DR (not Debian Policy) which enable to keep quiet on even mentioning non-free in
DR as an optional build feature for particular distribution.  After 10+ years,
no productive proposal nor discussion has happened on this direction.

Also, in light of Debian CD including non-free-firmware these days, I think that
the level of *mention* in DR is appropriate.  So I can close this bug but for
avoiding future repeat of this discussion, I decided to keep this bug but with
changing this bug tag from moreinfo to wontfix.

Regards,

Osamu

PS: I am CCing people who participated on this bug.  I intentinally excluded
list address.