Bug#809705: general: let people use non-free software but opt-out of non-open software

[Philippe Cerfon]

On Wed, Jan 6, 2016 at 1:10 PM, Ansgar Burchardt  wrote:
> Then why should one have "non-open" at all?  The argument was that this
> somehow brings some sort of "security" by being able to audit things
> (though the license may probably still forbid you from doing so or
> publishing your results, its non-free after all), but then there are
> "non-open" packages where this doesn't matter anyway...

Huh?
The argument for all this was, that people can easily opt-out of
non-open software if they wish to.
Which the debtags solutions doesn't really achieve.

Auditing the non-open software is anyway not possible, as it's non-open.


> The reason for the "non-free-firmware" component is the admission that
> in many cases non-free firmware is required to correctly use the
> hardware.  While this is not ideal, we want people to be able to use
> Debian on their hardware with the minimum amount of non-free things[1].

Sure, as I've said before, it would be nice to have a
non-open/firmware special case.
And I think firmware is likely really the only special case here, as
often there's no way around it.
So people who want firmware but no other non-open stuff simply add only:
non-open/firmware
People who want both add both:
non-open
non-open/firmware


> I don't think Debian should bother with differentiating between levels
> of non-freeness on the level of components besides this: after all
> Debian is about free software, not the various levels of non-free
> things.  Having them on the level of debtags or similar is way more
> flexible and more likely to suit different uses.

There are no different level of non-freeness involved in my proposal.
The one property is non-free, which means you cannot freely use it,
distribute it whatever.
The other is non-open, which means sources are not available, but they
owner might still fully allow you do use it, distribute it etc..


> Otherwise we end up with "non-free", "non-open", "non-free-data",
> "non-free-documentation", "non-free-firmware", "non-open-firmware",
> "non-open-data" and so on.  Just imaging a sources.list with 10
> different non-free component and only one free component ("main") ;)

No,..not really, why should we? The only reason why there would be a
special case for non-open/firmware is that there is typically no way
around it if you have such hardware.


Sincerely,
Philippe.

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Vincent Lefevre]

On 2016-01-04 23:14:11 +0100, Stefano Zacchiroli wrote:
> On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote:
> > Your second item has been brought up before with different
> > focus/rationale/purpose.  At least I remember there being an interest
> > in splitting "non-free" into "non-free/firmware" vs. various other
> > non-free sub components.
> 
> Another one that is worth mentioning here --- which I discussed in the
> context of non-free.org with Dafydd Harries and others --- is
> introducing a debtags facet to capture the reason why a package is in
> non-free. At least two hierarchies come to mind: 1) which point of DFSG
> is not respected, and 2) which one of the 4 freedoms are not granted.

And could something similar be done for free packages that can
download non-free stuff?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Ansgar Burchardt]

Philippe Cerfon  writes:
> On Mon, Jan 4, 2016 at 8:45 AM, Niels Thykier  wrote:
>> Philippe Cerfon:
>> Your second item has been brought up before with different
>> focus/rationale/purpose.  At least I remember there being an interest in
>> splitting "non-free" into "non-free/firmware" vs. various other non-free
>> sub components.
>
> Well, I think splitting of just the firmware sounds far less appealing.
> Actually in some cases having a non open firmware may not be *that*
> big security issues, e.g. when it's used to be loaded in some external
> device (something like ColorHug) and for many other firmwares there is
> simply no alternative (or e.g. one won't have networking).
> So while it would make of course to split of the non-open firmware
> packages as well, the whole effort seems to rather only make sense if
> really everything non-open is split off.

Then why should one have "non-open" at all?  The argument was that this
somehow brings some sort of "security" by being able to audit things
(though the license may probably still forbid you from doing so or
publishing your results, its non-free after all), but then there are
"non-open" packages where this doesn't matter anyway...

The reason for the "non-free-firmware" component is the admission that
in many cases non-free firmware is required to correctly use the
hardware.  While this is not ideal, we want people to be able to use
Debian on their hardware with the minimum amount of non-free things[1].

I don't think Debian should bother with differentiating between levels
of non-freeness on the level of components besides this: after all
Debian is about free software, not the various levels of non-free
things.  Having them on the level of debtags or similar is way more
flexible and more likely to suit different uses.

Otherwise we end up with "non-free", "non-open", "non-free-data",
"non-free-documentation", "non-free-firmware", "non-open-firmware",
"non-open-data" and so on.  Just imaging a sources.list with 10
different non-free component and only one free component ("main") ;)

Ansgar

  [1] Personally I don't see much of a difference between having such
  non-free blobs supplied by the operating system or having them
  stored in some sort of ROM, though the FSF sees that different.
  This should be unrelated to the decision whether to provide
  non-free-firmware as an extra suite or not.

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Brian May]

Johannes Schauer  writes:

> I am talking about adding the metadata about which license code is released
> under and/or which DFSG freedoms it violates as proposed by Stefano in a
> machine readable way: either debtags or DEP-5 and make either or both of them
> understood by apt pinning so that I can tell my system which software to allow
> and which to not allow.

It might be worth looking at what FDroid have done with there
antifeatures metainformation:

https://f-droid.org/manual/fdroid.html#AntiFeatures
-- 
Brian May 

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Philippe Cerfon]

Stefano Zacchiroli wrote:
>Another one that is worth mentioning here --- which I discussed in
> the
> context of non-free.org with Dafydd Harries and others --- is
> introducing a debtags facet to capture the reason why a package is in
> non-free.

I'd still say that solving that via debtags isn't actually solving the
issue (which doesn't mean that it would be nice to have it in Debtags
as well).
I guess not all software which is in Debian an makes use of apt repos
understands debtags, so until that is fixed (which easily takes
forever as new packages that do business with apt repos arrive), there
would be still "holes" through which non-open software could hit a
system.

And, as said before, it's far easier to accidentally forget setting
the "this is closed source" debtag, than to move it to the wrong
suite, the later would probably at least be checked by the
ftp-masters, right?

And even *if* it would work out, that all closed-source packages have
the right debtag set and no apt package installs them, these packages
would still show up, in package listings, perhaps when doing apt-get
source and so on.


Johannes Schauer wrote:
> Also, can the reason why something is in non-free not be captured by
> increased
> and a more structured use of DEP-5 (machine-readable
> debian/copyright)?
>
> Certainly I'd welcome support of apt for both: debtags *and* licenses
> in
> debian/copyright :)
>
> My own motivation to have better control over non-free is my package
> ldraw-parts which is released under the "Creative Commons Attribution
> Licence
> version 2.0" and thus non-free. I can imagine that more people than
> just me
> would find that license acceptable enough.

That sounds perhaps more like something for debtags, but this also
doesn't have the security motivation as my proposal.
You're package is likely less "worse" than non-free, while what I'd
consider for "non-open" is "worse" than "non-free" (it's not even
open).


I'm not a Debian developer, does anyone here know or has some
estimate, on what it would actually take in terms of effort to add
another suite like the "non-open" (or "closed-source") I had proposed
in the beginning?
Are there any technical, organisational or other arguments against it?
At least to me, though my knowledge may be too limited, it seemed like
a proper solution to be able to have closed-source software in Debian
repos in general, but also to be able to *completely* shut them out.
And that seemed quite appealing, at least more than the debtags based
approach.

Thanks and best wishes,
Philippe.

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote:
> Philippe Cerfon:
> > On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER  
> > wrote:
> >> Discussing infrastructure changes like what you're proposing (which I
> >> have no advice about) should usually be done through our mailing
> >> lists,
> > Which one would be the appropriate list?

debian-project, or hopefully debian-devel.  -project for talking about the
idea, -devel for discussing an implementation.  Having an implementation ready
hugely improves chances of it being done.  But of course probing the community
to see if there are any protests (as you are doing now) is a good idea.

> Your second item has been brought up before with different
> focus/rationale/purpose.  At least I remember there being an interest in
> splitting "non-free" into "non-free/firmware" vs. various other non-free
> sub components.
> 
> Mind you, its primary goal was not to address "source vs. no-source",
> but it is the closest related idea I could think of.  Sadly, I don't
> have a reference ready to backup my memory.

Yes; I think the conclusion of that discussion was two things:
1. Different people want different splits.  Using something like debtags may be
   more useful, so users can block their own tag selection.
2. The firmware category is special in that pretty much everyone needs it, so
   we may want to make that its own section the old way.  This allows people to
   use their hardware without enabling any (other) non-free sections and
   without worrying about debtags filters (once implemented).

Note that it was just my impression that there was consensus on this; I may be
mistaken.

Note also that nothing has happened (AFAIK) since that discussion.  Someone
implementing things would be very welcome as far as I'm concerned.

> On your first item, I would have to agree with Christian.  It is not
> actionable and much less by Debian.  At best we could stop packaging
> such software or disabling such features, but both have their disadvantages:
> 
>  * Even if we stop shipping them, people will still download them.
>Except your average user will probably be worse off because most of
>them do not verify their downloads.

I agree that not shipping things (that we are allowed to ship) is a bad idea
most of the time (except if it's because nobody considers it a priority; giving
upstream an incentive to release their software under a free license is good).
The exception is software that actively hurts the user (malware, spyware).
Which we can only block if we know about it, of course.

>  * If we disable the functionality, we would "cripple" the software to
>many people.  If this annoys people, we will end up in a situation
>where people will advise /against/ using the Debian package because
>it is "crippled", which leads to the situation above.  Or we could
>get badly unpopular with upstream (see the "Debian vs. Ruby" issue
>from a couple of years ago).

This is a valid concern, but it shouldn't always be the deciding factor.  Many
people (including me) use Debian because it easily allows installing a 100%
free system with a huge choice of packages.  If the choice is "move a thing to
non-free, or keep it in main and disable the functionality", those people will
lose the software completely if it's moved to non-free.

Disabling functionality is work, and when it's done, it's done for this group.
It leads to "crippled" packages and the complaints you mention, but the
alternative is moving it to non-free, which leads to the software missing from
Debian main entirely.  Either option may be better, depending on the situation.
Perhaps it's best to do both, like unrar does (AFAIK): package a "crippled"
version in main, and the original version in non-free.  But this is even more
work, and the maintainer has to decide if it's worth their time.

Personally, I don't care much for non-free, so I would choose between disabling
the functionality and not packaging the software at all.  But that doesn't mean
everyone has to work that way; if others want to spend their time on non-free
packages, I'm not stopping them.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWijfHAAoJEJzRfVgHwHE6J7gP/izcwZPCJ9YvtpDf9FNtDKmA
7Vop3e1wZD2h7G93FY/YvQkufkFQhW9KJp3cIZ2UkCDq6EBt5Of6xtoDEtSWmedV
Hi4djop7nIXJxFnzB2/5wMYVLa+DIeRUUhtR8/HkQu2/GCbf1SIbOH3ZjH2SW0Kj
BozkqzyQQkFv7t/GK9y34goW6l4oc0CF+vINlRV+iV886C0166Kim1rOBWM8Ctfq
JrP9JcfwVBFIVzznK2+6E4/0bCLT1AeRORyfpwIW/QI0+3wmjoECdmA2PRrtTxgD
vy1ZNEfAY+BxYIo4XJsSQpE4VTgtYMmnYDuP4IWx9NUlYKVA3jWwjdn4FSim5fRl
BqWk9tdY4zmM62WGkqLexwSgeyx2Ozh+zh9Cf4TIVRK5OXmUK3E2VUCA9CvE87pw
Dayw3F7ZJX0N5Tpal55DDcBEVHOFFmLgfqHHy80HEM1rgQnwbQE9Z0CrRckhDjIK
jQkCaZynCSknB/5iG7eL1U4UiLySmrxNYqCbuU7T5gEY6SABghwCdcFyCwtRttXC
Q/4H5bXDw7E/PszsSvaUDe39NsDS9xBDbpgSZ/OhylkhimhwUhtixWaNBCDzC9Tw
SLgQaW8TYrAClRzKM+JRBSJM8hTX1R3+CsnS1wVy3em6BRohFO/I8uq+kZZ5007S

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Mehdi Dogguy]

On 2016-01-03 07:35, Christian PERRIER wrote:

Quoting Philippe Cerfon (philc...@gmail.com):

Package: general
Severity: wishlist
Tags: security

Hi.

I think Debian has the following two problems (or rather its security
conscious users) with respect to software that gets into the system:



No idea whether what you're proposing is relevant or notbut
there's something I'm deeply sure of : that won't be solved through a
"general" bug report.

Such vague bug reports are usually either quickly closedor just
ignored by everybody in the project.



Well, the messages sent to this bugreport land in debian-devel, which
looks appropriate for this kind of discussions, IMHO. Be it a bugreport
or a simple message sent to the list, it doesn't look very different.

Once discussion happens and we have a clear idea on what is needed to
do, we will be able to describe a concrete plan or, aternatively, close
the bugreport because nothing is needed to do. The concrete plan could
be several bugreports files where appropriate, blocking this one.

We do already track discussions in bugreports (Tech-ctte issues for
example), even if the initial request might be very vague or quite
complicated.

Regards,

--
Mehdi

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Stefano Zacchiroli]

On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote:
> Your second item has been brought up before with different
> focus/rationale/purpose.  At least I remember there being an interest
> in splitting "non-free" into "non-free/firmware" vs. various other
> non-free sub components.

Another one that is worth mentioning here --- which I discussed in the
context of non-free.org with Dafydd Harries and others --- is
introducing a debtags facet to capture the reason why a package is in
non-free. At least two hierarchies come to mind: 1) which point of DFSG
is not respected, and 2) which one of the 4 freedoms are not granted.

I've had on my TODO list proposing the relevant debtags facets since at
least 2 years, but never found the time to actually do that. This is a
very actionable item: it is enough to follow the procedure for proposing
a new debtags. (Procedure that I cannot find right now, but IIRC it
includes coming up with a list of tag names + a list of at least N
packages, with N relatively low, that are already in the archive and
that would carry each tag.)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Philippe Cerfon]

Hey Niels

On Mon, Jan 4, 2016 at 8:45 AM, Niels Thykier  wrote:
> Philippe Cerfon:
> Your second item has been brought up before with different
> focus/rationale/purpose.  At least I remember there being an interest in
> splitting "non-free" into "non-free/firmware" vs. various other non-free
> sub components.

Well, I think splitting of just the firmware sounds far less appealing.
Actually in some cases having a non open firmware may not be *that*
big security issues, e.g. when it's used to be loaded in some external
device (something like ColorHug) and for many other firmwares there is
simply no alternative (or e.g. one won't have networking).
So while it would make of course to split of the non-open firmware
packages as well, the whole effort seems to rather only make sense if
really everything non-open is split off.


> On your first item, I would have to agree with Christian.  It is not
> actionable and much less by Debian.  At best we could stop packaging
> such software or disabling such features, but both have their disadvantages:
>
>  * Even if we stop shipping them, people will still download them.
>Except your average user will probably be worse off because most of
>them do not verify their downloads.
>  * If we disable the functionality, we would "cripple" the software to
>many people.  If this annoys people, we will end up in a situation
>where people will advise /against/ using the Debian package because
>it is "crippled", which leads to the situation above.  Or we could
>get badly unpopular with upstream (see the "Debian vs. Ruby" issue
>from a couple of years ago).

Removing the software is probably not going to work out, as one would
loose such big things like FF (though when looking at certain parts of
it, I wonder whether this woulnd't be quite good for
security/privacy).
So the only alternative seems to be to allow people to disable such
functionalities.
When I first stumbled over such packages, I was quite surprised that
no one had seriously complained about that before, but looking deeper
I found a number of tickets, but it seems these were usually not
accepted or just ignored :-(

The best thing would be if there was kind of a master-kill-switch,
that allows people to say yes or no to externally downloaded software.

Sincerely,
Philippe

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Philippe Cerfon]

Hey.

On Mon, Jan 4, 2016 at 10:13 AM, Bas Wijnen  wrote:
> debian-project, or hopefully debian-devel.  -project for talking about the
> idea, -devel for discussing an implementation.

Mehdi mentioned below that it would already land on debian-devel.
So I'm not sure whether it makes sense to post it to debian-project as
well, or whether people would get just annoyed because of
cross-posting.


>  Having an implementation ready
> hugely improves chances of it being done.

The point is, at least for the 2nd part of my original mail, I
wouldn't see much implementation work in kinds of code, or is there
any?
It would probably require some policy changes, the addition of a new
suite (e.g. "non-open" or any better name), and identification of such
non-free packages that would needed to be moved there.


> Yes; I think the conclusion of that discussion was two things:
> 1. Different people want different splits.  Using something like debtags may 
> be
>more useful, so users can block their own tag selection.

At first I had thought one could simply add a package that conflicts
any such packages for which there is no source code.
But I think (and I'd believe that would apply to your debtags idea as
well) that this is much less reliable, as it could be easily forgotten
to be added.

Having a separate suite for this has the appealing property that any
software in it wouldn't even show up in the package management when it
wasn't added in sources.list.


> 2. The firmware category is special in that pretty much everyone needs it, so
>we may want to make that its own section the old way.  This allows people 
> to
>use their hardware without enabling any (other) non-free sections and
>without worrying about debtags filters (once implemented).

But then I'd suggest to have something like e.g. "non-open/firmware",
where it would again be easily clear for anyone: beware the code
you're about to run is closed and may do anything.
The installers could then for example ask:
[ ] Do you want to enable non-open/closed-source software (Warning:
this means )
and if this isn't selected there could be a:
[ ] You're hardware XYZ was found to require non-open/closed-source
firmware to work. Shall non-open firmware be enabled?


> I agree that not shipping things (that we are allowed to ship) is a bad idea
> most of the time (except if it's because nobody considers it a priority; 
> giving
> upstream an incentive to release their software under a free license is good).
> The exception is software that actively hurts the user (malware, spyware).
> Which we can only block if we know about it, of course.

I recently stumbled over several sites which try to sanitize firefox
with several hidden settings in about:config.
Seems per default it does all kinds of experiments, send telemetry
data, transmits visited URLs to Google (couldn't really find out
whether it does so for all Mozilla doesn't really document any of this
properly) as well as hashsums of any downloaded file.
Sounds quite like spyware.

So the problem in the end is that we're in devil's circle.
Some software vendors (as one sees: including open source software
vendors) try to gain more and more power (e.g. shipping their own
"package management", recording all kind of "telemetry" data and so
on).
The majority remains silent and that behavior gets more and more
accepted until there is no way back. :-/


> This is a valid concern, but it shouldn't always be the deciding factor.  Many
> people (including me) use Debian because it easily allows installing a 100%
> free system with a huge choice of packages.  If the choice is "move a thing to
> non-free, or keep it in main and disable the functionality", those people will
> lose the software completely if it's moved to non-free.

Well moving something to non-free or the non-open I've proposed should
only happen when something really ships or downloads closed-source
code. Not because something provides a plugin-system.

It seems however quite worrisome, that there are more such big open
source projects (Firefox, I think I once read about Chromium doing
similar) that go to the dark side and install closed-source code.
The distros accept this, and e.g. Debian is doing a good job in trying
to prevent such rubbish, but since no one really shouts at these
upstream guys such things will rather continue and get more and more
difficult to be patched out.
First one had OpenH264, on Windows Firefox users already get the Adobe
DRM (surely no spyware) goodness. :-/

But it would of course be nice, if one could e.g. tell Debian's
Firefox (Iceweasel): don't allow to download/use any add-ons that
aren't part of Debian package.
Or to tell josm, the same. Or Picard.


In the end, I think these are really two distinct issues:
- closed-source software in Debian, which I think could be best dealt
wih a "non-open" suite (or e.g. "closed-source" or whatever people
like best)
- software that integrates automatic or 

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 05/01/16 08:15, Johannes Schauer wrote:
> Hi,
> 
> Quoting Stefano Zacchiroli (2016-01-04 23:14:11)
>> On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote:
>>> Your second item has been brought up before with different
>>> focus/rationale/purpose.  At least I remember there being an interest
>>> in splitting "non-free" into "non-free/firmware" vs. various other
>>> non-free sub components.
>>
>> Another one that is worth mentioning here --- which I discussed in the
>> context of non-free.org with Dafydd Harries and others --- is
>> introducing a debtags facet to capture the reason why a package is in
>> non-free. At least two hierarchies come to mind: 1) which point of DFSG
>> is not respected, and 2) which one of the 4 freedoms are not granted.
>>
>> I've had on my TODO list proposing the relevant debtags facets since at
>> least 2 years, but never found the time to actually do that. This is a
>> very actionable item: it is enough to follow the procedure for proposing
>> a new debtags. (Procedure that I cannot find right now, but IIRC it
>> includes coming up with a list of tag names + a list of at least N
>> packages, with N relatively low, that are already in the archive and
>> that would carry each tag.)
> 
> while I would welcome this sort of information being captured using debtags,
> this would not help me if I wanted to tell apt which packages are okay for me
> and which ones are not because apt cannot set pin priorities according to a
> package's debtags, right?
> 
> Also, can the reason why something is in non-free not be captured by increased
> and a more structured use of DEP-5 (machine-readable debian/copyright)?
> 
> Certainly I'd welcome support of apt for both: debtags *and* licenses in
> debian/copyright :)
> 
> My own motivation to have better control over non-free is my package
> ldraw-parts which is released under the "Creative Commons Attribution Licence
> version 2.0" and thus non-free. I can imagine that more people than just me
> would find that license acceptable enough.

Are you suggesting some kind of scale ?


Jerome


> 
> Thanks!
> 
> cheers, josch
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWi2/7AAoJEIC/w4IMSybj5lMH/i9u8R5lhuhLmTubJ1REFNZg
Pb+Cg6wNlBSIM/Za3lS5LzcePxZae/7g8ZLf6B/7VYHPPJQheczsX6YfRoa5as1C
47ArS6uR8sOdFOhvNOmR/hWKW2o9RE+3kLnlvz0I0qnc25ty7cP31w8G04W7yQCO
+fM/4XcW3MI+wtZpwZFrupm1DCHUpVpcwHLdrWJ7Bn0wmwHOWW8N7DgV9RsnBETT
FnMOAN+8f/DyOQviJPMuKRS2xDcbL0eFaaWrfdq909jdO7JJLHDsEdYYrmc5tHiH
Ajdg04jmA8XoZVzE1JYgL0LL56Y8r50jDqsJ9p7p4tPJRoLAoeT6ObEVXJ3Whh8=
=yNg4
-END PGP SIGNATURE-

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Johannes Schauer]

Hi,

Quoting Stefano Zacchiroli (2016-01-04 23:14:11)
> On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote:
> > Your second item has been brought up before with different
> > focus/rationale/purpose.  At least I remember there being an interest
> > in splitting "non-free" into "non-free/firmware" vs. various other
> > non-free sub components.
> 
> Another one that is worth mentioning here --- which I discussed in the
> context of non-free.org with Dafydd Harries and others --- is
> introducing a debtags facet to capture the reason why a package is in
> non-free. At least two hierarchies come to mind: 1) which point of DFSG
> is not respected, and 2) which one of the 4 freedoms are not granted.
> 
> I've had on my TODO list proposing the relevant debtags facets since at
> least 2 years, but never found the time to actually do that. This is a
> very actionable item: it is enough to follow the procedure for proposing
> a new debtags. (Procedure that I cannot find right now, but IIRC it
> includes coming up with a list of tag names + a list of at least N
> packages, with N relatively low, that are already in the archive and
> that would carry each tag.)

while I would welcome this sort of information being captured using debtags,
this would not help me if I wanted to tell apt which packages are okay for me
and which ones are not because apt cannot set pin priorities according to a
package's debtags, right?

Also, can the reason why something is in non-free not be captured by increased
and a more structured use of DEP-5 (machine-readable debian/copyright)?

Certainly I'd welcome support of apt for both: debtags *and* licenses in
debian/copyright :)

My own motivation to have better control over non-free is my package
ldraw-parts which is released under the "Creative Commons Attribution Licence
version 2.0" and thus non-free. I can imagine that more people than just me
would find that license acceptable enough.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Stefano Zacchiroli]

On Tue, Jan 05, 2016 at 08:15:37AM +0100, Johannes Schauer wrote:
> while I would welcome this sort of information being captured using debtags,
> this would not help me if I wanted to tell apt which packages are okay for me
> and which ones are not because apt cannot set pin priorities according to a
> package's debtags, right?

Right, but you need to start encoding the information in a machine
parsable way somewhere. Once you've that, you can exploit the
information, not before.

> Also, can the reason why something is in non-free not be captured by
> increased and a more structured use of DEP-5 (machine-readable
> debian/copyright)?

Policy §12.5 already requires to explain why a package is in non-free:

  Packages in the contrib or non-free archive areas should state in the
  copyright file that the package is not part of the Debian distribution
  and briefly explain why.

and DEP-5 prescribes the Disclaimer field to that end. Unfortunately, no
further (machine-readable) structure *within* the content of that field
is prescribed by DEP-5. So, yes, we will need to improve that part of
DEP-5 if we want to exploit information in there.

I duly note that, out of the box, having the information in d/copyright
won't help with APT pinning either.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Johannes Schauer]

Hi,

Quoting Jerome BENOIT (2016-01-05 08:25:47)
> On 05/01/16 08:15, Johannes Schauer wrote:
> > Hi,
> >
> > Quoting Stefano Zacchiroli (2016-01-04 23:14:11)
> >> On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote:
> >>> Your second item has been brought up before with different
> >>> focus/rationale/purpose.  At least I remember there being an interest
> >>> in splitting "non-free" into "non-free/firmware" vs. various other
> >>> non-free sub components.
> >>
> >> Another one that is worth mentioning here --- which I discussed in the
> >> context of non-free.org with Dafydd Harries and others --- is
> >> introducing a debtags facet to capture the reason why a package is in
> >> non-free. At least two hierarchies come to mind: 1) which point of DFSG
> >> is not respected, and 2) which one of the 4 freedoms are not granted.
> >>
> >> I've had on my TODO list proposing the relevant debtags facets since at
> >> least 2 years, but never found the time to actually do that. This is a
> >> very actionable item: it is enough to follow the procedure for proposing
> >> a new debtags. (Procedure that I cannot find right now, but IIRC it
> >> includes coming up with a list of tag names + a list of at least N
> >> packages, with N relatively low, that are already in the archive and
> >> that would carry each tag.)
> >
> > while I would welcome this sort of information being captured using debtags,
> > this would not help me if I wanted to tell apt which packages are okay for 
> > me
> > and which ones are not because apt cannot set pin priorities according to a
> > package's debtags, right?
> >
> > Also, can the reason why something is in non-free not be captured by 
> > increased
> > and a more structured use of DEP-5 (machine-readable debian/copyright)?
> >
> > Certainly I'd welcome support of apt for both: debtags *and* licenses in
> > debian/copyright :)
> >
> > My own motivation to have better control over non-free is my package
> > ldraw-parts which is released under the "Creative Commons Attribution 
> > Licence
> > version 2.0" and thus non-free. I can imagine that more people than just me
> > would find that license acceptable enough.
> 
> Are you suggesting some kind of scale ?

no. I don't think it's possible to find a scale from "dfsg-free" to "non-free"
which would work for everybody. Different people feel differently about what is
acceptable for them.

I am talking about adding the metadata about which license code is released
under and/or which DFSG freedoms it violates as proposed by Stefano in a
machine readable way: either debtags or DEP-5 and make either or both of them
understood by apt pinning so that I can tell my system which software to allow
and which to not allow.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Philippe Cerfon]

On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER  wrote:
> Discussing infrastructure changes like what you're proposing (which I
> have no advice about) should usually be done through our mailing
> lists,
Which one would be the appropriate list?

I thought general would fit, as it likely affects multiple packages
and infrastructure systems form Debian.
Anyway, I don't mind to forward this to some list as well.

Thanks,
Philippe.

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Niels Thykier]

Philippe Cerfon:
> On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER  wrote:
>> Discussing infrastructure changes like what you're proposing (which I
>> have no advice about) should usually be done through our mailing
>> lists,
> Which one would be the appropriate list?
> 
> I thought general would fit, as it likely affects multiple packages
> and infrastructure systems form Debian.
> Anyway, I don't mind to forward this to some list as well.
> 
> Thanks,
> Philippe.
> 

Your second item has been brought up before with different
focus/rationale/purpose.  At least I remember there being an interest in
splitting "non-free" into "non-free/firmware" vs. various other non-free
sub components.

Mind you, its primary goal was not to address "source vs. no-source",
but it is the closest related idea I could think of.  Sadly, I don't
have a reference ready to backup my memory.


On your first item, I would have to agree with Christian.  It is not
actionable and much less by Debian.  At best we could stop packaging
such software or disabling such features, but both have their disadvantages:

 * Even if we stop shipping them, people will still download them.
   Except your average user will probably be worse off because most of
   them do not verify their downloads.
 * If we disable the functionality, we would "cripple" the software to
   many people.  If this annoys people, we will end up in a situation
   where people will advise /against/ using the Debian package because
   it is "crippled", which leads to the situation above.  Or we could
   get badly unpopular with upstream (see the "Debian vs. Ruby" issue
   from a couple of years ago).


Thanks,
~Niels

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Philippe Cerfon]

Package: general
Severity: wishlist
Tags: security

Hi.

I think Debian has the following two problems (or rather its security
conscious users) with respect to software that gets into the system:


First,
more and more packages install software which sneaks around the
package manager (and thus typically around any security support from
Debian) by downloading further code, plugins and so on.
Examples include programms like firefox, thunderbird (both, the
add-ons and bad things like silent/automatic downloaded blobs as
OpenH264, even though the later has been disabled in Debian :-) ) but
also many others like josm, picard or ruby gems integration.

For the user it's not really visible when he crosses the line where
such plugins are simply proper Debian packages and where he gets
binaries or other code from 3rd parties, which are out of any security
support proper, and possibly even compromised.

Unfortunately, doing something about this wouldn't be very easy,
because it would require patching all these packages :-(


Second,
there is a growing number of packages, for which no sources are
available (not talking about the Debian source package, but the
sources from the software).
Examples include, steam, firmware packages and so on.
This software is, for policy reasons, in non-free.

Many non-free packages have however their sources available and are
for other reasons in non-free. One may not be happy about them not
being DFSG compatible, but at least one can read their code and check
for any backdoors or security holes.
Examples include many documentation packages in non-free or software like unrar.

I can understand that for some packages (typically the firmware
packages) there is no alternative to having them - but I don't quite
understand why Debian needs to ship packages (e.g. like steam) which
is by no means necessary and install code into the system that's not
only incompatible with the ideas of FLOSS but also not auditable.

Of course there are people who wand to have these packaged and
maintainers who are doing some good work on them, so maybe there can
be a solution that fits both sides' needs:
Why not adding another section which is so to say even "worse" than
non-free, e.g. call it non-open (or some better name).

This would contain any packages that contain anything (i.e. software)
for which there are no sources, while anything else, where software is
available that's just not DFSG compatbile, would remain in non-free.
A policy change should enforce that of course.

The benefit of this would be that it's far easier for users to rule
out any non-open software, but still continue to use "just non-free"
packages, which aren't perfect from their licensing but cannot contain
anything evil (or at least one could find it in the code).
With e.g. apt_preferences, one could still selectively allow certain
such closed-source packages, e.g. firmware packages.

Thanks in advance for your consideration.

Sincerely,
Philippe

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Christian PERRIER]

Quoting Philippe Cerfon (philc...@gmail.com):
> Package: general
> Severity: wishlist
> Tags: security
> 
> Hi.
> 
> I think Debian has the following two problems (or rather its security
> conscious users) with respect to software that gets into the system:


No idea whether what you're proposing is relevant or notbut
there's something I'm deeply sure of : that won't be solved through a
"general" bug report.

Such vague bug reports are usually either quickly closedor just
ignored by everybody in the project.

Discussing infrastructure changes like what you're proposing (which I
have no advice about) should usually be done through our mailing
lists, get some kind of agreement, include some implementation in key
packages, and get enough consensus among developers to draw the needed
changes in the infranstructure (in this case, our software
repositories, at minimum).

So, zero chances that this happens through a (soon to be forgotten)
bug report. No offense, but that's reality.




signature.asc
Description: PGP signature