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

[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?

[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?

[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?

[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?

[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?

[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?

[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