Code Provenance Review - Revision history

Vincentp: fix graduation link

2025-06-05T09:31:57Z

fix graduation link

Kbevers: Fixed formatting of a FAQ question

2019-08-31T09:58:19Z

Fixed formatting of a FAQ question

Wiki-Camerons: Link to Provenance Review Template

2014-12-16T19:41:02Z

Link to Provenance Review Template

Wiki-Camerons: Add link to official version of this document

2014-12-09T21:22:21Z

Add link to official version of this document

Wiki-Camerons: /* Frequently Asked Questions */

2014-12-09T21:18:40Z

Frequently Asked Questions

Wiki-Camerons: Correct grammar and incorrect wiki formatting

2014-12-09T21:18:10Z

Correct grammar and incorrect wiki formatting

Wiki-Camerons: Copied from http://www.osgeo.org/incubator/process/codereview.html version 1.0

2014-12-09T20:13:37Z

Copied from http://www.osgeo.org/incubator/process/codereview.html version 1.0

Show changes

Arnulf: /* Report/Form for Copyright Review */ removed

2007-03-07T22:31:45Z

Report/Form for Copyright Review: removed

Arnulf: /* FAQ */ typo

2007-03-07T22:31:05Z

FAQ: typo

Neteler: Category:Incubation

2006-08-21T12:03:03Z

Category:Incubation

@@ Line 1: / Line 1: @@
 =Code Provenance Review Process=
-'''The official version of this document lives at: http://www.osgeo.org/incubator/process/project_graduation_checklist.html'''
+'''The official version of this document lives at: https://www.osgeo.org/about/committees/incubation/graduation/'''
 ==Document Status==

@@ Line 83: / Line 83: @@
 ;Do I need to track down every contributor and ask for permission to use their code?
 :No. As long as code was knowingly provided by contributors to the project while it was under a clear licensing policy then it is reasonable to assume the project licensing arrangements are accepted unless there is some reason to have doubts. If code was brought into the project from outside sources under ambiguous circumstances then it may be necessary to contact the copyright holder for a legal release, or at least a statement of permission.
-:Some project code was adapted from other sources with ambiguous copyrights, what do I do?
 :First, document such concerns in the review document and within the source files themselves. Second, try to obtain a release to use the provide code. An email statement of permission should be sufficient, but pertinant details of such an email should be included in the source file in questions (eg. date, identification of releasing person, text of the release). If no release is possible, but the code isn't very necessary, consider removing or replacing it to simplify things. Otherwise the issue will need to be discussed in the incubator to assess risk.

@@ Line 22: / Line 22: @@
 The Code Provenance Review is separated into two sections, each with a slightly different process:
-# Create a Provenance Review Document by copying the Provenance Review Template (not created yet, in the meantime use existing review documents as a guide).
+# Create a Provenance Review Document by copying the [[Provenance Review Template]].
 # Complete the Library/Component Review Process.
 # Complete the Code Copyright Review.

← Older revision		Revision as of 21:22, 9 December 2014
Line 1:		Line 1:
	=Code Provenance Review Process=		=Code Provenance Review Process=
		+
		+	'''The official version of this document lives at: http://www.osgeo.org/incubator/process/project_graduation_checklist.html'''

	==Document Status==		==Document Status==

@@ Line 65: / Line 65: @@
     */
-or
+or:
    * COPYRIGHT:    (C) 2001 by the GRASS Development Team

@@ Line 3: / Line 3: @@
 ==Document Status==
-'''Version:''' 1.0
+'''Version:''' 1.1
-'''Status:''' approved
+'''Status:''' draft
-'''Last Edited:''' July 2, 2006
+'''Last Edited:''' TBD
 ==Purpose==
@@ Line 19: / Line 19: @@
 ==Process==
-The Code Provenance Review is separated into two sections, each with a slightly different process.
+The Code Provenance Review is separated into two sections, each with a slightly different process:
-# create a Provenance Review Document by copying the Provenance Review Template (not created yet, in the meantime use existing review documents as a guide)
+# Create a Provenance Review Document by copying the Provenance Review Template (not created yet, in the meantime use existing review documents as a guide).
-# complete the Library/Component Review Process
+# Complete the Library/Component Review Process.
-# complete the Code Copyright Review
+# Complete the Code Copyright Review.
-# submit the completed Provenance Review Document to the Project Mentor for review
+# Submit the completed Provenance Review Document to the Project Mentor for review.
 ==Library/Component Review Process==
 For the overall project, document potential Library/Component issues by:
-# listing any external components that are included "in the source tree" for the project. For instance, GDAL includes a copy of libtiff, libjpeg, etc in the source tree. It is necessary to be able to identify things like that in the source tree that are under their own distinct license, and are not explicitly vetted by the project team. If practical, it is desirable to remove these internal components and treat them as external dependencies. If kept internal, notes on the licenses of the components should be documented using the Provenance Review Template.
+# Listing any external components that are included "in the source tree" for the project. For instance, GDAL includes a copy of libtiff, libjpeg, etc in the source tree. It is necessary to be able to identify things like that in the source tree that are under their own distinct license, and are not explicitly vetted by the project team. If practical, it is desirable to remove these internal components and treat them as external dependencies. If kept internal, notes on the licenses of the components should be documented using the Provenance Review Template.
-# listing all external dependencies with:
+# Listing all external dependencies with:
-## potentially problematic license terms (all non-free libraries, for instance).
+## Potentially problematic license terms (all non-free libraries, for instance).
-## . all libraries with licenses that might conflict (for instance GDAL's use of GPL'ed GRASS libraries in the non-GPL GDAL).
+## All libraries with licenses that might conflict (for instance GDAL's use of GPL'ed GRASS libraries in the non-GPL GDAL).
 ==Code Copyright Review==
 For each project source file, perform the following:
-# . Does the file include the license information? If not, add it if there there is no ambiguity about whether the standard project license applies. If that is not obvious, make notes in the review document.
+# Does the file include the license information? If not, add it if there there is no ambiguity about whether the standard project license applies. If that is not obvious, make notes in the review document.
 # Is the file under the normal project license? If not, make notes in the review document.
 # Is there anything obviously unusual about the origin of the code? Does this pose any conflicts? Is the issue properly described in the source file? For instance, in GDAL, the gdal/port/cpl_strtod.cpp file is closely derived from external code that was placed in the public domain. cpl_strtod.cpp is placed under the normal GDAL MIT/X license, but detailed notes are kept in the header text on it's origin, the fact that this was public domain and so the fact that it is ok to relicense it. Oddities should be noted in the source file itself and in the review document.

← Older revision		Revision as of 22:31, 7 March 2007
Line 17:		Line 17:
	# Maintain a list of all copyright holders identified in the review document. This list is essentially everyone who would need to agree to relicense the project. It may be desirable to seek copyright assignment to a "project lead", or to the foundation to reduce the number of copyright holders for the project though this is not required.		# Maintain a list of all copyright holders identified in the review document. This list is essentially everyone who would need to agree to relicense the project. It may be desirable to seek copyright assignment to a "project lead", or to the foundation to reduce the number of copyright holders for the project though this is not required.

−	~~= Report/Form for Copyright Review =~~

−	~~to be done (TBD) - Brookshier~~

	= Review Document =		= Review Document =

@@ Line 78: / Line 78: @@
 : No.  However, if the code review turns up notes about patent issues - or if there are known patent issues for the project, then these should be noted in the review document.  Generally speaking a proper patent review is very difficult and may increase, rather than decrease, legal liability.
-; Should I be looking for tracemark conflicts?
+; Should I be looking for trademark conflicts?
 : Possibly.  It may be prudent to check for trademark conflicts for the project name, or the name of public packages within the project.  If issues are found they should be noted in the review document.
 [[Category:Incubation]]

← Older revision		Revision as of 12:03, 21 August 2006
Line 80:		Line 80:
	; Should I be looking for tracemark conflicts?		; Should I be looking for tracemark conflicts?
	: Possibly. It may be prudent to check for trademark conflicts for the project name, or the name of public packages within the project. If issues are found they should be noted in the review document.		: Possibly. It may be prudent to check for trademark conflicts for the project name, or the name of public packages within the project. If issues are found they should be noted in the review document.
		+
		+	[[Category:Incubation]]