Selección de licencias o "Licensing" para la data.

[Roberto Rosario]

Ricardo menciona usar GPL y AGPL para el software lo cual es para mi una excelente elección.  La licencia GPL y derivadas son mis favoritas aunque sean criticadas por ser "restrictivas" por los que no entienden realmente lo que es el concepto Open Source.

Estoy abriendo un topico como lo menciona Ricardo para discutir la licencia, protección y redistribución de la data, que es el activo mas importante del proyecto.

Datasets son mucho mas dinámicos que el software así que no estoy seguro si la licencia MIT seria la mejor opción, en adición a que permite re-licenciamiento de los derivados bajo otras licencias mas restrictivas y no fuerza crédito ni atribución al original.  Para data están: Creative Commons, Design Science y Open Data Commons.

Creative Commons es una licencia para contenido, y es ajustable, para este tipo de data y para el propósito que se vislumbra 'encendiendo' las restricciones: 1) Share-alike y 2) By attribution y 'apagando': 3) Non-Commercial, 4) No Derivatives, proveería protección sin sacrificar interoprabilidad comercial.  Design Science es mas para data científica (tipo research) es praticamente Creative Commons en la configuración que mencioné, pero en también hace distinción entre data primaria y visualizaciones basadas en la data y provee para especificar requisitos de uso en caso que se quieran por ejemplo forzar a los creadores de apps a poner un logo transparente pequeño como lo hace Google maps.  Por ultimo Open Data Commons (http://opendatacommons.org/) creó un set de licencias específicamente para lidiar con datos, pero la mas indicada (Open Database License) no provee para forzar la inserción de logos como se puede hacer en Design Science.  También esta la opción de crear un licencia usando de plantilla estas tres pero harían falta neuronas legales para que revise todo.

[Carlos Zapata]

Saludos.

Se me ocurre que se podría licenciar el "uso y acceso" a la data
dependiendo del tipo de usuario. Por ejemplo: se podría darle acceso
grátis a usuarios individuales para crear, modificar, y consumir la
data (esto incluye developers individuales o "shops pequeños") y
cobrarle al gobierno y entidades con fines de lucro por el acceso y
uso de la data.

Mi razonamiento es el siguiente:
1. El usuario individual será el más apto para proveer la data (crowd-
sourcing) y a la misma vez pienso que, inicialmente, serán los que más
se beneficien de su uso.
2. Las entidades gubernamentales y con fines de lucro tienen los
recursos monetarios para pagar por el uso de la data y así ayudar a la
longevidad del proyecto para que no termine siendo "abandon-ware".
3. A las entidades que paguen por el uso de la data se les podría
otorgar una licencia menos restrictiva en cuanto a derivativos, uso y
consumo, y "attribution" por escala. O sea, mientras más paguen, más
"libertades" se le otorgarían.

Ricardo, sé que esto es una "bastardización" de los principios de
FOSS. Es sólo algo que se ocurrió. No recuerdo haber visto este tipo
de licenciamiento usado anteriormente y tampoco sé si es posible. Pero
me parece interesante el "merge" de los tipos de licenciamiento.

[Roberto Rosario]

Por mi parte yo libero todo sin ningún tipo de restricción, pero tengo que admitir que los puntos que expones son muy interesantes.  Esto es algo que hay que definir bien desde el principio y para mi es personalmente importante pues tengo un proyecto para geocodificar puntos de interés submarinos en el Atlántico que puede servir de backend para PRDB.  El proyecto es cerrado pues fue pagado por una entidad privada, pero si los términos de licenciamiento son aceptables puedo entrar en comunicación con el cliente original para negociar la liberarción el proyecto, o al menos partes, o un 'fork' para hacer 'backporting' solo de lo que haga falta.

[Roberto Rosario]

Unos screenshots de una prueba usando algunos módulos de ASWiGD (Atlantic Submarine Wildlife and Geographic Database) para probar que tan viable seria hacer un backend para Puerto Rico Data Bank.

El test tiene apoyo para: puntos (lugares atómicos, teléfonos públicos, postes de alumbrado), lineas (puentes, cruces), polígonos (estructuras, edificios), multilineas (rutas, caminos), multipuntos (nidos de aves, lugares íntimamente relacionados entre si), multipoligonos (lagos, humedales), al momento todos son planos (no 3D) pues agregar apoyo para DEMs (digital elevation models) complica demasiado todo (base de datos, API, queries) y la utilidad extra que se obtiene es poca.  El sistema de metadatos esta sacado directamente de Mayan EDMS y apoya typos de metadatos (color, # telefono,), con lookup de opciones y valores default, apoya tambien sets de metadatos para agruparlos y facilitar el data entry.  Los elementos permiten un nombre, descripcion y al ser grabados se les asigna una numero universalmente único (UUID).  En la prueba tambien transporte la base de datos de fronteras mundiales que sirve para validar coordenadas durante el data entry obsevando que esten dentro del poligono de Puerto Rico o del país contra el cual se comparen, esta base de datos luego se puede extender manualmente para crear polígonos de pueblos y barrios para mayor precisión de validación y queries utilizando pueblos ("Todos los teléfonos públicos en el pueblo de Cidra").  De seguir adelante solo faltaria agregar código para indexar contenido para hacer full text searching de nombre, descripción y metadatos de los elementos, y mover el sistema de API de Mayan EDMS que es bien flexible y empezar a definir métodos de API para crear, editar, borrar elementos y para ejecutar algunos queries geograficos contra la dase de datos.

[Carlos Zapata]

Se ven muy bien los screenshots.

Mencionas el apoyo a polígonos, multi-lineas, etc, creo que es
importante que se apoye ese tipo de data. Pero me preocupa un poco la
mecánica para obtener datos más complejos que puntos ya que,
inicialmente, se está pensando hacer "crowd-sourcing" para obtener la
data y no veo una manera fácil de validar eso inicialmente. Por
ejemplo, yo me puedo parar en un esquina y usar el app para registrar
que ahí hay un McDonalds aunque no lo haya. Ricardo y yo hemos
discutido par de ideas sobre como validar la data pero tenemos que
definirlo mejor. Me parece que en este momento ese es el reto más
grande que tenemos, el validar la data "crowd-sourced".

Veo que estás usando django. ¿Que usas de base de datos? Yo escribí un
API inicial en PHP que usa MySQL de base de datos pero he estado
considerando MongoDB por la razón de que sería más conveniente para
almacenar la metadata. Me gustaría hablar contigo un poco sobre los
aspectos técnicos de almacenar la data necesaria para escuchar tus
recomendaciones.

[Roberto Rosario]

Gracias :) Esta un poco rough porque fue un code sprint de par de hora solo para probar viabilidad.

Si, en GIS, puntos es lo menos que se usa siendo poligonos el pan de todos los dias.  Para validar la data crowd sourced se puede usar una de dos:

• Moderación/curación centralizada - plus: mejor calidad de datos, contra: mucho trabajo.
• Moderación distribuida - Datos sometidos caen en un área de staging y comienzan a recibir un rating (ej 1 a 5 estrellas), solo cuando los datos pasan de X cantidad de ratings y si los ratings son Y cantidad positivos vs. negativos entonces los datos caen en la base principal.  En cuyo caso aun así están sujetos a que alguien los reporte como incorrectos, entonces se hace moderación manual o se mueven otra vez al queue de staging para que sean evaluados por la gente.  Este es el algoritmo que usa OpenRelay para hacer blacklisting the nodos y contenido de forma distribuida y que nadie controla realmente, obteniendo contenido auto regulado, por eso OpenRelay es llamado un network "self-healing".

No sabia que ya tenían un backend no lo había visto en ningún tópico.  Mi experiencia con MongoDB ha sido muy buena al punto que lo estoy empezando a usar para storage con GridFS también.  Podemos hacer un Google hangout para tirar mas ideas.

[Carlos Zapata]

Me gusta la idea de Moderación distribuida porque incentiva más aún la
participación. Ricardo me había hablado de algo parecido. En caso de
ser así, se le podrían asignar "badges" a los contribuyentes tanto por
registrar lugares como por la fidelidad de sus registros.

En cuanto al backend, es algo bien simple para iniciar el proyecto y
poder sacar un app a la calle. Definitivamente no es el modelo final.

[Roberto Rosario]

Si la gamificacion es realmente el hook psicologico para provocar el engagement de los usuarios.  Verifique la pagina de github pero no sale nada, hace tiempo que no toco PHP pero seria bueno verlo tomar forma.

[Ricardo Alcocer]

El codigo que me dio Carlos para subir a Git lo tengo local todavía.  A.ver si en el fin de semana logro sacar tiempo para subirlo.

R