Es una práctica común hacer algunos ajustes o correcciones en el código de terceros (ya sea una simple idea o una biblioteca completa). Pero también es común que muchos de estos códigos tengan sus propias reglas de licencia y, finalmente, un encabezado en cada archivo con información de copyright.
Después de hacer esas modificaciones, ¿qué es lo correcto a continuación? ¿Mantenga la información de la licencia intocable o intente actualizarla incluyéndose con algo como @authoro @revisionetiquetas?
Otro problema común es cambiar el espacio de nombres / paquete de terceros para que se ajuste a las convenciones de su proyecto. Algunos tipos de licencia incluyen este tipo de información en su bloque de licencia, ¿puedo cambiarla libremente?
Sé que la respuesta a estas preguntas depende de cada tipo de licencia, por lo que para hacer mi pregunta más específica ...
Teniendo en cuenta las reglas generales de licencia (generalmente son diferentes en aspectos menores, ¿verdad?), Es ético (o al menos permitido) que agregue libremente información al bloque de licencia sobre mis modificaciones y quizás también modifique cómo me refiero a él en mi código (por ejemplo, usar YACorp.YALibcomo Utils.YALib)?
Respuestas:
Creo que está confundiendo la licencia del software y cualquier prólogo que pueda ser parte del software.
La licencia es donde los propietarios de los derechos de autor del programa especifican los términos de uso (la licencia) para otras personas. Algunas licencias son muy permisivas, otras son mucho más restrictivas.
El prólogo es donde los autores insertan
@authory@revisionetiquetan para proporcionar una forma de rastrear los cambios en el código fuente. En algunos casos, convertirse en autor de una adición no trivial al código puede darle derecho a reclamar los derechos de autor sobre esa sección del código. Desenredar las preocupaciones de derechos de autor puede ser espinoso y es mejor manejarlo por abogados. Sin embargo, usted declaró específicamente que no le preocupa ese aspecto, así que seguiré adelante.Esto realmente depende de las convenciones del proyecto.
Si bifurcas el proyecto, puedes hacer lo que quieras.
Si planea contribuir con sus cambios al proyecto, debe seguir con la convención establecida. Si hay una razón convincente para cambiar el espacio de nombres, entonces debe presentarlo a la comunidad de la aplicación.
¡No cambies la licencia!
En primer lugar, es probable que no tenga los derechos legales para cambiar la licencia. En segundo lugar, cualquier cambio que realice probablemente estropeará la licencia. Deje los cambios de licencia a los abogados.
En cuanto a la actualización del prólogo, depende de las normas del proyecto. Algunos proyectos no quieren un prólogo porque usan el control de fuente para rastrear eso. Otros proyectos lo hacen. Siga las convenciones del proyecto.
Si te estás guardando los cambios, ¿por qué te importa lo que piensen los demás? Algo que usa solo para usted y que nunca distribuye a otros no tiene ningún impacto en el proyecto original. Entonces no les importa lo que haces.
Si planea distribuir sus cambios o contribuirlos nuevamente al proyecto, debe evaluar las convenciones de ese proyecto. Algunos proyectos no quieren ser bifurcados y tendrán una licencia para evitarlo. Otros van tan lejos como para decir "haz lo que quieras" y te dan carta blanca para que hagas lo que consideres conveniente. En última instancia, la respuesta aquí depende del proyecto particular que esté viendo.
fuente
Agregaría un comentario, en parte para indicarle al lector que el archivo no es "vainilla", con enlaces a cualquier documentación relevante o un sistema de seguimiento de problemas.
Editar: esta situación me recuerda cuando una distribución de Linux empaqueta, por ejemplo, una biblioteca. Debian tiene pautas y estándares sobre cómo se deben construir y nombrar los paquetes, que bien podrían variar de cómo la biblioteca generalmente se distribuye preconstruida.
No creo que deba ser tímido para nombrar / construir / modificar una biblioteca, ya que supongo que no distribuirá el resultado al resto del mundo. En este caso, incluiría un archivo README junto con la fuente que describe qué cambios ha realizado y por qué. Por ejemplo, README. $ {CompanyName} .changes
fuente
Tendrá que consultar la regla de licencia del código.
En general, muchas aplicaciones frontend de código abierto (por ejemplo, Firefox, OpenOffice) consideran su nombre y logotipo de la aplicación como una marca registrada; por lo tanto, si lanzara una versión modificada de la aplicación, no podrá usar las marcas comerciales originales / imagen comercial (por lo tanto, IceWeasel, Torbrowser, LibreOffice).
Sin embargo, la mayoría de las bibliotecas de programación a menudo están menos preocupadas por las marcas registradas, siempre y cuando esté bastante claro quién hace qué (por lo general, esto se puede encontrar en los metadatos de control de versiones).
La información del autor tiene dos propósitos:
Este último se vuelve más importante a medida que sus cambios se hacen más grandes. La información de autoría real generalmente se puede encontrar en el control de versiones, pero algunos proyectos acreditan formalmente a un conjunto de autores en un archivo separado. El punto de corte donde se acreditaría formalmente a las personas varía para cada proyecto, contacte a los autores originales si tiene dudas.
fuente