Intermediate Builds Sample Clauses

The "Intermediate Builds" clause defines the requirements and procedures for delivering and reviewing partial or in-progress versions of a project before final completion. Typically, this clause outlines when and how these builds must be provided, what level of functionality or completeness is expected, and the process for feedback or approval from the client. By establishing clear expectations for intermediate deliverables, this clause helps ensure ongoing communication, allows for early detection of issues, and reduces the risk of major problems at the final delivery stage.
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> Compati...
View SourceView Similar (16)

Related to Intermediate Builds

  • Loop Provisioning Involving Integrated Digital Loop Carriers 2.6.1 Where Freedom has requested an Unbundled Loop and BellSouth uses IDLC systems to provide the local service to the End User and BellSouth has a suitable alternate facility available, BellSouth will make such alternative facilities available to Freedom. If a suitable alternative facility is not available, then to the extent it is technically feasible, BellSouth will implement one of the following alternative arrangements for Freedom (e.g. hairpinning): 1. Roll the circuit(s) from the IDLC to any spare copper that exists to the customer premises. 2. Roll the circuit(s) from the IDLC to an existing DLC that is not integrated. 3. If capacity exists, provide "side-door" porting through the switch. 4. If capacity exists, provide "Digital Access Cross Connect System (DACS)- door" porting (if the IDLC routes through a DACS prior to integration into the switch). 2.6.2 Arrangements 3 and 4 above require the use of a designed circuit. Therefore, non- designed Loops such as the SL1 voice grade and UCL-ND may not be ordered in these cases. 2.6.3 If no alternate facility is available, and upon request from Freedom, and if agreed to by both Parties, BellSouth may utilize its Special Construction (SC) process to determine the additional costs required to provision facilities. Freedom will then have the option of paying the one-time SC rates to place the Loop.

  • Verizon OSS Facilities Any gateways, interfaces, databases, facilities, equipment, software, or systems, used by Verizon to provide Verizon OSS Services to Covista.

  • Site Visits ‌ The Commission may visit the School at any time and may, at its discretion, conduct site visits and monitoring. When appropriate, the Commission shall make reasonable efforts to provide notice of visits. Such site visits may include any activities reasonably related to fulfillment of the Commission’s oversight responsibilities including, but not limited to, inspection of the facilities; audit of financial books and records; inspection of records maintained by the School; interviews and observations of the principal, staff, school families, staff of an affiliated nonprofit or educational service provider and community members; and observation of classroom instruction.

  • DISADVANTAGED BUSINESS ENTERPRISE OR HISTORICALLY UNDERUTILIZED BUSINESS REQUIREMENTS The Engineer agrees to comply with the requirements set forth in Attachment H, Disadvantaged Business Enterprise or Historically Underutilized Business Subcontracting Plan Requirements with an assigned goal or a zero goal, as determined by the State.

  • Verizon Operations Support Systems Verizon systems for pre- ordering, ordering, provisioning, maintenance and repair, and billing.