From RAIL to Open RAIL: Topologies of RAIL Licenses — Responsible AI Licenses (RAIL)

In essence, we could consider licenses associated with AI related artifacts to be RAIL Licenses if:
they include behavioral-use restrictions which disallow/restrict certain applications by the licensee; and 
they require downstream use, including re-distribution, to include, at minimum, those same behavioral-use restrictions
Collectively, we refer to these as the “Use Restrictions”.
In this blog post we outline a new naming convention for RAIL Licenses that we hope the community shall find useful when conceptualizing and/or selecting their own Use Restrictions. We begin by discussing what the artifact being licensed, and subject to Use Restrictions, is : Is it the data (D)? The source code (S)? The model (M)? An application/service (A)? Combinations thereof? 
Data: The dataset(s) used to pretrain or train an AI Model.
Application/service: Any executable software code or application, including API-based remote access to software.
Model: Machine-learning based assemblies (including checkpoints), consisting of learnt weights and parameters (including optimizer states), corresponding to the model architecture.
Source: The source code and scripts associated with the AI system.
In order to easily distinguish licensing types using acronyms, we use the following representative naming conventions:
RAIL-D:  RAIL License includes Use Restrictions only applied to the data
RAIL-A:  RAIL License includes Use Restrictions only applied to the application/executable
RAIL-M:  RAIL License includes Use Restrictions only applied to the model
RAIL-S:  RAIL License includes Use Restrictions only applied to the source code
The nomenclature of each RAIL identifies what artifact the Use Restrictions apply to; licensing of AI artifacts in a RAIL license may be combined in various ways and should be listed in D-A-M-S order. For example, a RAIL License applying Use Restrictions to data, source code, models and applications/services would be referred to as a “RAIL-DAMS” license. Alternatively, a RAIL license applying Use Restrictions to the model and the source code would be referred to as a “RAIL-MS” license.
Open RAIL Licenses
Does a RAIL License include open-access/free-use terms, akin to what is used with open source software? 
If it does, it would be helpful for the community to know upfront that the license promotes free use and re-distribution of the applicable artifact, albeit subject to Use Restrictions. We suggest the use of the prefix "Open" to each RAIL license to clarify, on its face, that the licensor offers the licensed artifact at no charge and allows licensees to re-license such artifact or any subsequent derivative works as they choose, as long as the Use Restrictions similarly apply to the relicensed artifacts and its subsequent derivatives. A RAIL license that does not offer the artifact royalty-free and/or does not permit downstream licensing of the artifact or derivative versions of it in any form would not use the “Open” prefix.
This table shows a comparison of Open Source terms, Creative Commons terms and RAIL terms, so readers can more easily discern how the former two and RAIL terms address both overlapping and orthogonal concerns:
License
Yes
Yes
The table above is representative of certain OpenRAIL terms, and is not meant to be exhaustive. In particular, because open source requirements vary widely.  If the licensor has in-licensed open source code and chooses to redistribute such code, the licensor should continue to ensure that such redistribution is in compliance with the original, applicable open source terms.
In the table above, the  licenses require downstream users to comply with the terms identified with a “yes” - “OSI” refers to Open Source Initiative, whose definition of “open source” is our reference point in this table. See https://opensource.org/osd . CC” refers to Creative Commons, see: https://creativecommons.org/
In summary,  a license which includes behavioral-use restrictions on the artifact being licensed may be termed a RAIL license if Use Restrictions (as defined herein) apply both to the artifact and any derivative works. 
Further, we can utilize a simple naming convention  for open versions of RAIL Licenses – in DAMS order – to specify the artifact(s) being impacted by Use Restrictions: 
D: for data being licensed
A: for apps/binaries/services/executables or any non-source code form of the artifact
M: for models/parameters
S: for source code, including libraries and toolkits
Lastly, the naming convention proposed requires that RAIL Licenses which offer artifacts at no charge and allows licensees to re-license such artifacts or any subsequent derivative works as they choose to include the prefix “Open”. 
The following flow-chart presents a visual summary of the suggested naming convention.
Discussion
The Open Source movement has been critical to the growth of transparency and reproducibility in science allowing people to license code easily and with understandable clauses. We introduce the idea of Open RAIL licenses as an attempt to provide practitioners with more control over how what they create is used, while also creating a simple and understandable mechanism for them to license material broadly and permissively. However, there were several design choices that have been made in their development that deserve deeper discussion.   Data, apps, models and source code, each have their own considerations when it comes to licensing and we recognize the need for more deliberation on how RAIL licenses would need to be structured, organized as well as, tools and mechanisms to support developer adoption of RAIL Licenses. 
We’d love to hear what you think!
Contact us here !
Acknowledgments: We would like to thank Julia Haines, Brent Hecht, Joe Lindley, Jesse Benjamin for their feedback to improve the clarity and structure of this blog post.