@(#)contract 1.9 @(#) /shared/sac/arc/ARC-Templates/contract [1.9 10/04/14] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2010/XXX-01 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Oracle. The internal mailing alias contract-2010-XXX@oracle.com (the email address might need to be changed in future to follow the Oracle policy) 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 Consolidation: ON Department or Group: Sustaining Bugster Product/Category/SubCategory: solaris/library/i18n Responsible Manager: Joseph George 3. The CONSUMER is identified by the following: Product or Bundle: Solaris Consolidation: G11N Department or Group: Solaris G11N Bugster Product/Category/SubCategory: solaris/library/l10n-common Responsible Manager: Shinobu Matsuzuka 4. The INTERFACES are: Interface Stability _icv_open_attr() Contracted Consolidation Private _icv_iconvctl() Contracted Consolidation Private _icv_iconvstr() Contracted Consolidation Private 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing (Exporting) these INTERFACES is: PSARC/2010/XXX 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 Oracle, 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: Since the INTERFACES are initially defined and supplied by CONSUMER (esp. G11N), the CONSUMER (esp. G11N) will maintain the code and the INTERFACES even though the ownership is with the SUPPLIER. Nonetheless, if the SUPPLIER wish to make changes in the INTERFACES, 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. If the CONSUMER (esp. G11N) wish to make changes, the CONSUMER will also follow the same steps described at above. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: While the code and the INTERFACES are owned by the SUPPLIER, basically CONSUMER (esp. G11N) assumes the role of maintenance of the code and the INTERFACE. Nonetheless, if the SUPPLIER wish to take part in the support of the code and the INTERFACES, the following procedure will be used: 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 existing specification, then, the SUPPLIER will supply the bug fix at the corresponding ON gate of the current Solaris in development or of the patch development gate 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 specification, the SUPPLIER will follow the steps explained in the section 10 at above, SDF process, and ON development process to get necessary approvals and integrate the changes to the corresponding ON gate(s) as approved and needed. When the CONSUMER (esp. G11N) will support the INTERFACES, the CONSUMER will also follow the same steps described at above. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: The INTERFACES are described in the spec.txt, iconv-l10n-guide.txt, and associated man pages at the materials directory of the PSARC/2010/XXX. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: For any changes to the INTERFACES will require development of corresponding test cases. SUPPLIER and CONSUMER agrees that in that case, both parties will discuss who will and what to develop as the new test cases and also who will run the test cases to verify the correct operation of the changes. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: The CONSUMER can terminate the contract at any time 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: Joseph George Date: For CONSUMER: Shinobu Matsuzuka Date: For ARC: Ienup Sung 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: