Procedures for making draft software publicly available for comment.

This license and the specified additional information has now been used for several draft releases, which are listed at https://www.broadband-forum.org/software (a permalink that re-directs to the Software Release Registry public wiki page).

Introduction

BBF wishes to be able to make publicly-available draft software releases.

Reasons to make draft software releases:

  • Due diligence: should lead to higher quality software deliverables (implies ability to handle comments received).
  • Transparency/publicity: letting people see what BBF is working on.
  • Providing code to be tested: don’t want barriers to road-testing.

Additional rationale for making draft software releases:

  • Desire to share draft software with the relevant design authorities, e.g. with IETF for core YANG modules, with IEEE for Ethernet-related YANG modules etc. Any materials sent to many of these design authorities will be publicly available, so the problem has to be solved anyway.
  • The community that’s interested in BBF activities is bigger than the BBF membership. BBF membership covers the specification writers but not the implementers. It’s desirable to signal BBF intentions to the bigger audience as early as possible.

Additional notes about draft software releases:

  • A draft software release is subject to major or minor change before it becomes final:
    • For example, data model definitions and/or APIs might change in non-backwards-compatible ways.
    • A draft software release consists of either:
      • Standalone draft software, or
      • A draft specification plus draft software that is part of that draft specification.
      • A draft software release is made available publicly:
        • It can be downloaded freely without the need to accept an agreement.
        • The draft software will be placed on a public GitHub site (or similar).

The draft specification document, if any, may be placed on a BBF web site or may also be placed on a public GitHub site (or similar).

Handling of Public Comments

BBF staff and members may at their discretion view public comments and incorporate (or not) ideas or feedback reflected in those comments in the same manner as normal BBF contributions.

Public comments are given with no assurance that they are original, or that the commenter has the necessary legal rights to contribute any included intellectual property. BBF staff and members should therefore exercise caution before including in a contribution any text or code received in a public comment.

Draft License

This license will be included in each file that is part of the draft software release.

Copyright (c) <YEAR>, Broadband Forum

This is draft software, is subject to change, and has not been
approved by members of the Broadband Forum. It is made available to
non-members for internal study purposes only. For such study
purposes, you have the right to make copies and modifications only
for distributing this software internally within your organization
among those who are working on it (redistribution outside of your
organization for other than study purposes of the original or
modified works is not permitted). For the avoidance of doubt, no
patent rights are conferred by this license. 

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

Unless a different date is specified upon issuance of a draft
software release, all member and non-member license rights under the
draft software release will expire on the earliest to occur of (i)
nine months from the date of issuance, (ii) the issuance of another
version of the same software release, or (iii) the adoption of the
draft software release as final.

 

Member Copyright Statements

Members are responsible for adding their own copyright statements, where appropriate. The BBF copyright will be separated from the member copyright as shown below (this actually applies to all releases, not just to draft releases):

Copyright (c) <YEAR>, Broadband Forum


The undersigned members have elected to grant the copyright to
their contributed material used in this software:
  Copyright (c) <YEAR>, <MEMBER>

<LICENSE TEXT AS SHOWN ABOVE>

Additional information

This additional information will be included in each file that is part of the draft software release.

<DRAFT>

Draft software release unique identifier.

<NAME>

Software project name.

<LINK>

Link to public web page that provides access to details of all draft and final versions of this software project.

Checklist

Some of these rules are derived from similar rules in the YANG Publication page. All the rules need to be defined more rigorously.

The whole topic of how the draft software release should be pushed to GitHub is a separate topic and is not addressed here. One important consideration is whether to collapse the internal commit history before pushing to GitHub (this has implications for how the release will be prepared, e.g. it may make sense to prepare it in a temporary branch, or even in the master branch).

  1. Determine the draft software release unique identifier (<DRAFT> in the Additional Information specified above)
    1. The identifier SHOULD be of the form WT-nnnixaycz_draftd with the usual convention that i=1, a=0 and c=0 are omitted, and with d starting at 1, e.g. WT-369_draft1, or WT-181i2a12_draft2
    2. The identifier SHOULD be used internally, e.g. in documentation, when referring to the draft software release
  2. Ensure that all files that are part of the draft software release include the Draft License and the Additional Information (specified above).
    1. This requirement doesn't apply to non-Software files that are part of the draft software release
  3. Ensure that the draft software release's top-level directory includes a LICENSE file (containing the Draft License) and a PROJECT file (containing the Additional Information)
    1. These file names are RECOMMENDED but can be adjusted to match local conventions
    2. The PROJECT file is RECOMMENDED but is not REQUIRED
  4. After the draft release has been completed, update and tag the affected Bitbucket repositories
    1. For each affected repository, merge the release branch into master, and apply the tags in master (if publishing directly to GitHub, this can be done by pushing from master to the GitHub master)
    2. For primary repositories (e.g. for a WT-369 release, the primary repository is WT-369), the tag name is vx.y.z-draftd, where x, y, z and d are as in the draft software release unique identifier, e.g. for WT-369_draft1 the tag is v1.0.0-draft1
    3. For secondary repositories (e.g. for a WT-369 release, the secondary repositories are WT-106, WT-181 etc.), the tag name is preceded by WT-nnn- (where WT-nnn is the primary repository), e.g. for WT-369_draft1 the WT-106 and WT-181 tags are both WT-369-v1.0.0-draft1
  5. Update the release and develop branches to have the standard license and no longer to refer to draft releases
    1. This is important because it means that the "draft-ness" is only visible in the master branch, and members will see the appropriate license in the release and develop branches
  6. Update the Software Release Registry wiki page
    1. Currently only SAG and a few others are able to edit this page directly, but everyone can edit a child "In Progress" page
  • No labels