emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature/package-vc has been merged


From: Philip Kaludercic
Subject: Re: feature/package-vc has been merged
Date: Sun, 13 Nov 2022 20:54:55 +0000

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>>
>>> I translate this my self: Yes both sources contain only free software,
>>> but both contain software that interacts with non-free software.
>>
>> I believe that Stefan explained this, in distinguishing between
>> software
>> that you have to run on your own system and a fixed service that
>> runs on
>> non-free software.  A web browser is not at fault when requesting a
>> website from a non-free web server.
>
> What if the software only implements non-free standards such as Exchange?

The term "non-free" doesn't apply to standards.  How do you read the
source and share modifications of a protocol specification?

>>>> Richard went into that issue in a parallel thread just yesterday:
>>>> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg00792.html:
>>>>
>>>>   Our general policy makes a subtle distinction between these two
>>>> cases:
>>>>
>>>>   1. If a nonfree program FOO is not well known, we don't even
>>>> mention that
>>>>   it exists.  Because we don't want to promote using FOO.
>>>>
>>>>   2. If a nonfree program FOO is well known and widely used,
>>>> something to
>>>>   help and encourage FOO's users to use some GNU packages along with
>>>> FOO
>>>>   is good.
>>>>
>>>>   3. Anything that would encourage the existing users of some GNU
>>>> packages
>>>>   to use FOO with them is bad.
>>>
>>> OK I don't see anything against cooperating with Gnu in Melpa, the
>>> only
>>> difference is the barrier of entry for packages that interact with
>>> non-free systems, especially the amount of questioning that a package
>>> has go too but that is subjective I think.
>>
>> Are you saying that GNU ELPA or MELPA go through more "questioning"?
>
> I'm saying that packages that interface with non-free formats or systems
> have less questioning in Melpa.
> In Elpa a package has to justify why it should be added when it
> interfaces with non-free systems.

I guess that is true, but that is the issue too.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]