Please read: Releasing my Ruby port of Inform 6 under GPLv3

Authoring Inform 6
1

TL;DR Is it cool with you all if I release a faithful Ruby port of Inform 6 under the GPLv3?

Ever since I was 7, I have been enthralled with interactive fiction.

Ever since I was 16, I have been programming with Inform.

Over the past three and a half years I have been steadily pouring hours into a personal project after my normal 8-5 software development gig at the company at which I am employed.

My project has been the development of a nearly verbatim Ruby port of the entire Inform 6 parser, verb library, and grammars. My initial application is a Mud based on the JBoss Netty asynchronous networking engine, but making my port generally usable with a stream-lined API for telnet, CLI, and web -based apps alike is the next step on my roadmap.

I have tried to be as faithful to the original as possible, with the idea that any dramatic alteration its profile in the interest of modernization would occur in future forks and not this initial port. There are some portions of Inform 6 which as far as I can tell are simply impossible to convert directly to Ruby, but aside from those areas I feel that most of the code was a remarkably straightforward conversion process. I still have concerns about whether or not this is a good thing in terms of performance and completeness/correctness.

There are a number of advantages and flexibility that comes from the Ruby language that I suppose I needn’t get into right now. In my version are also a few significant weaknesses. My parser is currently significantly slower than Graham’s reference implementation played in an interpreter like Frotz. It also currently lacks a couple of (as far as I can tell) relatively minor features. However, I am confident that with help from some programmers more talented than I, its speed can be dramatically improved and all remaining features completed, while simultaneously nurturing a framework for future extensions and improvements. Hopefully, I would like to one day see a Ruby gem version of Inform 7 as well.

To ends such as these, I plan to release my codebase on Github or Bitbucket within the next few months after some cleanup, and formalization of my roadmap for the project.

The crucial bit that I want to discuss here is that I plan to release my code under Version 3 of the GNU General Public License.

I sent an e-mail to Graham Nelson about this just to see if he had any objections but never heard from him so I suppose I might have to assume that it is fine as far as he is concerned.

It would really mean a lot to me if I could get some buy-in from other developers in this community. However, in my reading on the rest of the Web, I have come to the realization that the GNU GPL is somewhat a bit of a political controversy among a small number of economically liberal-minded software developers and entrepreneurs, and it occurred to me that it might be wise to consult with the community that has been so influential to and supportive of the original software on which mine is entirely based.

I guess my question is this: In an attempt to maximize the participation of this community in the ongoing development of my project, is okay with you folks if I go forward with my plan as is?

I’ll be honest, this is pretty important to me, given the amount of time I have invested in the project so far and I would really appreciate any advice towards these goals that anyone here has to offer. In fact, I would appreciate it even more if anyone who likes would please get in contact with me directly at nels.n.nelson at gmail.com. Thanks for your time and attention, you all mean a lot to me.

Respectfully yours,
Nels Nelson

2

Inform 6 does have a licence, if a very informal one: it was released in 1996, before the fall of man. (Back then, the BSD licence was considered verbose.) It does make clear that the software is copyright, and that you need to ask permission to make derivative works, but it also says requests will be sympathetically considered. So here I am, being sympathetic. My position here is: it’s fine to make and publish your Ruby version, provided that

(a) you don’t call it literally “Inform”, but give it a name making clear it is an offshoot based on Inform, and

(b) you don’t alter the conceptual design without making that clear to users.

It’s a little surprising that native code isn’t as fast as interpreted, but bear in mind that most of the parser is not time-intensive - the speed-sensitive parts are the parsing of names of objects, on the whole, and the convoluted logic dealing with all of that doesn’t need to run so quickly. It may be that the most efficient solution for Ruby would be to write a fast Z- or G-interpreter, then provide hand-coded forms of certain heavily-used routines.

3

Something I didn’t get to in my previous post: derivative works of Inform can’t be published under the GPL, because then my one stipulation (essentially that the artistic integrity of the thing should remain unless it is clearly labelled as not being Inform) would be forfeit. But I will consent to you publishing it under the Artistic License v. 2.0 if you so choose.

4

Thank you very much for your reply, Graham – it really means quite a great deal to me to hear from you on this.

The incompatibility of the original Inform license with the GPL after all is a bit disappointing, but I am thrilled to learn that the ALv2 is compatible and I will be reading it thoroughly. Am I understanding you correctly that the ALv2 is only necessary if I wished to explicitly call my Ruby port by the name of Inform? I suppose it would be ideal if I could isolate the code for my Ruby Inform port entirely for other to use independently of my silly little Mud application, and doing exactly so is on my road map, like I mentioned earlier.

However, currently the library and parser is rather tightly coupled with the persistent object model which is based on a PostgreSQL mapping. I also have non-persistent objects used exclusively by the parser which use the same interface as and are interchangeable with the db-backed objects, so decoupling the Ruby-ported Inform libraries from my Mud’s persistence layer would not be too difficult.

My suspicion is that the persistence aspect of the system is the bottleneck that is slowing down my version of your parser at this stage of its development – lots of unoptimized SQL operations.

That’s all beside the point, however, and I suppose my real question is this: If I were able to successfully isolate the Inform portion of the code entirely, effectively splitting my project into two projects – the Ruby Inform port, and my Mud and persistence layer software – would it be acceptable to call the former by its original name while retaining your original comments and copyright information in the new Ruby source files, and also using the ALv2? I might then be able to release the latter under the GPLv3 and simply use the ALv2-licensed Ruby Inform port as a dependency for my Mud, yes?

I completely understand if it turns out that I am entirely confused about how different licensed software works when used together in a project, so please don’t hesitate to correct me where you feel necessary.

Anyway, thank you again very, very much for your replies, and I look forward to any clarification you can offer regarding the naming and licensing of this Ruby Inform port. This is very exciting for me.

5

What exactly have you ported? It sounds like the parser from the library, but without the world model or action processing or anything to do with the compiler. In which case it’s only a very small part of Inform.

6

Speaking as a user and contributor: Since (as you say) it is impossible to support the entire Inform 6 language on your Ruby platform, I’d rather you didn’t call it “Inform 6”. There is no language spec per se, so it’s good to be able to say “The Inform 6 language is what the Inform 6 compiler supports.” Variations should be clearly labelled.

Speaking as a game author: if the parser and verb library are GPL, it seems to me that any game released this way would have to be GPL also. (However, I might be wrong, not having seen your architecture – I’m not an expert in the GPL’s details anyhow.) If so, this would discourage me; none of my games are GPL, and I don’t intend to license any of them that way. Few Inform authors have done so, although that doesn’t really indicate how many of them would care one way or the other.

If the parser and verb library are AL, and the MUD framework is GPL, that bypasses my objection.

I guess you then just have to think about whether the prospect of a proprietary fork frightens you. I am a guy whose current business plan is based on proprietary forks of Z-code and Glulx interpreters(*). So the existence of non-GPL interpreters is important to me. But then I’m talking about mobile apps, not web services – your project is totally outside my space.

I can’t see a business starting up and saying “Lo, we will monetize this IF/MUD project by adding our special features!” But, on the other hand, if one did then I wouldn’t regard that as a theft from the community; I’d be cheering them on.

So, basically, that’s my license viewpoint. Not going to get into whether it counts as “economically liberal” – I suspect that phrase is flamebait this (US) election season, anyhow.

(* Not much of a fork, but I did add that snazzy map to iPhone Dreamhold without releasing its source code.)

7

Hi zarf! I really appreciate your thoughts on this.

I think I understand. I suppose clarification is in order. I see Inform as being several things not to mention version segmentation. First, I see the Inform compiler. Next, I see the Inform 6 language, used to write source code files which are compiled to byte code. Then I see the Inform standard library including the parser. I consider the Inform compiler to be the de facto specification of the Inform 6 language. It had not crossed my mind to attempt to port the entirety of the Inform language into a DSL inside Ruby. And of course, a compiler is not needed for Ruby code. Pleasantly for me in this project, Ruby closely resembles the Inform 6 language.

Inform 7, on the other hand, is a bit of a different animal. So I hope this explains why, in order to differentiate my port from the software described by Inform 7, I used the term Inform 6.

The truly indispensable part of Inform, however, has to me always been the natural language parsing algorithms, modular grammar system, extensible verb routine collection, world object tree, and object modelling features and these five things are what I have done my best to faithfully reproduce with software executable in a Ruby runtime.

You are right to say that variations should be clearly labelled and so perhaps “Ruby Inform” would suit?

I understand. Unless I am mistaken, the GPL would not have prevented people from making and selling games which use my Inform port as a dependency, only from capitalizing on the code itself or on derivative works from it. I only suggested using the GPLv3 this because its stipulations seemed compatible with the intentions of Graham’s original license as I interpreted them from the comments in his source code. I have no intention to and certainly no right to capitalize on Graham’s work, and neither does anyone else unless he grants such a right at his discretion. Fortunately, it appears that he would be fine with me licensing my ported version of his parser and library under the ALv2. Thankfully, the AL is compatible with the GPL. (http://www.gnu.org/licenses/license-list.html#ArtisticLicense2) And of course, Ruby makes it easy for a developer of a game using this version of the parser and library to dynamically extend any portion of either without explicitly altering any of its code.

This is certainly the way this thread has me leaning, due to Graham’s and your feedback.

My primary concern is the respect due to Graham and ensuring that my source code be licensed properly so as to give credit where credit is due and to take into account any wishes he might have for the future usage and ongoing development of software explicitly intended to resemble his original work. My next most important concern is the sensibilities and interests of this community in particular.

I think I would be excited about something like that too, but depending on its application I might have concerns. For instance, if Apple wanted to incorporate my software with their voice recognition systems, I’d probably be disgruntled since I disapprove of Apple’s business practices generally. But that’s total flame bait, right there.

8

I would call it a Ruby port of the Inform Library, Inform Library in Ruby, or maybe Ruby Inform Library. If you’re not touching the compiler then you can’t say you’re porting Inform. “Inform” is either the compiler alone or the compiler and library, IMO.