> As I've said, I'm not a programmer. But all that has been said is that
> wherever OGC is used it must be clearly identified and remain open. That
> is all that Ryan has said. If there is no way to clearly identify OGC
> that is being used by a program then there's no way that program can ever
There is a way to identify OGC *sources* used by program. However even while knowing
what is OGC, is
not the same as ability to edit and view the contents of OGC sources - that may depend
on user
acquiring proprietary viewers. And this is not the same thing as clearly identify OGC
*displayed* by
the program.
> be legal under the OGL. A separate listing of what is being used by the
> program is NOT the same thing.
As far as i understood no one was ever speaking about separate listing. It just
creates more
problems for software developer - support program code/data and separate listing in
parallel and
track differences during development. Much simpler is to use that listing as software
data itself.
> > all SRD converted into set of say XML files (or hashed XML binaries)
> > Software don't have a single idea what is SRD or D20. It just loads
> > XML files from OGC folder, does something by rules in that files, then
> > produces output. Theoretically speaking if somebody was to replace XML
> > OGC D20 folder with Battletech XML folder the very same software would
> > produce Battletech. ( And of course software probably won't work at
> > all without that folder ).
>
> Is the OGC identified as such in the XML files? If so, this would
We back to original point - do you have to mark it *inside* or *outside*. Text XML can
be marked
inside as OGC. Binary hashed XML can only be marked *outside* (folder attribute or
description file)
as OGC. But to build fast application you need to use binaries, not text.
> probably be a way to clearly indicate OGC, as has been stated already.
> But this isn't the same concept of a separate folder that has primarily
> been discussed. The separate folder idea has generally been put forth by
> people to say that there is no way to identify OGC in the program itself
> but they could provide a directory which contains all the OGC. That isn't
Then you are in misunderstanding. That was exactly the idea discussed as "separate
folder". At least
i was discussing *only* that approach. passive separated folder not integrated with
software simply
has no meaning in my opinion. We have to put all OGC in one place, and draw/load it
from there.
Therefore program code contains 0% of OGC, and its completely concentrated in one
folder. But! That
folder may contain binary files - viewable by platform specific or developer-specific
readers. My
argument was that as soon as we clearly marked EVERYTHING in this folder as OGC -
users and
re-distributors know exactly what part of software is OGC. How they edit or copy the
data in that
folder - with free hex editor or with user-friendly by expensive tool is up to them.
Software
authors just got to make a statement that all OGC data is coming from this folder
alone and nowhere
else.
> Of course the processing logic may contain OGC if that processing logic is
> derived from the rules available in the OGC. And this is where we get
Processing logic should be abstract - sort of "if A is greated then B then do C". A,B
and C are
loaded from OGC folder, which results in exectuion of "If [Spot check of Tordek] is
greater then
[Hide check of Jozan] then [Tordek Spot check succesful]". Replacing folder will lead
to "If
[BattleMech heat] is greater then [Mech overhating limit] then [Explode the Mech]". I'm
oversimplifying of course.
> Where has this been ruled unacceptable under the OGL? Ryan has offered
> his opinion that binary files containing OGC which cannot be viewed in a
> human-readable format in some reasonably simple and generally available
> way will violate the OGL because the OGC in such a file is not clearly
> identified.
Read the forum carefully and Ryan statements especially. Ryan has ruled out folder
idea completely
when binary question wasn't even discussed yet.
Ryan on folder: "No, because the work that is OGC in your software cannot be clearly
identified. Putting it in a separate folder just means you've conveniently
separated it from the larger work - but the larger work can still be
distributed by someone without the separate folder, thus violating the terms
of the OGL."
If I understand Ryan correct, despite the fact that OGC data may come from single text
file in
folder, and be clearly identified for user as such, the software still isn't OGL
compliant. software
may show message box with text "Your Disable Device skill roll is 15" where "Disable
Device" string
is OGC and message box itself did not clearly identify *that string* as OGC. Therefore
software
developers are forced to clearly identify each *display* of OGC data, not just the
sources of OGC
data. Of course this is much, much harder to do, it creates more limits for end users.
(Idea "all
OGC is red" may work - but that mean restricting users from using simple and popular
windows message
boxes. Message box can't show colored text).
> be directly viewed in a human-readable format (i.e. anything that can read
> and/or write XML). Of course the OGC in such XML files must now be
> clearly identified but I would assume that could be done with remarks
> within the coding. If this was simply a sub-application processed by
XML is fine, and its great step forward - unfortunately if you want to do anything
interesting or
fast you can't limit yourself to text based formats only. You combined text and
binaries formats,
hashed XMLs, databases, maps, and indexes - all that files are binary. For advanced
users and
developers they are definitely human-readable. For Upper Volta bean gatherer, or
highway 95 truck
driver they are most likely not.
- Max
_______________________________________________
Ogf-l mailing list
[EMAIL PROTECTED]
http://www.opengamingfoundation.org/mailman/listinfo/ogf-l
