This is CHARTER.rtf in view mode; [Download] [Up]
Copyright (c) 1993 Don Yacktman. All Rights Reserved. Version 0.3. MiscKit Charter The MiscKit is a kit of resources provided by members of the USENET and InterNet community for use by anyone who develops under NEXTSTEP and/or Objective-C. Changes, bug fixes, and suggestions for improvement in the kit are all welcome and encouraged. Programmers can submit code and tools, while users can suggest ways to improve what is here, to the benefit of all. In an effort to keep all this in some semblance of order, a few ªrulesº are in place. These rules aren't meant to make things difficult; they are intended to make things so smoothly and without confusion. If this goal isn't being met, then the rules will need to be adjusted to that they are met¼so send your suggestions to the MiscKit mailing list for discussion there. There is no reason why changes can't be made to improve things. Typically, a simple majority of MiscKit authors will need to be in agreement before a change may be made. First, and foremost: Donated code falls under the MiscKit license. There are certain special cases where public domain code is included in the MiscKit, retaining it's own license. In these special cases, the code is under it's own license and does not fall under the MiscKit license. This situation is highly discouraged, and it is up to the MiscKit administrator's discretion to decide whether or not not include such ªindependentº code. By contributing to the MiscKit, the author agrees unconditionally to the terms detailed in this license. If you don't like the license and/or charter, you shouldn't contribute. You cannot contribute under different terms without special permission from the MiscKit administrator, and which won't be easy to obtain. Note, however, that these documents may be revised if ratified by a vote of the MiscKit authors, so you could try to lobby for changes if you like. The charter is a document which accompanies this license and is a part of every MiscKit distribution. Also remember that the author and owner of a resource are the same person unless some written agreement exists which transfers ownership. Remember, also, that you cannot remove a contribution once you have contributed it. (See LICENSE.rtf and License_Notes.rtf 5. for the reasoning behind this.) The previous two paragraphs mention that it is possible to alter the charter and license. This is done by a vote of MiscKit authors. Each author has one vote; if your name is in the AUTHORS.rtf file, you are considered to be an author. When approval is requested for a particular change, failure to respond within two weeks of such a request constitutes a ªYESº vote. Voting is initiated by the MiscKit Administrator; the administrator will prepare a new license or charter with the proposed modifications and then present the new version for voting. Note that although changes are allowed in the charter and license, use and distribution of the MiscKit is free, and must remain so. That means that no party may come in, acquire the MiscKit, and then turn around and charge for it, nor may they impose any new restrictions on the distribution of the MiscKit. Prefix. For consistency, all MiscKit objects, including functions, compiler defines in header files, Objective-C objects, protocols, and defined types will be prefixed with ªMiscº except for the ExtendedApp object, for which MiscExtendedApp is simply far too cumbersome a name. Other exceptions to this rule will only be made in cases where a better solution is impossible, or the Misc prefix would cause a problem worse than the potential name conflicts. The MiscKit administrator must give permission for any exceptions. This prefix is intended to assure that the MiscKit's name space will conflict with no other Objective-C name space or kit. All compiler defines, defined types, and functions are expected to comply with this prefix as well; ªMISCº for defines and ªMiscº for functions. Static functions, variables, or preprocessor defines (static meaning statically defined or only visible within a source .[mc] file) do not need to use the ªmiscº prefix, but anything visible externally is expected to conform to this prefix. Kit maintenance and integration is overseen by the MiscKit administrator, currently Don Yacktman. Maintenance on a particular kit resource is to be handled through the resource's maintainer, as listed in the AUTHORS.rtf file in the MiscKit distribution. That maintainer will forward tested and completed changes to the administrator for inclusion in the official release of the kit. The administrator will also forward changes back to the maintainer rather than just putting them straight into the kit. (ie., just because the administrator makes the distributions does not mean he or she can break this rule and change what an author send to him!) The administrator will accept requests from third party distributors who wish to redistribute the MiscKit and provide them with the latest versions of the MiscKit as well as notification of new releases as they occur. Notification, performed via an e-mail alias, is available to anyone upon request, and will also be sent to the MiscKit e-mail alias (misckit@byu.edu, send mail to misckit-request@byu.edu to get on or off). The administrator may resign his/her post at any time, in which case a new administrator may be chosen and ratified by a simple majority of the MiscKit authors, and should be chosen based upon ability and resources to do a respectable (good) job keeping things up to date. The maintainer for a resource is typically the owner of a resource, which, by default, is the original author. The owner is the person who owns the copyright for a resource; this is the original author, unless a signed agreement transferring the copyright to another individual exists. The owner has the right to choose a maintainer for the resource. The maintainer, unless otherwise specified, is the owner. The maintainer accepts bug reports, code additions and enhancements, and any other feedback pertaining to the resource in question, and is then expected to forward the final revisions, after testing, to the MiscKit administrator for inclusion in the MiscKit. In the event that the owner forfeits the right to choose a maintainer, a maintainer will be chosen from the MiscKit authors, or any other suitable volunteer, by the MiscKit administrator. Note that a resource, once included in the MiscKit, cannot be removed by the owner; by contributing the resource to the MiscKit, this right was forfeited. If the owner decides they do not wish to be bothered by the MiscKit, but do wish to retain ownership for whatever reason, they may do so and a maintainer will be chosen as delineated above. Accepted contributions include foundation objects, interface objects, programming tools, InterfaceBuilder palettes, and ProjectBuilder .bproj (subproject) directories. All contributions should be accompanied by .rtf documentation if possible, but this is not required. If no documentation is provided, some willing soul will be assigned the task of keeping the documentation up to date. Typically, this is easiest to do if the code maintainer is the one who does documentation, and this is encouraged, even though it is not required. New features to the kit and architectural decisions should be discussed in the MiscKit mailing alias so that things are designed right before any code is written. This is not a strict requirement; it is OK to simply submit a resource, but discussion is recommended because it will make for a better design in the long run, and this is the main purpose of the mailing alias anyway. This alias is unmoderated; participants are expected to use their own good judgement. Flame wars are highly unwelcome; only constructive discussion is desired. (Of course, disagreement is expected; without opposing viewpoints it is impossible to consider all eventualities and thus all viewpoints are to be respected, especially when the topic is design of a particular resource.) Resources. Many MiscKit objects can require the use of external resources (tiff images, sounds, .nib files, string tables, etc.). Currently, there are two ways to provide for this. First, for an object in the MiscKit library file (.a), the resources needed should be added to a given project in ProjectBuilder. If the object is available as a ProjectBuilder .bproj file, the subproject should be added to the project; the subproject will contain all necessary resources, which will in turn be incorporated by ProjectBuilder into the project. This is preferred because the resources are encapsulated along with the object that uses them. If enough share±able resources become part of the MiscKit, a third alternative will also be implemented, but at this time is not implemented, and will be known as the MiscKit runtime library. It is hoped by most that a pool of shareable resources never becomes necessary. Although it doesn't exist, the basic shape of a runtime library is already partly fleshed out, in case of the event that it become needed. Basically, it would work like this¼ first, it would be completely contained in a directory that a user would install on their system, installable in either /LocalLibrary (preferred) or in ~/Library. (Another possibility, mimicking NEXTSTEP's shared resources, would be to install in /usr/local/lib or ~/lib.) The folder would be provided in the MiscKit both expanded and as an Installer .pkg file. The .pkg file could then be distributed with any app the uses the MiscKit; if the user hasn't already installed the package, they would do so before installing the app. When installed, subdirectories would be used to specify a particular version of the MiscKit, so that newer resources won't overwrite old resources, since an older third party application might require an older resource. When a MiscKit object requires a resource, it would then ask a manager object (which would be written and added to the MiscKit) to locate the resource. The manager would search, in the following order, the .app wrapper, the user's local ~/lib and ~/Library directories, then /usr/local/lib and /LocalLibrary. Within each of the listed directories, it would search from the newest back to the earliest version of the resource directory. Note that a version of the searcher compiled for a certain revision level of the misckit would start at it's revision level and work down, thus avoiding the problem of grabbing a newer, incompatible, resource. Also, to avoid duplication of resources, only resources that change or are new to the MiscKit would appear in the higher directory levels (since the search will eventually find the old resources in the lower levels). This system is a proposal, and it, or a similar scheme, will be implemented if deemed a worthwhile project by a simple majority of the MiscKit authors, but only if someone is willing to actually implement it. Currently, there is no perceived need for this feature. Any pending projects for the MiscKit will be listed in a TO_DO.rtf file in the MiscKit distribution. This will include things such as ªobjects we'd like to seeº, ªknown bugsº, ªdevelopment tools we'd like to addº, and so on. Anything that would be nice to have, but isn't a current work in progress would turn up in that file. An IN_PROGRESS.rtf file will list any bugs which are currently being chased, any deficiencies which are being dealt with, and any projects in progress. The misckit_proj/Temp directory will hold any projects that are in progress, but are not yet integrated into the MiscKit, if the author wants to make code available for public comment. It is not mandatory to provide the MiscKit administrator with code in progress; this directory is provided solely for those who wish to use it. Nothing in the Temp directory is guaranteed to work at all. It may work, it may not. Backward compatibility between versions is not always guaranteed. Minor revisions will be compatible with any previous version of the same major revision level. Between major revision levels, however, nothing is guaranteed. The programming interface will attempt to be kept uniform as much as possible. Incompatibilities will occur when it is better to move on and use improved code than it is to keep crufty old poorly written code around. In other words, unlike the DOS world, we refuse to keep dumb code around for compatibility's sake alone. The whole point of the MiscKit is to provide a useful kit of state of the art objects. It should be the best that it can be. (To the users of the MiscKit: Note that backward compatibility will be attempted, but it will only be achieved in cases where it is not a hindrance. Most of the time, backwards compatibility will occur, so don't worry about us turning your world upside down. We'll try not to do that. Really.)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.