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 Lassi Kortela 01 Sep 2024 08:19 UTC

In practice (given that public domain legislation is so complicated
internationally) it is imprudent to remove the CC0 boilerplate from a
project. CC0 is much more verbose than most of the popular permissive
licenses. For software, it's less trouble to use a short license.

I wouldn't overthink statements of the form "Copyright <year> so and
so". The world would grind to a halt if imprecise copyright notices
caused substantial problems. They are everywhere.

For code going into a SRFI's sample implementation, maybe dual license
as MIT and CC0, treating CC0 as just another license and using the
standard wording for each license even if it's imprecise. Non-standard
wording is more likely to cause confusion than to prevent it.