Intermediate Builds. If Licensee generally uses a bona fide open source software development methodology and does so to develop the Product, then, notwithstanding the limited license grant set forth in Section 2.1(a) or the additional limitation set forth in Section 2.1b(v), Licensee may make "Intermediate Builds" available subject to the following conditions: i. such Build is marked with the word "UNTESTED" or "INCOMPATIBLE" or "UNSTABLE" or "BETA" in any list of available builds and in every link initiating its download, where the list or link is under Licensee’s control; ii. Licensee displays the following notice in such a manner that anyone downloading the Intermediate Build must see the notice before commencing the download: "This is an intermediate build made available for testing purposes only. The code is untested and presumed incompatible with the <name of Java Specification>. You should not deploy or write to this code, but instead use the tested and certified <name of Java Specification> compatible version of the code that is available at [include a url and a link]. Redistribution of any Intermediate Build must retain this notice." Licensee must also include the same notice as a README.<shorthand name of specification> file with any source code bundle (e.g. tarball) download that corresponds to the Intermediate Build; iii. Moreover, Licensee shall not distribute (except as a passive download as provided above), market or promote Intermediate Builds, including without limitation in connection with providing any goods or services. iv. After making its initial release of a Product available, for any Intermediate Build subsequently made available by Licensee that is for the same context or environment (e.g. described by the same hardware architecture, operating system and version, and Java Virtual Machine version). Licensee must at all times also make the corresponding Product available. The link to such Product must be prominent and in close proximity to any corresponding Intermediate Build in any list of available builds or downloads. v. Licensee must include the following README.<shorthand name of specification> file in the root directory of any source code it may make available through access to a revision control system (e.g. CVS): "This version of [Project name] source code is made available in support of the open source development process. Some numbered or tagged revisions of this source have been tested and found to pass the <name of Java Specification> Compatibility Test Suite, and you can find information on which revisions or tags at [include URL and link]. Please note that since only binaries can be tested, source code cannot be described as a compatible implementation of the <name of Java Specification> Specification. The different build environment on your machine and any changes you may make to this code could render your resulting build incompatible. Because of this, writing or deploying applications to builds based on this code can lead to lack of portability. You should instead consider deploying production applications on the pre-built binaries of [Project Name] that are available at [include a url and a link] that have been tested and certified to meet the <name of Java Specification> compatibility requirements." vi. For each Product released by Licensee, Licensee must: (a) prominently identify the corresponding source version and configuration, including the identifying tag or other indicator required to extract the source code from the project revision control system, if any; and (b) provide a description of the build environment that was used to create the Product. For any notice required under this Section 2.1(c), in addition to providing such notice in English you must also include one or more accurate translations of the notice(s) in languages appropriate for the primary intended audiences when such audiences do not have English as their primary language.
Appears in 15 contracts
Samples: Stand Alone TCK License Agreement, Stand Alone TCK License Agreement, TCK License Agreement
Intermediate Builds. If Licensee generally uses a bona fide open source software development methodology and does so to develop the Product, then, notwithstanding the limited license grant set forth in Section 2.1(a) or the additional limitation set forth in Section 2.1b(v), Licensee may make "Intermediate Builds" available subject to the following conditions:
i. such Build is marked with the word "UNTESTED" or "INCOMPATIBLE" or "UNSTABLE" or "BETA" in any list of available builds and in every link initiating its download, where the list or link is under Licensee’s control;
ii. Licensee displays the following notice in such a manner that anyone downloading the Intermediate Build must see the notice before commencing the download: "This is an intermediate build made available for testing purposes only. The code is untested and presumed incompatible with the <name of Java Specification>. You should not deploy or write to this code, but instead use the tested and certified <name of Java Specification> compatible version of the code that is available at [include a url and a link]. Redistribution of any Intermediate Build must retain this notice." Licensee must also include the same notice as a README.<shorthand name of specification> file with any source code bundle (e.g. tarball) download that corresponds to the Intermediate Build;
iii. Moreover, Licensee shall not distribute (except as a passive download as provided above), market or promote Intermediate Builds, including without limitation in connection with providing any goods or services.
iv. After making its initial release of a Product available, for any Intermediate Build subsequently made available by Licensee that is for the same context or environment (e.g. described by the same hardware architecture, operating system and version, and Java Virtual Machine version). Licensee must at all times also make the corresponding Product available. The link to such Product must be prominent and in close proximity to any corresponding Intermediate Build in any list of available builds or downloads.
v. Licensee must include the following README.<shorthand name of specification> file in the root directory of any source code it may make available through access to a revision control system (e.g. CVS): "This version of [Project name] source code is made available in support of the open source development process. Some numbered or tagged revisions of this source have been tested and found to pass the <name of Java Specification> Compatibility Test Suite, and you can find information on which revisions or tags at [include URL and link]. Please note that since only binaries can be tested, source code cannot be described as a compatible implementation of the <name of Java Specification> Specification. The different build environment on your machine and any changes you may make to this code could render your resulting build incompatible. Because of this, writing or deploying applications to builds based on this code can lead to lack of portability. You should instead consider deploying production applications on the pre-built binaries of [Project Name] that are available at [include a url and a link] that have been tested and certified to meet the <name of Java Specification> compatibility requirements."
vi. For each Product released by Licensee, Licensee must: (a) prominently identify the corresponding source version and configuration, including the identifying tag or other indicator required to extract the source code from the project revision control system, if any; and (b) provide a description of the build environment that was used to create the Product. If Licensee generally uses a bona fide open source software development methodology and does so to develop the Product, but compliance with one or more of the requirements enumerated above in this section 2.1(c) would be impossible due to unique technical characteristics of the Product, then Licensee may make such Intermediate Builds available if Licensee expends best efforts to comply with all other requirements of this Section. For any notice required under this Section 2.1(c), in addition to providing such notice in English you must also include one (or more more, if necessary) accurate translations of the notice(s) in languages appropriate for the primary intended audiences when you are aware that such audiences do not have English as their primary language.
Appears in 1 contract
Samples: TCK License Agreement