Posts from Thursday, December 2nd, 2004

S5 Licensing

Published 13 years, 9 months ago

I’ve gotten a few e-mails and comments to the effect that instead of using a Creative Commons license for S5, I should use GPL instead.  One of the reasons given to me was that the Creative Commons licenses are not considered appropriate for software, according to the Creative Commons folks.

My problem is that I don’t really think of a collection of (X)HTML, CSS, and JavaScript as “software”, so the GPL doesn’t really seem to fit.  Yes, the JS is code, and one could argue that it’s software of a kind, but markup?  Presentational hints?  Not so much.  I feel the same way about the Color Blender: it’s not really software so much as a widget.  A fun widget, perhaps even cool to some people, but still not software in the way that BBEdit or NetNewsWire or any given Web browser is software.

My other problem with GPL is that it’s long and stunningly legalistic.  It kind of has to be, and I think that’s great for the purpose for which it’s intended.  To ‘protect’ things like S5 or the Color Blender, the GPL kind of feels like protecting a kitten with the 82nd Armored Division.  What I like about the CC licenses is that they’re easily understandable; even the “lawyer-friendly” versions are compact and mostly understandable.  In perusing the list of licenses over at the Free Software Foundation, I quickly got a headache.  The one license that seemed the closest fit is the Expat license.  But even there, given the way it’s written, I come up against the question: is a confederation of markup, styles, and client-side code really “software”?

So what to do?  Stick with the CC license?  Move to Expat?  Plunge into GPL-land?  Come up with my own variant license based on Expat or something similarly simple?  I’d be interested to hear people’s opinions—especially those of you who have faced the same question, or a similar question, in the past.

I’m still a little bit bemused that it’s even a question, and a little bit dismayed that ours is the kind of world where I really do have to worry about this sort of thing.

  • Published
  • Categorized under S5
  • 41 responses so far

S5 1.1b1

Published 13 years, 9 months ago

Okay, S5 version 1.1 is now at beta 1 status.  In the process, I’ve rearranged the S5 sub-site a bit.  The testbed is now in a new location that will let me more easily manage version changes, and also keep test files out of the main directory.  The testbed demonstrates, at least right now, various forms of incremental rendering, including both text and image techniques.

There are some changes to note in 1.1b1:

  • The controls div is now a child of the layout div, and is thus no longer structurally confined to the footer.  This makes a few things easier, but it does mean any 1.0 themes are likely to get mangled a bit.  I decided to do this now in order to minimize disruptions.  The structure reference does not reflect this, as it documents v1.0, but will when v1.1 is finalized.  I was able to convert the default theme, I18N, and a new theme to handle this new structure without much trouble.
  • I’ve refactored some of the CSS files to make them more compact.  Nothing earth-shaking, but I thought I should mention it.
  • The slideshow configuration meta elements have been renamed to defaultView and controlVis, and have slightly different accepted values, but otherwise do exactly what they’ve done since they were added.
  • I’ve added an authaffil meta element, with syntax set up to allow multiple authors to be listed.  I’m considering making the value format a little more machine-readable, but we’ll see what you all think first.
  • I fixed the Safari bug where it advanced the slide show when opening an external link.  Yay me.

I’m in the process of setting up an archive for ‘official’ S5 versions, so that you’ll still be able to download the S5 1.0 UI folder even when we’re up to 1.725 or whatever.  This will be in place for the launch of v1.1.  Yes, I hear you: use SourceForge!  I’m abstaining for now, because I don’t have time to figure out how to set up a project on their system, let alone how to fix their UI so it isn’t confusing and frustrating.  Mine may not be much better right now, but at least mine’s easy for me to fix (and I’ll get to it soon, I promise).

The other major addition I have planned is to create a set of guidelines for theme packaging.  For example, every theme should contain a file titled 00_head.txt that contains the head-based elements (links and so forth) that should be used in a presentation file in order to make the theme work.  This will make it much easier for presentation authors to use themes without having to understand the ins and outs of the S5 file structure, and for theme authors to only have to package the files they want to change.  Hopefully that will make more sense once I write the guidelines.

And finally, you may have noticed that I’ve stopped superscripting the 5 in S5.  Practically nobody else was doing it, and it was getting to be a pain even for me to type, so I figured I’d go with the flow.  I’ll change the documentation eventually.

So please test out the testbed and let me know if anything goes seriously awry.  If anyone wants to try hooking up the 1.1b1 UI files to their own presentation, I’d be interested in hearing the results.  Remember, though: make sure your presentation file’s XHTML validates!  If you report problems in an invalid presentation, I’m not going to look at it until the validation errors are corrected.  That’s because the DOM routines depend on well-formed markup, and it would be futile for me to try to debug any problems caused by invalid markup.

With luck, we’ll only need one or two beta cycles before 1.1 can go final.