Task #1723
Updated by Cesar Ordiñana almost 13 years ago
The gvsig tools library is divided in the following subprojects:
* org.gvsig.tools.lib: framework related utilities.
* org.gvsig.tools.swing.api: UI framework related utilities API.
* org.gvsig.tools.swing.spi: UI framework related utilities SPI.
* org.gvsig.tools.swing.impl: UI framework related utilities implementation.
* org.gvsig.tools.swing.serv.jform: service to create forms for DynObjects.
* org.gvsig.tools.swing.serv.field: service to create form fields for DynObjects.
* org.gvsig.tools.swing.serv.jlist: service to create form fields of type list for DynObjects.
* org.gvsig.tools.main: showcase and testing application.
First tasks to perform:
* Checkout the current trunk project source code. (DONE)
* Compile it: mvn clean install (DONE)
Tasks to perform:
h1. Code Copyright Review
# 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.
Make sure all source code files contain the current valid gvSIG header. You can use a maven plugin configured to perform the task with::
mvn license:format
Once the process has finished, review the file changes and upload them to the repository. For example, perform a *mvn clean install*, check all unit tests keep working, and check also the *.main* project to see if it still works.
This tool will change all source code files. If there are external files with other copyright header or ownership, undo the change before uploading the header changes. Finally, commit all changes.
If the headers have been already updated, check if they are correct with the following instruction::
mvn license:check
# 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.
# Maintain a list of all copyright holders identified in the Provenance 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, although this is not required.
**Headers updated and uploaded, all files belong to the gvSIG project, so no copyright issues**
**Copyright holder: gvSIG Association**
h1. Library/Component Review Process
# List any external components that are included "in the source tree" for the project.
**There
There are not any external components in the source code of the project.** project.
# List all external dependencies with:
* 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).
To perform this task, first of all generate the project's site documentation and upload it: mvn site-deploy. It will take a very long time to generate all the site documentation, as the javadoc pages generation takes ages and generates a lot of files, which must be uploaded one by one.
Then go to the site of each final submodule project (the ones with java code) (ex: ...) and open the link *Project Information > Dependencies*. *...*. There you will find all project dependencies and its license. Add the following anchor link Review them to the URL to go straight to the dependency tree: *#Dependency_Tree*.
Review all the external look for dependencies and its related license. If with non-compatible licenses, or the ones whose license is not defined, look for the project home page and its license. If there is any incompatibility with the GPLv2 license add a note so you will have to the dependency, license if any, project home page and all available information.
You can take a look at the following page for a list of GPL compatible and non-compatible or non-free licenses: http://www.gnu.org/licenses/license-list.html .
**Dependencies without defined license:**
* SLF4J: MIT (COMPATIBLE).
* Easymock: Only for testing, we don't distribute it.
**Dependencies with incompatible license:**
* log4j: CPL v1.0. (We might change to another logging implementation, like Logback: http://logback.qos.ch/license.html).
* flib-jcalendar: Artistic License. If it is the 1.0 version of the license, it is not compatible with GPL. From version 2.0 onwards it is compatible. Maybe we should ask the library developer to know for sure.
* org.gvsig.tools.lib: framework related utilities.
* org.gvsig.tools.swing.api: UI framework related utilities API.
* org.gvsig.tools.swing.spi: UI framework related utilities SPI.
* org.gvsig.tools.swing.impl: UI framework related utilities implementation.
* org.gvsig.tools.swing.serv.jform: service to create forms for DynObjects.
* org.gvsig.tools.swing.serv.field: service to create form fields for DynObjects.
* org.gvsig.tools.swing.serv.jlist: service to create form fields of type list for DynObjects.
* org.gvsig.tools.main: showcase and testing application.
First tasks to perform:
* Checkout the current trunk project source code. (DONE)
* Compile it: mvn clean install (DONE)
Tasks to perform:
h1. Code Copyright Review
# 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.
Make sure all source code files contain the current valid gvSIG header. You can use a maven plugin configured to perform the task with::
mvn license:format
Once the process has finished, review the file changes and upload them to the repository. For example, perform a *mvn clean install*, check all unit tests keep working, and check also the *.main* project to see if it still works.
This tool will change all source code files. If there are external files with other copyright header or ownership, undo the change before uploading the header changes. Finally, commit all changes.
If the headers have been already updated, check if they are correct with the following instruction::
mvn license:check
# 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.
# Maintain a list of all copyright holders identified in the Provenance 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, although this is not required.
**Headers updated and uploaded, all files belong to the gvSIG project, so no copyright issues**
**Copyright holder: gvSIG Association**
h1. Library/Component Review Process
# List any external components that are included "in the source tree" for the project.
**There
There are not any external components in the source code of the project.** project.
# List all external dependencies with:
* 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).
To perform this task, first of all generate the project's site documentation and upload it: mvn site-deploy. It will take a very long time to generate all the site documentation, as the javadoc pages generation takes ages and generates a lot of files, which must be uploaded one by one.
Then go to the site of each final submodule project (the ones with java code) (ex: ...) and open the link *Project Information > Dependencies*. *...*. There you will find all project dependencies and its license. Add the following anchor link Review them to the URL to go straight to the dependency tree: *#Dependency_Tree*.
Review all the external look for dependencies and its related license. If with non-compatible licenses, or the ones whose license is not defined, look for the project home page and its license. If there is any incompatibility with the GPLv2 license add a note so you will have to the dependency, license if any, project home page and all available information.
You can take a look at the following page for a list of GPL compatible and non-compatible or non-free licenses: http://www.gnu.org/licenses/license-list.html .
**Dependencies without defined license:**
* SLF4J: MIT (COMPATIBLE).
* Easymock: Only for testing, we don't distribute it.
**Dependencies with incompatible license:**
* log4j: CPL v1.0. (We might change to another logging implementation, like Logback: http://logback.qos.ch/license.html).
* flib-jcalendar: Artistic License. If it is the 1.0 version of the license, it is not compatible with GPL. From version 2.0 onwards it is compatible. Maybe we should ask the library developer to know for sure.