Sample implementation licences Daphne Preston-Kendal (31 Aug 2024 09:18 UTC)
Re: Sample implementation licences Arthur A. Gleckler (31 Aug 2024 16:12 UTC)
Re: Sample implementation licences Daphne Preston-Kendal (31 Aug 2024 19:12 UTC)
Re: Sample implementation licences Arthur A. Gleckler (31 Aug 2024 19:19 UTC)
Re: Sample implementation licences Marc Nieper-Wißkirchen (31 Aug 2024 20:02 UTC)
Re: Sample implementation licences Daphne Preston-Kendal (31 Aug 2024 20:49 UTC)
Re: Sample implementation licences Daphne Preston-Kendal (31 Aug 2024 20:51 UTC)
Re: Sample implementation licences Arthur A. Gleckler (31 Aug 2024 20:55 UTC)
Re: Sample implementation licences Daphne Preston-Kendal (31 Aug 2024 20:57 UTC)
Re: Sample implementation licences Arthur A. Gleckler (31 Aug 2024 21:01 UTC)
Re: Sample implementation licences Daphne Preston-Kendal (31 Aug 2024 21:33 UTC)
Re: Sample implementation licences Lassi Kortela (01 Sep 2024 08:19 UTC)
Re: Sample implementation licences Philip McGrath (02 Sep 2024 00:00 UTC)

Re: Sample implementation licences Daphne Preston-Kendal 31 Aug 2024 21:33 UTC

On 31 Aug 2024, at 23:01, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:

> On Sat, Aug 31, 2024 at 1:58 PM Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:
>>   Once I have abandoned my copyright and placed the work in the public domain, you can do anything you like. You could even put a copyright notice on it claiming it is your own copyright (but good luck enforcing that)
>
> Where is this coming from, Daphne?  Are you sure that this is a licensing issue?  SRFI has used the MIT license successfully for well over a decade now, and it has not been a problem.  Is it really that important to you?  Licensing issues truly are not what gets in the way of adoption of SRFIs.

My SRFI is going up against a thoroughly entrenched existing library which serves a similar purpose but with which it is not compatible.
This incompatibility is necessary in order to enable a superior design.
The existing library, which is not *badly* designed but simply could not be compatibly extended in the way I wanted, is included with a significant number of Scheme implementations already.
It will therefore be an uphill battle to persuade implementers to include my library instead of (or even as well as) the existing library.
Therefore I want to eliminate as many possible reasons why someone might prefer the existing library to mine.

You are right that there are many reasons implementations choose not to pick up SRFIs.
To give an example:
Performance might be one technical objection; many SRFIs have sample implementations which are not particularly fast. It might be an argument against using my library if it were slow. Therefore I have spent quite a while getting to know the optimization passes of Guile, Chez Scheme, and Loko, in order to tune my implementation to produce fast code – it should be faster than the existing library, and indeed should ideally be a ‘zero-cost abstraction’ in terms of performance at run time, compared to the equivalent hand-written (not macro-generated) code.
(Side note: If anyone knows any other implementation whose optimizers’ output can be as easily examined as these, please let me know (privately, so as not to further derail this thread). I want my code to run reasonably fast on a reasonably average Scheme implementation, not just these implementations which are among the best of breed.)

Another, non-technical reason implementations might not want to bundle a library is licensing. I don’t know if this has ever happened to a SRFI, at least since the MIT licence became standard here.
But the existing library is public domain, and therefore I feel my code will have a disadvantage if it is more encumbered than what I hope it will supplant.

I am just trying to take a systematic approach to removing all possible obstacles to adoption, within the context that I am writing this particular code, and I feel the licence in this case might be one of them.

Daphne