Reply to thread

Message: <blockquote data-quote="Hollywood" data-source="post: 458715" data-attributes="member: 7408">Smart move actually.  I recently ran across a very large-scale [or so they hope] enterprise app that I sat in on technical briefs as a tech advisor for.  The developer had placed all business logic in the stored procedures.  Well, even with an enterprise database like Oracle, the language available to you with stored procs is not very robust.  Thankfully the business rules and logic for this system are fairly simple so that it won't completely flop.Frankly, I'm not sure why they necessarily want to be d20 complaint anyways.I'd say that they aren't gaining expertise at all.  Maybe there are beginning to understand some central concepts, but not any viable form of expertise.No, you are right... lst files are quite confusing and would have been better in a better format, such as XML format that contained even scriptlets for each piece of data if calculations needed to be performed.Well, I dunno... didn't take too much headscratching as after all anything hosted at SourceForge MUST be open-source. <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" />And yes, key SRD mechanics are expressed in SOURCE CODE as per the OGL license.  Since those same source files are available [although they should be made available as a 4th zip file] and are human readable they fall under the OGL license just fine.  Just as if you had translated the SRD into native Navajo;  how many folks outside the Navajo reservation really know how to read their language? <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" />That'd be a bogus arguement since its already been establish via prior art that algorithms are not copyrightable.  Only the implementation/expression of the algorithm.   A generic "stacking" algorithm is nothing more than an expanded addition algorithm... so I suppose if Wizard wants to try and take ownership they can fight the entire computer [and math] industry and academia. <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" />But yeah, I could see WotC arguing that expression in source of an OGL specific mechanism must be in human-readable form as per the OGL license.  If the source has been compiled into machine code, its no longer readable by humans.I completely disagree.  PCGen, while I do not believe its well engineered in any form, is still completely human readable.  Anyone can get the source and discern what is contained in the OGL'd SRD by reading the PCGen source and lst files.   Therefore its compliant.  It doesn't need to expose small snippets of scripting, all its "scripting" is already exposed.   With RPM or TwinRose' software or other software that anyone can not get the source to, then scripting is the only alternative to expressing the SRD's mechanics, that are not generic software engineering algorithms, as the script can be exposed externally to anyone while still maintaing the intergrity of the software's base code such as UI, printing, reporting, etc.Although unless WotC is going to employ some software engineers to perform code reviews on closed-source code, like Redblade, RPM, TwinRoses stuff, etc. they will never be truly certain, even if the software exposes scripted mechanics, that there isn't some SRD mechanics that are in the closed-source portion of the code base.  They'll just have to take it on "faith" [by George Michael of course!]Yes, thats my interpretation of it with the exception that "human readable" means that you must have knowledge of the language they are written in, whether it be English, Armanian, Pascal, Cobol, or even as a musical score.  And to me these mean the following:a) Have the data store open and available.  This probably means storing all base source material in flat files.  A database or other data store may be populated from these files for better performance and ease of manipulation, but still the root of the source must be in human-readable format.b) The source that translates the OGL'd SRD mechanics must be available in human readable format. c) The translate source of course could appear as hard-code in an open-source project where all the source is open, as scripting code thats pre-compiled/interpreted by a closed or open-source compiled program at run-time, open-sourced source that can be pre-compiled and executed by the program, etc.  Plenty of ways to do that.Yes, its probably the most forward way to do so if attempting to implement the open SRD mechanics in a closed-source solution.  Matters not whether the script is pre-compiled, and uses the solutions native language, or intrepreted.I disagree with your statements concerning OGL compliance.  However, I don't understand how they can be d20 compliant when the d20 license states that anyone using the d20 license can NOT duplicate/translate/provide character creation and leveling mechanics.Yes, I expect to see new revisions of the OGL and d20L.  And I suspect that they will attempt to more clearly state WotC's software policy, however will be completely inept at doing so mainly due to Hasbro's lawyers.As they should, but I think that if they do so with too much fantasism they will drive people away from the OGL's SRD; not necessarily open source gaming, but at least away from WotC's brand of it.There is a line thats hard to tread and easily overstepped on both sides of the fence.</blockquote>

Verification