DM Genie

[Luke]

I'll also sum myself up: Wizards does not believe that binaries allow for any identification of OGC beyond all/none.

How does that reconcile with why PCGen had to go and do all that restructuring.

They are a free, open source project. Is it really possible that all they had to do was say - our entire "binary" is all OGC, and somehow everybody missed it?

 

[Anakyne]

Originally posted by Luke
I can definitely tell you that it's irrelevant whether or not your application is commercial.

I know what I meant is that I don't care if the source code is distributed since it won't be shareware nor commercial.

Originally posted by Luke
Quite probably, though, you could distribute your source code, but you wouldn't be able to distribute a binary with it, or make a binary available to anyone.

Ironically I could even only distribute two binaries, binaries that are used by the development environment which allow to consult the code... but that's another matter.

Originally posted by Luke
Anyone who wanted to use your stuff would have to set up their own development environment and compile it themselves, as you suggest.

The environment is not complicated, download, install, copy two files, run through some steps for compilation... done... but I agree, it's not a good idea for end users... but only a way to respect the license. And since I have found other ways to compile at run time

Originally posted by Luke
Do you suspect that given all the hassle and issues with being able to supply a decent program that doesn't rely on decent 3rd party components (which you are unlikely to be able to provide with your source), that you'll actually offer something better than is already available?

First of all, I don't expect to offer something better than is already available. I only hope for that

 

[Anakyne]

Originally posted by Fractalwave
There are other considerations, as well, that are discussed on the OGF lists and apply to programming specifically.

[...]

Originally posted by Fractalwave
One thread ended with a serious discussion as to whether publishing PDF's was not compliant with WotC's licenses and why. And yes, that's an extreme example.

To some extent, PDF are binaries AFAIK... But to get this further, do you consider RTF to be human readable ? However WOTC are distributing the official release of the SRD as RTF... not as TXT ? I'm not denouncing what WOTC do, they can do what they want with their OGC, basically the OGF has really been a good thing for RPG IMHO.

 

[Klintus Fang]

No.

Both code and data that is part of the SRD needs to fulfil the criteria. Making the data alone openly readable (clearly identified), isn't enough.

Consider working out a creatures AC, by way of example. You may pull together a whole bunch of modifiers (dodge, dex, armor, magical enhancement, natural AC, magical item benefits, size etc etc).
The SRD is the source that tells you that the AC is 10, and what sort of modifiers are applied to it.

Now, the process of adding these together (choosing the right things to add), and applying the correct stacking rules, is all an SRD derivation. Therefore, the code that does all the work of calculating the AC is a derivation of the SRD, and must fulfil the license obligations. It can't be in binary.

I'm aware of that Luke. But you misunderstand me. I am thinking much more general. I am assuming that every game mechanic will be encoded in this theoretical data file, including all the rules for how stacking works (to take your example). I am assuming that the core engine will read the data file to determine what the stats are, and what their names are. The data files will also inform the binary of what type of value each stat holds (could be an integer, a string, a float or whatever). The core binary won't even assume that any such stat as "AC" even exists. It will find that in the data file. It will also find in the data file that this thing called "AC" is a sum of a bunch of other things (also defined in the data file). Those other things would be some stats called things like "AC:natural", "AC:armor", "AC:deflection", etc. Then in the data file there will also be some rules that specify how to calculate each of these sub-stats. Stacking rules really aren't a big deal in that respect. To calculate "AC:deflection" you simply specify in the data file that you take the "maximum" of all the relevant components rather than summing them together.

I realize there would have to be a lot of nitty gritty details that would make defining the format of this data file a serious endeavor, but in principle there is no reason that all of the rules cannot be encoded in a data file in such a way that a general purpose "rpg engine" would be able to interpret it and then construct a set of data structures at run time that model the rule system. This engine would assume nothing that can be construed as another person's copyrighted material. It would assume only that there will be a bunch of statistics that need to be calculated and added together according to certain rules, all which will be defined in some data file that has a predefined format.

 

[Klintus Fang]

In fact, in theory, (though this would be a nigh impossible thing to code), if the technology for software that is able to intuit meaning from text was just a little better, there is no reason that a person could not write a program that was capable of reading the SRD directly, figuring out the rules and then building a character generator, or combat management tool, or what have you, at run time.

In truth this is what I have in mind. I'm just proposing that someone rephrase the SRD in a more "table oriented" format that makes the process of interpreting it and constructing a model of the rule system easier.

Instead of

Every character has six basic ability scores: Strength, Dexterity, Constitution, Intelligence, Wisdom, Charisma....

One would write something like:

begin_stat_group ability_scores("Ability Scores")
integer str("Strength")
integer dex("Dexterity")
integer con("Constitution")
integer int("Intelligence")
integer wis("Wisdom")
integer cha("Charisma")
end_stat_group

etc.

 

[Mynex]

I'm aware of that Luke. But you misunderstand me. I am thinking much more general. I am assuming that every game mechanic will be encoded in this theoretical data file, including all the rules for how stacking works (to take your example). I am assuming that the core engine will read the data file to determine what the stats are, and what their names are. The data files will also inform the binary of what type of value each stat holds (could be an integer, a string, a float or whatever). The core binary won't even assume that any such stat as "AC" even exists. It will find that in the data file. It will also find in the data file that this thing called "AC" is a sum of a bunch of other things (also defined in the data file). Those other things would be some stats called things like "AC:natural", "AC:armor", "AC:deflection", etc. Then in the data file there will also be some rules that specify how to calculate each of these sub-stats. Stacking rules really aren't a big deal in that respect. To calculate "AC:deflection" you simply specify in the data file that you take the "maximum" of all the relevant components rather than summing them together.

I realize there would have to be a lot of nitty gritty details that would make defining the format of this data file a serious endeavor, but in principle there is no reason that all of the rules cannot be encoded in a data file in such a way that a general purpose "rpg engine" would be able to interpret it and then construct a set of data structures at run time that model the rule system. This engine would assume nothing that can be construed as another person's copyrighted material. It would assume only that there will be a bunch of statistics that need to be calculated and added together according to certain rules, all which will be defined in some data file that has a predefined format.

Just to chime in here, you realize, what you described above, is exactly how PCGen operates now?

All the information _is_ contained in the data files, the interface itself is completely dumb and will not do anything it is not told to specifically do by the data files with regards to character creation.

This applies to stats and AC calc's etc, but does not apply to random character name generation (by definition a name does not determine success or failure for a character, so per Wizards that is legitimate)... But the data files tell the interface 'Hey, I have x stats here, these are their names, here's a short name, here's what they do, and here's how they work'... each class is broken down completely for it's BAB's, saves, etc, and tell the interface what to do. same for spells, equipements, skills, etc...

Now it's not perfect, there's still some bugs to work out (ins't there always? ), but the end goal is to be completely generic, eventually being able to define any rule sets in the data files telling the interface what to do. And yes, eventually, we'll be moving the data formats, currently text, to XML to make them easier to manipulate by other programs, but that's still a work in progress.

 

[ladyofdragons]

I've been watching this thread with interest, because I've been working on my own D20 software off and on (mostly off) for some time now, mostly as a programming exercise. I have a few comments and questions.

1) Repeatedly people say to look in the OGL lists. I went ahead and tried to search through the lists to find these elusive posts, try to get some more info. Which would probably take me hours, since there isn't a search facility or a FAQ or anything, and nobody's nice enough to actually subject their posts properly as to the nature of the information contained therein so I'd have to read every post for the past 6 months. Just a comment on my part about the state of the OGL lists, which I am now subscribed to.

2) binaries vs. 'human readable'. I'm a VB coder, and as such my code is compiled into binary. So, I'm trying to figure out ways to do what I need without violating any licenses, and without having to load all of the script in afterwards as text (which will slow things down considerably). So trying to figure out what's legal:
- could I have a button on each form that will bring up notepad with the uncompiled code for that form, as well as code in all called modules & classes, with OGC-derived content clearly marked? it's not exactly like giving out the source code with the binary, and would be human readable.
- or perhaps just have buttons that come up listing just the code bits that are OGC-derived. Maybe in a help file? then you could click the AC label, and it would bring up the topic containing the code used to derive AC, and that it is OGC derived content.
- I've created a database to hold the information. The database currently is in Access, and is human readable (if you have Access). Can I just say that the database structure is my own design, based on principals that are OGC-derived?

This is such a sticky situation. I'd rather do this right the first time than have to go back and change it later like so many small-time coders are doing.

 

[Luke]

- could I have a button on each form that will bring up notepad with the uncompiled code for that form, as well as code in all called modules & classes, with OGC-derived content clearly marked? it's not exactly like giving out the source code with the binary, and would be human readable.

There seems to be an easy legal approach to this which is technically challenging, and a technically easy approach which is legally very difficult.
Charles suggests a different easy "silver bullet" where anything is okay, as long as you declare everything open.

If I were to hedge a bet, I'd suggest that the reason PCGen didn't take Charles' easy silver bullet, was because WotC wouldn't wear it.

What I can tell you is that when WotC tested my own software, they wanted to know that changing what I show as SRD-derived scripts actually changed the interpretation of the rules. There was a very strong implication that what I showed as being the SRD-derived content actually needed to be what was being executed. This is another way of saying that distributing source and compiled binary may not be sufficient. You need to execute the source itself. A notepad showing context-sensitive source for binaries is unlikely to be okay. If you think about it, binary and supplied source are different things, and it's only your word that indicates that they are even the same thing.

I've really being trying to avoid saying this, but here goes...
Without putting any names to it (and I'm disinclined to explain this any further):

The originator(s) of the SRD and the OGL behind it were fairly convinced that software of the RolePlayingMaster-type capabilities would never occur - especially from a fan-based effort. Wizard's interpretation of their license was that such an application would throw almost everyone, because of the compiled binary problem.
Guys, from a developer viewpoint - it's not to difficult to knock up a "DM Genie" style app. It's a lot harder to go the RPM/PCGen route, and actually comply with the license.
This whole binary/human-readable problem is the crux of the issue. Wizards did not expect a workable solution to appear from a fan-based effort.

So, you can accept the Wizard's interpretation of their own license implications and try to work with that (yes, it's hard), or you can look for an easy way out, and risk resolving it in court.

As I stated before (as has being echoed by another), I really hope that people work with "the spirit" of the license. This entire possibility from Wizards is a gift, and trying for loopholes in the license does not help the industry.

I can understand that the difficulties are frustrating for those of us who really want to create something they can share with the community. I agree that the whole "clearly indicated/human readable" gotcha can too easily catch out those who start with the best of intentions to follow the license ( aka DM Genie) - but there it is...
Life is easy for "paper" publishers, and a lot harder for software publishers.

I remember the TSR days where anything even remotely like a D&D application landed you threats of court-time. Now, Wizard's have even given you the ability to compete with their own product (E-Tools). I certainly don't blame them for not making it an easy "free-for-all". I suspect that Wizards technically risked millions of dollars worth of intellectual property in going down the whole opening gaming path, to our own advantage, and I'd hate to see a loophole-search somehow succeed in invalidating the concept. Of course, disputes in interpretation are ultimately decided in courts - and I don't think Wizards would lose.

It may seem that this is an easy position for me to adopt, since I am now "vetted" against the license. From the start, though, I made a clear decision to take the hard road, and to work with the license, rather than against it. That made it a very hard road...

Perhaps Wizards could release another version of the OGL. They wouldn't need to give up any restrictions, but could reword a little to make these issues a bit more obvious.

 

[ladyofdragons]

There seems to be an easy legal approach to this which is technically challenging, and a technically easy approach which is legally very difficult.
Charles suggests a different easy "silver bullet" where anything is okay, as long as you declare everything open.

If I were to hedge a bet, I'd suggest that the reason PCGen didn't take Charles' easy silver bullet, was because WotC wouldn't wear it.

What I can tell you is that when WotC tested my own software, they wanted to know that changing what I show as SRD-derived scripts actually changed the interpretation of the rules. There was a very strong implication that what I showed as being the SRD-derived content actually needed to be what was being executed. This is another way of saying that distributing source and compiled binary may not be sufficient. You need to execute the source itself. A notepad showing context-sensitive source for binaries is unlikely to be okay. If you think about it, binary and supplied source are different things, and it's only your word that indicates that they are even the same thing.

ah. I can see that. hmm. quite a pickle then. Alrighty. if I were to have a log window, that showed every bit of OGC-derived functionality as it was being performed (hideable by uninterested users) including formulae and OGC notes, would that be moderately acceptable?

I realize this is probably a pain for those like twinrose, pcgen and you to keep answering all these questions when you've long since done the work to make sure that you're OGL compliant, but for those of us just starting out, I give my thanks for your opinions on the subject. I'm posting here trying to come up with a solution that perhaps all little freeware developers can follow when designing their fan-based program, so they don't have to get all the way through and then realize they need to completely rewrite in order to avoid litigation. I'm not a lawyer, I'm a code monkey.

 

[Luke]

ah. I can see that. hmm. quite a pickle then. Alrighty. if I were to have a log window, that showed every bit of OGC-derived functionality as it was being performed (hideable by uninterested users) including formulae and OGC notes, would that be moderately acceptable?

If I read you correctly, that's okay. You'd be going a lot further than you actually need to go, though. Showing OGC-derived functionality as it's executed is a (typically) heavy and unnecessary burden. Just having it there and viewable should be sufficient.

I realize this is probably a pain for those like twinrose, pcgen and you to keep answering all these questions when you've long since done the work to make sure that you're OGL compliant, but for those of us just starting out, I give my thanks for your opinions on the subject. I'm posting here trying to come up with a solution that perhaps all little freeware developers can follow when designing their fan-based program, so they don't have to get all the way through and then realize they need to completely rewrite in order to avoid litigation. I'm not a lawyer, I'm a code monkey.

Not a problem. I agree with you. I'm sticking out my own neck here and saying things people probably don't want to hear, so that we can hopefully avoid the type of situation that arose around the "DM Genie" release. If Janik decides it's all too hard, and just walks away from it, that's a lot of wasted effort. Whether it's freeware or commercial is irrelevant to the license.