Instructions for Setting Up a Project on opensolaris.org

After your project is approved by following the project request process, read the following instructions and rules about populating web pages and posting binaries and/or source on opensolaris.org.

Information about managing your Project moving forward can be found on the Project Lead Reference page.

Process and Information

Approvals

If you are a Sun engineering team that is moving a pre-existing, completed project from inside Sun to opensolaris.org, you must use internal processes to get approval to do this.

Trademarks

Solaris and OpenSolaris are trademarks of Sun Microsystems, Inc. that are used to identify Sun products/services. They are used as an adjective, followed by an appropriate noun. It is best/safest to not use these on community and project web pages, particularly in titles.

If you represent a Sun engineering team that is using a code name, that name must be cleared (i.e., approved) for use on this site. It's better/easier not to use code names. Instead, use generic, descriptive words to title your project.

Detail about Sun's trademarks and fair use of them can be found on the Trademarks page.

License Choice

Brand new projects started and developed on opensolaris.org use the Common Development and Distribution License (CDDL). Prototype files containing the CDDL comment block can be found in the prototypes directory of the ON consolidation source hierarchy.

If Sun engineers participate in the project, no internal processes are required as long as internal guidelines are followed.

If a new project is started that uses existing, published open source software, license information must be provided as noted below. If Sun engineers participate in the project, Sun internal processes must be followed.

License Documentation

Wherever information available for download is referenced, licensing information must be posted and/or referenced so applicable licenses can be evaluated prior to downloading anything. This usually means at least two places: the page that points to information available for download, and the page that contains the information that can be downloaded. For example, if code is available for download on the Download Center and a Project page points to the Download Center, both the Download Center page and the Project page must contain licensing information. If the code available for download is small and is posted directly on a Project page, only that page needs the license information.

 Sample Text:
 The NAME (code/tool/component/library/source) is provided under the LICENSE license.

 Where
 NAME = the name of the code/tool/component/library/source;
 LICENSE = name of the license (or well-known acronym) linked to the license text.

Sun Contributor Agreement

A Sun Contributor Agreement must be on file before source or binaries from an external community member is/are posted on opensolaris.org. "Posting" includes integrating source code changes to a source repository or posting source or binaries using tarballs or adding information to web pages.

Bug Categories/Subcategorires

When a project is moved from inside the Sun firewall to opensolaris.org, associated bug database categories/subcategories need to be made available via bugs.opensolaris.org. Sun engineers are responsible for reviewing all bug database categories/subcategories to prepare them for availability. Then send email to oso-admin AT opensolaris DOT org with a list of the product/categories to add to bugs.opensolaris.org. All associated sub-categories will be made available unless explicitly noted in the email that one or more should not be made available.

Posting Locations

Tarballs and ISO images can be posted in two places

• If less than 15M, they can be posted directly on a project webpage.
• If larger than 15M, they need to be posted on the Download Center.

Currently, only Sun employees can post directly to the Download Center. If you are not a Sun employee, please contact someone on your project who is. Sun employees should read the internal webpage for instructions about posting on the download center.

A mechanism will be available at a later date to allow everyone to post directly to the Download Center.

REMINDER: License information must be provided wherever there is a download or pointer to a download. See instructions above under "License Documentation."

Posting Binaries

ONLY BINARIES THAT CAN BE FREELY RE-DISTRIBUTED BY ANYONE MAY BE POSTED ON opensolaris.org. Sun employees must read the additional posting instructions on the internal webpage for instructions and information about publishing binaries on opensolaris.org.

FOR SUN EMPLOYEES ONLY: See the internal webpage for instructions about publishing binaries built from pre-existing Sun source code that is not available as open source yet.

Licensing Information

Create a tarball that contains the binaries and also the following licensing information:

• If using the OpenSolaris Binary License
  • Include a text file that contains the text of the OpenSolaris Binary License.  Name this file: BINARYLICENSE.txt.  This file can be created using the OpenSolaris Binary License text file.
  • Include a file named: README.tarballname.arch.  See the README template for information about the contents of this file and instructions about how to populate it.
  • If some binaries are covered by other licenses, include a file named: THIRDPARTYLICENSE.tarballname.  See THIRDPARTYLICENSE template for information about the contents of this file and instructions about how to populate it.
• If using the CDDL
  • If the binaries were built using only source covered by the CDDL, the binaries are also covered by the CDDL.  A text file must be included with the source that contains the license text.  Such a file can be created using the CDDL text file
• If using one or more different open source licenses
  • If the binaries were built using one or more third-party open source licenses, all requirements of the license(s) must be met, and one or more files containing appropriate license text must be included in the tarball.

Tarball Naming Conventions

In the examples below, the following definitions apply.

• ABBREVIATION = consolidation abbreviation/name
• DESCRIPTION = description of the subset of this consolidation, if applicable
• NAME = [project choice]
• DATE = YYYYMMDD
• ARCH = i386/sparc/ppc

• For Consolidations providing Binaries built from open source
  • ABBREVIATION[-DESCRIPTION]-bins-DATE.ARCH.tar.bz2
  • EXAMPLES:
    • devpro-libm-bins-20051213.sparc.tar.bz2
    • nws-bins-20051127.i386.tar.bz2
• For Consolidations providing Binaries built from non-open source
  • ABBREVIATION[-DESCRIPTION]-closed-bins-DATE.ARCH.tar.bz2
  • EXAMPLES:
    • on-closed-bins-20060102.sparc.tar.bz2
    • nws-closed-bins-20051127.i386.tar.bz2
• For Projects providing Binaries built from open source
  • NAME-bins-DATE.ARCH.tar.bz2
• For Projects providing binaries built from non-open source
  • NAME-closed-bins-DATE.ARCH.tar.bz2

Posting Source

NOTE:Tarballs should only be provided as a convenience or if the associated consolidation gate is inside the Sun firewall. New projects should be started in the open with source code repositories on opensolaris.org. Existing projects with project gates inside the Sun firewall should be moving source repositories to opensolaris.org. The following information is about tarballs and manual posting processes. Instructions for creating source repositories can be found on the Project Lead Reference page.

FOR SUN EMPLOYEES ONLY: See the internal webpage for instructions about publishing pre-existing Sun source code.

Licensing Information

Create a tarball that contains the source hierarchy, release notes or a README file that explains the source hierarchy, dependency information, build instructions, etc. and also the following licensing information:

• If using the CDDL
  • Include a text file at the top of the source hierarchy that contains the text of the CDDL. This file can be created using the CDDL text file
  • Make sure the CDDL comment block in the code references the correct name and location of the license text file in your hierarchy.
• If using the Public Documentation License (for documentation source)
  • Include a text file at the top of the source hierarchy that contains the full license text of the PDL.  Such a file can be created using the PDL text file

Tarball Naming Conventions

In the examples below, the following definitions apply.

• ABBREVIATION = consolidation abbreviation/name
• DESCRIPTION = description of the subset of this consolidation, if applicable
• NAME = [project choice]
• DATE = YYYYMMDD

• For Consolidations
  • ABBREVIATION[-DESCRIPTION]-src-DATE.tar.bz2
  • EXAMPLES:
    • on-src-20060102.tar.bz2
    • devpro-libm-src-20051213.tar.bz2
    • nws-src-20051127.tar.bz2
• For Projects
  • NAME-src-DATE.tar.bz2