Este documento se basa en la guía de lanzamiento oficial de ASF para extraer y simplificar, centrándose en las partes que es más probable que pasemos por alto/cometamos errores en el proceso de lanzamiento.Estudiantes que participan en el lanzamiento por primera vez, especialmente la persona a cargo de cada almacén/módulo debe completarse, léalo detenidamente, si no está seguro, comuníquese a tiempo.
Nota: Este artículo describe principalmente los proyectos que se han incorporado a la incubadora, es decir, los proyectos que están siendo incubados, y no hará explicaciones adicionales para proyectos graduados y de otro tipo.
*Pautas de publicación:
https://infra.apache.org/release-distribution.html
0. Prefacio
Creo que para cada proyecto de incubación que es nuevo para ASF , habrá muchos pequeños problemas y dificultades en la primera versión, especialmente los problemas relacionados con Licencia/Aviso/Copyright como representante típico. Después de pensarlo, las razones principales pueden ser :
Los documentos oficiales de ASF están bastante dispersos, los desarrolladores comunes de la comunidad y los estudiantes que no han participado en el lanzamiento a menudo no tienen paciencia para leer todos los documentos y notar problemas clave (o desviaciones de comprensión);
El documento oficial de ASF todavía es vago para algunas descripciones, o recomienda directamente a PMC/Mentor/Mail para discutir la decisión, pero esta parte de la conclusión generalmente no se actualiza ni se registra en el documento;
Los funcionarios de la ASF no recomiendan herramientas de inspección automatizadas similares a skywalking-eye (encabezado/dependencia), estas herramientas pueden ser de gran ayuda para los estudiantes que publican por primera vez;
Algunas normas/reglas en el documento ASF no son estrictamente requeridas, pero diferentes revisores pueden tener diferentes hábitos/preferencias al publicar y votar, por lo que propondrán algunas "sugerencias" para mejorar;
Desviación de comprensión semántica/idioma "chino/inglés", lo que conduce a una mala comprensión de algunos contenidos.
Aprovechando la oportunidad del primer lanzamiento de Apache HugeGraph , también resumí algunos asuntos y experiencias encontrados en relaciones públicas/correos electrónicos. Debido a la comprensión personal, puede haber lugares imprecisos. Bienvenidos a todos a revisar, complementar y mejorar juntos para evitar similitudes. El problema apareció repetidamente en el proceso de lanzamiento del proyecto de incubadora .
*Apache enorme gráfico:
https://github.com/apache/incubator-hugegraph
0.1 sustantivo
Algunas abreviaturas de nombres comunes que aparecen en el texto :
ASF: Fundación de Software Apache
ASL2.0: Licencia de software Apache 2.0
0.2 ASF y Apache
Los nuevos estudiantes pueden estar confundidos por qué a menudo ven la descripción de no usar directamente el proyecto Apache en el correo/documentación de ASF , pero sugieren/personalizan el uso del proyecto ASF . Esto se debe a que el proyecto Apache es propenso a la ambigüedad: debido a que Apache tiene muchos otros significados, puede referirse a proyectos que usan la licencia de software Apache , pero los proyectos ASF (base) tienen algunos requisitos/limitaciones independientes, que se distinguen en la descripción Puede evitar que todos malinterpreten el significado correspondiente y puedan comprender mejor la diferencia entre presentar proyectos que no son ASF que usan la licencia de software Apache e introducir dependencias de proyectos con el nombre ASF .
1 . Licencia
La LICENCIA es el lugar donde es más probable que ocurran problemas menores, asegúrese de confirmar y verificar uno por uno (si no está seguro, consulte las instrucciones oficiales / correo electrónico / comunicación del mentor):
Cada paquete fuente y binario (incluido el paquete jar lanzado ) debe proporcionar un archivo de LICENCIA + AVISO + DESCARGO DE RESPONSABILIDAD :
El paquete fuente debe estar ubicado en el directorio raíz del proyecto;
El paquete binario generalmente también se encuentra en el directorio raíz (Nota: este elemento se refiere a otros proyectos de ASF, y ASF no ha encontrado un requisito estricto hasta el momento).
La versión original del archivo de LICENCIA debe estar completa y correcta en formato/contenido, descargue la versión oficial directamente y colóquela en el directorio del proyecto (evite copiar y pegar manualmente el texto).
Se recomienda que el archivo de LICENCIA/AVISO no contenga información innecesaria . Por ejemplo, no incluya la LICENCIA de las dependencias que no ha utilizado. Si elimina /actualiza las dependencias, debe actualizar/eliminar la información de LICENCIA/AVISO correspondiente. a tiempo.
Para la licencia de terceros a la que se hace referencia , la información detallada se debe adjuntar a nuestro archivo de LICENCIA . Si la LICENCIA a la que se hace referencia es muy larga, se debe almacenar y señalar un archivo separado.
如LICENCIA-<nombre-dependencia>.txt。
Si la fuente del código de referencia es un acuerdo APL2.0 estándar (sin modificar), puede indicar que la otra parte es una versión estándar y referirse directamente a la LICENCIA APL2.0 en el directorio raíz sin repetir la copia.
Los paquetes binarios también necesitan atención especial. Por lo general, el contenido del archivo LICENCIA + AVISO que lleva es diferente del paquete fuente. No reutilice el mismo archivo directamente:
El paquete de código fuente generalmente no tiene dependencias como paquetes binarios/jar/imágenes, por lo que su LICENCIA y AVISO son mucho más simples y limpios. Principalmente declara referencias de código fuente.
El paquete binario generalmente se basa en las dos referencias de archivo del paquete fuente, y todas las dependencias/imágenes/archivos binarios de terceros a los que se hace referencia y sus archivos de LICENCIA correspondientes deben complementarse.
Si un tercero depende de varias licencias de LICENCIA (como ASL2.0 y GPL ), se recomienda seleccionar solo una referencia de LICENCIA en lugar de enumerar todas (no es conveniente que otros las revisen):
En general, la base básica para las opciones múltiples es elegir la licencia suelta de tipo A mencionada en el documento ASF , si no se considera el tipo B;
Si el archivo de LICENCIA dependiente existe de forma independiente, solo debe seleccionar el contenido seleccionado (por ejemplo, eliminar la GPL u otras referencias de declaración redundantes);
De hecho, se puede ver que algunos proyectos ASF han introducido dependencias en todas las entradas de LICENCIA en el archivo de LICENCIA , pero puede que no sea la forma recomendada de escribir (debe evitarse la referencia a la copia).
*Descripción oficial:
https://infra.apache.org/licensing-howto.html
* Versión oficial del expediente de LICENCIA:
https://www.apache.org/licenses/LICENSE-2.0.txt
* Licencia permisiva Clase A:
https://www.apache.org/legal/resolved.html#category-a
Además de leer la documentación, una de las mejores maneras es consultar los ejemplos oficiales /otros proyectos de incubadoras y luego preguntar al mentor/comunidad a tiempo si aún no está seguro (no se adivine).
httpd - fuente
https://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENCIA
seatunnel - fuente
https://github.com/apache/incubator-seatunnel/blob/dev/LICENCIA
seatunnel - binario
https://github.com/apache/incubator-seatunnel/blob/dev/seatunnel-dist/release-docs/LICENCIA
linkis - fuente
https://github.com/apache/linkis/blob/master/LICENCIA
vinculado - binario
https://github.com/apache/linkis/blob/master/linkis-dist/release-docs/LICENCIA
Nota: Linkis ahora se ha graduado, consulte cuidadosamente sus últimos documentos, puede saltar a la instantánea antes de la graduación.
2. Encabezado de licencia
Habiendo terminado la referencia a la LICENCIA del proyecto como un todo arriba, hablemos sobre el encabezado de la licencia que muchos estudiantes pueden confundir (por ejemplo, por qué se declara globalmente y cada archivo debe declararse por separado):
En primer lugar, la mayoría de las organizaciones de código abierto requieren que cada archivo fuente del proyecto tenga una declaración de licencia obvia , de modo que cuando otros se refieren a un archivo solo, es más fácil mantener la declaración / también es la más intuitiva y clara;
En segundo lugar, considerando que el archivo LICENSE original es generalmente muy largo, en aras de la brevedad, se estipula que se cite una versión abreviada en el encabezado del archivo, denominada encabezado de licencia , y luego la versión completa se coloque debajo de la raíz ( LICENCIAS archivo ), formando una relación de referencia;
Por lo tanto, se puede ver que incluso si el mismo protocolo es ASL2.0, los encabezados de licencia de diferentes proyectos pueden no ser exactamente iguales, y es normal que se agregue/sustraiga algún contenido (no "unifique" usted mismo) .
*LICENCIA Original:
https://www.apache.org/licenses/LICENSE-2.0.txt
Núcleo 2.1
ASF estipula que el encabezado de la licencia (encabezado del archivo) del proyecto bajo el nombre no puede contener la declaración de Copyright , y esta parte debe ser considerada:
Si es innecesario, como el abandono voluntario del Copyright antes de la donación, simplemente elimínelo directamente ;
Si es necesario, declararlo por separado en la cabecera del archivo AVISO .
Atención especial, si está citando un código de un tercero , no elimine/modifique el encabezado de la otra parte y la declaración de derechos de autor que contiene , y no agregue encabezados ASL2.0 adicionales:
Por lo general, todos están acostumbrados al formateo por lotes a través de complementos/scripts . En este momento, es necesario verificar que el código de terceros no agregue declaraciones ASL2.0 adicionales;
Otro problema común es que solo se hace referencia a una parte del código, ¿cómo debemos tratarlo?
-
Modificación/adición menor (para código de terceros) , generalmente se debe usar la licencia del archivo original y no se debe modificar la licencia original/el contenido del autor;
Para las revisiones mayores , la ASF recomienda que PMC las discuta y trate específicamente (no existe una definición estricta de revisiones "grandes/pequeñas", así que trátelas como revisiones menores si no son necesarias);
Si se hace referencia a una estructura/clase interna (docenas de líneas) en un archivo grande (miles de líneas) , ¿cómo mantener su referencia de encabezado de licencia en este momento? (Debe evitarse tanto como sea posible, consulte la discusión separada en el final del artículo para más detalles)
Incluso si el formato/gramática/puntuación del encabezado del código de terceros tiene problemas o está incompleto (versión simplificada), no modifique el encabezado de licencia original .
Como se indicó anteriormente, si una pieza de software/código en su conjunto contiene varias licencias opcionales, considere una de las siguientes opciones:
Priorice la licencia suelta Clase A más adecuada de Apache como encabezado de licencia para evitar problemas innecesarios;
Si se han mencionado varias licencias opcionales en el encabezado de la licencia del código original, no es necesario modificarlo (porque normalmente el autor del código original tiene derecho a modificarlo).
*Licencia permisiva Clase A:
https://www.apache.org/legal/resolved.html#category-a
2.2 Caso especial
ASF estipula que algunos archivos no necesitan agregar un encabezado de licencia . El principio se basa en "no hay creatividad en el contenido/estructura". Si no está seguro, debe agregarlo de manera predeterminada . Ejemplos que deben ser agregado:
Información de texto breve (típico README, CONTRIBUTING, *.txt, *.md, *.log y varios archivos lint );
Se agregaron comentarios de encabezado que pueden informar errores ( archivos json típicos );
Archivos que se pueden excluir al empaquetar código fuente, como archivos de acción dedicados en .github , .git o archivos similares.
Los siguientes son ejemplos más típicos de adiciones recomendadas (pero no obligatorias):
Archivos de configuración de administración/dependencia de paquetes, como Makefile/pom.xml , etc. ASF recomienda agregarlos si no es necesario para evitar disputas ( consulte la discusión por correo electrónico) ;
La plantilla generada por el programa/los archivos *.conf y *.properties utilizados por el usuario se pueden discutir en el PMC de acuerdo con la situación específica, y se sugiere que los archivos de configuración utilizados en las pruebas unitarias o inciertas se traigan de forma predeterminada. (o consultado);
Si hay archivos css/js y otros archivos comprimidos, si son generados por el desarrollo de su propio proyecto, se recomienda utilizar la versión corta de la declaración en lugar de la versión del encabezado original.
En resumen, ASF recomienda agregar un encabezado de licencia para indicar el permiso, excepto en los casos en que claramente no se usan o son difíciles de agregar.
*Algunos archivos que no necesitan agregar encabezado de licencia:
https://www.apache.org/legal/src-headers.html#faq-excepciones
*Discusión por correo sobre si se debe agregar un encabezado de licencia a los archivos de configuración de administración/dependencia de paquetes:
https://lists.apache.org/thread/l6w0ytfodywfsb6ky0gd41qfzb148r50
*Declaración de versión corta de css/js comprimido y otros archivos generados por proyectos de desarrollo propio:
https://www.apache.org/legal/src-headers.html#is-a-short-form-of-the-source-header-disponible
3. AVISO
Es más fácil entender que LICENSE/Header almacena sus propias licencias + licencias de terceros. ¿ Qué hace el archivo NOTICE ? En pocas palabras, puede almacenar los requisitos de licencia obligatorios (legales) de Copyright +:
El archivo de AVISO debe seguir la especificación estándar ASF y el formato no se puede modificar a voluntad (se recomienda hacer referencia al proyecto de incubación publicado , y el proyecto graduado puede tener razones históricas, no lo copie directamente);
El año de Copyright del archivo NOTICE debe ser lo más consistente posible (por ejemplo, hay varios repositorios), y el año final debe actualizarse con el lanzamiento (por ejemplo, 2017-20xx, el lanzamiento debe marcar el año xx);
Si nos referimos a otros proyectos ASF, consulte aquí ( https://infra.apache.org/licensing-howto.html#bundle-asf-product, tenga en cuenta que esto no es equivalente a los proyectos que hacen referencia al protocolo Apache2.0 normal) ;
Mantenga el AVISO lo más conciso posible. Consulte a la comunidad/mentor en caso de referencias inciertas. No debe asumir la necesidad aquí, ya que supondrá una carga adicional (transitiva) para el usuario (descendente);
El aviso de derechos de autor incorporado en la licencia BSD/MIT no requiere recitación (LEGAL-59);
Si el archivo de AVISO en el que se basa el tercero cita incorrectamente la LICENCIA u otra información, ¿cómo debemos elegir?
En general, no es necesario que copie la parte incorrecta, solo seleccione la parte requerida/de conformidad ( consulte el problema : https://github.com/apache/incubator-hugegraph-computer/pull/227#discussion_r1081107569 );
Si no está seguro, puede consultar al tutor o enviar un correo electrónico a la comunidad de incubadoras .
*JURÍDICO-59：
https://issues.apache.org/jira/browse/LEGAL-59
3.1 Ejemplo oficial + incubadora:
La plantilla mínima oficial (recomendada)
https://www.apache.org/licenses/AVISO-2.0.txt
seatunnel (recomendado)
https://github.com/apache/incubator-seatunnel/blob/dev/AVISO
Servidor HTTP (no recomendado)
https://www.apache.org/licenses/example-AVISO.txt
4. Descargo de responsabilidad
Cualquier paquete de distribución (incluido el sitio web) del proyecto en incubación debe llevar el archivo DISCLAIMER (descargo de responsabilidad). Hay dos opciones para este archivo que suena legal: (ver la descripción oficial para más detalles)
Versión estándar: un proyecto en incubación que puede seguir todas las políticas de liberación de ASF, denominado archivo EXENCIÓN DE RESPONSABILIDAD (se debe dar prioridad si las condiciones lo permiten);
Versión WIP (Work In Progress) : significa que habrá algunas políticas de lanzamiento que no pueden cumplir con los requisitos de ASF durante el proceso de lanzamiento, denominado DISCLAIMER-WIP, donde las condiciones "no satisfechas" son menos estrictas, como *GPL/CC -BY , etc. Se pueden tolerar licencias incompatibles con X Class (en casos más especiales, mejor consultar al instructor/correo electrónico).
El contenido de las plantillas para las dos descripciones es diferente, especialmente la versión WIP debe enumerar específicamente la "lista de problemas conocidos", lo que significa recordar a los usuarios que es posible que estos lugares deban verificarse cuidadosamente. Además, se debe tener en cuenta que los proyectos de incubación deben actualizarse antes de la graduación Convertido a una declaración de EXENCIÓN DE RESPONSABILIDAD estándar (lo que significa que la versión WIP menciona que los problemas de lanzamiento relacionados se han resuelto).
*Descripción oficial:
https://incubator.apache.org/policy/incubation.html#disclaimers
5. Derechos de autor
Los avisos de derechos de autor solo se reubican si se donan a la ASF como parte de una subvención de software.
Una nota separada sobre los derechos de autor:
Los proyectos de ASF requieren que los derechos de autor se coloquen en el archivo AVISO en lugar del encabezado de la licencia . Esto es requerido solo por ASF y no tiene nada que ver con otros proyectos que usan y agregan derechos de autor libremente. No es el requisito original de la licencia de Apache ( ASL2.0). Para evitar malentendidos, esta es también una de las diferencias significativas entre el proyecto ASF y el proyecto Apache mencionado al principio.
6. GPL
Básicamente, las referencias binarias/de código representadas por * licencias GPL no se pueden incluir en los proyectos ASF, o simplemente: las licencias que limitan estrictamente la distribución/comercialización/básicamente no se pueden introducir (para obtener una lista detallada, consulte la lista oficial de referencias prohibidas). )
Lo que no se puede incluir aquí no es solo que el código fuente no está incluido, sino que el paquete binario generado por la compilación no se puede incluir teóricamente, por lo que es necesario eliminar o refactorizar algunos códigos que usan dependencias/complementos similares; de lo contrario, será muy complicado. Están disponibles los siguientes: Prácticas comunes de referencia:
Haga que este tipo de referencias que ASF no permite llevar sean opcionales, como el paquete ojdbc.jar de Oracle , puede escribir un documento para decirles a los usuarios que lo necesitan que lo descarguen y asocien/habiliten por sí mismos;
Si un acuerdo de proyecto permite varias licencias, se puede usar siempre que contenga licencias compatibles con ASL2.0 y la licencia que elijamos se especifique en el archivo de LICENCIA del proyecto;
Además, atención a la licencia CC (Creative Commons), si ASF aparece solo, no está permitido (https://www.apache.org/legal/resolved.html#cc-by) (esto puede pasarse por alto fácilmente) por todos, se recomienda utilizar el escaneo de complementos).
*ASF prohíbe oficialmente citar la lista de software de acuerdo de licencia de código abierto de terceros:
https://www.apache.org/legal/resolved.html#category-x
7. Binario/Archivo
Los archivos binarios + paquetes jar separados (considerados como archivos de archivo ) también necesitan atención especial, lo que puede evitar muchos problemas innecesarios al publicar:
Los archivos binarios no deben aparecer en el paquete de código fuente en la medida de lo posible, si se considera que los existentes se reemplazan mediante la descarga o la generación temporal durante la compilación/prueba (los nuevos PR deben evitar la reintroducción);
Para archivos comprimidos relativamente grandes/difíciles de revisar (por ejemplo, swagger-ui es un paquete front-end con licencia de Apache), intente no importarlos directamente al código fuente, sino descargarlos y descomprimirlos durante la compilación.
La mayoría de las imágenes también se considerarán archivos binarios. Si esta parte no es necesaria para el código fuente, se puede considerar excluida al empaquetar.
Si es una imagen/binario necesario, debe haber una descripción de referencia separada en el archivo de LICENCIA (se agregará un ejemplo).
8. Git/GitHub/sitio web oficial relacionado
Aquí hay principalmente algunos detalles misceláneos que son fáciles de malinterpretar, pero los errores también pueden hacer que la versión se revierta:
La rama de lanzamiento se puede actualizar por separado, pero una vez que se envía el correo electrónico de VOTO de lanzamiento, se debe solidificar/detener cualquier envío de actualización posterior (de lo contrario, se considerará que no cumple);
Al lanzar la versión, debido a que es probable que haya varias rondas, se recomienda usar el sufijo rc para la etiqueta, por ejemplo, 1.0.0-rc1 representa el primer voto y el número de rc se incrementará si es devuelto (no obligatorio pero recomendado);
La rama (branch) no es necesaria como se menciona en el correo de ASF (https://lists.apache.org/thread/k08vq5r4nfos2ptn69w2fbm2mvmkb91n) , así que mantenga release-1.0.0 para su reutilización;
Puede llevar el último Commit-ID (abreviatura) de la etiqueta en el correo electrónico de publicación para una fácil confirmación;
Antes de que se complete el lanzamiento, la página de descarga del sitio web oficial no puede tener una dirección de descarga temporal (de manera similar, la página de lanzamiento de Github debe usar una versión preliminar en lugar de la versión más reciente;
Lo mejor es tener la documentación básica de "comprobación de integridad" + "cómo compilar el código fuente" en la página de descarga del sitio web oficial o en el proyecto README (no es necesario pero se recomienda).
8.1 Comprobaciones automáticas (muy recomendable)
Para evitar una gran cantidad de pequeños problemas innecesarios y peligros ocultos causados por negligencia en la operación manual/manual, se recomienda enfáticamente agregar alguna acción/CI automatizado para ayudarnos en nuestra inspección:
Maven RAT comprueba archivos binarios/encabezados/archivos (complemento de Maven, solo Java, obligatorio);
verificación de encabezado de licencia de skywalking (también puede proporcionar un recordatorio de comentarios en relaciones públicas, excelente, necesario);
generación y verificación de dependencias de skywalking (se recomienda al menos habilitar la parte de verificación, el documento es el mismo que el anterior, opcional);
validar el paquete de lanzamiento (consulte la acción de verificación automática escrita por HugeGraph , verifique GPG/SHA/archivos binarios/archivos vacíos (carpetas) por adelantado, etc. - recomendado);
dependencia-revisión-acción (GitHub proporciona oficialmente una Acción que puede verificar/excluir la licencia - opcional).
Luego, la inspección manual principal se centra en algunos lugares que no pueden cubrir los scripts, centrándose en cuestiones como "LICENCIA + AVISO + declaraciones de encabezado dependientes de terceros", lo que puede reducir mucho el esfuerzo.
* Verificación de encabezado de licencia de skywalking:
https://github.com/apache/skywalking-eyes
Acción de verificación automática escrita por *HugeGraph:
https://github.com/apache/incubator-hugegraph-doc/blob/master/.github/workflows/validate-release.yml
*acción-revisión-dependencia：
https://github.com/actions/dependency-review-action
9. Resolución de problemas
Aquí hay algunos problemas/sugerencias problemáticas que los funcionarios de la ASF no explican directamente/carecen de definiciones claras, pero que en realidad pueden encontrar. Hay algunas conclusiones para referencia, y las sugerencias complejas se discuten con mentores/comunidades :
Después de citar un código de terceros (código fuente), ¿debo agregar citas en diferentes archivos de LICENCIA de código fuente y versión binaria al mismo tiempo?
R: Sí, se requieren ambos (consulte el problema).
Algunos puntos sobre el encabezado de la licencia :
(Principio) No se recomienda usar código de terceros en fragmentos, debe dar prioridad a separarlo o reescribirlo usted mismo, cuando tenga que citarlo, debe mantener el encabezado de licencia del código original ;
(Principio) La conversión de código de terceros de un lenguaje de programación a otro no es una modificación importante, y se debe conservar el encabezado de la licencia original (común en algunos códigos relacionados con algoritmos);
(Caso especial) Si el código de terceros importado es solo una pequeña parte de un archivo de código, ¿debería usarse su encabezado de licencia como encabezado de todo el archivo?
-
Si importa una definición/subclase/estructura de interfaz, ¿puede importar directamente su encabezado de licencia en esta parte del fragmento de código ?
Si el encabezado de la licencia no se puede introducir en medio del código , ¿se permite mantener dos encabezados de licencia en el encabezado (uno es ASF, el otro es importado);
Si solo se reserva un encabezado de licencia, ¿necesita especificar el rango de líneas de código importadas en el archivo de LICENCIA ? Si no lo importa, parece que otros no saben a qué parte del código se refiere;
R: La situación anterior debe introducirse por separado a través de archivos de encabezado/clases independientes tanto como sea posible. Si es necesario hacer referencia a una pequeña cantidad de código/función, se recomienda dar prioridad a la reescritura (de lo contrario, debe extraerse por separado para evitar caer en los problemas anteriores).
Desliza hacia arriba para ver las referencias de este artículo
https://incubator.apache.org/guides/releasemanagement.html (guía de lanzamiento del proyecto Incubator ①)
https://www.apache.org/foundation/preFAQ.html (Preguntas comunes sobre el uso del protocolo ASL2.0)
https://www.apache.org/legal/src-headers.html (problemas de referencia de encabezado de licencia común, incluidas referencias de terceros)
https://infra.apache.org/licensing-howto.html (Cómo escribir su archivo de LICENCIA/AVISO)
https://www.apache.org/legal/resolved.html#category-x (lista oficial de referencias prohibidas, incluido CC-BY)
https://lists.apache.org/[email protected] (lista de correo de incubadoras ASF)
…
Reimpreso de丨ALC Beijing
Autor丨imbajin
Editar丨Luo Ruiyan
Lectura relacionada | Lectura relacionada
¡La reunión del primer trimestre de 2023 del Comité Asesor de Kaiyuanshe se llevó a cabo con éxito!
Software de código abierto similar a ChatGPT, ¿pueden usarlo los desarrolladores?
Introducción a Kaiyuanshe
Fundada en 2014, la Sociedad Kaiyuan está compuesta por miembros individuales que contribuyen voluntariamente a la causa del código abierto. Se forma de acuerdo con el principio de "contribución, consenso y cogobernanza". Siempre ha mantenido las características de neutralidad del proveedor, bienestar público y sin fines de lucro. Integración internacional, desarrollo comunitario, incubación de proyectos "es una federación comunitaria de código abierto con la misión. Kaiyuanshe coopera de forma activa y estrecha con comunidades, empresas y unidades relacionadas con el gobierno que apoyan el código abierto. Con la visión de "Con sede en China y contribuyendo al mundo", su objetivo es crear un ecosistema de código abierto saludable y sostenible y promover la comunidad de código abierto de China. convertirse en una fuerza activa en el sistema global de código abierto Participación y colaboradores.
En 2017, Kaiyuanshe se transformó en una organización compuesta en su totalidad por miembros individuales, que opera con referencia al modelo de gobierno de las principales fundaciones internacionales de código abierto como ASF. En los últimos nueve años, ha conectado a decenas de miles de personas de código abierto, ha reunido a miles de miembros y voluntarios de la comunidad, cientos de disertantes en el país y en el extranjero, y ha cooperado con cientos de patrocinadores, medios y socios de la comunidad.
