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)
|
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.