Email list hosting service & mailing list manager

licenses for pre-existing sample implementations Arthur A. Gleckler (21 Feb 2021 23:16 UTC)
Re: licenses for pre-existing sample implementations Marc Nieper-Wißkirchen (22 Feb 2021 07:46 UTC)
Re: licenses for pre-existing sample implementations hga@xxxxxx (22 Feb 2021 11:34 UTC)
Re: licenses for pre-existing sample implementations Marc Nieper-Wißkirchen (22 Feb 2021 12:20 UTC)
Re: licenses for pre-existing sample implementations hga@xxxxxx (22 Feb 2021 13:25 UTC)
Re: licenses for pre-existing sample implementations Lassi Kortela (22 Feb 2021 13:40 UTC)
Re: licenses for pre-existing sample implementations Marc Nieper-Wißkirchen (22 Feb 2021 13:45 UTC)
Re: licenses for pre-existing sample implementations Vladimir Nikishkin (22 Feb 2021 13:54 UTC)
Re: licenses for pre-existing sample implementations Arthur A. Gleckler (22 Feb 2021 16:56 UTC)
Re: licenses for pre-existing sample implementations John Cowan (25 Feb 2021 05:07 UTC)

Re: licenses for pre-existing sample implementations Vladimir Nikishkin 22 Feb 2021 13:54 UTC

>The ideal of free software exists (in the mathematical sense) independently of RMS.

The ideal of free software exists independently of GPL (or, indeed,
any other license).

On Mon, 22 Feb 2021 at 21:45, Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Mo., 22. Feb. 2021 um 14:25 Uhr schrieb <xxxxxx@ancell-ent.com>:
>>
>> RMS and I were roommates when he started the GNU project, and before that allies as I worked for LMI and he was the primary, almost sole maintainer of the MIT fork of the Lisp Machine software we used, so at this point I'd say it's very unlikely you'll be able to change my mind.  And I believe the intolerance of so much of the Free Software community towards the Open Source community, like your claim a neutral position is impossible, does no one any good, one of many reasons I am indeed an opponent of Free Software and use accurate language like "viral" to describe it.
>>
>>
>> I have my own reasons for preferring Open Source to Free Software, but besides minor details like quality and desiring Scheme to be used by as many people as possible they're not germane to the issue of what's best for SRFIs.  If we were to take your principles to heart, why not make SRFIs entirely viral, including the text descriptions?  Is there any principle you hold which means we should even tolerate liberally licensed Scheme software including implementations, seeing as how neutrality towards them is impossible in your viewpoint?
>
>
> The ideal of free software exists (in the mathematical sense) independently of RMS.  I don't perceive the intolerance you have perceived. By saying that a neutral position is impossible, I didn't mean much. Just that every position you choose has its implications.  If you choose a BSD-x license over an xGPL one (or vice versa), you do it because of how much various things matter to you.
>
> As for the whole SRFI process, sure it could make some sense to put the documents under licenses that preserve freedom in the long run, but I doubt that a majority would support such a model. Copyrighting the abstract API itself wouldn't make sense, I think, but the documentation insofar as it may be copied into Scheme implementations.
>
> I don't see why tolerating (whatever this means) "liberally" licensed Schemes should be impossible. It's not the Schemes that are the problem, it is people using them to create unfree software.
>
> Anyway, I don't think such a long discussion belongs here. Feel free to contact me privately if you want to continue it.
>
> Thanks,
>
> Marc
>
>>
>>
>> - Harold
>>
>> ----- Original message -----
>> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
>> Date: Monday, February 22, 2021 6:20 AM
>>
>> Dear Harold,
>>
>> thank you for your input and thoughts although I strongly disagree with you on the main points. Besides, I wouldn't use language like "viral license". Such language is used by opponents of free software and would have been appropriate for Microsoft's 2004 "Get the Facts" campaign.
>>
>> In fact, my point of view is that the xGPL licenses are the more liberal ones because they protect the users' freedom (liberty) in the long run. The BSD licenses don't. They only feed those who do not care about the freedom of software. Those who care have no reason to choose a license that protects the users' freedom.
>>
>> You cannot be neutral. If you choose an xGPL license for your sample implementation, you can influence Scheme implementers positively to choose a license that protects the users' freedom in the long run. If they decline, they cannot use your sample implementation but that's fine. There's no moral obligation for you and your sample implementation to support code that may later be used in a way that damages the users' freedom.
>>
>> For me, it is a very important point. For example, I released my Unsyntax Scheme frontend under the SRFI license because it is used as a sample implementation for a couple of my SRFIs. I would have released it under the, in my opinion, superior GPL if this had been possible with the SRFI process. So explicitly allowing contributors to use the BSD-x but not the xGPL licenses means that the SRFI process discourages contributors to use a license to which we owe a huge part of the software freedom we currently enjoy and which makes sure that this freedom won't be lost.
>>
>> Of course, for you, the long-term users' freedom may not matter that much (or you view it differently than I do), but I can hopefully convince you that it would be bad to enforce your view on every contributor. Likewise, I don't want to remove the option to use the BSD-x licenses; all I want is that the xGPL licenses are on an equal footing.
>>
>> Marc
>>
>> Am Mo., 22. Feb. 2021 um 12:34 Uhr schrieb <xxxxxx@ancell-ent.com>:
>>
>>
>> Is not one of the purposes of SRFIs, Scheme Requests for Implementation, getting them implemented in as many Scheme implementations as possible?
>>
>> If so, viral licenses like the AGPL, GPL, and LGPL are entirely inappropriate, for liberal ones like the BSDs are comparable with all Scheme implementations including those that use viral licenses, whereas if you have a liberally licensed Scheme you'd best not even look at a virally licensed SRFI implementation.
>>
>> Users' freedoms as defined by the Free Software community will still be well protected because the Scheme implementation itself will still be virally licensed, unless I'm missing some way in which a small portion of these Scheme implementations being under a liberal license would or could be used for ill by its developers who are already distributing the rest of it as Free Software.
>>
>> - Harold
>>
>> ----- Original message -----
>> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
>> Date: Monday, February 22, 2021 1:46 AM
>>
>> Dear Arthur,
>>
>> if you specifically allow the BSD licenses, please add the AGPL, GPL and LGPL licenses to the list as well. They are much better for preserving the users' freedom and thus preferable to the BSD licenses in many cases. While the BSD licenses have their own virtues, I think it is wrong to give them precedence to the GPL-derived licenses.
>>
>> Thanks for considering!
>>
>> Best,
>>
>> Marc
>>
>> Am Mo., 22. Feb. 2021 um 00:16 Uhr schrieb Arthur A. Gleckler <xxxxxx@speechcode.com>:
>>
>> Often, SRFI authors write SRFIs that describe features that already exist in one or more Scheme implementations.  Sometimes, writing a portable implementation of a SRFI is difficult or even impossible, but the existing implementation is not licensed under the standard SRFI license.  In order to avoid requiring a completely from-scratch implementation in these and similar cases, I've added an explicit exception to the license section of the SRFI process.  In cases where the SRFI refers to an existing implementation, it's okay for that implementation to be under a different license at the editors' [editor's] discretion.  I'm specifically allowing the BSD 2- and 3-clause licenses.  Note that this applies only to existing implementations.  Sample implementations written from scratch specifically for the SRFI should still use the standard SRFI license.
>>
>> I hope this makes it easier to provide sample implementations of some of the more deeply integrated features.
>>
>>
>>

--
Yours sincerely, Vladimir Nikishkin
(Sent from GMail web interface.)