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

2017-08-14 Thread Andrey Rahmatullin 
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


signature.asc
Description: PGP signature

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

2017-08-14 Thread Miles Fidelman 

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

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

2017-08-14 Thread Marc Haber 
On Sun, Aug 13, 2017 at 05:29:20PM -0700, Russ Allbery wrote:
> "Dr. Bas Wijnen"  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

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

2017-08-14 Thread Andrey Rahmatullin 
On Mon, Aug 14, 2017 at 01:07:32PM +, 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


signature.asc
Description: PGP signature

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

2017-08-14 Thread Dr. Bas Wijnen 
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


signature.asc
Description: PGP signature

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

2017-08-14 Thread Holger Levsen 
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


signature.asc
Description: Digital signature

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

2017-08-14 Thread Dr. Bas Wijnen 
On Sun, Aug 13, 2017 at 05:28:29PM -0700, Russ Allbery wrote:
> Miles Fidelman  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.


signature.asc
Description: PGP signature

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

2017-08-13 Thread Russ Allbery 
Miles Fidelman  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 (r...@debian.org)

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

2017-08-13 Thread Russ Allbery 
"Dr. Bas Wijnen"  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 (r...@debian.org)

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

2017-08-13 Thread Miles Fidelman 

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

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

2017-08-13 Thread Dr. Bas Wijnen 
On Sat, Aug 12, 2017 at 12:07:51PM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 09:12 GMT, "Dr. Bas Wijnen"  :
> > 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


signature.asc
Description: PGP signature

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

2017-08-12 Thread Russ Allbery 
Vincent Bernat  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 (r...@debian.org)

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

2017-08-12 Thread Tollef Fog Heen 
]] Christian Seiler 

> Hi,
> 
> I don't have anything useful to add to your other comments, but:
> 
> On 08/12/2017 02:11 PM, Tollef Fog Heen wrote:
> > ]] Christian Seiler 
> >>> [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.
> 
> Well, if I'm not wrong about POWER, that's supported in Debian
> as a release arch (ppc64el).

I was talking about the microcode for said arch (which doesn't seem to
be packaged, or at least not in main, from a quick apt-cache search).

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

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

2017-08-12 Thread Christian Seiler 
Hi,

I don't have anything useful to add to your other comments, but:

On 08/12/2017 02:11 PM, Tollef Fog Heen wrote:
> ]] Christian Seiler 
>>> [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.

Well, if I'm not wrong about POWER, that's supported in Debian
as a release arch (ppc64el).

Regards,
Christian

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

2017-08-12 Thread Tollef Fog Heen 
]] 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

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

2017-08-12 Thread Vincent Bernat 
 ❦ 12 août 2017 09:12 GMT, "Dr. Bas Wijnen"  :

>> 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)


signature.asc
Description: PGP signature

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

2017-08-12 Thread Christian Seiler 
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

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

2017-08-12 Thread Dr. Bas Wijnen 
On Sat, Aug 12, 2017 at 09:55:17AM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 07:37 GMT, "Dr. Bas Wijnen"  :
> > 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

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

2017-08-12 Thread Vincent Bernat 
 ❦ 12 août 2017 07:37 GMT, "Dr. Bas Wijnen"  :

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


signature.asc
Description: PGP signature

Are online services also software for Debian's rules?

2017-08-12 Thread Dr. Bas Wijnen 
On Sat, Aug 12, 2017 at 08:55:01AM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 06:29 GMT, "Dr. Bas Wijnen"  :
> 
> > 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


signature.asc
Description: PGP signature