Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #9370 > unrolled thread

Bug#856139: certspotter: long description advertises commercial service

Back to article view | Back to linux.debian.project

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#856139: certspotter: long description advertises commercial service Jonas Smedegaard <dr@jones.dk> - 2017-08-05 02:10 +0200
    Bug#856139: certspotter: long description advertises commercial service Paul Wise <pabs@debian.org> - 2017-08-05 15:50 +0200
      Re: Bug#856139: certspotter: long description advertises commercial  service "Dr. Bas Wijnen" <bas@wijnen.dtdns.net> - 2017-08-06 09:30 +0200
      Bug#856139: certspotter: long description advertises commercial service Jonas Smedegaard <dr@jones.dk> - 2017-08-06 17:30 +0200
    Bug#856139: [pkg-go] Bug#856139: certspotter: long description advertises commercial service Vincent Bernat <bernat@debian.org> - 2017-08-06 14:20 +0200
      Bug#856139: [pkg-go] Bug#856139: certspotter: long description advertises commercial service Chris Lamb <lamby@debian.org> - 2017-08-06 14:40 +0200
      Re: [pkg-go] Bug#856139: certspotter: long description advertises  commercial service "Dr. Bas Wijnen" <wijnen@debian.org> - 2017-08-07 20:20 +0200
        Re: [pkg-go] Bug#856139: Bug#856139: certspotter: long description advertises commercial service Vincent Bernat <bernat@debian.org> - 2017-08-07 21:00 +0200
          Debian packages advertising non-free services (was: [pkg-go] Bug#856139: Bug#856139: certspotter: long description advertises commercial service) Ben Finney <bignose@debian.org> - 2017-08-08 01:40 +0200
            Re: Debian packages advertising non-free services Vincent Bernat <bernat@debian.org> - 2017-08-08 07:40 +0200
              Re: Debian packages advertising non-free services Scott Kitterman <debian@kitterman.com> - 2017-08-08 07:50 +0200
                Re: Debian packages advertising non-free services Charles Plessy <plessy@debian.org> - 2017-08-08 09:00 +0200
                Re: Debian packages advertising non-free services Andrey Rahmatullin <wrar@debian.org> - 2017-08-08 10:10 +0200
              Re: Debian packages advertising non-free services Ben Finney <bignose@debian.org> - 2017-08-08 08:20 +0200
        Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service Sean Whitton <spwhitton@spwhitton.name> - 2017-08-08 05:50 +0200
          Re: [pkg-go] Bug#856139: certspotter: long description advertises  commercial service Wouter Verhelst <wouter@debian.org> - 2017-08-11 14:10 +0200
            Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service Sean Whitton <spwhitton@spwhitton.name> - 2017-08-11 17:00 +0200
            Re: [pkg-go] Bug#856139: certspotter: long description advertises  commercial service Faidon Liambotis <paravoid@debian.org> - 2017-08-12 00:00 +0200
              Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial  service Jonas Smedegaard <dr@jones.dk> - 2017-08-12 05:50 +0200
              Re: [pkg-go] Bug#856139: certspotter: long description advertises  commercial service "Dr. Bas Wijnen" <wijnen@debian.org> - 2017-08-12 08:30 +0200
                Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service Vincent Bernat <bernat@debian.org> - 2017-08-12 09:00 +0200
                  Are online services also software for Debian's rules? "Dr. Bas Wijnen" <wijnen@debian.org> - 2017-08-12 09:40 +0200
                    Re: Are online services also software for Debian's rules? Vincent Bernat <bernat@debian.org> - 2017-08-12 10:00 +0200
                Re: [pkg-go] Bug#856139: certspotter: long description advertises  commercial service Christian Seiler <christian@iwakd.de> - 2017-08-12 10:10 +0200
                  Re: Are online services also software for Debian's rules? "Dr. Bas Wijnen" <wijnen@debian.org> - 2017-08-12 11:20 +0200
                    Re: Are online services also software for Debian's rules? Vincent Bernat <bernat@debian.org> - 2017-08-12 12:10 +0200
                      Re: Are online services also software for Debian's rules? Russ Allbery <rra@debian.org> - 2017-08-12 17:20 +0200
                      Re: Are online services also software for Debian's rules? "Dr. Bas Wijnen" <wijnen@debian.org> - 2017-08-13 22:10 +0200
                        Re: Are online services also software for Debian's rules? Miles Fidelman <mfidelman@meetinghouse.net> - 2017-08-13 23:10 +0200
                          Re: Are online services also software for Debian's rules? Russ Allbery <rra@debian.org> - 2017-08-14 02:30 +0200
                        Re: Are online services also software for Debian's rules? Russ Allbery <rra@debian.org> - 2017-08-14 02:30 +0200
                          Re: Are online services also software for Debian's rules? "Dr. Bas Wijnen" <wijnen@debian.org> - 2017-08-14 14:10 +0200
                            Re: Are online services also software for Debian's rules? Holger Levsen <holger@layer-acht.org> - 2017-08-14 15:00 +0200
                              Re: Are online services also software for Debian's rules? "Dr. Bas Wijnen" <wijnen@debian.org> - 2017-08-14 15:10 +0200
                                Re: Are online services also software for Debian's rules? Andrey Rahmatullin <wrar@debian.org> - 2017-08-14 15:30 +0200
                          Re: Are online services also software for Debian's rules? Marc Haber <mh+debian-project@zugschlus.de> - 2017-08-14 15:30 +0200
                            Re: Are online services also software for Debian's rules? Miles Fidelman <mfidelman@meetinghouse.net> - 2017-08-14 19:40 +0200
                              Re: Are online services also software for Debian's rules? Andrey Rahmatullin <wrar@debian.org> - 2017-08-14 19:50 +0200
                    Re: Are online services also software for Debian's rules? Christian Seiler <christian@iwakd.de> - 2017-08-12 12:10 +0200
                      Re: Are online services also software for Debian's rules? Tollef Fog Heen <tfheen@err.no> - 2017-08-12 16:00 +0200
                        Re: Are online services also software for Debian's rules? Christian Seiler <christian@iwakd.de> - 2017-08-12 16:20 +0200
                          Re: Are online services also software for Debian's rules? Tollef Fog Heen <tfheen@err.no> - 2017-08-12 16:50 +0200
                  win32-loader (was: Re: Bug#856139: certspotter: long description advertises commercial service) Didier 'OdyX' Raboud <odyx@debian.org> - 2017-08-12 17:00 +0200
                Re: [pkg-go] Bug#856139: certspotter: long description advertises  commercial service Tobias Frost <tobi@debian.org> - 2017-08-12 17:40 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#9408 — Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service

[Multipart message — attachments visible in raw view] — view raw

 ❦ 12 août 2017 06:29 GMT, "Dr. Bas Wijnen" <wijnen@debian.org> :

> That is a disservice to our users.  While for many users this is true, those
> users will have contrib (and probably non-free) enabled in their sources.list.
> So moving the package to contrib doesn't change anything for them.  The only
> people who see a difference are the ones who asked not to see this kind of
> software, and they will no longer see it.  That is a great outcome, not
> something to get upset about.

By default, contrib and non-free repositories are not enabled. They are
also unsupported from the security team. They are not part of
Debian. They are an additional service provided to users requesting it
specifically.

Debian is about free software. There is nothing in DFSG about "free
services". How do you know if a service is implemented with free
software or not? Amazon S3 could be free software, but only distributed
internally at Amazon.
-- 
Lord, what fools these mortals be!
		-- William Shakespeare, "A Midsummer-Night's Dream"

[toc] | [prev] | [next] | [standalone]

#9409 — Are online services also software for Debian's rules?

[Multipart message — attachments visible in raw view] — view raw

On Sat, Aug 12, 2017 at 08:55:01AM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 06:29 GMT, "Dr. Bas Wijnen" <wijnen@debian.org> :
> 
> > That is a disservice to our users.  While for many users this is true, those
> > users will have contrib (and probably non-free) enabled in their sources.list.
> > So moving the package to contrib doesn't change anything for them.  The only
> > people who see a difference are the ones who asked not to see this kind of
> > software, and they will no longer see it.  That is a great outcome, not
> > something to get upset about.
> 
> By default, contrib and non-free repositories are not enabled. They are
> also unsupported from the security team. They are not part of
> Debian. They are an additional service provided to users requesting it
> specifically.

Your argument seems to be:

Debian cares about free software.
Therefore, Debian does not enable contrib and non-free by default.
Therefore, users may not see non-free related software.  This is a problem.
Let's fix it by pushing that software into main anyway.

In other words: We care about free software, therefore we should put non-free
(related) software in main.  What?

If you believe it is a problem that our users don't have access to the software
in contrib by default, then propose to fix that.  The obvious way to do that
would be by enabling contrib by default, not by moving software that belongs in
contrib into main.

Another solution for those users is to install one of our many derivatives,
most of which don't care about non-free software like we do.

> Debian is about free software. There is nothing in DFSG about "free
> services". How do you know if a service is implemented with free
> software or not? Amazon S3 could be free software, but only distributed
> internally at Amazon.

They can be, but that is irrelevant to this discussion.  There is no question
that the client is free software.  If the server is not packaged in main, that
means this free client software belongs in contrib.  Whether that is because it
is non-free or for some other reason does not matter.  That is, unless you are
claiming that their service is not "software".  Are you?

Thanks,
Bas

[toc] | [prev] | [next] | [standalone]

#9410 — Re: Are online services also software for Debian's rules?

[Multipart message — attachments visible in raw view] — view raw

 ❦ 12 août 2017 07:37 GMT, "Dr. Bas Wijnen" <wijnen@debian.org> :

>> > That is a disservice to our users.  While for many users this is true, those
>> > users will have contrib (and probably non-free) enabled in their sources.list.
>> > So moving the package to contrib doesn't change anything for them.  The only
>> > people who see a difference are the ones who asked not to see this kind of
>> > software, and they will no longer see it.  That is a great outcome, not
>> > something to get upset about.
>> 
>> By default, contrib and non-free repositories are not enabled. They are
>> also unsupported from the security team. They are not part of
>> Debian. They are an additional service provided to users requesting it
>> specifically.
>
> Your argument seems to be:
>
> Debian cares about free software.
> Therefore, Debian does not enable contrib and non-free by default.
> Therefore, users may not see non-free related software.  This is a problem.
> Let's fix it by pushing that software into main anyway.

No, _your_ argument is that contrib and non-free are part of Debian and
are just a fine recipient for random software. I just emphasize the fact
they are not part of Debian.

My argument is that services are not software. Free software depending
on non-free services (something we don't define in Debian) should be in
main. Like they always have been.

> In other words: We care about free software, therefore we should put non-free
> (related) software in main.  What?

Strawman argument. Please, refrain from that.

> If you believe it is a problem that our users don't have access to the software
> in contrib by default, then propose to fix that.  The obvious way to do that
> would be by enabling contrib by default, not by moving software that belongs in
> contrib into main.

Contrib cannot be enabled by default, it is not part of Debian. It's an
additional service using Debian infrastructure. Policy is quite clear
about that.

And honestly, I don't have to do a thing. Nothing will change. Free
software using "non-free services" will stay in main because they meet
the proper requirements (policy 2.2.1).

>> Debian is about free software. There is nothing in DFSG about "free
>> services". How do you know if a service is implemented with free
>> software or not? Amazon S3 could be free software, but only distributed
>> internally at Amazon.
>
> They can be, but that is irrelevant to this discussion.  There is no question
> that the client is free software.  If the server is not packaged in main, that
> means this free client software belongs in contrib.  Whether that is because it
> is non-free or for some other reason does not matter.  That is, unless you are
> claiming that their service is not "software".  Are you?

Yes, I am! They are services. Even the FSF acknowledges they are
different. They have created the AGPL for that.
-- 
O, what a tangled web we weave, When first we practice to deceive.
		-- Sir Walter Scott, "Marmion"

[toc] | [prev] | [next] | [standalone]

#9411 — Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service

Because it's so fun, let me play devil's advocate for a bit:

On 08/12/2017 08:29 AM, Dr. Bas Wijnen wrote:
> No.  The question is not "is there non-free software that the program can work
> with?"  That would be much too broad, and it would make anything that touches
> the network non-free.  Instead, the question is "is non-free software required
> for major functionality of the program?"

I don't think this is as black and white as you paint it:

win32-loader probably doesn't run on Wine or ReactOS (though I haven't
tried it, so I may be wrong here) - should that be in contrib if that's
the case?

Consider the following scenario: I write a chat client that supports
both XMPP and ICQ - but don't separate the code. As the "major
functionality", i.e. chat, still works with free services (there are
plenty of free software XMPP servers out there), by your logic it should
be in main. But if at some point I decide to refactor that thing and
separate out the protocol implementations into libs, the library that
does ICQ should now be in contrib, and by extension the program then
should either be in contrib or drop support for ICQ. (Or implement a
plugin mechnaism, which can be a lot of work.)

So should the packaging granularity, which in the end is to a certain
extent always somewhat arbitrary, dictate whether a program goes into
main or contrib?

Or would you instead say - to be consistent here - that the ICQ part
should also be disabled in the case where the libs aren't factored
out? But would that not mean that any minor subfeature of a software
in main that only works with proprietary software should either be
disabled for refactored into a plugin-based system where the version
with support for that could live in contrib?

But if that is the case, do our efforts to de-blob the kernel go far
enough? Because while there is some free firmware available for some
devices, if we take the principle to the extreme conclusion, any
driver where there's only non-free firmware available should have
the firmware-loading capability stripped if it's to be in main. But
even if you say, well, firmware loading is mostly a memcpy() in
current times, let's ignore that for now - there are some features
of kernel drivers that only work with non-free firmware (while the
basic device functionality may already work without any firmware).
Should the driver in main disable these extended features?

(Speaking of: as far as I can tell the WiFi drivers that require
non-free firmware to work at all are in main at the moment. Or do
drivers not count as "major functionality" if they're part of the
kernel? But would they then count as "major functionality" if they
are still a separate DKMS module before it was included in the
mainline kernel? But if the code is exactly the same, why should it
then suddenly move to main, just because upstream decided to merge
it in?)

Or, I don't know if this is true, but let's say there's a feature in
the PDF standard that is currently supported by non-free authoring
tools. Should free PDF readers disable support for this specific
feature if they want to be in main because it requires non-free tools
at the moment to generate PDF files with said feature? (And even if
this is not true for PDF, there's probably some file format out there
where this holds.)

Furthermore, you can go to more extremes: "requires non-free
software to work" can also be applied to hardware drivers in more
general terms. What about devices that have firmware embedded on
them? Isn't communicating with a device firmware via USB or PCIe
not in some sense equivalent to communicating over the network?
And sure, some devices can be emulated by e.g. qemu, so there you
would have a free implementation of the "remote side", but in
many cases you don't. Couldn't you also argue that any hardware
driver that talks to hardware that has any kind of firmware on it
(even if it's pre-embedded on there and doesn't need to be loaded
during runtime) should be in contrib unless a) there firmware is
free software or b) there's something like qemu emulating that
hardware?





I do think there are easy cases:

 - the Microsoft TrueType Corefonts downloader should definitely
   be in contrib

 - any tool dedicated to updating the firmware of devices where no
   free firmware exists for any of the devices it supports should
   also be in contrib (I'm talking about devices that have a flash
   where the firmware is in, not about firmware loading that takes
   place during device initialization)

 - the ZFS DKMS module should definitely not be in main as any
   binaries produced by it are (probably) non-redistributable





But in other cases I don't think the answer is quite as simple,
see the examples I gave. And I don't think there's any consensus
here, I'm not even sure what opinion I have on all of these
issues. I can just see that no matter in which way I try to create
a set of more specific principles to flesh out the more broader
idea of contrib that I accept [1], I can always easily think of
examples where I go "wait, this doesn't seem quite right".

Regards,
Christian

[1]  "if it requires non-free software it should be in
    contrib".

    Though wait a minute, I just re-read what policy says, it's
    actually:

    "The contrib archive area contains supplemental packages
     intended to work with the Debian distribution, but which
     require software outside of the distribution to either
     build or function."

    Well, if I take that to its extreme conclusion, wouldn't that
    also mean that I any network client I package should go into
    contrib until there's a free software implementation of a
    corresponding network server available in Debian as well? And
    vice-versa? And what about file format readers? And what about
    software that talks with other services that are free but not
    in the purview of Debian? For example if you have software
    that only works with a small embedded device that's connected
    via e.g. USB or the network, and that embedded device will
    never run Debian (say it has only 32k of RAM), but does run
    free software?

    This discussion just got way more interesting... ;-)

[toc] | [prev] | [next] | [standalone]

#9412 — Re: Are online services also software for Debian's rules?

[Multipart message — attachments visible in raw view] — view raw

On Sat, Aug 12, 2017 at 09:55:17AM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 07:37 GMT, "Dr. Bas Wijnen" <wijnen@debian.org> :
> > Your argument seems to be:
> >
> > Debian cares about free software.
> > Therefore, Debian does not enable contrib and non-free by default.
> > Therefore, users may not see non-free related software.  This is a problem.
> > Let's fix it by pushing that software into main anyway.
> 
> No, _your_ argument is that contrib and non-free are part of Debian and
> are just a fine recipient for random software. I just emphasize the fact
> they are not part of Debian.

I agree that they are not part of Debian, but they are indeed fine as recipient
for software (free software in the case of contrib).  Debian is a
self-contained system that does not require anything outside it.  This is not
true for a client of a network service that is not packaged in main, so such a
client cannot be in main.

> My argument is that services are not software.

How do you think those services are implemented, if not as software?

> > In other words: We care about free software, therefore we should put non-free
> > (related) software in main.  What?
> 
> Strawman argument. Please, refrain from that.

If you read my message, I explained that this was what I understood your
argument to be.  Instead of accusing me of rhetorical tricks, please just point
out that I misunderstood you.

> > If you believe it is a problem that our users don't have access to the software
> > in contrib by default, then propose to fix that.  The obvious way to do that
> > would be by enabling contrib by default, not by moving software that belongs in
> > contrib into main.
> 
> Contrib cannot be enabled by default, it is not part of Debian.

So?  You just said that there is no problem whatsoever with Debian packages
using non-free services, which I hope we agree are not a part of Debian either?
Isn't contrib just a network service?

> It's an additional service using Debian infrastructure. Policy is quite clear
> about that.

Yes, and your position is that programs using additional services outside of
Debian can be in main.  So how is this a problem for you?

To be clear: I like to ship main-only by default, but I would understand if
contrib was enabled by default and I don't think it would be against the SC,
DFSG, or Policy.

> And honestly, I don't have to do a thing. Nothing will change. Free
> software using "non-free services" will stay in main because they meet
> the proper requirements (policy 2.2.1).

No, it doesn't.  2.2.1 says "None of the packages in the main archive area
require software outside of that area to function."  In other words, if
software outside of main would not exist, the program would still work.  But if
that software wouldn't exist, the non-free service would not be available and
the free client would be useless.

> >> Debian is about free software. There is nothing in DFSG about "free
> >> services". How do you know if a service is implemented with free
> >> software or not? Amazon S3 could be free software, but only distributed
> >> internally at Amazon.
> >
> > They can be, but that is irrelevant to this discussion.  There is no question
> > that the client is free software.  If the server is not packaged in main, that
> > means this free client software belongs in contrib.  Whether that is because it
> > is non-free or for some other reason does not matter.  That is, unless you are
> > claiming that their service is not "software".  Are you?
> 
> Yes, I am! They are services. Even the FSF acknowledges they are
> different. They have created the AGPL for that.

They have created the AGPL to close a loophole, namely that it was possible to
move a program into the cloud and thereby the users lost their freedoms.  The
idea of copyleft is to guarantee those freedoms to downstream recipients and
this trick made that impossible.  So the AGPL says "if you access software over
a network, you're still considered a user and need to receive all the rights".
In other words, the AGPL is created specifically _because_ they acknowledge
that a network service is also software.

On Sat, Aug 12, 2017 at 10:06:40AM +0200, Christian Seiler wrote:
> Because it's so fun, let me play devil's advocate for a bit:

Sure. :)

> On 08/12/2017 08:29 AM, Dr. Bas Wijnen wrote:
> > No.  The question is not "is there non-free software that the program can work
> > with?"  That would be much too broad, and it would make anything that touches
> > the network non-free.  Instead, the question is "is non-free software required
> > for major functionality of the program?"
> 
> I don't think this is as black and white as you paint it:

It's certainly not black and white, and as I wrote elsewhere, the line can
move.  But there is a line and I don't think it's anywhere near where some
people seem to draw it.

> win32-loader probably doesn't run on Wine or ReactOS (though I haven't
> tried it, so I may be wrong here) - should that be in contrib if that's
> the case?

Possibly.  The GPL makes an exception for components of the OS (so "it runs on
Windows" doesn't make things non-free), and I think it is reasonable if Debian
followed that rule as well.  But it's certainly debatable.

> Consider the following scenario: I write a chat client that supports
> both XMPP and ICQ - but don't separate the code. As the "major
> functionality", i.e. chat, still works with free services (there are
> plenty of free software XMPP servers out there), by your logic it should
> be in main. But if at some point I decide to refactor that thing and
> separate out the protocol implementations into libs, the library that
> does ICQ should now be in contrib, and by extension the program then
> should either be in contrib or drop support for ICQ. (Or implement a
> plugin mechnaism, which can be a lot of work.)

Yes, this is how it works.

> So should the packaging granularity, which in the end is to a certain
> extent always somewhat arbitrary, dictate whether a program goes into
> main or contrib?

In practice, yes.  That's how we do things.  Not because package granularity is
relevant, but because we don't want to keep software out just because it
contains the option to interact with something non-free.  But if that option is
in a package of its own, yes it belongs in contrib.

> Or would you instead say - to be consistent here - that the ICQ part
> should also be disabled in the case where the libs aren't factored
> out?

That is another option, and we leave that to the maintainer to decide.  Which
is good, IMO.  There are many subjective choices to be made here and trying to
force strict rules on them is usually not a good idea.  But we should agree on
the spirit of the rules.  Saying that network services are not software is not
in the spirit that I thought we had.

> Furthermore, you can go to more extremes: "requires non-free
> software to work" can also be applied to hardware drivers in more
> general terms.

Yes, hardware is complex and I follow the principle of RMS there: if you need
it to get to a better (more free) place, it's acceptable.  Once there are free
options, we should recommend them.

So that means I don't think all of Debian should be in non-free because there
are no free cpu designs (although I'm sure there are...)  But when there are
"real" computers with a free cpu, I think supporting features that only exist
on non-free cpus would become debatable.  Again this is a subjective choice
which I wouldn't want to formalize.

>  - any tool dedicated to updating the firmware of devices where no
>    free firmware exists for any of the devices it supports should
>    also be in contrib (I'm talking about devices that have a flash
>    where the firmware is in, not about firmware loading that takes
>    place during device initialization)

Why the distinction?

Thanks,
Bas

[toc] | [prev] | [next] | [standalone]

#9413 — Re: Are online services also software for Debian's rules?

[Multipart message — attachments visible in raw view] — view raw

 ❦ 12 août 2017 09:12 GMT, "Dr. Bas Wijnen" <wijnen@debian.org> :

>> And honestly, I don't have to do a thing. Nothing will change. Free
>> software using "non-free services" will stay in main because they meet
>> the proper requirements (policy 2.2.1).
>
> No, it doesn't.  2.2.1 says "None of the packages in the main archive area
> require software outside of that area to function."  In other words, if
> software outside of main would not exist, the program would still work.  But if
> that software wouldn't exist, the non-free service would not be available and
> the free client would be useless.

Then, please file bugs against offending packages, severity
serious. Otherwise, all this discussion is useless. A starting point
could be golang-github-datadog-datadog-go and golang-google-api
packages.
-- 
Avoid temporary variables.
            - The Elements of Programming Style (Kernighan & Plauger)

[toc] | [prev] | [next] | [standalone]

#9419 — Re: Are online services also software for Debian's rules?

Vincent Bernat <bernat@debian.org> writes:

> Then, please file bugs against offending packages, severity
> serious. Otherwise, all this discussion is useless. A starting point
> could be golang-github-datadog-datadog-go and golang-google-api
> packages.

And please think about the significant hardship you will create for people
trying to maintain software in Debian that works with multiple free and
non-free services before you go down this path.  The number of things that
would have to move to contrib because one of their underlying libraries
would now be in contrib would be substantial.  Is the amount of effort
people would have to go to in order to untangle that mess, and the number
of our users who would immediately enable contrib who don't have it
enabled now, really worth it?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#9426 — Re: Are online services also software for Debian's rules?

[Multipart message — attachments visible in raw view] — view raw

On Sat, Aug 12, 2017 at 12:07:51PM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 09:12 GMT, "Dr. Bas Wijnen" <wijnen@debian.org> :
> > No, it doesn't.  2.2.1 says "None of the packages in the main archive area
> > require software outside of that area to function."  In other words, if
> > software outside of main would not exist, the program would still work.  But if
> > that software wouldn't exist, the non-free service would not be available and
> > the free client would be useless.
> 
> Then, please file bugs against offending packages, severity
> serious. Otherwise, all this discussion is useless. A starting point
> could be golang-github-datadog-datadog-go and golang-google-api
> packages.

My purpose of this thread (which is a question asked elsewhere) is to find out
if there is consensus about this issue.  If there isn't, I don't want to bother
everyone with a mass bug report.  Which, as Russ pointed out, would be a pretty
large operation.

Also, I don't want to move lots of software to contrib.  I would much rather
have it fixed by removing the support for the non-free services, or by having
plugin systems that allow only the non-free-interfacing part to be in contrib.
However, that is still a large operation, so I still do not want to do a mass
bug filing unless there is consensus that it should be done.  So far, it
doesn't seem like there is consensus at all.

Thanks,
Bas

[toc] | [prev] | [next] | [standalone]

#9428 — Re: Are online services also software for Debian's rules?

On 8/13/17 1:05 PM, Dr. Bas Wijnen wrote:

> My purpose of this thread (which is a question asked elsewhere) is to find out
> if there is consensus about this issue.  If there isn't, I don't want to bother
> everyone with a mass bug report.  Which, as Russ pointed out, would be a pretty
> large operation.
>
> Also, I don't want to move lots of software to contrib.  I would much rather
> have it fixed by removing the support for the non-free services, or by having
> plugin systems that allow only the non-free-interfacing part to be in contrib.
> However, that is still a large operation, so I still do not want to do a mass
> bug filing unless there is consensus that it should be done.  So far, it
> doesn't seem like there is consensus at all.

Getting past all the obfuscatory count and counterpoint, there seem to 
be two clear questions on the table:

1.  Given a piece of FOSS client software, that has no purpose other 
than to interface with a proprietary back-end service (say a FOSS 
twitter GUI), should that be considered "free software" for the purposes 
of placement in main vs. contrib vs. non-free?  (Or alternatively, where 
should it reside?)

2.  Given a piece of FOSS client software that interfaces to, among 
other things, a proprietary back-end service (e.g., a multi-protocol 
chat interface that includes AIM and MS Messenger among the back-ends it 
supports), be placed in contrib or non-free, simply because its 
description mentions those services?

Personally, I don't really care, and could argue both points either 
way.  But they are clear policy questions that might be of interest to 
packagers.

Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]

#9431 — Re: Are online services also software for Debian's rules?

Miles Fidelman <mfidelman@meetinghouse.net> writes:

> Getting past all the obfuscatory count and counterpoint, there seem to
> be two clear questions on the table:

> 1.  Given a piece of FOSS client software, that has no purpose other
> than to interface with a proprietary back-end service (say a FOSS
> twitter GUI), should that be considered "free software" for the purposes
> of placement in main vs. contrib vs. non-free?  (Or alternatively, where
> should it reside?)

> 2.  Given a piece of FOSS client software that interfaces to, among
> other things, a proprietary back-end service (e.g., a multi-protocol
> chat interface that includes AIM and MS Messenger among the back-ends it
> supports), be placed in contrib or non-free, simply because its
> description mentions those services?

The point that I think may not yet be clear enough is that if the answer
to 2 is that such software should not be moved to contrib (as has
historically always been the case), the answer to 1 *also* has to be that
the software is not moved to contrib.  Because the way you get software of
type 2 is that it uses a variety of libraries of type 1, so if those
libraries are moved to contrib, the main software of type 2 would also
have to be moved to contrib.

Writing a library specifically to interact with a non-free service is
*good software engineering* (do one thing and do it well), and the correct
way to implement software of type 2.  So unless you want to see all
software of type 2 kicked out of Debian, at least libraries of type 1 also
need to be allowed in Debian.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#9430 — Re: Are online services also software for Debian's rules?

"Dr. Bas Wijnen" <wijnen@debian.org> writes:

> Also, I don't want to move lots of software to contrib.  I would much
> rather have it fixed by removing the support for the non-free services,
> or by having plugin systems that allow only the non-free-interfacing
> part to be in contrib.

I believe this would be hugely counter-productive for free software.  It
would hurt us way more than it would hurt proprietary services.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#9432 — Re: Are online services also software for Debian's rules?

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 13, 2017 at 05:28:29PM -0700, Russ Allbery wrote:
> Miles Fidelman <mfidelman@meetinghouse.net> writes:
> 
> > Getting past all the obfuscatory count and counterpoint, there seem to
> > be two clear questions on the table:
> 
> > 1.  Given a piece of FOSS client software, that has no purpose other
> > than to interface with a proprietary back-end service (say a FOSS
> > twitter GUI), should that be considered "free software" for the purposes
> > of placement in main vs. contrib vs. non-free?  (Or alternatively, where
> > should it reside?)
> 
> > 2.  Given a piece of FOSS client software that interfaces to, among
> > other things, a proprietary back-end service (e.g., a multi-protocol
> > chat interface that includes AIM and MS Messenger among the back-ends it
> > supports), be placed in contrib or non-free, simply because its
> > description mentions those services?

Yes, thank you for this summary.  One correction: I don't think anyone claims
that mentioning a non-free service in the description is a problem.
Recommending it is a different story.

It was also mentioned somewhere (here or on -devel, I don't remember) that RMS
agreed that an ICQ client can still be free software, even if there is no free
server.  I agree with that.  But being free is not enough to be in main.  I'm
not saying that an ICQ client should be in non-free.  It should be in contrib
(if it is free software).  That does not conflict with RMS's view that it is
free software.

> The point that I think may not yet be clear enough is that if the answer
> to 2 is that such software should not be moved to contrib (as has
> historically always been the case), the answer to 1 *also* has to be that
> the software is not moved to contrib.

I don't agree that this automatically follows.  You make a good argument, but
it is still a policy choice to do one or the other.

> Because the way you get software of type 2 is that it uses a variety of
> libraries of type 1, so if those libraries are moved to contrib, the main
> software of type 2 would also have to be moved to contrib.
> 
> Writing a library specifically to interact with a non-free service is
> *good software engineering* (do one thing and do it well), and the correct
> way to implement software of type 2.  So unless you want to see all
> software of type 2 kicked out of Debian, at least libraries of type 1 also
> need to be allowed in Debian.

That depends on the reasoning for letting 2 be in main.  It was my impression
that it is a matter of convenience: ideally, we have a clear separation of free
and non-free software.  Software of type 2 would then need a plugin system and
the part interacting with the non-free service would be in contrib, while the
rest can be in main.  This is done by several programs, including the Linux
kernel.  Debian is often a driving force behind such splits, and I am proud of
that.

But before the non-free parts were removed from the main Linux binary, it was
software of type 2, and it was still in main.  With your logic,
linux-firmware-nonfree should now also be in main, because it was acceptable in
main when it was part of the kernel-image package.  That is obviously not
correct: the entire reason for splitting the package was to put it in non-free.

Following this logic, it seems logical to me that we can accept non-free
interfacing programs (and libraries) in main as a workaround for the bug that
the non-free part cannot be split yet.  However, it is a bug, it should be
fixed (when someone considers it important enough to work on it) and when it is
fixed, the plugin library should indeed move to non-free.

> I believe this would be hugely counter-productive for free software.  It
> would hurt us way more than it would hurt proprietary services.

I don't care about hurting proprietary services, so I'm also not interested in
knowing who is hurt more.  If it hurts us, we shouldn't do it.  But I disagree
that it does.  I think in the long run, making Debian free not only in terms of
what runs on the local cpu, but also what runs remotely, would be beneficial
for software freedom overall.  Especially because many services are moved to
the network, it means that local software is less and less relevant.  If we
ignore remote software for the purpose of our rules, we can soon as well not
have rules.

Thanks,
Bas

P.S: I just wrote a post on -devel explaining that I do not mean to say our
rules should apply to external software.  If that is not clear when reading
this post, please read that post for clarification.

[toc] | [prev] | [next] | [standalone]

#9433 — Re: Are online services also software for Debian's rules?

[Multipart message — attachments visible in raw view] — view raw

Hi,

you are running this on a computer with non-free software (*). Should everything
now be in contrib?

Or can we maybe rather bury this thread?


(*) all hardware includes non free software… at least all, which is assembled 
into a "computer". You surely find some hardware pieces with only free software
on them, but I challange you to find such a computer.

-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#9434 — Re: Are online services also software for Debian's rules?

[Multipart message — attachments visible in raw view] — view raw

On Mon, Aug 14, 2017 at 08:51:06AM -0400, Holger Levsen wrote:
> you are running this on a computer with non-free software (*). Should everything
> now be in contrib?

No, I explained before that I think we should be pragmatic.

> Or can we maybe rather bury this thread?

I do not see how "you run non-free software" should imply "you cannot care
about software freedom in anything, ever".

If there is disagreement about what software freedom means, I think it is
important that we know each other's positions.  We may eventually agree to
disagree, but at the moment I don't think we understand each other yet.

If you don't care, of course feel free to ignore the thread.  But please don't
tell others that they must not talk about it.

Thanks,
Bas

[toc] | [prev] | [next] | [standalone]

#9435 — Re: Are online services also software for Debian's rules?

[Multipart message — attachments visible in raw view] — view raw

On Mon, Aug 14, 2017 at 01:07:32PM +0000, Dr. Bas Wijnen wrote:
> > you are running this on a computer with non-free software (*). Should everything
> > now be in contrib?
> 
> No, I explained before that I think we should be pragmatic.
We already were, before this discussion.



-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#9436 — Re: Are online services also software for Debian's rules?

On Sun, Aug 13, 2017 at 05:29:20PM -0700, Russ Allbery wrote:
> "Dr. Bas Wijnen" <wijnen@debian.org> writes:
> > Also, I don't want to move lots of software to contrib.  I would much
> > rather have it fixed by removing the support for the non-free services,
> > or by having plugin systems that allow only the non-free-interfacing
> > part to be in contrib.
> 
> I believe this would be hugely counter-productive for free software.  It
> would hurt us way more than it would hurt proprietary services.

I fully agree with Russ' assessment of the situation.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

[toc] | [prev] | [next] | [standalone]

#9437 — Re: Are online services also software for Debian's rules?

On 8/14/17 5:42 AM, Marc Haber wrote:

> On Sun, Aug 13, 2017 at 05:29:20PM -0700, Russ Allbery wrote:
>> "Dr. Bas Wijnen" <wijnen@debian.org> writes:
>>> Also, I don't want to move lots of software to contrib.  I would much
>>> rather have it fixed by removing the support for the non-free services,
>>> or by having plugin systems that allow only the non-free-interfacing
>>> part to be in contrib.
>> I believe this would be hugely counter-productive for free software.  It
>> would hurt us way more than it would hurt proprietary services.
>>

Who's us?  Developers?  Distro managers?  Packagers?  Users? Somebody else?

And is "who gets hurt?" really the right question?  Isn't it more about 
who are "we" serving,
and what best serves their interests.

(Me, I'm primarily a user & sys admin - I care most
about convenience & reliability.  Hurting proprietary services is pretty 
low on my list of priorities.)

Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]

#9438 — Re: Are online services also software for Debian's rules?

[Multipart message — attachments visible in raw view] — view raw

On Mon, Aug 14, 2017 at 10:32:57AM -0700, Miles Fidelman wrote:
> > > > Also, I don't want to move lots of software to contrib.  I would much
> > > > rather have it fixed by removing the support for the non-free services,
> > > > or by having plugin systems that allow only the non-free-interfacing
> > > > part to be in contrib.
> > > I believe this would be hugely counter-productive for free software.  It
> > > would hurt us way more than it would hurt proprietary services.
> > > 
> 
> Who's us?  Developers?  Distro managers?  Packagers?  Users? Somebody else?
Yes.

> And is "who gets hurt?" really the right question?  Isn't it more about who
> are "we" serving,
> and what best serves their interests.
Yes, and hurting someone in this context means not serving their
interests.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#9414 — Re: Are online services also software for Debian's rules?

Hi,

On 08/12/2017 11:12 AM, Dr. Bas Wijnen wrote:
> On Sat, Aug 12, 2017 at 10:06:40AM +0200, Christian Seiler wrote:
>> I don't think this is as black and white as you paint it:
> 
> It's certainly not black and white, and as I wrote elsewhere, the line can
> move.  But there is a line and I don't think it's anywhere near where some
> people seem to draw it.

The point of my email was to illustrate that if I want to come up with a
consistent set of principles that tries to further flesh out the very
vague basic idea of what contrib is, and then start to follow these
principles to their logical conclusion, then I always appear to be able
to come up with examples that just don't seem right to me.

So I don't think there's a clear and easy line to draw.

And to be explicitly clear: there are two types of gray areas: ones
where there is a set of consistent principles can be applied, but the
question where individual examples fall might not always be easy to
decide - and other ones where I don't think it's easy to come up even
with a consistent set of principles. I do believe this here is the
latter case, not just the former.

>> win32-loader probably doesn't run on Wine or ReactOS (though I haven't
>> tried it, so I may be wrong here) - should that be in contrib if that's
>> the case?
> 
> Possibly. 

> The GPL makes an exception for components of the OS (so "it runs on
> Windows" doesn't make things non-free),

Well, nobody claims that contrib is non-free. The GPL clause here 
is more about making an exception to the requirement that all code
that a GPL'd software is linked to also has to be under a license
compatible with the GPL.

> and I think it is reasonable if Debian followed that rule as well.

Could you then not also argue that other exceptions are reasonable?
In the case of the GPL I think the rationale for this exception is
much more clear-cut, because there it talks about specific issues
related to copyright and licensing restrictions.

>> So should the packaging granularity, which in the end is to a certain
>> extent always somewhat arbitrary, dictate whether a program goes into
>> main or contrib?
> 
> In practice, yes.  That's how we do things.  Not because package granularity is
> relevant, but because we don't want to keep software out just because it
> contains the option to interact with something non-free.  But if that option is
> in a package of its own, yes it belongs in contrib.

I personally find this to be completely absurd.

I do believe that packaging granularity as a _consequence_ of the
ability to include certain things in main or not is fine and even
necessary. Take for example the non-free firmware blos that are
split out of the kernel.

But I don't think that packaging granularity as a _reason_ for
either including or dropping the _very same code_, producing the
_very same binaries_, from main is a sensible position.

>> Furthermore, you can go to more extremes: "requires non-free
>> software to work" can also be applied to hardware drivers in more
>> general terms.
> 
> Yes, hardware is complex and I follow the principle of RMS there: if you need
> it to get to a better (more free) place, it's acceptable.

Couldn't you also say that about ICQ clients? That if you are in a
situation where you can't get rid of ICQ it's better to use a free
software client to connect to it?

> Once there are free options, we should recommend them.

I don't think anyone here has an objection to that.

> So that means I don't think all of Debian should be in non-free because there
> are no free cpu designs

Ahem, nobody said anything about non-free here, we're talking about
contrib. That said: for all release archs of Debian there are
actually free implementations of the CPU architecture, in the form
of Qemu. So I don't think this applies here.

> [free CPU designs]
> (although I'm sure there are...)

There are, take a look at RISC-V, for example. [1] And for the
requirement about not requiring non-free software, you don't need
to have a fully free CPU design, just one where the microcode is
free. And I believe that current POWER CPUs fall under that
category. (I may be wrong though.)

>>  - any tool dedicated to updating the firmware of devices where no
>>    free firmware exists for any of the devices it supports should
>>    also be in contrib (I'm talking about devices that have a flash
>>    where the firmware is in, not about firmware loading that takes
>>    place during device initialization)
> 
> Why the distinction?

If you have to load a firmware before the device works you have
to actually ship the blob to the user to make it useful. If the
firmware is already embedded in the hardware the software that
is distributed doesn't have to contain any non-free parts to
make the hardware work.

This distinction is certainly debatable, but is one that has been
made by a lot of people in the past, including the FSF.

(And to be absolutely clear: I'm not trying to advocate for a
specific position, because I don't have a clear position on these
issues. I just think there are flaws in the arguments I've seen
presented here, which I want to point out.)

Regards,
Christian

[1] https://wiki.debian.org/RISC-V

[toc] | [prev] | [next] | [standalone]

#9415 — Re: Are online services also software for Debian's rules?

]] Christian Seiler 

> > So that means I don't think all of Debian should be in non-free because there
> > are no free cpu designs
> 
> Ahem, nobody said anything about non-free here, we're talking about
> contrib. That said: for all release archs of Debian there are
> actually free implementations of the CPU architecture, in the form
> of Qemu. So I don't think this applies here.

Taking this to its absurd extreme gets you, unsurprisingly, absurd
results:

Sure, qemu itself is free, but it'll have to run on an OS which is
either not Debian (in which case, according to some of the arguments in
this thread, it should go to contrib), or Debian.  Eventually, you end
up on the silicon.  However, modern silicon is largely defined by
software, and has supporting software on many chips (all of which is not
in Debian), so effectively requires software outside of Debian to
function (and so should go to contrib).

I don't think our distro would be improved by arguing that all packages
should move to contrib.

Having to structure your code or packaging in a specific way to ensure
you can actually put it in main rather than contrib also does not seem
like something we should encourage; it should be done according to what
makes technical sense.

> > [free CPU designs]
> > (although I'm sure there are...)
> 
> There are, take a look at RISC-V, for example. [1] And for the
> requirement about not requiring non-free software, you don't need
> to have a fully free CPU design, just one where the microcode is
> free. And I believe that current POWER CPUs fall under that
> category. (I may be wrong though.)

Doesn't help if it's not packaged in Debian, though.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.project

csiph-web