On Mon, 4 Jun 2001, Max Skibinsky wrote:
> Alec, detailed answer tomorrow, for now just the most important part.
>
> In my opinion you fail to realize that software application is not
> equal software source code. To give you example from our work - City
> Overseer as whole is about 590+ MB. From this only meager 2Mb are
> executables for which i can provide source code. The rest 99+% is
> binary files which simply don't have source code. So if i proclaim
> that our app is open source tomorrow and all its source code is OGC -
> that less then 1% of the whole. Your second wrong assumption is that
> there is some sort of "other" solution for binary files. There is
> none. All our suggestions was removed from the table by Ryan
> clarifications.
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
be legal under the OGL. A separate listing of what is being used by the
program is NOT the same thing.
> > clearly identifies all OGC. Of course I fail to see how this has anything
> > to do with the current discussion. All of the discussion has revolved
> > around the creation of programs which actually contain or generate OGC for
> > the end user. Someone would have to explain to me how a program can
> > create OGC without actually containing OGC.
>
> Simple - by processing one type of data from files into another type
> of data. Remember the folder idea? Its so useful for developers
> because its allow them to clearly separate & identify OGC/D20/D&D data
> from processing logic. ( When any OGC appears on user screen its
> really memory shadow of some part of file in that folder.) Imagine
> 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
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
acceptable under the OGL or any theory of copyleft protection.
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
into the messy area of what can actually be copyrighted, and is some of
the material released as OGC by Wizards really not copyrightable, etc.
etc. But once again, this is one of the reasons why Ryan says time and
experience are necessary. Your very open ended hypothetical is extremely
hard to accurately judge as to compliance with the OGC. Someone needs to
try and write some programs using clearly identified OGC so that it's
possible to actually examine the program to see if all OGC has been
identified clearly. And then offer suggestions as to how to improve
things if there are violations of the OGL. Surprisingly this is exactly
the same process being used for printed material.
> This is beneficial for developers (just put everything OGC/D20
> specific in folder, and code only generic processing), its clearly
> beneficial for end users (all OGC is in one folder, change the rules
> or data there, and application will work the way you wanted.) However
> by current OGL policies mutually beneficial solutions are restricted,
> and no alternatives is offered.
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. What you've just proposed sounds like a binary file which can
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
another program, it sounds like it would be very similar to a PDF, which
it is perfectly clear is acceptable under the OGL. The rest of the
program of course cannot contain any OGC -- but from what you've described
you wouldn't want it to anyway.
alec
_______________________________________________
Ogf-l mailing list
[EMAIL PROTECTED]
http://www.opengamingfoundation.org/mailman/listinfo/ogf-l
