Disseminating your Open Work

Work developed by RIT Employees (faculty, staff, and students being paid to work on RIT projects) can be released so long as:

• Releasing it under an open license does not conflict with dependencies of any kind of non-Open work.
• Releasing the work openly is within the boundaries of any funding or other obligations that might restrict it. Ideally you would review the conditions of your funding and any potential license conflict issues with RIT Legal to ensure both you and RIT are in the clear to do so.
• You have cleared the release with:
  • The lead faculty member (if you are a student, post-doc, or research staff member)
  • Departmental Permission (if you are an RIT Staff Member)
  • Our IP Policy (if you are faculty)

Students own their own IP as long as it has not been funded through the university or its partners. If a student wishes to have their Open Work officially associated with RIT the release must follow RIT’s policies. If a student’s project is to be released as a personal project, they may still want to follow these steps.

Regardless of the specific type of work, it should be held to a standard of care to ensure legibility, accessibility, ease of understanding, and further contribution. At Open@RIT, we will have templates and boilerplate documents available by the beginning of summer 2022.

Here’s our recommended pre-release checklist:

Name your project uniquely enough to avoid:

• Confusion with other projects or product
• Trademark violations

Scrub the project content itself and its related website, documentation, and comments of:

• Personal information of contributors and collaborators
• RIT Proprietary Information
• Gendered or offensive terminology such as master/slave or whitelist/blacklist. Calls for inclusive language in software code have been growing, especially within open source software projects. Consult tools such as In Solidarity or Google’s guide to Writing Inclusive Documentation.

Include a README file in the repository or section of the documentation or website that:

• Includes a clear description of what your Open Work is and what it does.
• Show examples if possible.
• This file is not a substitute for actual documentation but should provide enough background and detail to allow a reader to familiarize themselves with project purpose, goals, etc.

Include a LICENSE file in the repository or a place in the documentation or website that:

• Includes the text of the license along with any copyright notices
• Please consult our recommended licenses above

Include a CONTRIBUTING file in the repository or a place in the documentation or website that:

• Includes current contact for the leader(s) or maintainer(s) of the project
• Details the process for how the project engages with collaborators and contributors
• Includes a link to RIT’s Code of Ethical Conduct and Compliance. with a statement indicating that all contributors are considered bound by that agreement.

If the project includes third party work under policies such as Fair Use, CCL, OSSL, etc, it must be credited within the project.

Free and Open Source Software

• Permissive Licenses: MIT or Apache 2.0
• Copyleft/Reciprocal License: GPL

Open Hardware Licenses

• Permissive Licenses: CERN-OHL-P or TAPR
• Copyleft/Reciprocal License: CERN-OHL-S
• OSHWA certification recommended

Arts, Humanities, and Related Works

• Any Creative Commons License, though philosophically Open@RIT recommends those that CC labels as “Free Culture” licenses.

Open Access

• All published scholarly works that will not violate a publisher’s copyright should be deposited in RIT’s Scholar Works.

Open Data

• We recommend open data sets be hosted on a service such as Databrary or the Center for Open Science or another profession/discipline-specific data hosting organization under the licenses they use/recommend.