sogaiu

I'm not sure how practical that is and also I'll need to think about whether that's something that should be done.

I'll put down some of my thoughts below based on some research I did recently:

This project put a license in place before the Fedora "decision". AFAIU, the license was put in place in 2021 and Fedora's stance came in 2022.
So far I did not find other distributions (unrelated to Fedora, e.g. Red Hat doesn't count) that reject CC0 for software. For example, I think Debian allows it.
The Fedora spokesperson statement below seems vague in various ways:

The reason for the change: Over a long period of time a consensus has been building in FOSS that licenses that preclude any form of patent licensing or patent forbearance cannot be considered FOSS. CC0 has a clause that says: "No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document."
The impression I got was that Fedora might have decided to make exceptions

2026-01-01

https://github.com/eerohele/pp - Peppy pretty-printer for Clojure data.
https://github.com/brandonbloom/fipp - Fast Idiomatic Pretty Printer for Clojure
https://cljdoc.org/d/zprint/zprint/1.3.0/doc/introduction

zprint is a library and command line tool providing a variety of pretty printing capabilities for both Clojure code and Clojure/EDN structures.
https://clojure.github.io/clojure/clojure.pprint-api.html
https://novaspec.org/cl/22_2_The_Lisp_Pretty_Printer
https://people.cs.aau.dk/~normark/laml-distributions/laml/lib/man/scheme-pretty-printing.html
https://cs.brown.edu/courses/cs173/2008/Manual/reference/pretty-print.html

non-lisp

so regarding tree-shaking, if we put aside the mentioned pr for a moment, and take a look at this bit of text (from here):

As a matter of style, it is also recommended to group small libraries together into "bundles" that are updated, tested, and deployed together. Since Janet libraries are often quite small, the cost of downloading more functionality that one might need isn't particularly high, and JPM can remove unused functions and bindings from generated standalone binaries and images, so there is no runtime cost either.

when i first read this i thought what was being referred to by:

JPM can remove unused functions and bindings from generated standalone binaries and images

was user-defined things and not built-in janet things.

	* repository organization

	* make the main deliverable `<name>.janet` -- the extension is
	important if wanting to be able to use as a library. nicest if
	this deliverable sits in the repository root as well.

	* for libraries, could still have a `<name>` directory that has the
	content `init.janet` and `<name>.janet` for jpm / jeep
	installation, but `<name>.janet` can still be used independently
	as a single file library? would be nice to have `<name>.janet` at

	* description

	create and run certain "tests" that live in comment forms.

	* rationale

	* want some meaningful "tests" / "usages" to co-evolve with
	development from as early as desired with little activation
	effort.

	$ cat sample.janet
	(def a 1)

	$ janet
	Janet 1.40.1-7d672f43 linux/x64/gcc - '(doc)' for help

	repl:1:> (import ./sample)
	@{_ @{:value <cycle 0>} sample/a @{:private true}}

	repl:2:> (import ./sample :export true)

	deps number of projects
	1 22
	2 4
	3 5
	4 1
	5 2
	6 1

	----
	todo

	(defn diff-path
	[left right]
	(var i 0)
	(var done false)
	(def [shorter longer]
	(if (<= (length left) (length right))
	[left right]
	[right left]))
	(for j 0 (length shorter)
	(when (not= (get left j) (get right j))