<<If you distribute an application that uses Access, it shouldn't matter
whether or not you have Access to view the database files. Since a program
is the medium providing you a derivation of the SRD, that program (or suite
of "programs") needs to be able to show you what it uses from the SRD (any
database files or derivational scripts).>>
But I could just as easily say on the box, "requires Access to use", and declare that it is an Access DB product that happens to have an additional compiled program packaged with it. This argument is weak.
The product distributor should be able to make any reasonable demands he cares to about any type of electronic media he distributes.
If I put on a box, "you need MS Access, MS Word, Office 2000, MS Excel, Adobe Acrobat, Windows 2000, and a Windows 2000-compliant PERL interpreter" on your machine, then that's what you need. The fact that I happen to be distributing a piece of utility software in addition is immaterial.
In fact, my software might be utilizing the core features of each of these MS applications and be unable to function without them in place.
Your requirements seem pretty arbitrary.
<<Whilst I'm pretty confident of what I say above, I'll go a bit further on my
own interpretation of the Access example. I would say that if you have an
application that uses SRD content in an Access database, you need to provide
the viewing screens for any SRD data you use in your program. >>
I think this is thin. If I create a program and describe it as requiring Access to use, I don't need to package a viewer for the data. Any more than if I sell a PDF requiring Adobe Acrobat to use that I have to create my own PDF browser.
If I put a PDF and an MDB file on the CD do I suddenly have to write a program that can display both to the user or otherwise not include any program at all? I really disagree strongly.
<<I don't
believe that its sufficient to say "Use your own copy of Access if you want
to see my data. In this case, you have provided a *program* to utilise the
SRD, so the program needs to indicate the OGC.
>>
This is again, pretty thin. I can certainly distribute non-OGC material with my OGC products. The fact that I have a program there does not mean that I don't expect the user to have Access. In fact my program may _require_ that Access be present on the machine or some other piece of MS software, up to and including Windows. Just because I include a piece of software doesn't mean it has to then turn into a universal panacea providing 1000s of different core requirements to view all files I have on my CD-ROM distribution.
If I distributed a PDF document with my application would you assume that I had to write my program to read Adobe Acrobat files? I wouldn't. I'd expect to notify the user that Adobe Acrobat is required.
<<
On the other hand (the confusing part), if all you provide is an Access
database, which requires Access in the first place to use *any* of it, then
all is okay. Once a person is able to use *part* of what you provide, then
they need to be able to clearly see all used OGC.
>>
This is really, really thin.
If I distribute OGC on a CD, and chapter 1 is in MSWord, chapter 2 is a PDF, and chapter 3 is an encrypted binary file that can only be read by a program I wrote that's also on the CD, then my program shouldn't have to be able to read MS Word and PDF files.
You are reading in an entire tome into the OGL, sir.
It simply doesn't address these issues at all, and certainly not with the wild specificity you are proposing. Perhaps you feel this is how it would be convenient for things to work, but certainly the OGL should not be read in such a fashion as to require this sort of odd take you have on things.
<<As a last example, you may provide a program that only works
on some unusual computer and operating system in the Eskimo language. The
point is, that once an Eskimo with that machine and operating system is able
to run your program and use it, all OGC must be clearly viewable to that
person.>>
I think the point is that the intended audience, with ALL the appropriate pieces of software and linguistic skills in place should be able to "clearly identify" the OGC.
I think its an onerous requirement that if one piece of software is used for one task it must therefore be a universal panacea and be able to open, display, and analyze every other computer file distributed along with it.
IANAL
YMMV (and probably does)
