@(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2006/448-YY 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. The netadmin alias contract-2006-448@sun.com will include both the SUPPLIER and the CONSUMER in this contract. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris Nevada and beyond (bugtraq: xserver) Consolidation: X Department or Group: X, OPG Bugtraq Category/SubCategory: xserver/libx11 Responsible Manager: John McKernan 3. The CONSUMER is identified by the following: Product or Bundle: [TBD] Consolidation: [TBD] Department or Group: [TBD] Bugtraq Category/SubCategory: [TBD] Responsible Manager: [TBD] 4. The INTERFACES are: Interface Classification Comments --------- -------------- -------- XLC UTF-8 at Xlib Contracted Cons. Private Xlib built-in UTF-8 XLC 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing these INTERFACES is: PSARC/2006/448 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: _N_ 7a. Although the stability level doesn't normally restrict it, SUPPLIER promises to only modify INTERFACES in an incompatible way as follows: _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will expose INTERFACES to a PARTNER, which is external to Sun, namely: Name of Company: Name of Department or Group within Company: Responsible Manager: _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same consolidation, they have the option of arranging for simultaneous conversion to the new interfaces. If this is not possible, or if they are not in the same consolidation, then SUPPLIER will either make best effort to work with CONSUMER so that CONSUMER can detect which version of INTERFACES is being supplied, or else SUPPLIER will make best effort to supply both old and new versions of INTERFACES. If SUPPLIER cannot make both versions of INTERFACES available, and SUPPLIER and CONSUMER cannot devise a method whereby CONSUMER can detect which version of INTERFACES is being supplied, and the old version of CONSUMER will not run with the new version of SUPPLIER, then either the EOL process must be followed by SUPPLIER, or else a major release of SUPPLIER will be required, or the change will not be allowed. 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make best effort to accommodate such changes, which shall then be treated in accordance with paragraph 7 above. 9. Notwithstanding paragraphs 7 and 8, a change to any portion of the INTERFACES shall be regarded as a completely new set of INTERFACES which require both ARC approval and execution of a new contract. 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: The SUPPLIER will communicate with all CONSUMERS by using email alias shown at the paragraph 1 and also contact person info at paragraph 3. If any kind of changes are needed at the INTERFACES, the SUPPLIER will first submit the change proposal to all CONSUMER parties and get the approvals from all of them. Once the proposal is approved by all CONSUMER parties, the SUPPLIER will submit the change proposal as an ARC case to ARC and get architecture review and approval if necessary. If the ARC does not approve, the INTERFACES will not be changed. If the ARC approves but requires technical correction(s) that is(are) different from the change proposal that the CONSUMER parties have approved, the SUPPLIER will once again try to gain approvals from all CONSUMER parties; if there is any CONSUMER who wish not to approve the technical correction(s) required by the ARC, the INTERFACES will not be changed. Once all necessary approvals are gained, esp., from all CONSUMER parties and the ARC, the SUPPLIER will develop and test the changes. Once the quality is acceptable by the SUPPLIER's standard, the SUPPLIER will inform all CONSUMERS the availability of the changed INTERFACES. All CONSUMERS have responsibility of doing test and informing back to the SUPPLIER if the changed INTERFACES are acceptable or not. If not acceptable by any of the CONSUMER parties, the SUPPLIER will not ship the INTERFACES. If acceptable by all CONSUMER parties, then, the SUPPLIER will ship the changed INTERFACES. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: When any kind of bugs are found or RFEs are needed, the CONSUMER will file a bug/rfe report to the SUPPLIER through the bugtraq category/ subcategories shown at the paragraph 2. The SUPPLIER will then evaluate the bug report and if the bug or RFE filed is something that will not cause any changes at the INTERFACES and an obvious error against the X Window System specification, then, the SUPPLIER will file a bug/RFE to X.Org Bug Tracking system at the X.Org web site with suggested fix; once the bug is committed to the X.Org master repository, then, the SUPPLIER will supply the bug fix at the SUPPLIER's corresponding master workspace and issue new packages for the next available internal build of Solaris or patchs if the target Solaris release isn't the current release being developed. If the bug or the RFE filed is something that will require changes at the INTERFACES and/or the X Window System specification, the SUPPLIER will file a bug/RFE to the X.Org Bug Tracking system at the X.Org open source community web site. Once the bug or the RFE is accepted and committed to the X.Org CVS, then, the SUPPLIER will follow the steps described in the paragraph 11 and apply the bug fix or the RFE fix, as the changes, to the SUPPLIER's corresponding master workspace and issue new packages for the next available internal build of Solaris or patchs if the target Solaris release isn't the current release being developed. When agreed by both, i.e., the SUPPLIER and the CONSUMER, the bug or the RFE filed will cause changes at the SUPPLIER's corresponding master workspace only and the SUPPLIER will issue new packages for the next available internal build of Solaris or patchs if the target Solaris release isn't the current release being developed. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: There is no documentation available for the INTERFACES except the actual C source program lcUTF8.c shown at the case directory. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: Proper text data exchange among XlcNCharSet, XlcNChar, XlcNString, and XlcNUtf8String for entire supported Unicode coding space will be tested and guaranteed. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: The CONSUMER can terminate the contract at anytime by contacting the SUPPLIER with a written statement of terminating the contract. Afterward, the SUPPLIER will not have any obligation to the CONSUMER in future versions. The SUPPLIER, if wish to terminate contract, must gain approval from the CONSUMER first. Once the CONSUMER approves, then, the contract can be terminated. 15. This contract is not valid until "signed" via agreement from the SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by this contract. E-mail agreement to the contract should be archived in the mail archive of CASE; verbal agreement to the contract should be noted in the meeting minutes. This contract remains valid until superseded or invalidated. For SUPPLIER: Date: For CONSUMER: Date: For ARC: Date: A copy of this contract shall be deposited in the CASE directory as "contract-" or in a "contracts" subdirectory. 16. (Not to be filled in until superseded or invalidated.) This contract was superseded or invalidated by CASE: For ARC: Date: