License Review Tool Requirements, Candidates, and Selection

1

The [[License Review>>url:http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org]] mailing list [[is considering>>url:http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-June/003384.html]] using a project management tool for public tracking of the license review process. This page is for collecting information related to this tool selection.

2

3

The License Committee recommends hiring a person to aid in the identification and implementation of a better workflow for license review. We have decided that the current email listserve is inadequate because it is exceedingly difficult to follow discussions, which reduces participation. The tasks that this person will undertake are:

4

5

* Identify an appropriate license-review vehicle with the below attributes

6

* Implement the vehicle on an OSI-approved host

7

* Document the expected process for reviewing a license and the roles of all participants in the process

8

* Document the solution and any maintenance tasks so they can be handed off to a new maintainer

9

* Evaluate feasibility of creating a complete, searchable database of all license-review emails, either incorporated into the tool or separate from the tool (currently emails are at at least three different urls)

10

11

(((

12

The person may also be asked to:

13

14

* create a maintainable system for making machine-readable licenses available

15

* create a complete, searchable database of all license-review emails

16

)))

17

18

== Requirements for license-review process ==

==== Must have ====

* Ability to submit a license for review

23

* Being able to immediately identify the current state of review for a license (eg. "approved", "rejected", "new", "being redrafted", "invalid", "rejected", etc.)

24

* Ability to submit updated revisions of a license, without destroying previous ones or history

25

* Ability to comment on specific sections/words/lines of a given draft of license

26

* Ability to comment on a license generally

27

* Ability to moderate discussions (including removing comments, editing comments, banning users)

28

* Discussions must be publicly accessible, without authentication

29

* Users must authenticate and maintain a consistent identity in order to comment/participate in the process

30

* Time-stamping of all comments and submissions

31

* Entirely separate discussions for each license

32

* Easy to learn and use by non-technical users

33

* Must not assume experience with specific technical tools (i.e. requirement to use git, XML, a specific programming language, etc.)

34

* Tools should be open source

(((

)))

==== Nice to have ====

41

42

* Ability to cross-reference a different comment in the same or different discussion

43

* Canonical URIs for each license for review

44

* Machine-readable output from the license review process (text of the license + metadata such as Author, Date approved, Link to discussion, etc.)

45

* Low administrative overhead/hosted service (OSI does not have a good track record of hosting/maintaining new services)

46

* Previous license review emails can be added so that all license reviews are in the same place (we may need to engage someone separately to complete a migration)

47

* Badges to easily identify participants to provide context (e.g. OSI board members, long-time community participants, etc.)

48

* Not mandatory to use the tool in order to participate in review, i.e., system integrates with an email workflow

(((

)))