Re: Automatic downloading of non-free software by stuff in main

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Re: Automatic downloading of non-free software by 
stuff in main"):
> Le jeudi, 30 novembre 2017, 18.54:32 h CET Ian Jackson a écrit :
> > [1] The GR would require a 2:3 supermajority because the TC abandoned
> > my efforts to reform the bugs in its constitutional foundations, when
> > I left the TC.
> 
> These don't need to be carried by the TC. It's "nice" if the TC kept in the 
> loop though. 

I don't think it would really be a good idea for me to be the one
driving changes to the TC's constitutional status, even if those
changes are bugfixes.  I think it would be a bad idea for the 2:3 GR
supermajority abolition to be done other than with explicit TC
approval.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Automatic downloading of non-free software by stuff in main

[Didier 'OdyX' Raboud]

Le jeudi, 30 novembre 2017, 18.54:32 h CET Ian Jackson a écrit :
> [1] The GR would require a 2:3 supermajority because the TC abandoned
> my efforts to reform the bugs in its constitutional foundations, when
> I left the TC.

These don't need to be carried by the TC. It's "nice" if the TC kept in the 
loop though. 

OdyX

Re: Automatic downloading of non-free software by stuff in main

[Simon McVittie]

On Tue, 05 Dec 2017 at 14:50:00 +, Ian Jackson wrote:
> I appreciate that the configuration I am describing is quite fierce.
> Many people would hate it.  I wouldn't use it myself.  It shouldn't be
> the default.

Then why are you suggesting that the project should consider using
release-critical bugs to force Debian maintainers to choose between
patching this in, potentially against their upstreams' objections,
or getting the package they wanted to maintain removed from Debian?
That seems rather heavy-handed for a feature that you don't even want
to use!

Debian is a volunteer project and we don't/can't force contributors
to do anything; but the closest we come to forcing contributors to do
things is to say "Policy says you must do this, so either do this or
see your work removed from Debian". That is a large club to be wielding,
and if that's the way we're going, we should be careful what we wish for.

I certainly wouldn't want to arrive in a future where Firefox (or
Chromium, or npm, or pip, or Flatpak, or Snap) was removed from Debian
because nobody was willing to maintain a long-term patch to make it filter
addons by our particular view of Freeness - that would be particularly
perverse for the browsers, whose entire purpose is to download arbitrary
data, much of it executable, and very little of it Free.

> But the need for it is demonstrated by the existence of Debian
> derivatives which do a lot of this work.

They are welcome to do so, but I don't think we should demand new work
from Debian maintainers, enforcing it with the threat of removing the
relevant packages, for the benefit of those derivatives. The level of
work we should demand from Debian maintainers is what's necessary to
meet *Debian's* minimum standards, not someone else's.

smcv

Re: Automatic downloading of non-free software by stuff in main

[Ian Jackson]

Anthony DeRobertis writes ("Re: Automatic downloading of non-free software by 
stuff in main"):
> Ok, let's take an example: how should Firefox (or Chromium) behave 
> differently if the free-only flag is set?

The minimum implementation IMO is: the "addons" menu is greyed out, or
simply brings up a dialogue saying that this is disabled because the
Mozilla addons repository contains a mixture of free and non-free code
which is not trivial to filter.

If there are users and developers who want the more sophisticated
filtering option, they should implement it.

> Josh Tripplet's example of language package managers is another good one 
> - I doubt any of those repositories have a "is-this-DFSG-free" field. 
> And they often have search features which return results regardless of 
> license status, and features to follow dependencies (again regardless).

Language-specific package managers whose upstream repositories contain
unflagged non-free software should be disabled, when the user has
asked for a fully-free system.

I appreciate that the configuration I am describing is quite fierce.
Many people would hate it.  I wouldn't use it myself.  It shouldn't be
the default.

But the need for it is demonstrated by the existence of Debian
derivatives which do a lot of this work.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Automatic downloading of non-free software by stuff in main

[Anthony DeRobertis]

On 11/30/2017 12:31 PM, Josh Triplett wrote:


- For the sake of avoiding ambiguity, an interpreter for file formats or
   network protocols that include software, such as scripts, may consider
   the user browsing to a site or opening a file as "user interaction"
   for the purposes of processing the software embedded or referenced by
   that site or file. However, this does not extend to automatically
   downloading or installing separate non-free software to interpret such
   sites or files, such as non-free codecs or plugins; that must still
   require explicit user interaction.


"separate non-free software to interpret such sites or files" is not 
really clear. For example, it's extremely common for web sites to link 
to 3rd party software that greatly extend JavaScript (thankfully, most 
of those are free). That'd seem to be separate software to interpret the 
site. Similarly, there are JavaScript frameworks to extend CSS—or allow 
it to be written in non-CSS and translated to CSS on the fly.


Codecs, even, can be written in JavaScript and automatically downloaded 
(it looks no different than any other JavaScript to the browser); 
JavaScript performance is somewhat of a problem for that use case, but 
now with WebAssembly that problem is going away. You can even compile 
your C/C++ codec to WebAssembly. This isn't a hypothetical — codecs 
written both JavaScript and WebAssembly already exist.

Re: Automatic downloading of non-free software by stuff in main

[Anthony DeRobertis]

On 11/30/2017 08:52 AM, Ian Jackson wrote:

[...] But the overall result is that a user who wants to use Free
software can be steered by Debian into installing and using non-free
software, sometimes unwittingly,

I would like to establish a way to prevent this.


I think the ideal way would be if instead of those programs offering & 
downloading the plugin at runtime, the plugin were instead packaged & 
put in non-free. Then of course if you don't have non-free in your 
sources.list, you won't be offered it. Of course, that's not always 
feasible.


And when it's not, software should let the user know that what he/she is 
about to download is non-free, especially when it's the single-plugin 
case like Clementine. Worst case, that's carrying a string-changing 
patch, but probably upstream won't object to that change.


This seems to get us 90%: it's true that software might still point you 
to non-free stuff, but you'll be warned it's non-free (and/or have opted 
in by putting non-free in your sources.list).



I think the necessary new central technical component is a
configuration somewhere, checked by programs with plugin download
capability.


For the stated goal, this is oddly narrow. Especially since we've always 
taken the stance that "software" is opposed to "hardware"; it is not a 
synonym of "executable machine code". Just plugins (especially with that 
"does not include sandboxed code" caveat later in your message) prevents 
such a tiny portion of non-free stuff that I struggle to see the point.



Ideally we can come up with a technical solution which means that it
is easy for existing programs implement the new check, so that failure
to do so can be RC for buster.

The minimum required changes to individual packages should be small.


Ok, let's take an example: how should Firefox (or Chromium) behave 
differently if the free-only flag is set?


So one option is that it claims everything is sandboxed (now that 57 has 
gotten rid of the old XUL extensions). So it ignores the flag entirely. 
Even, I believe, binary plugins run in a sandbox (at least on Chromium 
they do—e.g., Flash does).


But let's try taking the flag seriously. At first glance, it'd appear we 
just need to add code to filter addons.mozilla.org results by freeness. 
First problem, the site doesn't have a field for that (which isn't 
surprising), but it does have a license field. So we just need to 
somehow map each license to a freeness status, which will be fun since 
there isn't an official list of DFSG-free licenses and some licenses 
depend on the exact options picked (e.g., invariant sections).


But then, thinking about it, depending on what you mean by plugin, those 
aren't the only ones. For example, the web folks have been (for better 
or worse) working towards making web applications just as functional as 
desktop apps. And they've added things like Service Workers, which can 
run even when the web page isn't open (to provide things like desktop 
notifications). Web apps can even run offline, saving the data to local 
storage, syncing (or not) when the network is available. It's hard to 
see why that isn't a plugin. And there is no way for Firefox to know 
which of those are free.


Josh Tripplet's example of language package managers is another good one 
— I doubt any of those repositories have a "is-this-DFSG-free" field. 
And they often have search features which return results regardless of 
license status, and features to follow dependencies (again regardless).

Re: Automatic downloading of non-free software by stuff in main

[Simon McVittie]

On Thu, 30 Nov 2017 at 09:31:57 -0800, Josh Triplett wrote:
> Ian Jackson wrote:
> > The obvious example is web browsers with extension repositories
> > containing both free and non-free software.

Another example that seems obvious in the context of Debian is libapt
frontends.

Like a web browser with extensions, a libapt frontend will happily
install whatever packages it's pointed at. Some frontends, like apt(1),
do what they're told and give no indication of the freeness or otherwise
of what they're downloading. Other frontends, like aptitude and
GNOME Software, make an attempt to indicate which packages are free and
which are not (aptitude by knowing about the Section field, GNOME Software
by reading AppStream metadata).

I say "make an attempt" because both are dependent on the metadata
provided by their source of packages matching their expectations.
aptitude claims the packages in http://repo.steampowered.com/steam/
are in "The main Debian archive" (I've opened a bug), while GNOME
Software can't say anything about repositories or packages that don't
have AppStream metadata.

I don't think it is or should be considered a bug that libapt frontends
don't ask for confirmation before installing non-free software: they are
just doing what the user asked them to do. IMO policing users' software
choices is not, and should not be, our job.

There is another very common way a web browser can offer to install
non-free software: it can be directed to a website where non-free software
(some of it in native Linux binaries, even) is made available, like
gog.com. That clearly isn't a bug or a lack of freeness in the browser,
and we shouldn't have policies that might be interpreted to imply that
it was.

> - Packages in main may provide a mechanism for the user to download and
>   install other software (e.g. extensions) from a collection of such
>   software. If they do, that mechanism should (note: not "must", and
>   this should not change to become stricter in the future) either
>   require that all software in the collection be Free Software, *or*
>   make it easy for the user to determine the license of the software
>   they're installing.

This is a higher standard than the one we hold libapt frontends to.
Most libapt frontends only tell me whether the software is Free, not
its precise licensing. I think that's reasonable.

smcv

Re: Automatic downloading of non-free software by stuff in main

[Adam Borowski]

On Thu, Nov 30, 2017 at 01:52:18PM +, Ian Jackson wrote:
> Over the years, d-legal has discussed a number of packages which
> automatically download non-free software, under some circumstances.
> 
> The obvious example is web browsers with extension repositories
> containing both free and non-free software.
> 
> We have also recently discussed a media downloader/player which, when
> fed a particular kind of url, will offer to automatically download a
> proprietary binary-only protocol module to access the specified
> proprietary web service.
[...]
> I would like to establish a way to prevent this.  (There are even
> whole Debian derivatives who have as one of their primary goals,
> preventing this.

No, those derivatives are damage.  While their hearts are in the right
place, they cause data loss and security holes by at least making people on
Intel and AMD machines use known-buggy microcode.

Yeah, opaque encrypted microcode can be used to sneak in new backdoors,
but that doesn't make past bugs (and "oh, those foul hackers found one of
our backdoors, it was a honest bug, really!") any better.  At the very
least, you get new TLA-only backdoors while those fixed are usable by both
TLAs and any random punk.

Likewise, closed firmware for your wifi card is evil, but still strictly
better than the same code burned into ROM: you get some bug fixes, and can
go back to a past version.  Sweeping non-free code under the carpet doesn't
help in any way -- if you have to use it, it's better kept where you can
see it.

The biggest reason for me to avoid non-free code is that neither me nor
anyone among us can fix problems.  And those derivatives you're talking
about tend to reintroduce this problem for political reasons (GFDL with
invariants).

Even Debian is not without fault here: for example, the ftpmasters accept
such a blatantly non-free licence as AGPL[1] into main.

> I think the necessary new central technical component is a
> configuration somewhere, checked by programs with plugin download
> capability.
> 
> We should have a conversation about:
> 
>  * What user experience options should ideally be available
>  * How those options should be represented in configuration
>  * Bug severity for programs that do not respect the "only free
>stuff" setting.

I don't think any such extra infrastructure is needed: what we have already
works well, at most it could take some clarification in the Policy.  I
believe the model that's in place for apt is worth adopting for browsers,
media players and such.

That is:
* no new non-free code is ever installed without the user's consent
  ("new" defined at package granulation, allowing splits/etc)
* it's not even proposed unless the software detects that such non-free
  parts are actually needed
* once a piece of non-free code is installed, it should receive updates
  unless explicitly configured otherwise

The last part matters because of recent Chromium issues.  Of course, checks
for updates should be done in a way that minimizes privacy issues (which
Chromium's upstream loves to maximize), but defaulting to no updates at all
is irresponsible.


Meow!

[1]. AGPL fails FSF freedom 0: you can't reuse snippets of code from an
AGPLed project in anything networked that has no, or cumbersome, ways to
pass advertising statements to the user (such as, eg, an IMAP server).
It also fails the Dissident Test: take a blogging software with
steganographic features, that you provide hosting for, for two classes of
users: fellow dissidents, and public at large.  The former receive the code
(both binaries and source), the latter do not.  Even revealing the existence
of your changes is a serious risk for the life of you and your friends.
Regular GPL has no such problems.

You might read my words as a sort of FSF bashing, as both bad licenses are
provided by them (GFDL and AGPL3), but regular GPL is generally much better
than BSD/MIT: it emulates a world without copyright much better, as in such
a world we'd have decompilers, etc.
-- 
< darkling> When all you have is a hammock, every problem looks like a nap.

Re: Automatic downloading of non-free software by stuff in main

[Josh Triplett]

Ian Jackson wrote:
> If there is a core implementation needed (eg a library which parses a
> standard config location or soemthing), I expect to to write it.

I sincerely hope we can avoid needing to develop some new infrastructure
or library here, since any such mechanism would almost certainly involve
a pile of Debian-specific patches to incorporate the use of that.

As an example for what I think we *should* be doing: if there are
package managers packaged in Debian, we should encourage the upstreams
of those package managers to make sure packages have appropriate license
metadata. Or if there are browsers in Debian that download and install
proprietary plugins without prompting the user, we should work with
upstream to get them to stop doing that, and only patch them downstream
if upstream completely rejects even having configuration to avoid that.

Re: Automatic downloading of non-free software by stuff in main

[Josh Triplett]

On Thu, Nov 30, 2017 at 06:54:32PM +, Ian Jackson wrote:
> Josh Triplett writes ("Re: Automatic downloading of non-free software by 
> stuff in main"):
> > - Packages in main must not point the user to specific non-free or
> >   contrib software and recommend its installation,
> 
> I agree with this as a goal for at least some configuration settings.
> I'm basically sympathetic.  But:
> 
> Unfortunately, this statement is inconsistent with the Technical
> Committee decision in #681419.  That is, it cannot be implemented
> without a General Resolution[1], or someone persuading the TC to
> reverse #681419.

I don't believe the decision in that bug in any way prevents this
effort, though it may require more careful phrasing.  That bug refers to
Debian package dependencies; my text above was intended to refer to
other mechanisms, such as prompting the user or otherwise pointing them
to "you should download and isntall this specific third-party non-free
thing".

We could add a sentence, for instance, saying "Providing a non-default
alternative in package dependencies or recommendations, or a Suggests,
is acceptable."  (Which I don't think is unreasonable; that's precisely
the threshold that ensures the user will not automatically install such
software without making an explicit choice to do so.)

> >  Such an opt-in
> 
> I was hoping to get away from questions of default configuration, and
> to do the technical work first.

I'm not trying to talk about default configuration here; I'm trying to
solve a usability issue.  People who have already said "I want to be
able to install non-free software with apt" are presumably also OK with
being asked "you need to download and install this proprietary DRM
plugin to watch Netflix, is that OK?".  I also don't want to *require*
that software pay attention to such system-wide settings either, just
suggest that they may wish to do so for usability.

> I was also hoping to avoid trying to make a long list of political
> demands, which is what your bullet points are.

On the contrary, I was attempting to write text suitable for Policy
(modulo annotations) regarding specific mechanisms of packages in main
to pull in third-party software that may potentially be non-free or
contrib.  None of this is intended to be "political demands", nor is it
intended to be a substantial change to current practice for how we
already handle software in Debian (e.g. people already, today, file
serious bugs for packages in main that attempt to download and install
non-free software; we just don't have a clear and unambiguous written
policy).

Is there something that makes this text not suitable for that purpose?
(Other than the specific issues you've identified in your reply, which
I'd be happy to work to address.)

(Also, I just realized that all the points in my previous mail need to
be prefaced by "for packages in Debian main", since they don't apply to
contrib or non-free.)

> Finally, your set of bullet points doesn't explain to me what the
> "additional distinction" it is you are trying to make.

Sorry, I meant to go back and add a note about that, and forgot to do
so. The additional distinction was between auto-installing such software
without prompting, prompting the user to a *specific* proprietary
program, and simply exposing a collection of software (e.g. Firefox
extensions) only some of which are proprietary. I think we should
prohibit the first, prohibit the second unless the user has opted in,
and allow the third with a recommendation (but not requirement) to make
the individual software licenses clear.

> > - For the sake of avoiding ambiguity, an interpreter for file formats or
> >   network protocols that include software, such as scripts, may consider
> >   the user browsing to a site or opening a file as "user interaction"
> >   for the purposes of processing the software embedded or referenced by
> >   that site or file. However, this does not extend to automatically
> >   downloading or installing separate non-free software to interpret such
> >   sites or files, such as non-free codecs or plugins; that must still
> >   require explicit user interaction.
> 
> Does that mean that a web browser is allowed to execute non-free
> Javascript ?  What about nominally-free Javascript
> (Libre-JS-permitted) which the user doesn't have the practical
> capability to modify because of the way it website JS deployed and
> distributed ?

Yes, and yes.  I wrote this additional point specifically to allow that
case.  People who want to deal with that particular issue are welcome to
install LibreJS or another such extension, which we could even package
in Debian.  Without this specific point added, the previous points
regarding automatically downloading and running non-free software would
necessarily apply to browsers running JavaScript or WebAssembly (or, for
that matter, HTML, CSS, fonts and font hinting instructions, or many
other things that in some way could be considered 

Re: Automatic downloading of non-free software by stuff in main

[Ian Jackson]

Josh Triplett writes ("Re: Automatic downloading of non-free software by stuff 
in main"):
> - Packages in main must not point the user to specific non-free or
>   contrib software and recommend its installation,

I agree with this as a goal for at least some configuration settings.
I'm basically sympathetic.  But:

Unfortunately, this statement is inconsistent with the Technical
Committee decision in #681419.  That is, it cannot be implemented
without a General Resolution[1], or someone persuading the TC to
reverse #681419.

[1] The GR would require a 2:3 supermajority because the TC abandoned
my efforts to reform the bugs in its constitutional foundations, when
I left the TC.

>  Such an opt-in

I was hoping to get away from questions of default configuration, and
to do the technical work first.

I was also hoping to avoid trying to make a long list of political
demands, which is what your bullet points are.

Finally, your set of bullet points doesn't explain to me what the
"additional distinction" it is you are trying to make.

> - For the sake of avoiding ambiguity, an interpreter for file formats or
>   network protocols that include software, such as scripts, may consider
>   the user browsing to a site or opening a file as "user interaction"
>   for the purposes of processing the software embedded or referenced by
>   that site or file. However, this does not extend to automatically
>   downloading or installing separate non-free software to interpret such
>   sites or files, such as non-free codecs or plugins; that must still
>   require explicit user interaction.

Does that mean that a web browser is allowed to execute non-free
Javascript ?  What about nominally-free Javascript
(Libre-JS-permitted) which the user doesn't have the practical
capability to modify because of the way it website JS deployed and
distributed ?

These are questions I would prefer to avoid answering now.


Summary: please help me try to avoid making the best the enemy of
improvement.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Automatic downloading of non-free software by stuff in main

[Andrey Rahmatullin]

On Thu, Nov 30, 2017 at 06:40:46PM +, Ian Jackson wrote:
> > > I would like to establish a way to prevent this. 
> > Why would the project do that, though?
> 
> Because...
> 
> > > We should aim for most of the changes necessary for
> > > such derivatives to be in Debian proper, so the derivative can be
> > > little more than a change to the default configuration.)
> >
> > Why?
> 
> ... we should aim for the above statement to be true for all
> reasonable derivatives.
Why we should aim for the above statement to be true for all reasonable
derivatives?

> > I also hope that you already have people who will do the actual work after
> > the discussions will provide the architecture.
> If there is a core implementation needed (eg a library which parses a
> standard config location or soemthing), I expect to to write it.
Work also includes patching all packages.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Automatic downloading of non-free software by stuff in main

[Ian Jackson]

(dropping the profligacy of lists)

Andrey Rahmatullin writes ("Re: Automatic downloading of non-free software by 
stuff in main"):
> On Thu, Nov 30, 2017 at 01:52:18PM +, Ian Jackson wrote:
> > I would like to establish a way to prevent this. 
> Why would the project do that, though?

Because...

> > We should aim for most of the changes necessary for
> > such derivatives to be in Debian proper, so the derivative can be
> > little more than a change to the default configuration.)
>
> Why?

... we should aim for the above statement to be true for all
reasonable derivatives.

> I also hope that you already have people who will do the actual work after
> the discussions will provide the architecture.

If there is a core implementation needed (eg a library which parses a
standard config location or soemthing), I expect to to write it.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Automatic downloading of non-free software by stuff in main

[Josh Triplett]

Ian Jackson wrote:
> Over the years, d-legal has discussed a number of packages which
> automatically download non-free software, under some circumstances.
> 
> The obvious example is web browsers with extension repositories
> containing both free and non-free software.
> 
> We have also recently discussed a media downloader/player which, when
> fed a particular kind of url, will offer to automatically download a
> proprietary binary-only protocol module to access the specified
> proprietary web service.

Another good example is language package-managers, such as pip, npm, and
cargo.

> We have generally put software like this in main, because it asks the
> user first, and can be used perfectly well without the proprietary
> parts.  But the overall result is that a user who wants to use Free
> software can be steered by Debian into installing and using non-free
> software, sometimes unwittingly,
> 
> I would like to establish a way to prevent this.  (There are even
> whole Debian derivatives who have as one of their primary goals,
> preventing this.  We should aim for most of the changes necessary for
> such derivatives to be in Debian proper, so the derivative can be
> little more than a change to the default configuration.)

I think this makes sense, but there's a further distinction we should
draw that I didn't see in your mail.  Here's roughly what I'd love to
see:

- Packages in main must never automatically download or install non-free
  or contrib software without user interaction. (For instance, if you
  launch a browser and it auto-downloads and installs a proprietary
  plugin in the background, that should be a bug of severity serious.)

- Packages in main must not point the user to specific non-free or
  contrib software and recommend its installation, unless the user has
  previously opted into receiving such recommendations. Such an opt-in
  may be combined with questions regarding Debian's non-free repository.
  (For instance, "you should download and install this specific
  proprietary codec" should be a bug of severity serious. That said, we
  need to find a way to make this requirement not compromise usability
  by requiring the user to manually determine what they need)

- Packages in main may provide a mechanism for the user to download and
  install other software (e.g. extensions) from a collection of such
  software. If they do, that mechanism should (note: not "must", and
  this should not change to become stricter in the future) either
  require that all software in the collection be Free Software, *or*
  make it easy for the user to determine the license of the software
  they're installing.

- Packages should (note: not "must" yet, but we should change this to
  "must" in the future) perform appropriate cryptographic integrity
  verification of downloaded software from an appropriate chain of
  trust, or should obtain such software from packages in the Debian
  repository that already include such verification.

- For the sake of avoiding ambiguity, an interpreter for file formats or
  network protocols that include software, such as scripts, may consider
  the user browsing to a site or opening a file as "user interaction"
  for the purposes of processing the software embedded or referenced by
  that site or file. However, this does not extend to automatically
  downloading or installing separate non-free software to interpret such
  sites or files, such as non-free codecs or plugins; that must still
  require explicit user interaction.


How does that sound?

Re: Automatic downloading of non-free software by stuff in main

[Andrey Rahmatullin]

On Thu, Nov 30, 2017 at 01:52:18PM +, Ian Jackson wrote:
> I would like to establish a way to prevent this. 
Why would the project do that, though?

> (There are even whole Debian derivatives who have as one of their
> primary goals, preventing this.
Good.

> We should aim for most of the changes necessary for
> such derivatives to be in Debian proper, so the derivative can be
> little more than a change to the default configuration.)
Why?

I also hope that you already have people who will do the actual work after
the discussions will provide the architecture.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Automatic downloading of non-free software by stuff in main

[Ian Jackson]

This mail is going to a lot of lists.  I have set the followups to
d-policy because ultimately this is hopefully going to result in a
change to policy.


Over the years, d-legal has discussed a number of packages which
automatically download non-free software, under some circumstances.

The obvious example is web browsers with extension repositories
containing both free and non-free software.

We have also recently discussed a media downloader/player which, when
fed a particular kind of url, will offer to automatically download a
proprietary binary-only protocol module to access the specified
proprietary web service.

We have generally put software like this in main, because it asks the
user first, and can be used perfectly well without the proprietary
parts.  But the overall result is that a user who wants to use Free
software can be steered by Debian into installing and using non-free
software, sometimes unwittingly,

I would like to establish a way to prevent this.  (There are even
whole Debian derivatives who have as one of their primary goals,
preventing this.  We should aim for most of the changes necessary for
such derivatives to be in Debian proper, so the derivative can be
little more than a change to the default configuration.)

I think the necessary new central technical component is a
configuration somewhere, checked by programs with plugin download
capability.

We should have a conversation about:

 * What user experience options should ideally be available
 * How those options should be represented in configuration
 * Bug severity for programs that do not respect the "only free
   stuff" setting.

Ideally we can come up with a technical solution which means that it
is easy for existing programs implement the new check, so that failure
to do so can be RC for buster.

The minimum required changes to individual packages should be small.

NB that this is going to be a _user option_.  I'm not trying to shut
down non-free extension repositories.  (Indeed I sometimes use them.)
I want to give users more control.


Obviously excluded from this discussion are downloader packages, which
have the fetching and use of proprietary things as their primary
purpose, and which therefore live in contrib.


But there is another category I want to distinguish:

Applications for processing Turing-complete file formats.  This
includes web browsers, because of Javascript; but it also includes
PostScript viewers; interactive fiction interpreters; and so on.

The distinction between this and the general plugins I mention above
is that these applications all restrict the capabilities of the code
being executed, by running it in some kind of sandbox or container.
The idea being that the code gets to control the user's interactions
_with the providers of that code_, but not anything else.

There are some people who object to executing any non-free code on
their computer and I don't mind providing a facility for people to
restrict that.  But I don't know exactly how to design such a thing.

For web browsers, there is the FSF's libre-JS.  Personally I think
that is rather quixotic (and doesn't really address the real user
freedom question anyway), but I have no objection if anyone wants to
do the work to integrate that into some kind of freeness control
system.

But with file formats, the situation is much harder.  I don't feel we
can introduce a policy requirement requiring package maintainers to
support users who want this kind of restriction, until we can come up
with a scheme that will actually work and be useable (and indeed, will
be minimal effort for a package maintainer to opt into).

(The question is: how do we stop a Postscript file received by email
being rendered automatically when the user clicks on it, while
allowing the user to still open a Postscript file they generated
themselves ?)


Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.