Bug#856139: certspotter: long description advertises *unused* commercial service

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Bug#856139: certspotter: long description advertises *unused* commercial service

Jonas Smedegaard
Stuff like s3cmd are tools connecting to cloud services.  Arguably
usable to have tools to free data from the clouds.

...but bug#856139 is, I believe, about a tool advertising a cloud
service which is *not* used by the tool.  Instead that cloud service is
advertised as an option *instead* of installing and using the Free tool.

Anyone having opinions more narrowly on that kind of advertisements?


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#856139: certspotter: long description advertises *unused* commercial service

Philipp Kern-6
On 09.08.2017 23:30, Jonas Smedegaard wrote:
> Stuff like s3cmd are tools connecting to cloud services.  Arguably
> usable to have tools to free data from the clouds.
>
> ...but bug#856139 is, I believe, about a tool advertising a cloud
> service which is *not* used by the tool.  Instead that cloud service is
> advertised as an option *instead* of installing and using the Free tool.
>
> Anyone having opinions more narrowly on that kind of advertisements?

And then you go to the bug and you see that it degenerated into a "if it
uses a non-free service, it should go into contrib" subdiscussion. Since
when do we believe that? Neither the DFSG nor the Social Contract would
imply that you need to have a free server for an API client
implementation. Now, I understand that this would be desirable and we
should encourage it but we shouldn't just move goal posts willy-nilly.

The only crucial sentence might be this one from §2.2.2 in the policy:

"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."

The policy isn't something we voted upon. Do people really understand
that this means tools calling an API on the Internet would need to be in
contrib? I don't think I agree with this non-free'ization of Debian.
Stuff like licq never belonged into contrib either, despite its main
purpose back then being to connect to the ICQ (and MSN?) services.
Someone wrote a Free client implementation, hence we should offer it to
our users. I could pull other strawmans like "what about tools that
connect to the telephone network, which is non-free?". Where would we
even draw that line?

Kind regards
Philipp Kern


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#856139: certspotter: long description advertises *unused* commercial service

Tobias Frost-2
Am Donnerstag, den 10.08.2017, 12:45 +0200 schrieb Philipp Kern:

> The only crucial sentence might be this one from §2.2.2 in the
> policy:
>
> "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."
>
> The policy isn't something we voted upon. Do people really understand
> that this means tools calling an API on the Internet would need to be
> in
> contrib? I don't think I agree with this non-free'ization of Debian.
> Stuff like licq never belonged into contrib either, despite its main
> purpose back then being to connect to the ICQ (and MSN?) services.

> Someone wrote a Free client implementation, hence we should offer it
> to
> our users.

Maybe another data point from the game-team which I think is relevant:
When a game-engine is free, but requires to have non-free data to be
usable, it has to go into contrib. If there is free data available,
even it is only a (engine) demo, it can go to main. [1]

> I could pull other strawmans like "what about tools that
> connect to the telephone network, which is non-free?". Where would we
> even draw that line?

--
 tobi


[1] https://wiki.debian.org/Games/Policy#guidelines_for_packaging_game_
engines

> Kind regards
> Philipp Kern
>

Reply | Threaded
Open this post in threaded view
|

Re: Bug#856139: certspotter: long description advertises *unused* commercial service

Jonas Smedegaard-2
In reply to this post by Philipp Kern-6
Quoting Philipp Kern (2017-08-10 06:45:39)

> On 09.08.2017 23:30, Jonas Smedegaard wrote:
> > Stuff like s3cmd are tools connecting to cloud services.  Arguably
> > usable to have tools to free data from the clouds.
> >
> > ...but bug#856139 is, I believe, about a tool advertising a cloud
> > service which is *not* used by the tool.  Instead that cloud service
> > is advertised as an option *instead* of installing and using the
> > Free tool.
> >
> > Anyone having opinions more narrowly on that kind of advertisements?
>
> And then you go to the bug and you see that it degenerated into a "if
> it uses a non-free service, it should go into contrib" subdiscussion.
I agree the discussion degenerated, which is the reason I try rehash
with emphasis in the subject line: I seek opinions on the sanity in
Debian package descriptions including paragraphs solely about non-free
*replacement* of the packaged code.


> Since when do we believe that?

Believe what? Please let us not degenerate the discussion again!


> Neither the DFSG nor the Social Contract would imply that you need to
> have a free server for an API client implementation. Now, I understand
> that this would be desirable and we should encourage it but we
> shouldn't just move goal posts willy-nilly.

DFSG and Social Contract do not explicitly forbid us to mention my
birthday in long descriptions either, even if that would be irrelevant
for most if not all package descriptions as well.


> The only crucial sentence might be this one from §2.2.2 in the policy:
>
> "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."

That section might relate to a degenerated discussion, but does not
really apply to packages mentioning in their package description
services *that* *are* *not* *needed* *at* *all* *for* *any* *use* *of*
*said* *package* - it is only rguably needed for supporting the
existance of the package through creating a revenue stream for the
upstream author of it.


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Whether remotely running software is considered "software" for Debian.

Dr. Bas Wijnen-2
In reply to this post by Philipp Kern-6
Note: this post is not about certspotter at all, so I'm not Cc'ing the bug and
changed the Subject line.

On Wed, Aug 09, 2017 at 05:30:19PM -0400, Jonas Smedegaard wrote:
> Stuff like s3cmd are tools connecting to cloud services.  Arguably
> usable to have tools to free data from the clouds.

Which would be a great example of software that is free interacting with
software that is non-free.  Thus the package with this as its main purpose
should live in contrib.  There's nothing wrong with that.

(Note: I'm not saying s3cmd must be in contrib.  It can work with free servers,
so it can be in main.)

On Thu, Aug 10, 2017 at 12:45:39PM +0200, Philipp Kern wrote:

> On 09.08.2017 23:30, Jonas Smedegaard wrote:
> > ...but bug#856139 is, I believe, about a tool advertising a cloud
> > service which is *not* used by the tool.  Instead that cloud service is
> > advertised as an option *instead* of installing and using the Free tool.
> >
> > Anyone having opinions more narrowly on that kind of advertisements?
>
> And then you go to the bug and you see that it degenerated into a "if it
> uses a non-free service, it should go into contrib" subdiscussion. Since
> when do we believe that? Neither the DFSG nor the Social Contract would
> imply that you need to have a free server for an API client
> implementation. Now, I understand that this would be desirable and we
> should encourage it but we shouldn't just move goal posts willy-nilly.
What seems to be the dispute is whether software that runs on a remote system
is still "software" for the purpose of our rules.  I think it is, especially
considering the trend that almost everything is being moved into the cloud.  If
this continues, the only thing people will still run locally is their web
browser.  I believe Debian's philosophy should be that software running
remotely on behalf of the user should be considered part of the system and thus
free programs interacting with such software should be in contrib if the remote
software is non-free (and there is no free alternative).

> The only crucial sentence might be this one from §2.2.2 in the policy:
>
> "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."

It seems clear to me that a program which is intended to interact with server
software does indeed require that server software to function.  So if there is
no free implementation of the server, then the client cannot be in main.

> The policy isn't something we voted upon.

We codify existing practice in our policy.  If you think it was a mistake to
put this in there, and it needs to be changed, please explain what you believe
it should say instead.  I don't think this part of policy is controversial at
all.

> Do people really understand that this means tools calling an API on the
> Internet would need to be in contrib?

Let's frame that differently: From the point of view of a user who does not
want to deal with non-free software, what is the best solution?  That user will
not have contrib in their sources.list.  So should they see an ICQ client?  I
don't think they should.  You can say that it limits them to not be able to use
ICQ, and surely they care more about that than about not dealing with non-free
software?  No, they don't.  They specifically asked not to see software that
will take them to non-free software, so we should respect their decision and
not sneak clients to non-free servers (without free alternatives) into main.
Of course there are users who care more about not losing functionality, but
those are not the users this is about.  Those users have contrib and non-free
enabled in their sources.list, and thus they will find this software in
contrib.

> I don't think I agree with this non-free'ization of Debian.
> Stuff like licq never belonged into contrib either, despite its main
> purpose back then being to connect to the ICQ (and MSN?) services.

If you agree that the main purpose of the program is to interact with non-free
software, do you not agree that it requires software outside of main to
function?  If you do, please propose new wording for policy.  Do you want to
make an exception for services on the network?  I don't think such an exception
would serve our users.  Those who ask not to see non-free related software
should not see clients to non-free services.  Does that not make sense to you?

> Someone wrote a Free client implementation, hence we should offer it to
> our users.

Yes, we should.  You imply that software in contrib isn't really free.  It is!
The only difference with software from main is that it cannot properly function
in a world where only Debian main is available.  If a maintainer or upstream
cares about that, they should fix the dependency (by convincing the server
upstream to release their code, or by writing a free alternative).  And if they
don't care about it, they should not be offended when their software is in
contrib.  This is exactly what contrib is meant for.

> I could pull other strawmans like "what about tools that connect to the
> telephone network, which is non-free?". Where would we even draw that line?

There certainly are debatable situations.  There always will be. And the line
moves with time: we have different ideas about it than we used to.

The main reason for that is that the world has changed as well.  More and more
software that used to run locally is now offered as online services.  When
users could use Microsoft Office, we said: that's not-free, please use
LibreOffice instead.  Now that Microsoft and others are offering the same kind
of product on a remote server through a web interface, shouldn't we still make
the same argument?  This is software that runs on behalf of the user.  I don't
think Debian should have different rules based on where the hardware that it
runs on is located (the local machine or some remote machine).

Thanks,
Bas

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Simon Richter-2
Hi,

On 12.08.2017 09:19, Dr. Bas Wijnen wrote:

> (Note: I'm not saying s3cmd must be in contrib.  It can work with free servers,
> so it can be in main.)

It can be in main as soon as a free server exists, I think.

   Simon


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Jeremy Stanley
On 2017-08-12 17:51:49 +0200 (+0200), Simon Richter wrote:
> On 12.08.2017 09:19, Dr. Bas Wijnen wrote:
> > (Note: I'm not saying s3cmd must be in contrib. It can work with
> > free servers, so it can be in main.)
>
> It can be in main as soon as a free server exists, I think.

Not that I've personally tested them together, but this would
probably count if someone gets a chance to try:

    https://git.openstack.org/cgit/openstack/swift3/
    https://tarballs.openstack.org/swift3/

It's not packaged in Debian though (at least not yet anyway).
--
Jeremy Stanley

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Marco d'Itri
In reply to this post by Dr. Bas Wijnen-2
On Aug 12, "Dr. Bas Wijnen" <[hidden email]> wrote:

> Which would be a great example of software that is free interacting with
> software that is non-free.  Thus the package with this as its main purpose
> should live in contrib.  There's nothing wrong with that.
There is no such requirement for Debian packages and there has never
been one.
This was settled about 15 years ago, discussing ICQ clients.
Even RMS agreed.

You may argue to introduce one if you feel so inclined, but this kind of
policy does not currently exist.

--
ciao,
Marco

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Ondřej Surý-4
In reply to this post by Dr. Bas Wijnen-2
I fail to see what is the purpose of this thought exercise. Could you first
clearly define the problem/goal/... and only then start finding solutions?

Ondřej


On 12 August 2017 09:19:51 "Dr. Bas Wijnen" <[hidden email]> wrote:

> Note: this post is not about certspotter at all, so I'm not Cc'ing the bug and
> changed the Subject line.
>
> On Wed, Aug 09, 2017 at 05:30:19PM -0400, Jonas Smedegaard wrote:
>> Stuff like s3cmd are tools connecting to cloud services.  Arguably
>> usable to have tools to free data from the clouds.
>
> Which would be a great example of software that is free interacting with
> software that is non-free.  Thus the package with this as its main purpose
> should live in contrib.  There's nothing wrong with that.
>
> (Note: I'm not saying s3cmd must be in contrib.  It can work with free servers,
> so it can be in main.)
>
> On Thu, Aug 10, 2017 at 12:45:39PM +0200, Philipp Kern wrote:
>> On 09.08.2017 23:30, Jonas Smedegaard wrote:
>> > ...but bug#856139 is, I believe, about a tool advertising a cloud
>> > service which is *not* used by the tool.  Instead that cloud service is
>> > advertised as an option *instead* of installing and using the Free tool.
>> >
>> > Anyone having opinions more narrowly on that kind of advertisements?
>>
>> And then you go to the bug and you see that it degenerated into a "if it
>> uses a non-free service, it should go into contrib" subdiscussion. Since
>> when do we believe that? Neither the DFSG nor the Social Contract would
>> imply that you need to have a free server for an API client
>> implementation. Now, I understand that this would be desirable and we
>> should encourage it but we shouldn't just move goal posts willy-nilly.
>
> What seems to be the dispute is whether software that runs on a remote system
> is still "software" for the purpose of our rules.  I think it is, especially
> considering the trend that almost everything is being moved into the cloud.  If
> this continues, the only thing people will still run locally is their web
> browser.  I believe Debian's philosophy should be that software running
> remotely on behalf of the user should be considered part of the system and thus
> free programs interacting with such software should be in contrib if the remote
> software is non-free (and there is no free alternative).
>
>> The only crucial sentence might be this one from §2.2.2 in the policy:
>>
>> "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."
>
> It seems clear to me that a program which is intended to interact with server
> software does indeed require that server software to function.  So if there is
> no free implementation of the server, then the client cannot be in main.
>
>> The policy isn't something we voted upon.
>
> We codify existing practice in our policy.  If you think it was a mistake to
> put this in there, and it needs to be changed, please explain what you believe
> it should say instead.  I don't think this part of policy is controversial at
> all.
>
>> Do people really understand that this means tools calling an API on the
>> Internet would need to be in contrib?
>
> Let's frame that differently: From the point of view of a user who does not
> want to deal with non-free software, what is the best solution?  That user will
> not have contrib in their sources.list.  So should they see an ICQ client?  I
> don't think they should.  You can say that it limits them to not be able to use
> ICQ, and surely they care more about that than about not dealing with non-free
> software?  No, they don't.  They specifically asked not to see software that
> will take them to non-free software, so we should respect their decision and
> not sneak clients to non-free servers (without free alternatives) into main.
> Of course there are users who care more about not losing functionality, but
> those are not the users this is about.  Those users have contrib and non-free
> enabled in their sources.list, and thus they will find this software in
> contrib.
>
>> I don't think I agree with this non-free'ization of Debian.
>> Stuff like licq never belonged into contrib either, despite its main
>> purpose back then being to connect to the ICQ (and MSN?) services.
>
> If you agree that the main purpose of the program is to interact with non-free
> software, do you not agree that it requires software outside of main to
> function?  If you do, please propose new wording for policy.  Do you want to
> make an exception for services on the network?  I don't think such an exception
> would serve our users.  Those who ask not to see non-free related software
> should not see clients to non-free services.  Does that not make sense to you?
>
>> Someone wrote a Free client implementation, hence we should offer it to
>> our users.
>
> Yes, we should.  You imply that software in contrib isn't really free.  It is!
> The only difference with software from main is that it cannot properly function
> in a world where only Debian main is available.  If a maintainer or upstream
> cares about that, they should fix the dependency (by convincing the server
> upstream to release their code, or by writing a free alternative).  And if they
> don't care about it, they should not be offended when their software is in
> contrib.  This is exactly what contrib is meant for.
>
>> I could pull other strawmans like "what about tools that connect to the
>> telephone network, which is non-free?". Where would we even draw that line?
>
> There certainly are debatable situations.  There always will be. And the line
> moves with time: we have different ideas about it than we used to.
>
> The main reason for that is that the world has changed as well.  More and more
> software that used to run locally is now offered as online services.  When
> users could use Microsoft Office, we said: that's not-free, please use
> LibreOffice instead.  Now that Microsoft and others are offering the same kind
> of product on a remote server through a web interface, shouldn't we still make
> the same argument?  This is software that runs on behalf of the user.  I don't
> think Debian should have different rules based on where the hardware that it
> runs on is located (the local machine or some remote machine).
>
> Thanks,
> Bas


Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Ben Finney-3
In reply to this post by Dr. Bas Wijnen-2
"Dr. Bas Wijnen" <[hidden email]> writes:

> What seems to be the dispute is whether software that runs on a remote
> system is still "software" for the purpose of our rules.

That is not in dispute, it seems to me. The rules of the Debian Project
can only bind what the Debian Project does.

The Debian Project could moot rules about what the project will do with
regard to software that runs on a remote system. While there are trends,
I don't think such rules exist yet, or if they do you haven't shown us
what rules you're referring to.

The Debian Project does have rules about software *in Debian*, as
described in, for example, our Social Contract.

I hope we can agree that the Social Contract's rules about software in
Debian do not have any power to restrict software running on remote
systems (unless they also get their software from Debian).

> I think [software that runs on a remote system] is [software for the
> purpose of the Debian Project's rules], especially considering the
> trend that almost everything is being moved into the cloud.

Which of the Debian Project's rules are you referring to there? Can you
show from where in those rules you draw this interpretation?

> I believe Debian's philosophy should be that software running remotely
> on behalf of the user should be considered part of the system

By that philosophy, if person Foo connects to a system I am operating on
the internet, the rules person Foo has chosen to accept are also binding
on me? Even if I do not accept those rules?

If not, please explain where that interpretation of your statement is
inaccurate.

> It seems clear to me that a program which is intended to interact with
> server software does indeed require that server software to function.
> So if there is no free implementation of the server, then the client
> cannot be in main.

Maybe so, but that appears to be a different position: that the Debian
Project's rules apply to software in Debian which interacts with remote
systems.

That's very different from stating that the remote system's software is
also part of Debian and therefore subject to the Debian Project's rules.

Please help by clarifying which of those positions you hold.

--
 \          “One time I went to a drive-in in a cab. The movie cost me |
  `\                              ninety-five dollars.” —Steven Wright |
_o__)                                                                  |
Ben Finney

Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Dr. Bas Wijnen-2
On Mon, Aug 14, 2017 at 08:58:00AM +1000, Ben Finney wrote:
> "Dr. Bas Wijnen" <[hidden email]> writes:
>
> > What seems to be the dispute is whether software that runs on a remote
> > system is still "software" for the purpose of our rules.
>
> That is not in dispute, it seems to me. The rules of the Debian Project
> can only bind what the Debian Project does.

Yes, I agree of course.

> The Debian Project could moot rules about what the project will do with
> regard to software that runs on a remote system. While there are trends,
> I don't think such rules exist yet, or if they do you haven't shown us
> what rules you're referring to.

I'm referring to policy 2.2, which lists what software belongs in main and what
belongs in contrib.  While this is not voted on and it does not follow directly
from the SC, I thought there was agreement that what's in Policy 2.2 is a good
way to determine where software should go.  In particular, if it is free, but
requires software outside of main to do its job, then it should go in contrib.

People are arguing here that "It requires a network server that is not in main"
is fundamentally different from "it requires local software that is not in
main".  I think they are equivalent; server software is still software and I
don't see why it running remotely suddenly makes it acceptable to depend on it.

> I hope we can agree that the Social Contract's rules about software in
> Debian do not have any power to restrict software running on remote
> systems (unless they also get their software from Debian).

Yes, this is about whether our packages should be in main or contrib.  External
software may influence that, but the result is a rule about our package, not
about the external software.

> > I think [software that runs on a remote system] is [software for the
> > purpose of the Debian Project's rules], especially considering the
> > trend that almost everything is being moved into the cloud.
>
> Which of the Debian Project's rules are you referring to there? Can you
> show from where in those rules you draw this interpretation?

Policy 2.2.  So again, I'm not saying the rules apply to the external software,
I'm just saying that the external software is indeed software and therefore
depending on it requires a package to be moved to contrib if the external
software is not packaged in Debian (main).

> > I believe Debian's philosophy should be that software running remotely
> > on behalf of the user should be considered part of the system
>
> By that philosophy, if person Foo connects to a system I am operating on
> the internet, the rules person Foo has chosen to accept are also binding
> on me? Even if I do not accept those rules?

Sorry, that is not what I meant.  What I mean with "part of the system" is that
it should be taken into account when deciding what to do with our software.  So
if Foo has chosen to always wear a hat while running /bin/bash, and that is
their shell on your system, then they must not only wear a hat when running
bash locally, but also when they log in at your system.

You don't need to do anything, and you are obviously not bound by their rules.
But your system does mean that they need to do something (if they want to
follow their own rules).

Similarly, if a client program's purpose is to connect to a server that is not
in main, the server operator doesn't need to do anything, but the fact that it
is not in main means (IMO, but apparently that is disputed) that the client
must be in contrib.

> > It seems clear to me that a program which is intended to interact with
> > server software does indeed require that server software to function.
> > So if there is no free implementation of the server, then the client
> > cannot be in main.
>
> Maybe so, but that appears to be a different position: that the Debian
> Project's rules apply to software in Debian which interacts with remote
> systems.
>
> That's very different from stating that the remote system's software is
> also part of Debian and therefore subject to the Debian Project's rules.
>
> Please help by clarifying which of those positions you hold.
Yes, that was unclear.  I meant "part of the system" in the way that you need
to consider all forces in a system if you want to find the acceleration on an
object.  It was not my intention to imply that we have any say over the
external software.

Thanks for your questions, I hope my answers make my position more clear.

Thanks,
Bas

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Ben Finney-3
"Dr. Bas Wijnen" <[hidden email]> writes:

> I'm referring to policy 2.2, which lists what software belongs in main
> and what belongs in contrib. While this is not voted on and it does
> not follow directly from the SC, I thought there was agreement that
> what's in Policy 2.2 is a good way to determine where software should
> go. In particular, if it is free, but requires software outside of
> main to do its job, then it should go in contrib.

The parts of Policy §2.2 relevant to this appear to be:

    §2.2.1 “The main archive area”

    […]
    In addition, the packages in _main_
    * must not require or recommend a package outside of _main_ for
      compilation or execution (thus, the package must not declare a
      [dependency relationship] on a non-_main_ package)
    […]

    §2.2.2 “The contrib archive area”

    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.

    […]
    Examples of packages which would be included in _contrib_ are:
    * free packages which require _contrib_, _non-free_ packages or
      packages which are not in our archive at all for compilation or
      execution
    […]

The language is clear that it is talking about dependency in the sense
of requiring the program installed on the system in order for the
program to build or execute.

> People are arguing here that "It requires a network server that is not
> in main" is fundamentally different from "it requires local software
> that is not in main".

I don't know of any program even proposed for Debian that would require
a network server in order to build or execute that program. So yes, that
is a distinction that is salient in the above Policy language.

> I think they are equivalent; server software is still software and I
> don't see why it running remotely suddenly makes it acceptable to
> depend on it.

You appear to be using “depend” here to mean “without this the program
*is not useful*”.

That is not a distinction relevant to the above Policy sections. They
speak only to whether the program will build or execute.

Whether the program does something useful is not relevant for the
categorisation into different archive areas, as laid out in the above
Policy sections.

> Policy 2.2. So again, I'm not saying the rules apply to the external
> software, I'm just saying that the external software is indeed
> software and therefore depending on it requires a package to be moved
> to contrib if the external software is not packaged in Debian (main).

The text of the above Policy sections uses “depend” and “require” in the
sense only for the cases they explicitly state: that of building the
program or executing it.

> Similarly, if a client program's purpose is to connect to a server
> that is not in main, the server operator doesn't need to do anything,
> but the fact that it is not in main means (IMO, but apparently that is
> disputed) that the client must be in contrib.

The language in Policy §2.2 does not relate to any program's purpose at
all.

Policy experts may correct me, but I find that your interpretation does
not fit what is written there.

--
 \      “When I was born I was so surprised I couldn't talk for a year |
  `\                                        and a half.” —Gracie Allen |
_o__)                                                                  |
Ben Finney

Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Dr. Bas Wijnen-2
On Tue, Aug 15, 2017 at 08:46:43AM +1000, Ben Finney wrote:
> The language is clear that it is talking about dependency in the sense
> of requiring the program installed on the system in order for the
> program to build or execute.

I think the mention of package dependencies is an incomplete list of examples.
But even if it was meant to be complete, thinking for a moment about the
purpose of Debian should make clear that your interpretation cannot be correct:

The reason we have the rules is because we care about freedom.  That doesn't
suddenly end when a program runs on a different server.

Consider the following: unrar-nonfree contains some software which is non-free
and can therefore not be in main.  The reason we don't put it in main is that
we want users who care about freedom to not even see this software.  Agreed?

Now what would be the result of moving this non-free part to a network server?
In terms of freedom there are no benefits to this.  The user is still using the
non-free software, but now they can also be tracked by the server admin, and
they can't use a debugger to hack it, should they want to.  So it is 100% bad
for them.

However, according to your logic, because it is no longer running on your own
cpu, this change would allow unrar-nonfree to go into main.  You do agree that
this is not a sensible result of making software worse, right?

> > I think they are equivalent; server software is still software and I
> > don't see why it running remotely suddenly makes it acceptable to
> > depend on it.
>
> You appear to be using “depend” here to mean “without this the program
> *is not useful*”.

Most programs in contrib can build and run without non-free software.  They
will just immediately produce an error message.  Our users would describe that
as depending on the non-free software.

> The language in Policy §2.2 does not relate to any program's purpose at
> all.

What do you think the purpose of policy is, if not to ensure that our software
gives freedom to our users?

Thanks,
Bas

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Philipp Kern-6
On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote:
> Consider the following: unrar-nonfree contains some software which is non-free
> and can therefore not be in main.  The reason we don't put it in main is that
> we want users who care about freedom to not even see this software.  Agreed?

Ex falso quodlibet?

Archive areas serve a purpose of grouping and indeed everything that is
not main is not part of the distribution. But I don't think the purpose
of the separate areas is to hide anything.

> Now what would be the result of moving this non-free part to a network server?
> In terms of freedom there are no benefits to this.  The user is still using the
> non-free software, but now they can also be tracked by the server admin, and
> they can't use a debugger to hack it, should they want to.  So it is 100% bad
> for them.
>
> However, according to your logic, because it is no longer running on your own
> cpu, this change would allow unrar-nonfree to go into main.  You do agree that
> this is not a sensible result of making software worse, right?

I think such a package would fail other sanity checks (the existence of
a free implementation of the algorithm being one of them - there's no
right to be included in the distribution).

In my view a more interesting thought example would be DRM: What about
an DFSG-compliant module that communicates with a remote license server
returning encryption keys. There's not an inherent need for a DRM module
to be Closed Source, given that the Linux platform does not offer any
security guarantees against Reverse Engineering and leaking the key
material anyway.

Would that be acceptable for main? Would the existence of a free server
implementation change the opinion, even though it likely would not help
the media files you intend to view?

At the same time: As long as programs are talking to an API - even if
RE'ed - and doing so lets users accomplish their tasks at hand and the
programs in question are completely DFSG-compliant, I think we should
carry them in main if they provide a benefit.

We have lots of historic precedent in this area. What are we going to do
otherwise? Proof for every program that there's a way to use them either
entirely disconnected or against a free server/device? What about
proprietary hardware connected over, say, USB? Would we remove the
corresponding drivers from the kernel? Where would we stop on this
slippery slope?

>> The language in Policy §2.2 does not relate to any program's purpose at
>> all.
> What do you think the purpose of policy is, if not to ensure that our software
> gives freedom to our users?

The agreed-upon baseline is the DFSG which does not offer this premise
you interpret as a guarantee, though.

Kind regards
Philipp Kern


signature.asc (523 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Dr. Bas Wijnen-2
On Sat, Aug 19, 2017 at 06:21:23PM +0200, Philipp Kern wrote:

> On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote:
> > Consider the following: unrar-nonfree contains some software which is non-free
> > and can therefore not be in main.  The reason we don't put it in main is that
> > we want users who care about freedom to not even see this software.  Agreed?
>
> Ex falso quodlibet?
>
> Archive areas serve a purpose of grouping and indeed everything that is
> not main is not part of the distribution. But I don't think the purpose
> of the separate areas is to hide anything.
Let me put it differently then: for me, one of the major benefits of Debian
over (most of) our derivatives is that I can set the system up in a way that
allows me to live in a free software bubble.  Is there a non-free alternative
to my free program?  I don't care, and I'm happy that it doesn't show up in my
package list.  Is there a program that is only useful in conjunction with a
non-free program?  Same thing.

So I'm not talking about hiding in the sense of "let's make sure people will
not find this", but instead in the sense of "let's allow people to not be
bothered by those packages".

> > Now what would be the result of moving this non-free part to a network server?
> > In terms of freedom there are no benefits to this.  The user is still using the
> > non-free software, but now they can also be tracked by the server admin, and
> > they can't use a debugger to hack it, should they want to.  So it is 100% bad
> > for them.
> >
> > However, according to your logic, because it is no longer running on your own
> > cpu, this change would allow unrar-nonfree to go into main.  You do agree that
> > this is not a sensible result of making software worse, right?
>
> I think such a package would fail other sanity checks (the existence of
> a free implementation of the algorithm being one of them - there's no
> right to be included in the distribution).
I'm glad you agree that it fails sanity checks.  However, can you find a rule
that actually forbids it?  If a maintainer were to do this, how would you argue
that their package cannot go in main?

The two arguments you mention don't work:

No free implementation: That's what this discussion is all about.  For all the
real examples that have been mentioned in this thread (amazon s3, icq), someone
has noted that there actually is a free implementation of the server software.
Which as far as I understand means everybody agrees (I know I do) that that is
enough to allow the package in main.  The question is if a package can be in
main if it requires a non-free service.  Even if that requirement cannot be
written as a package dependency because it doesn't run on the same machine.
Because if it does, policy is very clear.  If it doesn't, it seems obvious to
me that the same principle still stands and it must not be in main, but
apparently others disagree.

No right to be included: we're assuming that a maintainer wants to include this
in Debian and they don't need a right, they can just do it if nobody stops
them.  So we still need a reason to stop them.

> In my view a more interesting thought example would be DRM: What about
> an DFSG-compliant module that communicates with a remote license server
> returning encryption keys. There's not an inherent need for a DRM module
> to be Closed Source, given that the Linux platform does not offer any
> security guarantees against Reverse Engineering and leaking the key
> material anyway.
>
> Would that be acceptable for main?

You seem to think that I want to kick everything out of main that is capable of
interacting with non-free software?  If so, you are mistaken.  I want to kick
things out of main if the _only_ way to use (major parts of) it is by
interacting with non-free software (and I don't care on what machine that is
running).

> Would the existence of a free server implementation change the opinion, even
> though it likely would not help the media files you intend to view?

Yes, of course.  That would mean that it is possible to make use of the
software without interacting with non-free software.  Again, my goal here is
not to stop people from using non-free software; it is to make sure people who
don't want to use it will not have to decide that they don't want to use this
package.  They made that decision when leaving contrib out of their
sources.list and Debian should respect that choice.

> At the same time: As long as programs are talking to an API - even if
> RE'ed - and doing so lets users accomplish their tasks at hand and the
> programs in question are completely DFSG-compliant, I think we should
> carry them in main if they provide a benefit.

How is that not true for my unrar-nonfree example?  I'm assuming an API has
been set up for the communication between the free client and the non-free
server.  It seemed that you agreed that such a client should still not be
allowed in main.  But why not?  If you think "talking to an API for which only
a non-free server exists" is not a blocker, what is the blocker that keeps the
client of this split version of unrar-nonfree out of main?

> We have lots of historic precedent in this area. What are we going to do
> otherwise?

It wouldn't be the first time that we decided to follow our rules more strictly
than we have previously done.  In this case, I'm not even sure if it would make
any difference for any current package.  I am not aware of any package that
would be impacted by clarifying that "None of the packages in the main archive
area require software outside of that area to function" does in fact apply to
software on a server contacted through the network as well.  (I also wasn't
aware that this was more strict than the interpretation in recent history.)

> Proof for every program that there's a way to use them either
> entirely disconnected or against a free server/device?

This isn't about forcing everyone to prove that they are allowed in main.  It's
about agreeing on what the rules are, so that when a package violates them it
can be recognized and handled.  And a temporary solution can also be to ignore
the problem.  But we should at least agree that it is a problem.

This is similar to the dissident and desert island tests.  We don't need to go
through our packages to see if they pass.  We just need to agree that when
someone points out they don't pass, it is a problem that needs fixing.

> What about proprietary hardware connected over, say, USB? Would we remove the
> corresponding drivers from the kernel? Where would we stop on this slippery
> slope?

Hardware is indeed a tough issue.  I would love to see a world where free
hardware is so abundant that it would be reasonable to require it.  But that is
not the world we currently live in.  So for now, we'll have to live with that.

I agree that it is a slope, and perhaps it is slippery.  But that doesn't mean
we shouldn't go on it at all.  Because that would mean abandoning free software
entirely, and I'm sure you agree that isn't the solution either.  So
discussions like this one are important to see where we stand on this slope.
There will always be a programs that are clearly allowed in main and those that
are clearly not allowed.  And some for which it isn't so clear.  And over time,
some packages will change from one side to the other.  Because the world
changes.

> >> The language in Policy §2.2 does not relate to any program's purpose at
> >> all.
> > What do you think the purpose of policy is, if not to ensure that our software
> > gives freedom to our users?
>
> The agreed-upon baseline is the DFSG which does not offer this premise
> you interpret as a guarantee, though.

You are not answering the question.  If I see a rule in our Policy, I
understand the reason behind that rule and I can understand that the rule also
applies to a case which isn't made so explicit in the text.  You seem to say
that the letter of the text is the only thing that counts and even if it makes
no sense, the document must be followed to the letter.

I'm sure you don't think that the above description is an accurate
representation of your position.  However, it is unclear to me what your
position is.  Can you clarify?

Thanks,
Bas

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Andrey Rahmatullin-3
On Sun, Aug 27, 2017 at 10:20:27AM +0000, Dr. Bas Wijnen wrote:
> Let me put it differently then: for me, one of the major benefits of Debian
> over (most of) our derivatives is that I can set the system up in a way that
> allows me to live in a free software bubble.  
So you don't update the non-free software in your CPU?

> No free implementation: That's what this discussion is all about.  For all the
> real examples that have been mentioned in this thread (amazon s3, icq), someone
> has noted that there actually is a free implementation of the server software.
Did anyone realy mention a free implementation of the ICQ server?

> Which as far as I understand means everybody agrees (I know I do) that that is
> enough to allow the package in main.
No, we happily had s3cmd in main even before someone found a free server
implementation.
Not to mention ICQ.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Dr. Bas Wijnen-2
On Sun, Aug 27, 2017 at 04:00:54PM +0500, Andrey Rahmatullin wrote:
> On Sun, Aug 27, 2017 at 10:20:27AM +0000, Dr. Bas Wijnen wrote:
> > Let me put it differently then: for me, one of the major benefits of Debian
> > over (most of) our derivatives is that I can set the system up in a way that
> > allows me to live in a free software bubble.  
> So you don't update the non-free software in your CPU?

I suppose so.  Are you saying that a Debian system where only main is enabled
is unsafe?  If that is correct, it is a huge problem that that is the default
setup we ship, don't you think?

> > No free implementation: That's what this discussion is all about.  For all the
> > real examples that have been mentioned in this thread (amazon s3, icq), someone
> > has noted that there actually is a free implementation of the server software.
> Did anyone realy mention a free implementation of the ICQ server?

Yes, I believe so.  I don't care enough to look it up, as it isn't all that
relevant to the discussion.

> > Which as far as I understand means everybody agrees (I know I do) that that is
> > enough to allow the package in main.
> No, we happily had s3cmd in main even before someone found a free server
> implementation.

I did not contradict that.  My statement is that if there is a free
implementation, it is certainly good enough.  The situation without a free
server is obviously not as clear.

Thanks,
Bas

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Andrey Rahmatullin-3
On Mon, Aug 28, 2017 at 06:58:50AM +0000, Dr. Bas Wijnen wrote:
> > > Let me put it differently then: for me, one of the major benefits of Debian
> > > over (most of) our derivatives is that I can set the system up in a way that
> > > allows me to live in a free software bubble.  
> > So you don't update the non-free software in your CPU?
> I suppose so.  Are you saying that a Debian system where only main is enabled
> is unsafe?
Not only that, but also "free software purists often don't understand the
current world".
And it looks like all your hardware has its non-free software installed on
the board and thus not required to be downloaded from Debian non-free.

> If that is correct, it is a huge problem that that is the default setup
> we ship, don't you think?
It is, but solving it most likely means actually violating Debian
principles, unlike things you are complaining about.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Dr. Bas Wijnen-2
On Mon, Aug 28, 2017 at 12:29:07PM +0500, Andrey Rahmatullin wrote:
> On Mon, Aug 28, 2017 at 06:58:50AM +0000, Dr. Bas Wijnen wrote:
> > Are you saying that a Debian system where only main is enabled is unsafe?
> [...]
> > If that is correct, it is a huge problem that that is the default setup
> > we ship, don't you think?
> It is, but solving it most likely means actually violating Debian
> principles,

You cannot be serious...  You believe that if our rules say we should harm our
users, the rules are more important than the users?  Have you not read the
social contract?

Also, I'm interested to hear which rule would be broken if we make it the
default to provide our users with updates that they need to be safe.  If such a
rule exists, I believe it should be changed (because our users are our
priority, as per SC), but I'm not aware that we would break any of our rules.
Please clarify.

Also, as a reminder, I'm still waiting for anyone to answer the unrar-nonfree
question: if the non-free part is split off and placed in the cloud, would the
other part be allowed into main?  In other words, would this be a way for the
unrar-nonfree maintainer to get the package into Debian?  And if not, why not?

Thanks,
Bas

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whether remotely running software is considered "software" for Debian.

Andrey Rahmatullin-3
On Mon, Aug 28, 2017 at 08:55:43AM +0000, Dr. Bas Wijnen wrote:
> > > Are you saying that a Debian system where only main is enabled is unsafe?
> > [...]
> > > If that is correct, it is a huge problem that that is the default setup
> > > we ship, don't you think?
> > It is, but solving it most likely means actually violating Debian
> > principles,
>
> You cannot be serious...  You believe that if our rules say we should harm our
> users, the rules are more important than the users?  
No, I believe our users are more important and so you shouldn't set
arbitrary restrictions on main just so your apt search output could be
untainted.

> Have you not read the social contract?
Have you?

> Also, I'm interested to hear which rule would be broken
"Debian will remain 100% free", "non-free is not part of Debian" etc.

> if we make it the default to provide our users with updates that they
> need to be safe.
But then you will be able to see and install non-free software, isn't that
what you don't want to happen?

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
123