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

non-free and users?

One of the fundamental arguments for getting rid of non-free is that it
makes the social contract simpler.  But this isn't enough justification
alone, because while simplicity isn't a virtue, point 4 of the social
contract makes clear that simplicity isn't our highest priority.

But then there's the claim that non-free hurts users, and that by
providing non-free we are hurting users.  A compelling argument, if true.

One aspect of that argument, and one I think has weight, is that a
user might not be aware of when they're using non-free software, or
why it is bad.  So let's consider an attempt to address this aspect,
taking "non-free hurts users" as a literal fact.  For example, let's
consider a policy change which adds a caution statement to non-free
package descriptions:

   Warning: this software does not satisfy all of Debian's Free Software
   Guidelines, and installing this package will hurt you.

Is this a valid warning?  Well, "non-free hurts users" doesn't necessarily
mean that it hurts all users, so maybe "will hurt" should be changed to
"may hurt".

But a bigger problem is that a user reading this is going to go "huh?"
Maybe some users will take the statement as fact, without understanding
why, but many users would want to know "How is this package going to
hurt me?"

So, maybe a better statement would be:

   Warning: this software does not satisfy all of Debian's Free Software
   Guidelines.  There are limitations on copying and distributing this
   software which may interfere with your future activities.

And I think that that statement has enough truth to it that even if we
retain non-free [for example, if my proposal wins on the upcoming ballot],
we should seriously consider updating policy to incorporate something
like it in all package descriptions in non-free.  [And, for contrib,
something similar but about "the software which must be installed to
properly use this software" instead of simply "this software".]

But, value statements are best judged locally -- it's really up to
the user to decide whether the potential harm from a non-DFSG license
outweighs whatever other issues the user is dealing with.

So the real question should be "does non-free harm users more than it
helps them?"  And the real answer should come from the users.

Some of the recent posts about popcon seem to be addressed at exactly this
point: finding out what users have decided in the context of non-free.
Unfortunately, there are a few problems with those numbers, including:

[a] sample
[b] what popcon measures, within that sample

In particular, we've never indicated to users who do need non-free that
popcon results will be used to remove the packages they use.  I think
that if we are actually going to use popcon's results in this fashion
we should give them fair warning and a chance to enable popcon.  [Yes,
we'll still have a self-selected sample.  However, that sample would by
definition include a significant number of the people who cared about
some non-free package.]  Perhaps non-free packages should have something
in postinst which let's people who don't have popcon enabled know that
the package may be removed from debian if we don't get an indication
that people need it.

Also, there are a number of uses of a package which popcon is not
capable of measuring.  This is even a more serious problem than the
sampling issue.  I'm not sure how to address this.

Make no mistake -- we are, right now, capable of removing packages
from non-free.  We do this all the time for a variety of reasons.

The proposal to remove non-free, however, isn't about our traditional
reasons for removing packages.  Instead, I believe the proposal is about
removing all non-free packages, regardless of there merits.  Embedded in
this discussion, however, are a number of sub-threads which do address
the merits of those packages -- and those discussions can be relevant,
regardless of the surrounding context.

Finally, note that there are a number of variations on this theme which
I've not addressed.  But this message has gotten long enough.



Reply to: