> Ryan S. Dancey > > > If that is the case, then OGC software > > could be created using the ASP model, even commercial software. > > That's my opinion. If you're not distributing the source code, it > doesn't have to comply with the OGL.
Since XML files are very similar to HTML files, it would stand to reason that it is possible to "clearly indicate" OGC within an XML file. If that is the case, do you see any reason not to carry that logic through to remote procedure calls over the Internet via XML-RPC or SOAP? So long as the client software was kept OGC-free it should allow the creation of distributed applications as well as ASP-based applications. It would allow an unsophisticated user be able to use the client software right out-of-the-box, so long as they had a net connection (a requirement for a commercial product, IMO). It would allow the sophisticated user to take the "clearly identified" source code and compile their own version of the server-side object, which would allow offline operation of the code. It would undoubtedly also create a black-market distribution of the server-side binary by third parties. I'm not advocating such distribution, only pointing out that it would be inevitable. You could use the d20 Logo if the client software were distributed as closed content of a larger work, where the OGC in one or more separate files "clearly identified" by conventional methods (and without needing to resort to the flawed 'appendix' technique). It could satisfy the OGC requirement by including the source code to the server-side object, and perhaps some additional XML files containing OGC to be used by the client in conjunction with the server-side component. There would still be the interactive game rule to watch out for, but that is a relatively easy to avoid. -Brad For those interested in the technical aspects of how this would work, read on: XML-RPC (Remote Procedure Call) and SOAP (the Simple Object Access Protocol) allow binary software to call libraries on remote machines over the Internet. The process for both is the same: The client packages up all of the parameters of a function call in XML and transmitting an HTTP request over the net. The server unpacks the XML, performs some sort of work (in this case involving OGC in a binary file that does not get distributed), and replies to the HTTP request with an XML file of its own, containing the results of the function (and presumably some OGC). The client then unpacks the XML, performs some work, and then displays it to the user. The only time OGC is actually distributed under this model (other than the conventional text or XML files distributed with the client) is during the XML transmissions between the server and the client. It also seems that so long as the XML transmissions "clearly indicate" the OGC they contain there would be no violation of the license. In practice, each request and reply would be a stand-alone OGL licensed work. Further, since the XML-RPC and SOAP discovery and transmission protocols are public domain (published by the W3C), there is no problem with having an "authority to contribute" the XML schema if you simply wanted to mark every portion of the exchange as 100% OGC. SOAP is one of the big new technologies in Microsoft's .NET framework, so this technology will be very easy to implement with robust commercial development packages. It is also available to non-Microsoft platforms such as Standard C, Java and Perl under the GPL via The Apache Group, and others. The transmissions are language-neutral, so you only need one server object no matter how many languages your clients use. A key requirement is that the client software must be kept OGC-free. This is possible by using late-binding methods (SOAP requirement and built into Microsoft .NET) and by using thin-client coding techniques to validate input and display the output from the server-side component, but leaving almost all of the business logic on the server. Such a thin client would be able to contain virtually any proprietary multimedia or textual content, giving plenty of protection to any commercial venture. -Brad _______________________________________________ Ogf-l mailing list [EMAIL PROTECTED] http://www.opengamingfoundation.org/mailman/listinfo/ogf-l
