article

|

As I’ve been experimenting more with IndieWeb ideas on this site, I’ve been kicking around the idea of open sourcing the custom theme I use to power this site (currently called “K”). Part of this is from a desire to start sharing useful code again. I haven’t really put anything out there in years now. Once upon a time, long before the rise of Github, any code I wrote for myself would at least have ended up as a downloadable .zip file.

The other reason I’ve been giving myself, is to add to the pool of MF2-compatible themes available, in an effort to give people more options for deploying Indieweb sites. Right now, the Indeweb wiki only lists a handful of themes as compatible out of the box, so the more that can be added, the better it will be for growing the community.

The thing is, the theme is very much not ready for other people to lay eyes on, in its current state:

  • I (currently) do a bunch of non-standard things under the hood.
  • I’m also not doing a bunch of theme “best practices”. Simply because I’ve not needed to.
  • I’ve not really cared much about testing in browsers beyond the ones I use day to day.
  • A lot of the code has been cobbled together as and when I’ve needed it, so there are loads of “standard” features straight-up not implemented.
  • There’s a tonne of things hard-coded specifically for me. Those would have to be stripped out or altered to be configurable. That’s more code I’d have to write.
  • I’ve hacked up a bunch of dependencies, in the name of optimisation for my own needs. A public release would need to include the full code of these dependencies, or it’ll severely restrict anyone who wants to use the theme.

All in all, there’s quite a lot to do to make the theme usable by anyone who isn’t me. My natural instinct is to hold it back until it’s “ready” but as I’ve been typing this out, I’ve been wondering if I should just go ahead and put the code on Github anyway?

article

|

I received an email from a developer the other day, who had forked the repository for my “IIS Express Here” shell extension on GitHub [editors note – no longer available]. He had noticed there was no license information available in the project, so asked if I could either add a license, or give him written permission to adapt my code and share it to others (as is the spirit of GitHub and OSS).

To be honest, this wasn’t something I’d thought about before, and was a bit of an oversight on my part. I’d not really considered the need to add explicit licenses to my repositories. After all, the code is out there anyway – it’s open to use on GitHub, and I’ve often shared it on this blog… if someone wanted to copy the code, they could, right?

Unfortunately, this creates a grey-area, which some are naturally uncomfortable with. Can I use this code in something else? Can I modify it at all? Do I have to pay royalties if I do?

But licensing is hard, isn’t it? All the different types, with different caveats, liabilities, and legal mumbo-jumbo… well, yes, it can be hard. The good folks at GitHub have a solution: ChooseALicense.com is attempting to demystify open source licenses so you can pick the right one for your project. More than this, when you create a new repository on GitHub, the site will ask if you want to add a template license during the initialisation process:

repo_licenses

Coming back to the developer who emailed me – I mailed him back to let him know that IIS Express Here is now licensed under the MIT license. This fits best with how I see the code and projects I share on this blog (unless noted otherwise) – free for anyone else to use, but with no warranty, so if something goes wrong then I’m not liable and it’s not my responsibility to fix it. I haven’t got around to updating all of my repos with licenses, as I’m evaluating each one in turn, based on my goals and even whether the project is going to archived.

ChooseALicense.com