I love Pencil Revolution. That is all.

Rob and I have been talking about licensing a bit over the past month or so, and I'm listening to a lot of discussion and debate about software freedom and licensing courtesy of the Free as in Freedom podcast.

So I decided to license the content of this blog. It's possible to use a software license like the GPL for written, "creative" content, just as it's possible to use a license like those from Creative Commons, which were written with "creative" works in mind, for software.

But since what's here is, for lack of a better word, prose, I am choosing a Creative Commons license: the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0) license, the full text of which you can read here.

It means you can use what you see here for non-commercial purposes if you attribute it and share it under the same (or a like-minded) license.

If you do want to use what you see here in a commercial (read: moneymaking) setting, contact me at steven (at) stevenrosenberg (dot) net. We can probably work something out.

What licensing is (and isn't): A lack of a license on your code or content -- seemingly giving no rights -- doesn't "protect" it more than having an actual license. Nor will a license in and of itself keep others from doing things with your content that are in violation of the license.

As Bradley Kuhn often says on Free as in Freedom, sometimes enforcement is required. If you find somebody violating terms of the license under which you have made your work available, you might have to get out there and do some enforcement. The license gives you a legal framework under which to do that enforcement.

Updated: Question -- Should cached HTML be prioritized over dynamic CGI? (see Discussion and Questions below)

Level of difficulty: High

Description

Over the past few years, there has been a trend away from dynamically delivery blogging systems like WordPress and Ode to static-site generators like Pelican, Nikola, Jekyll/Octopress and others.

Everybody is worried that their potential web host won't support the technologies that create and deliver blogs, such as Perl, Python, Ruby on Rails, Node.js, etc., and that dynamic delivery is "costly" in terms of CPU time on the server and actual financial cost for those resources.

Feeding into this is the worry (real or imagined) that goes something like this:

What if my site is Slashdotted, or somehow gets wildly popular, or I become the toast of the Internet? Will Ode/whatever-I'm-using be able to keep up with my overwhelming popularity?

It's generally assumed that a static HTML site with no dynamic elements will hold up the best under this "I'm so popular, I have to wear shades" scenario.

But in the "real" world, we're not all so darn popular. But we want to be ready. For our moment.

WordPress, which features dynamic delivery via PHP, solves this problem with caching plugins. These plugins generally take PHP requests that have been made in the recent past and turns them into temporarily cached static HTML files on the server. In Ode's case, posts and indexes are delivered via Perl/CGI.

When a "popular" (aka recently requested) query is made for an entry or index, the plugin delivers the static file, potentially reducing overall CPU load for the system and better handling increased traffic for a few of the many entries in the filesystem/database. And since the likelihood of a "Slashdot"-style traffic onslaught being limited to a single entry (or very few entries) is very high, this sort of scenario (caching as HTML of recently popular entries) has a high likelihood of making the overall blog site much more efficient.

An Ode caching addin would probably always create cached versions of the main index page (i.e the Home page) and maybe the page that delivers the second 10 posts.

It would also cache any individual posts or category requests that are made in the course of the blog's operation over a given period of time (say a day, hour, week or ??). The addin would write these "popular" requests as static HTML.

With the caching addin active, a request for any Ode content would go "through" the addin. The addin would check a list of static files it has created. If the request matches, that file would be delivered. If the request does not match, the request would be processed via Perl/CGI, and that CGI output would be cached as HTML and added to the caching addin's list.

The caching addin would "flush" the cached HTML and the list on a periodic basis. This could be accomplished via HTML request with the addin flushing based on pre-set rules, or via a timed interval, with time determined by a request to the server.

Discussion and questions

• Would a caching addin require more CGI overhead than it would save? (There would still be some CGI required to run the addin and determine whether a request could be delivered via static HTML.)

• Maybe the caching code and the resulting static HTML files should be "baked in" to Ode a little more than a traditional addin. By this I mean that an initial request for an index or post could immediately check either a list, or the filesystem itself, for static HTML. If that file is not present, the CGI request would be initiated, and the page would be delivered dynamically and subsequently added to the cache. This way, Ode would "favor" the cached HTML and only initiate a "full" CGI request when necessary.