Palm Familiar, legal issues, & possible solutions

[SaiZai]

As you probably know by now, there is one main sticking point for making software that WotC won't sue over (or threaten to): "human readable".

By WotC's interpretation - which I disagree with, but they have more lawyers than I so that's moot - this means "scripted".

The question for me is: how to proceed?

Scripting per se on the Palm platform is, simply put, impractical. It would require an engine, text files, and more processing power than is available, resulting in an extremely slow and bloated program. This, on a platform where the expectation is for instant reaction speeds and <100kb programs.

So these are my [viable] options as I see them:

1. Make PF "dumb"... in that it would not calculate anything whatsoever.

IOW, you would have to enter strength bonus seperately from strength proper, manually recalculate and enter things, etc. This is not far from what many people have asked me for already, but means that it would be primarily a read-only program.

This also means that dice rolls would not be allowed within the program.

On the up side, it would result in a usable program in the shortest possible time.

2. Make PF a "zombie" program: controlled by another, PC-based, fully legit and scripted program

(e.g., Luke's RPM)

This would presume some sort of connection between the two - either an IR port (if your PC has one), or the cradle. Both options are limited by Palm's API; it has only limited support (especially pre-OS 3.5) for GUI created on-the-fly. [Translation for non-techies: all buttons, boxes, and everything else are normally made with the program. On-the-fly means the program can say "put a button here, with these properties" while running.]

Variant 1: pure zombie

This would make PF an extension of RPM, displaying, querying, etc., at the main program's behest, and reporting all responses immediately back. Somewhat like a telnet client, with GUI.

It's not very practical - being tied to a PC somewhat nulls the point of having a Palm in the first place - but would allow high level scripting stuff that couldn't be done locally. Would still be the slowest method, though.

Variant 2: one-time load zombie

This would be like the first option (dumb program), with RPM handing PF *compiled* rules, which presumably are then legal. This is a somewhat gray area, though, and would still require at least a basic scripting engine within PF.

It would however be the closest thing to the original intent of PF - that of an independent, fully-calculated character sheet.

3. Allow the user to define the interrelationships manually, within the program

This is a variation on "dummy program" and "one-time load". It is NOT scripting.

To elaborate: you would somehow, while running PF, say "this field, 'StrBon', equals (('Str' - 10) / 2)."

Problems with this:
1. would have to be reentered every time you install PF on a new Palm
2. potential for user error
3. designing a good, usable interface

This would, however, completely sidestep the legality issue; I don't think there is any way that WotC can say that my allowing *you* to enter game mechanics is illegal.

4. Plugins

This would mean starting with a dummy program - or possibly one of the other versions above - and allowing third-party plugins to modify it and provide extra features. Just what they would be capable of would depend on how much time I spend developing the API. It would however mean that I would not be responsible by possible OGL violations in the plugins themselves.

So...

The question is: which of the above should I go for?
Sub-question: which of the above would you pay for?

If you need me to elaborate on any, just ask (as always).

 

[Plane Sailing]

As you probably know by now, there is one main sticking point for making software that WotC won't sue over (or threaten to): "human readable".

By WotC's interpretation - which I disagree with, but they have more lawyers than I so that's moot - this means "scripted".

I don't understand exactly what you are saying here - is it that WotC will only allow apps which have a scripting engine in the middle of them? Why is that?




Regarding your actual question I'd say go for option 1 every time. A usable program in the shortest possible time makes sense for lots of reasons: programmer satisfaction at getting something completed, user satisfaction at getting their hands on something useful, "prototyping benefit" which often comes as you write the first working version of the program and get lots of ideas for the next version, etc.

Cheers

 

[Luke]

Re: Re: Palm Familiar, legal issues, & possible solutions

I don't understand exactly what you are saying here - is it that WotC will only allow apps which have a scripting engine in the middle of them? Why is that?

Its not exactly a question of scripting. Its a question of any D&D data and mechanics being openly human readable.

Scripting is just an easy solution to the hard problem of showing how you calculate the things you do.

WotC's position is that they supply the D20 SRD to you as an open "uncopyrighted" piece of work. If you use it and distribute what you do, you need to ensure that you keep the algorithms and data open. You can't have "hidden data" or calculations compiled away into your program.

This is the exercise that PCGen, for example, went through (and I think, continue to). They had to ensure that any WotC data and algorithms were openly viewable. This meant expanding the capabilities and the use of their .lst files containing tags.

PCGen consumes lots of RAM, and reads in lots of text files when it starts up.
This is extremely difficult for a Palm device to do, having very limited RAM, and not particularly fast calculating capabilities (compared to PCs).
Thus it is easier for a Palm to have all the data (and especially) algorithms hard-coded into a compiled program, since the compiled program will run faster, and won't rely on some massive amount of code to interpret rules from text files.
Unfortunately, that breaks the rules.

The rules are pretty tough on Palm devices...

 

[smetzger]

Read the d20 license and the OGL again. There is _no_ restriction on human readability. The actual restriction is that you must clearly mark Open Game Content.

I released a new version of my Faster Tools program over 2 weeks ago, that has non-human readable OGC. I announced it here, on the OGF-d20 list at Open Gaming Foundation, and I sent Andy the intern an email about the program. I have received nothing from WOTC indicating that they have a problem with this. Also, the only potential problem that people on the OGF-d20 list found was that I needed to make sure that my compiler allows me to create an executable and distribute that executable with no restrictions.

Download to see how I did the license:
http://yoyodyne.virtualave.net/faster_tools/index.html

*:> Scott

 

[Luke]

We have the same circular talk again and again.

Last time I quoted from the post of WotC's Andy, which explicitly stated that human readable was necessary.

Just because you declared that your compiled program is compliant, and Wizard's never said anything, doesn't mean that its okay. Are you even sure that they looked at it? They certainly haven't got the time to look at *everything* out there.

Riddle me this one: Why did PCGen go through a massive re-organization of their app? It wasn't just about pulling Wizard's non-SRD content. It was also about significant reworking of their tags, to pull SRD algorithm code out of the compiled java.
Why did PCGen go through this significant effort ???

A long time ago I went through a whole series of e-mails, answering WotC's questions, to demonstrate how RPM has everything available in human readable format.
I believe that most "significant" RPG software apps have been through the same thing.

Once again, you are still at liberty to argue your interpretation that the license doesn't require human readability, but then WotC, based on their interpretation, are at liberty to settle the issue in court.

Regards,

 

[Luke]

Okay. I had a look at the FasterTools link you showed.

Its quite possible that it is compliant - based on the fact that it doesn't seem to really do that much.

The question is:
Does your compiled program have any D20 data, or algorithms mechanics, compiled into it in such a way that it can't be seen how you do what you do?
You can do RPG stuff, and do dice rolls, without necessarily using the D&D information in the SRD.

The "Total Skill Points" is an interesting example of where things could go wrong.
For example, it doesn't look as if you calculate available skill points, based on creature levels. If you did that in compiled code, there would be a problem. If you did anything to calculate the rank value of points spent (eg class-skill, or not), then there would be a problem, since these things are actually using game mechanics described in the SRD.

You can argue that your list of Races and Classes are viewable, and your Domain list is in text.

------------

Oops. I've checked a bit more thoroughly.
Your doco says that calculate your available skill points in your program, and that you check the feat prerequisites in your compiled code.

These are clearly algorithms derived from the SRD, which you apparantly have in your compiled code.
From what I understand, WotC would rate this as being a violation.

Their point is that they gave you the SRD as an open set of data and rules (for example, describing the prerequisites for feats, and how to calculate skill point totals), and then you went and "closed" it, by distributing it as compiled code.

Perhaps you could mention these specific issues on the OGL list, and ask Andy directly if its okay?
I wouldn't take a "no reply" as a signal that its okay. A "no reply" could easily mean other things.

 

[smetzger]

Oops. I've checked a bit more thoroughly.
Your doco says that calculate your available skill points in your program, and that you check the feat prerequisites in your compiled code.

These are clearly algorithms derived from the SRD, which you apparantly have in your compiled code.
From what I understand, WotC would rate this as being a violation.

Their point is that they gave you the SRD as an open set of data and rules (for example, describing the prerequisites for feats, and how to calculate skill point totals), and then you went and "closed" it, by distributing it as compiled code.

Perhaps you could mention these specific issues on the OGL list, and ask Andy directly if its okay?
I wouldn't take a "no reply" as a signal that its okay. A "no reply" could easily mean other things.

These things have been mentioned on the d20 list. Andy reads the list. Plus I sent him a personal email. I have tried to publicise this as much as possible, it was posted to the software forum, the publishers form, the OGF d20 list, and was on the EN World front page.

I haven't closed anything. The .exe is all OGC except for icons and images and company names. It may be difficult to extract and re-use my OGC, but that doesn't mean that it isn't clearly marked. No-one on the list has challenged the legality of this technique. The challenges have come mainly from the no description of character creation/leveling up and the 'does your compiler really let you distribute an executable without any restrictions?'.

Maybe they are about to release a software d20 license and so they are ignoring my little program since it doesn't do alot and the software d20 license will address this soon anyway. However, there has been no rumors of this impending release on the d20 list. But since the 'clearly marked OGC' is part of the OGL and not d20 license its pretty much a moot point.

 

[Plane Sailing]

Luke, it is interesting if it is true, since my little PalmOS utilities naturally break the rules - it would be pretty much impossible to create a jump calculator which didn't, I'd have thought.

Still, distributing the source code alongside the executable (a la GNU public license) might well do the job, eh?

 

[smetzger]

Luke, it is interesting if it is true, since my little PalmOS utilities naturally break the rules - it would be pretty much impossible to create a jump calculator which didn't, I'd have thought.

Still, distributing the source code alongside the executable (a la GNU public license) might well do the job, eh?

The real trick in this startegy is that you cannot have any other licenses or restrictions other than the OGL and possibly d20. So that means you cannot restrict decompilation and you cannot include the standard 'don't blame me if this messes up your computer'. I am not sure if the DM

Not sure how PalmOS works. But, if you didn't want to declare parts of your GUI as OGC then you could separate all the calculations into a DLL and then just have a GUI shell that took user inputs, shuffled it to the DLL, and displayed the results of the DLL. This would allow you to declare the whole DLL as OGC and still keep some restrictions on your GUI. Thus you have not only clearly marked your OGC you have made it readily reusable.

 

[SaiZai]

*cough*

Let's please keep the nitpicking about the legal interpretations to their own threads, please?

There have been several such already; the reason I summarized the issue and the only (current, fully agreed) way out was to avoid having this argument and focus on the main question.

Thanks.