GitHub

Quizás obviamente (aunque quizás no tan obviamente en la era de Wikipedia y tener las preguntas y respuestas de StackExchange editadas por otros sin preguntar) ... el repositorio GitHub de alguien en la web no es algo que se modifique directamente. En su lugar, lo "bifurca" para crear su propio clon, que solo usted (y los colaboradores que designe) pueden modificar.

Entonces, si el proyecto es github.com/JohnDoe/coolproject, le dirías a GitHub que deseas establecer github.com/Noah/coolproject. Esto establece un "clon de git" de todos los archivos y el historial del proyecto, y se conserva la relación con el original.

El modelo de trabajo es que luego haga otro clon en su máquina local, de github.com/Noah/coolproject. De esta manera, puede modificar archivos en el proyecto directamente (incluso si posee un repositorio, GitHub no le brinda una cuenta de shell y una contraseña para iniciar sesión en sus máquinas y editar sus archivos) . Una vez que haya realizado los cambios para agregar el logotipo y actualizar los archivos que lo usan, deberá resumir los cambios relacionados en una sola "commit" que represente las diferencias.

Una vez que tenga su compromiso local, "empujará" ese compromiso a su clon del proyecto alojado en GitHub en github.com/Noah/coolproject. Debido a que usted creó esa bifurcación, tiene los privilegios necesarios para hacerlo. Luego envía lo que se llama una "solicitud de extracción" a github.com/JohnDoe/coolproject. Recibirán una notificación de que hay una confirmación disponible y pueden optar por integrarla... solicitar comentarios o mejoras... o simplemente rechazarla.

No deberías tener que preocuparte demasiado por la etiqueta si tus intenciones son buenas. Lo más que puedes hacer es irritar a alguien si le envías una solicitud mal formulada o que de alguna manera no obedece las convenciones del proyecto. Su copia del código no cambiará sin su aprobación específica.

SIN EMBARGO , si todo lo que está haciendo es enviar una imagen y no un parche de código, lo más fácil es enviar el archivo como un archivo adjunto en un problema de GitHub . Este es un sistema de seguimiento de tickets que está integrado con GitHub, y la mayoría de los proyectos (pero no todos) lo tienen habilitado. Lo encontrará, por ejemplo, en github.com/JohnDoe/coolproject/issues. El desarrollador puede encargarse de colocarlo en los lugares correctos si lo acepta, por lo que la pregunta real es más sobre la discusión de si quieren usarlo... y qué modificaciones podrían necesitar.

Licencia

La práctica estándar cuando se donan diseños de logotipos a código abierto es designar el logotipo para que se mantenga bajo los términos de derechos de autor existentes de la marca/denominación. Quien controla el nombre controla así la marca; esto evita una divergencia en la que los administradores del proyecto le dan permiso a alguien para usar el nombre, pero luego el diseñador del logotipo de hace años regresa y dice "pero no me gustan, ¡no puedes usar mi logotipo!"

Especialmente en proyectos grandes, el nombre y el sitio web es todo lo que conserva la organización central de código abierto. Puede llevar todo el código a Firefox y cambiar una línea de código para hacer NoahBrowser, pero no puede llamarlo Firefox (y probablemente ni siquiera NoahFirefox). Un diseñador que trabaja con código abierto debería estar dispuesto a ceder el diseño de buena fe a la organización que administra el proyecto... y si no tienes esa fe, probablemente no deberías estar haciendo un trabajo gratuito para ellos en un primer momento. lugar.

Puede haber algunas personas que sean pioneras en la idea de que el logotipo de un proyecto de código abierto se licenciaría a través de Creative Commons. Pero tenga en cuenta que incluso los propios Creative Commons no hacen esto , y uno pensaría que si alguien lo haría, serían ellos... así que probablemente haya una buena razón para mantener este aspecto de identidad particular de un proyecto bajo el control tradicional de "todos los derechos reservados". ".

Crédito

No tiene nada de malo preguntarles si no les importaría mencionarlo en el blog oficial del desarrollador si deciden usarlo. O puede escribir sobre ello en su propio blog, para aquellos curiosos de dónde proviene el logotipo.

El código abierto a menudo es algo anónimo, y la mayor parte de "quién hizo qué" se captura en los registros del historial de versiones del código fuente. No ves el nombre de los desarrolladores en una gran cantidad de software, por lo general eso queda para un huevo de Pascua en alguna parte. Los gráficos son un trato similar.

(Si tuviera que ver una lista de todos los desarrolladores que contribuyeron a Linux antes de que se iniciara, estaría observando ese desplazamiento durante mucho tiempo... y la lista de nombres se convertiría en un archivo significativamente grande en cada distribución).

Si está enviando activos e íconos... imágenes para un botón o algo que es más razonable "parte del código" que "parte de la identidad del proyecto"... entonces esas contribuciones generalmente se realizan bajo la misma licencia que el código. sí mismo. Si se requiere atribución, generalmente se hace al proyecto; no a los contribuyentes.

Para los requisitos de atribución personal de los activos gráficos que se utilizarán en el programa en sí , si desea aplicarlos, probablemente debería hacerlos como su propio proyecto y elegir su propia licencia. Entonces podría sugerir que el proyecto puede usar el trabajo bajo esa licencia. Nada de malo con eso; cosas como Silk Icons funcionan de esa manera. En mi opinión, ejerce un poco de presión sobre usted para definir el trabajo como generalizado, y algo que podrían usar varios proyectos.

Mi experiencia con esto

He realizado dos intervenciones de diseño de logotipos de OSS y he escrito un poco al respecto aquí.