eTools Patch and Source Code

[Luke]

It may be bordering on scripting; especially the way that I presented it. To be more precise you would have a table with a Key and a value and then the code would construct the logical statement by combining Keys and Values. It gets a little more complex than that when you consider some weirder rules and 'Ors', but that is the basic idea. I have currently done Feat prereqs that way and it is working out quite well so far.

What you showed was a piece of text that represented an algorithm to execute on variables. If its not compiled, then its a script.
What you describe is effectively building a type of scripting engine, via database configuration. Its a direct parallel to what they call "ladder logic" in the process control world. It has the advantage of being reasonably easy to configure very simple expressions in a controlled manner without exposing the complexities of a scripting engine, and on the other hand its a lot more cumbersome, especially for non-trivial expressions.
Essentially you're building a database tree that passes through an iterim stage of being put together just like a script, just before you actually execute it.
I don't see any legal problem with it. The only problem I see is it possibly being relatively slow and simplistic in power. You're effectively building your own scripting interpreter.
In RPM for example, casting a Cat's grace (or equipping gauntlets of dexterity to keep it out of the in-game area), causes a massive number of recalculations. The type of stacking modifier needs to be measured against all other current dexterity modifiers to come up with a new dexterity which recalcs dexmod, reflex, AC, all dex based skills, all ranged weapon attack bonuses, etc etc.

PCGen uses "Keys" or "Tags" in their .lst file and this is how they are designating OGC (everything in the .lst is OGC while the actual program is PI). Until I hear differently from WOTC I am assuming that they use of "Keys" in the database that represent the rules is a viable way of complying with the d20 license. I agree that this is shaky ground, but if WOTC says its Ok then its Ok.

The variables being open was never in question. Its the *algorithms* that are in question. Use of clever compiled generic algoithms that aren't specifically derived from the SRD are not a problem. That's where most of the work is done ( adding stacked modifiers). The issue is when SRD derived algorithms are required, and they are put in compiled code because the lst/tag system isn't sophicated enough (or too slow, or whatever) to cope.
What I'm saying is that if Wizard's *know* where that's going on, they'll say *no*.

Perhaps there won't be much difference between your system and PCGen's at the end of the day...

Ultimately the database configuration route is going to be more complex and slower than a compact scripting language, for the bits that go beyond stacked modifier addition. Its an age-old argument of simplicity and safety vs speed and power.

You can probably break an RPG app down into 3 distinct parts:
1. The textual part (such as a skill name and description)
2. The data you need (such as the modifiers to skills for the Alrtness feat).
3. The algorithms that combine the data mathematically to produce the required calculations.

As long as all 3 of those parts from the SRD, or derived from it, are all openly human readable, you're okay.
Its part 3 that causes all the problems, and which is addressed most easily by scripting (since a script, by definition, is a readable piece of text that calculates a result).

Getting back to the very original point about ETools being limited due to lack of scripting:
The algorithms in ETools are hard-coded into the app, and hence open D20-style expansion is extremely limited. ETools doesn't have scripting, and it also doesn't have the method you describe of flexible algorithm building via a database tree.

 

[Arnix]

Here we go:

If your application is licensed under GPL or compatible OSI license approved by MySQL AB, you are free and welcome to ship any GPL software of MySQL AB with your application. By "application" we mean any type of software application, system, tool or utility. -- http://www.mysql.com/support/arrangements.html

But that seems to conflict with this:
As long as you never distribute (internally or externally) the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL or other OSI approved license or not. -- http://www.mysql.com/support/arrangements.html

So dunno, probably best just to ask them if one was going to proceed with an eTools replacement that is GPL'd and is going to distribute MySQL [instead of Access] with it.

I think you missed sections 3 and 5 (you quote parts of 1 and 2 above). Section 4 deals with exceptions for NPO's and Free Commercial Licensing so is irrelevent for open source.

3) Commercial Use: If app is not open source or under special permission
"If your application is NOT licensed under GPL or compatible OSI license approved by MySQL AB and you intend to distribute MySQL software (be that internally or externally), you must first obtain a commercial license to the MySQL software in question. "
- Section 3 paragraph 1


5) Who can use: If your app is GPL, use it for free.

"To all GPL/Open Source enthusiasts we do recommend our products under the GPL licence. We believe that MySQL AB is the world's largest company that offers all its software under the GPL licence. So help yourself to the MySQL server and the drivers and feel the freedom of free software! "
- Section 5, paragraph 2


Arnix (tm)

 

[Hollywood]

First of all there is no requirement in the d20 license that OGC be in a human readable format. The requirement is to clearly mark OGC. In the FAQ human readable format is one way that they suggest that software could be clearly marked.

Well, I don't pay much attention to the d20 license, as I'd never distribute anything under it. Its too restrictive, and 'sides, I have yet to see any reason to need the "d20 logo". In the people I've run across in Chicago, outside of my regular gamers, that have some insterest in roleplaying... there isn't a concept of d20 at all, people don't seem to understand what it means. However, they all know what D&D means.

But yes, I would say that it'd be hard to clearly mark compiled machine code. Although you could put in variable values that would show up if you opened the executables with a hex editor but still.

Anyways, I would say that while, and I stand corrected, human readable format is not a formally requirement of d20, its an implied requirement due to the constraints of labeling what is open source content.... unless of course you declare the entire program as open source content.

Secondly - point 2 of the OGL says that you cannot restrict any OGC with any other licenses and you can only release OGC under the OGL. PCGen distributes the code under GPL. Because of this PCGen is not supposed to put any OGL material into their GPL code.

Ok, thats a good point that I missed. However, I think that this is a problem with the OGL license, and not PCGen in particular. The GPL license was devised to pretty much keep the current source, and any derivative source, open. So I can see where it could conflict with the OGL in language, but I don't see that it conflicts in spirit.

Mmms... interesting anyways... and off to lunch, wonk.

 

[Vpenman]

Yes, but all the customer service rep has to ask is this: "Did you install any 3rd party additions to the program?" If the answer is yes, then the rep says "I am sorry, I can only help you with the standard program."

Based on my personal interaction with our customers, I am pretty sure many of them would not recognize importing a data item as using a 3rd party addition. Especially as an import utility is built into the program.

Maybe the people who hacked the database in the first place would recognize that. But after the hack and the general sharing of the data, it would end up in the hands of people who would have no way to recognize that it was different from the legitimate data they had been importing.

As part of the program design, it was intended that people would be sharing data. The DM sends the player a file containing the custom item that character just received in the campaign. The player sends the DM the character file so the DM can be familiar with what that character can and cannot do.

With the Core Rules programs, data sharing is a supported feature. It is not a "use at your own risk" type of thing. Nor should it be. There are utilities in the program that support the importing and exporting of data. They prevent the overwriting of valid, existing data. They do not prevent the sharing of hacked data that might cause the program to malfunction.

Unless a utility provides the ability to share data among the program's users, in my opinion, it is a substandard utility. If importing something causes the program to break, folding your arms and saying "not my fault" is not an acceptible answer.

Providing an easy out for the service rep is not the same as providing good customer service. How customer service will be handled is something that should be considered when the product is being designed.

... Ah. If you don't mind my asking, what was your role on the project or at Evermore?

I was the project manager. I am also the president of Evermore.

Victor

 

[Arnix]

Ok, thats a good point that I missed. However, I think that this is a problem with the OGL license, and not PCGen in particular. The GPL license was devised to pretty much keep the current source, and any derivative source, open. So I can see where it could conflict with the OGL in language, but I don't see that it conflicts in spirit.

Actually, I think they got around this by seperating the GPL and OGL items. The GPL is the code, which simply reads data, a glorified parser with a dislay window if you will, and interprets it. The OGL section is the lst files, which are completely human readable and modifiable. Either can be distributed independently of the other, if you want to write your own lst files or an app to use existing ones.

If you mix the 2, i.e. intertwine OGL data in the GPL source then you could have trouble (older versions of pcgen fall here I believe).


Arnix (tm)

p.s. IANAL

 

[Luke]

I'd be much more interested in what Luke is doing under the covers [Sorry Luke, I still don't like your UI ].

There's virtually nothing "under the covers", as far as 3rd edition mechanics is concerned. That's the whole point of keeping it open

As for the user interface: Well, I've done what I can according to what people have told me.
The UI for a kitchen sink of integrated 3rd edition utilities is necessarily a tight balance of competing requirements. "Balance" necessarily means compromise. An obvious example is the spacious layout of lots of info vs the need of many to use a lower resolution laptap. Another example is the simplistic use of a "Wizards-style" guided approach to ease-of-use vs the need to quickly jump between different functions, as suits your gaming style.
If you tell me *why* you don't like it, I could possibly do something with that. If you propose a solution (especially where you've considered that balance of different needs), then we're really cooking.

 

[Luke]

ooopss thought it was a full sourcecode disclosure to the masses. My mistake..

They only said that the source was given to Wizards.

This has led to all sorts of conjecture, including assumptions that Fluid themselves no longer have a copy of the code, and Wizards won't use them anymore.

It could be as simple as: Wizards actually own the source code, and it was always a key deliverable of the "completed" project.

 

[smetzger]

What you showed was a piece of text that represented an algorithm to execute on variables. If its not compiled, then its a script.
What you describe is effectively building a type of scripting engine, via database configuration.

Your definition of a script is much broader than my definition. If I were to use your definition than I would agree that scripting is necessary.

 

[Bacrof]

Yes, but all the customer service rep has to ask is this: "Did you install any 3rd party additions to the program?" If the answer is yes, then the rep says "I am sorry, I can only help you with the standard program."

It's not always this easy.

My pastor asked me once why the font he was using looked all screwed up on his monitor. The first question I asked was "have you installed anything on this machine since it last worked?" He said that he had not.

Half an hour later, he asked if it could be related to the new fonts he had copied onto the machine the day before...

I think this sort of behavior/level of knowledge is more typical of the average user than what you describe.

 

[Bacrof]

It could be as simple as: Wizards actually own the source code, and it was always a key deliverable of the "completed" project.

Nope. Fluid stated quite clearly a while ago that the object code belonged to Wizards, but the sourc code belonged to Fluid. This was mentioned at the same time that they promised to release the source to the online community if Fluid was no longer able to support the product.