Clawing my attention span back from the void

for much of my code, I want to make it public entirely for educational purposes. I think that, broadly, if any part of what I have currently published made it into corporate use, that would be more funny than anything. projects that I think could be monetized maliciously, such as lfm_embed are licensed under the AGPL, but other than that I mostly code to have fun, and don't care what others do with it.

in service of this, a bit ago I began using the BSD 0-clause license for projects. the problem, as I've learned, with it, is that it is not strictly a public domain dedication in some contexts. I am rather sympathetic to the philosophy behind the WTFPL and similar. I think that terse, easily understood language in software licensing is a good goal to strive for. so, I wrote my own license.

This repository is dedicated entirely to the public domain. The creator
waives all intellectual property rights to the work as much as is
possible in the given jurisdiction.

In other words, do whatever.

THE SOFTWARE IS PROVIDED “AS IS” AND THE AUTHOR DISCLAIMS ALL
WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE
FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

that's one of the earliest forms. the text at the bottom is directly ripped from the BSD 0-clause license, and the public domain dedication is my own. it's pretty simple.

and then someone I know was working on a project, and looking for a simple noncommercial license, that was good for software. in theory the creative commons family will do, though from what I've heard their language around derivative works isn't as good for software as other licenses.

so I wrote them one too.

and then I got to thinking that it would be sick if there were terse licenses that weren't pigeonholed into artistic or software use. if there was something as flexible in terms of use as the CC family, as terse as the WTFPL, BSD0, etc, and usable for multiple creative domains.

so I decided to make that.

TPL

TPL is hosted on 雨hut. it makes use of a simple templating engine and a simple file structure to create configurable small licenses, where the language can be adjusted for every user. the wizard is hosted statically on my tilde.institute domain, and works well.

I don't think this project is nearly in a complete state, but it is functional, which is why I am publishing this. I am no lawyer, and I want the language to be robust, despite its size. I would appreciate all thoughts and criticisms (constructive only) of the language and license offerings that come to mind, either in the mailing list or under this post. help me make this project better.

I do plan to eventually create a system for generating and saving licenses statically, so that a no-js templater can be served over HTTP, Gopher, Gemini, etc, but that is a ways out. for now, the wizard is the only source of truth for licenses.

I hope this can become a robust-ish and useful tool to those who may desire it.

~aleteoryx, signing off

Welp, I'm hosting another thing, but this thing will probably end up being very much so used in the future.

Introducing...

ameHUT(ah may hut), a sr.ht install!

I have a lot of respect for Drew DeVault, and the general philosophy with which he operates. Sourcehut is exemplary of this. It is ascetic software, shipping barely anything to the browser and relying only on Postgres and Redi{s,ct} in the backend. It eschews fancy modern editors for mailing lists and git send-email. Most important for me, it is software built to stay running, and software built to work first and show off later. It is software built to be lightweight and yet capable of scaling with load trivially.

Switching from cgit/soft-serve to this as my main forge feels better, in a way that other, more cluttered programs do not.

SourceHut is also project-focused, not repo-focused. What this means in practice is that docs can be associated with code, without sharing a file tree; announcement feeds can be associated with a number of repos, instead of just one; etc. I find this significantly nicer in terms of organization, and it's a shame GitHub et al. don't have much similar.

As always...

Deployment was a thing!

I spent a week or two setting up the services on a little Alpine box at my house. It proxies via Wireguard to the VPS that runs my core internet services, and I have an Apache macro to manage proxying. Currently, this macro does not account for API proxying, and I will be fixing this... eventually! Currently there are 3 users, myself included, only 1 of which, yours truly, has actually used any of the services, which is to say there is no strong demand for a working API at present time. Wouldn't be hard to get working though lol

SourceHut is built to be easy to shard. Each subdomain is composed of 2+ services, most minimally an API server and webserver. As long as all services can see the same Postgres and Redi{s,ct} databases, it sorta just works. At present moment, I do not have the need to shard, so, naturally, I set the server up on a Core 2 Duo with 2GB of RAM. Does this work? Yes, actually! With minimal stability issues, too! Sourcehut is almost exclusively written in Golang and Python, which accounts for its backend lightweightness. There will probably be an eventual hardware upgrade, but yk, it works for now.

The setup process for each service is roughly the same. Install the package with APK, copy in and tweak the example config from Git, tell the webserver to listen over Wireguard, start everything, test it, and add them to the default runlevel. There were no major issues during it.

So, what works?

Currently the following subdomains work, and run the same-named services as sr.ht:

• amehut.dev
• git.amehut.dev
• hg.amehut.dev
• meta.amehut.dev
• lists.amehut.dev
• todo.amehut.dev

Planned are:

• amehut.page (srht.site)
• paste.amehut.dev
• builds.amehut.dev

The first is unimplemented due to poor documentation(a rarity in this project, as it were). The second is unimplemented because I am lazy. The third requires special treatment and I have yet to provision a VPS for it. I will likely reuse the one that currently powers redmine, and decommission redmine.

At some point, I will be soft-forking the sr.ht project, and changing around the color scheme and some of the marketing details.

Well, this sounds interesting, where can I learn more?

I've put together an FAQ that says mostly the same stuff as this blog, with some extra details thrown in.

Alas, it seems signups are out-of-the-question.

Almost! If you want an account on amehut, and we've interacted before, PM me here or anywhere else. Despite some of the slightly cursed details of the backend, it runs like a dream.

Oh, nice!

IKR! Also when did you learn to type my headings? Ah whatever.

Aleteoryx, signing off.