Virtual Interaction Configuration


Yeah, you'd rather not read this, right? Well I didn't want to write it either but on the subject of legalities you may find this worth reading anyway. It does contain some insight into the functionality of the V.I.C. and the problems the V.I.C. addresses. The essence of the software source legalities is that of GPL. Though some may view GPL as a form of "restricted/constrained software" (in that you are "NOT allowed, in your distribution of it, to NOT make available its open source and your changes to its open source"), I do not share that view of GPL being restrictive due it being insistently "open and available". I still can NOT figure out how any contract/agreement where you give up your constitutional rights, is legal.

Copyrights and Patents

Legal Copyrights and Patents are a product of mans imagination and produce constraints often for the purpose of financial profit. However, such ownership constraints can become, or contribute to, such a legal mess that either nothing is gained financially or profit potential is greatly reduced. In addition, there is the man created concept of piracy where legal copyrights and patents are ignored. Relating this to the V.I.C. : The profit potential from V.I.C. use exceeds, beyond calculation, the profit potential from constraining the V.I.C. to only those whom have paid for it or practice piracy. The greatest potential to gain from the V.I.C., and use of, will only be achieved without constraints restricting use.

Free-ware vs. Commercial-ware

It has always been the intent to make the V.I.C. available as Free-ware. Specifically, the application tool set of the V.I.C.. The V.I.C. is based on concepts found in nature and applied within the inherent constraints of computers. The V.I.C. is built by using long known programming concepts integrated into a small (nine commands) and versatile tool set. If there is anything new here, it might only be the integration but even this could be debatable.

The V.I.C. makes use of data/knowledge/definition bases and processes defined in scripts, where the data/knowledge/definition bases will likely contain such scripts. The data/knowledge/definition bases and scripts are a product of those whom produce them. Of course, these producers are able to place whatever use constraints they wish upon the data/knowledge/definition bases and scripts they create. However, any data/knowledge/definition bases and scripts written with intent to inherently constrain the use of the V.I.C. (via copyrights and/or patents), will be viewed and treated as a contradiction of the efforts and intent of producing the V.I.C. (i.e. defining/creating the english language and its syntax to place constraints on its use, would leave only those whom pay for it, legally allowed to use it. And this would contradict the intent and purpose of creating the language to begin with. The V.I.C., with it's small set of commands, makes it much easier to produce a complete, or near complete, set of general or non-specific processes or cycles.)

In any case of such intentional inherent constraint, the status of the V.I.C. automatically changes from free-ware to Commercial-ware (in regards to the offending party(s)), with a royalty to pay being nothing less than: twice the amount of Investment + Profit and/or Profit from preventing use of the V.I.C., and directed at such party(s) creating and/or profiting from such intentional constraint(s) to legally pay. The solution objective is intended to remove, and keep removed, fabricated illusion based legal constraints. In other words: Don't waist your time with intent to restrict use of the V.I.C., whether it be for direct profit from use or indirect profit from non-use. There is simply far to much benefit to gain from the unrestricted use of the V.I.C. to waist with efforts to restrict use.

To clarify: Data/Knowledge/definition bases and scripts that are specific to the integration of a specified and specific application program set and/or specified and specific objective(s) are fine and constrainable for whatever purpose, so long as they do not constrain the evolutional growth and use of the V.I.C. (i.e. in the field of non-linear video editing, the Newtek Video Toaster Flyer technology is constrainable by Newtek, but it does not restrict others from producing non-linear editors through other methods.)

The Importance of communicating and understanding the purpose of the Free-ware Vs. Commercial-ware condition, is in knowing: by the inherent nature and functionality of the V.I.C., it is possible to create such data/knowledge/definition bases and scripts, and apply the constraints of copyrights and/or patents on them, that would inherently restrict V.I.C. use and evolution. And in doing so, contradict the efforts and intent of producing the V.I.C. Also, Understand it is the intent, in developing and evolving the V.I.C. and its use, to develop such data/knowledge/definitions and script of the complete set of non-specific possible processes and cycles. And to make these data/knowledge/definitions and script available under the same conditions as the V.I.C. application, of being free-ware. Such work is considered part of the application tool set objective. Contributions to such an effort are welcomed and encouraged and credit shall be given where credit is due.

User Registration, Not Shareware

Although the concept of shareware is not allowable or intended, the concept of registered V.I.C. user is allowable under these conditions.

1) There is no such thing as a registered version of the software. Only users are registered.

2) There is no alteration done to the software in the process of becoming a registered user.

3) Only Non-Profit organizations supporting the evolution of the V.I.C. and its use may act as a registration point. And there is, or exist a real effort to establish, a central registered user database to be accessible by all qualified/registered registration points.

4) Any fees/dues/contributions received from registration will be in return for an equal and reasonable level of support. Of which a reasonable percentage may be used for support expenses (i.e. newsletters, postage, etc..)

5) The registered user database will not be used in anyway, shape or form to harm anyone or to harm the evolution of the V.I.C. and it's use. Also, the registered user database will not be shared (sold, rented, or given) to any individual, organization, or company outside the non-profit organizations registered as registration point, without the consent of the individual registered users. And of which only the consenting registered users name(s) and address(s) are given. Also the recipient of such a list must only use it to inform users of the recipients relative supporting products and/or services. The list is not to be used by the recipient in any other way. Also, any consideration for such a list can only be accepted in the form of a voluntary contribution. And such contributions are to be used in giving additional support to the registered users.

6) The distribution of funds received from user registration, need not go beyond the given registration/support point so long as those registering at a given support point receive a fair and reasonable share of support. To encourage world, group and individual support is the why behind establishing a central registered user database. It is through the collected registered user database that all registration points know how to contact all registered users for support exchange. And through the collected consenting user database that additional funds (other than registration) may be obtained. In consideration of funds generated by the consenting user database, there will evolve a mathematical calculation, relative to the consenting user database, to use in the reasonable distribution of such support funds among the world, group and individual support points.

Source Code and the Development of the V.I.C.

1) No source code that is copyrighted/patented for restricted/constrained use shall be used in producing the V.I.C. There is plenty of non-restricted source code to use in producing the V.I.C. thanks to such organizations as the Free Software Foundation. Also, code use is not limited to using existing source code, but to produce the source code with the intent and effort to make it non-restricted in use.

2) Source code of the V.I.C. will be made available to and perhaps through such organizations supporting the free software concept. The source code will be made freely available but protected (via copyright(s) and if needed patent(s)) in order to protect it against constraints contradicting the intent and effort behind the V.I.C.

3) The intent and effort behind the creation of the source code and application is to establish consistent functionality and use. With this in mind, effort is to be applied in meeting this functionality consistency, in regards to producing variations of the V.I.C., in that such data/knowledge/definitions and scripts shall be included in any released version, to allow the given version to meet functionality consistency. Software does evolve but any alteration(s) to the V.I.C. functionality will only be such alteration(s) that addresses and corrects exception failures and does not constrain/break previous working data/knowledge/definitions and scripts. In other words: such alterations will only improve the integration of the programming concepts used within the V.I.C. and as such, improve the Virtual Interaction abilities of the V.I.C.. Such improvement will be shared with all A.S.A.P.

4) To satisfy the problems encountered in developing versions for the different platforms, let it be understood:

a) The primary concept of the V.I.C. is of Virtual Interaction and connection. With this in mind let it be understood the V.I.C. functionality is NOT to be limited to the lowest denominator. Each platform version should take advantage of the limitation ceiling of the given platform. (i.e. single-tasking and filename size ceiling of the old XT's may not be able to take advantage of multi-tasking within itself and files used by the V.I.C. may need to be converted to the 8.3. But given a better understanding of the V.I.C. functionality, it's clear all versions of the V.I.C. can translate, given the proper data/knowledge/definitions and scripts. And although an XT may not be able to have more than one active V.I.C. "cell" running at a time within itself, there will be nothing stopping it from creating a multi-cell structure or passing, via connection to other machines, instructions to help build and run a multi-cell structure.)

b) The functionality of a single V.I.C. "cell" is very much single-tasking or sequential in operation. Because the V.I.C. is built by integrating long known programming concept (concepts not platform specific) there is nothing platform specific about the general design of the V.I.C. (i.e. batch files are sequential regardless of the platform they run on. However, on a multi-tasking platform a batch file can spawn off many application to run simultaneous while the single-tasking platform is inherently sequential in what it can do. Either way the batch file is sequential.)

c) For input and output direction and redirection of platforms and platform specific software that does not include the ability to communicate and control applications through a "side-door", then either this limitation will be treated as a platform/software specific limitation or someone will need to create the utility/device/plug-in or whatever that will enable such "side-door" access. (i.e. on the Amiga, programmers have the option to include an AREXX port for their program. A port that enables the program to receive and send instructions and data to other applications [AREXX use is not required to make use of these ports but often is, due the added functionality of AREXX]. And before AREXX, programs were created enabling an application to be controlled in a manner consistent with a one-way side-door concept, though perhaps just controlling/automating the use of the user interface of the application. On other platforms the concept of plug-ins and the like can add functionality to an application. With this in mind, it should be possible to create such "plug-ins" to make available such "side-door" access to an application. But in any event, this side-door creating is not to be part of the functionality built into the V.I.C. but an external, to the V.I.C., program/device/plug-in or whatever.)

d) Let it be understood: the objective of the V.I.C. is to enable Virtual Interaction connection to happen using must-exist functionality. Any optional functionality is best left to what already exist or can be created external to the V.I.C. We are not inventing or re-inventing the wheel, but creating/producing the functionality to allow the wheels to be attached to and usable by many different things.

Copyright © 1996, 2001 by Timothy V. Rue