Ce document est basé sur le guide de publication officiel d'ASF pour extraire et simplifier, en se concentrant sur les parties que nous sommes les plus susceptibles de négliger/de faire des erreurs dans le processus de publication. Les étudiants qui participent à la publication pour la première fois, en particulier la personne en charge de chaque entrepôt/module doit être complété, lisez-le attentivement, si vous n'êtes pas sûr, veuillez communiquer à temps.
Remarque : Cet article décrit principalement les projets qui ont rejoint l'incubateur, c'est-à-dire les projets qui sont en cours d'incubation, et ne fournira pas d'explications supplémentaires pour les projets diplômés et d'autres types.
*Consignes de publication :
https://infra.apache.org/release-distribution.html
0. Préface
Je crois que pour chaque projet d'incubation qui est nouveau pour ASF , il y aura de nombreux petits problèmes et problèmes dans la première version, en particulier les problèmes liés à la licence/à l'avis/au droit d'auteur en tant que représentant typique. Après y avoir réfléchi, les principales raisons peuvent être :
Les documents officiels d'ASF sont assez dispersés, les développeurs ordinaires de la communauté et les étudiants qui n'ont pas participé à la publication n'ont souvent pas la patience de lire tous les documents et de remarquer les problèmes clés (ou les déviations de compréhension) ;
Le document officiel d'ASF est encore vague pour certaines descriptions, ou il recommande directement PMC/Mentor/Mail pour discuter de la décision, mais cette partie de la conclusion n'est généralement pas mise à jour et enregistrée dans le document ;
Les responsables d'ASF ne recommandent pas d'outils d'inspection automatisés similaires à skywalking-eye (en-tête/dépendance), ces outils peuvent être d'une grande aide pour les étudiants qui publient pour la première fois ;
Certaines normes/règles du document ASF ne sont pas strictement requises, mais différents examinateurs peuvent avoir des habitudes/préférences différentes lors de la publication et du vote, ils proposeront donc des "suggestions" d'amélioration ;
Écart de compréhension de la langue/sémantique "chinois/anglais", ce qui conduit à une mauvaise compréhension de certains contenus.
Profitant de l"opportunité de la première version d "Apache HugeGraph , J"ai également résumé certaines questions et expériences rencontrées dans les relations publiques / e-mails. En raison d"une compréhension personnelle, il peut y avoir des endroits imprécis. Bienvenue à tous pour revoir et compléter et améliorer ensemble pour éviter les similitudes. problème est apparu à plusieurs reprises dans le processus de publication du projet d'incubateur .
*Apache HugeGraph :
https://github.com/apache/incubator-hugegraph
0.1 nom
Quelques abréviations de noms communs apparaissant dans le texte :
ASF : Fondation du logiciel Apache
ASL2.0 : licence logicielle Apache 2.0
0.2 ASF et Apache
Les nouveaux étudiants peuvent ne pas comprendre pourquoi ils voient souvent la description de ne pas utiliser directement le projet Apache dans le courrier/documentation ASF , mais suggérer/personnaliser l'utilisation du projet ASF . Cela est dû au fait que le projet Apache est sujet à l'ambiguïté : étant donné qu'Apache a de nombreuses autres significations, il peut faire référence à des projets qui utilisent la licence logicielle Apache , mais les projets ASF (fondation) ont des exigences/limitations distinctes, qui sont distinguées dans la description. Il peut empêcher tout le monde de se méprendre sur la signification correspondante, et peut mieux comprendre la différence entre l'introduction de projets non ASF qui utilisent la licence logicielle Apache et l'introduction de dépendances de projet sous le nom ASF .
1 . Licence
La LICENCE est l'endroit où des problèmes mineurs sont le plus susceptibles de se produire, assurez-vous de confirmer et de vérifier un par un (si vous n'êtes pas sûr, veuillez vous référer aux instructions officielles / e-mail / communication du mentor ) :
Chaque paquet source et binaire (y compris le paquet jar publié ) doit fournir un fichier LICENSE + NOTICE + DISCLAIMER :
Le package source doit se trouver dans le répertoire racine du projet ;
Le package binaire se trouve généralement également dans le répertoire racine (Remarque : cet élément fait référence à d'autres projets ASF, et ASF n'a pas encore trouvé d'exigence stricte).
La version originale du fichier LICENCE doit être complète et correcte dans son format/contenu, veuillez télécharger directement la version officielle et la mettre dans le répertoire du projet (évitez de copier et coller manuellement le texte).
Il est recommandé que le fichier LICENSE/NOTICE ne contienne pas d'informations inutiles . Par exemple, n'incluez pas la LICENSE des dépendances que vous n'avez pas utilisées. Si vous supprimez/mettez à jour les dépendances, vous devez mettre à jour/supprimer les informations de LICENSE/NOTICE correspondantes. à l'heure.
Pour la licence tierce référencée , les informations détaillées doivent être jointes à notre fichier LICENCE . Si la LICENCE référencée est très longue, un fichier séparé doit être stocké et pointé vers.
如LICENSE-<dependency-name>.txt。
Si la source du code de référence est un accord APL2.0 standard (non modifié), cela peut indiquer que l'autre partie est une version standard et se référer directement à la LICENCE APL2.0 dans le répertoire racine sans copie répétée.
Les packages binaires nécessitent également une attention particulière. Généralement, le contenu du fichier LICENSE + NOTICE qu'il contient est différent de celui du package source. Ne réutilisez pas directement le même fichier :
Le package de code source ne contient généralement pas de dépendances telles que des packages binaires/jar/images, de sorte que sa LICENCE et son AVIS sont beaucoup plus simples et plus propres.Il déclare principalement des références de code source.
Le package binaire est généralement basé sur les deux références de fichier du package source, et toutes les dépendances/images/fichiers binaires tiers référencés et leurs fichiers de LICENCE correspondants doivent être complétés.
Si un tiers dépend de plusieurs licences LICENCE (telles que ASL2.0 et GPL ), il est recommandé de sélectionner une seule référence de LICENCE au lieu de toutes les répertorier (ce n'est pas pratique pour les autres de les examiner) :
Généralement, la base de base des choix multiples est de choisir la licence libre de type A mentionnée dans le document ASF , si aucun type B n'est pris en compte ;
Si le fichier LICENSE dépendant existe indépendamment, vous ne devez sélectionner que le contenu sélectionné (par exemple, supprimer la GPL ou d'autres références de déclaration redondantes) ;
En effet, on peut voir que certains projets ASF ont introduit des dépendances sur toutes les entrées LICENSE dans le fichier LICENSE , mais ce n'est peut-être pas la manière recommandée d'écrire (il faut éviter de faire référence à la copie).
*Description officielle :
https://infra.apache.org/licensing-howto.html
* Version officielle du fichier LICENCE :
https://www.apache.org/licenses/LICENSE-2.0.txt
* Permis permissif de classe A :
https://www.apache.org/legal/resolved.html#category-a
Outre la lecture de la documentation, l'un des meilleurs moyens est de se référer aux exemples officiels / autres projets d'incubateur, puis de demander au mentor / à la communauté à temps si vous n'êtes toujours pas sûr (ne vous devinez pas).
httpd - source
https://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE
tunnel de siège - source
https://github.com/apache/incubator-seatunnel/blob/dev/LICENSE
tunnel de siège - binaire
https://github.com/apache/incubator-seatunnel/blob/dev/seatunnel-dist/release-docs/LICENSE
lienis - source
https://github.com/apache/linkis/blob/master/LICENCE
lié - binaire
https://github.com/apache/linkis/blob/master/linkis-dist/release-docs/LICENSE
Remarque : Linkis a maintenant obtenu son diplôme, veuillez vous référer attentivement à ses derniers documents, vous pouvez passer à l'instantané avant l'obtention du diplôme.
2. En-tête de licence
Après avoir terminé la référence LICENSE du projet dans son ensemble ci-dessus, parlons de l'en-tête de licence qui peut confondre de nombreux étudiants (par exemple, pourquoi il est déclaré globalement et chaque fichier doit être déclaré séparément) :
Tout d'abord, la plupart des organisations open source exigent que chaque fichier source du projet ait une déclaration de licence évidente , de sorte que lorsque d'autres se réfèrent à un fichier seul, il est plus facile de conserver la déclaration / c'est aussi la plus intuitive et la plus claire ;
Deuxièmement, considérant que le fichier LICENSE d'origine est généralement très long, par souci de concision, il stipule qu'une version abrégée est citée dans l'en-tête du fichier, appelée en- tête de licence, puis la version complète est placée sous la racine ( LICESEN file ), formant une relation de référence ;
Par conséquent, on peut voir que même si le même protocole est ASL2.0, les en-têtes de licence de différents projets peuvent ne pas être exactement les mêmes, et il est normal d'avoir du contenu ajouté/soustrait (ne pas "unifier" par vous-même) .
*LICENCE originale :
https://www.apache.org/licenses/LICENSE-2.0.txt
2.1 Noyau
ASF stipule que l'en-tête de licence (en-tête de fichier) du projet sous le nom ne peut pas contenir la mention Copyright , et cette partie doit être considérée :
Si c'est inutile, comme l'abandon volontaire du Copyright avant donation, il suffit de le retirer directement ;
Si nécessaire, déclarez-le séparément en tête du fichier NOTICE .
Attention particulière, si vous citez un code tiers , ne supprimez/modifiez pas l' en-tête de l'autre partie et la déclaration de copyright qu'il contient , et n'ajoutez pas d'en-têtes ASL2.0 supplémentaires :
Tout le monde est généralement habitué au formatage par lots via des plug-ins/scripts , à ce stade, il est nécessaire de vérifier que le code tiers n'ajoute pas de déclarations ASL2.0 supplémentaires ;
Un autre problème courant est que seule une partie du code est référencée, comment doit-on s'y prendre ?
-
Modification/ajout mineur (pour le code tiers) , généralement la licence du fichier d'origine doit être utilisée, et le contenu de la licence/auteur d'origine ne doit pas être modifié ;
Pour les révisions majeures , ASF recommande que PMC en discute et les traite spécifiquement (il n'y a pas de définition stricte des révisions "grandes/petites", donc traitez-les comme des révisions mineures si elles ne sont pas nécessaires) ;
Si une structure/classe interne (des dizaines de lignes) est référencée dans un fichier volumineux (des milliers de lignes) , comment conserver sa référence d'en-tête de licence à ce moment ? (Cela devrait être évité autant que possible, voir la discussion séparée à la fin de l'article pour les détails)
Même si le format d'en-tête /la grammaire/la ponctuation du code tiers présente des problèmes ou est incomplet (version simplifiée), veuillez ne pas modifier l' en-tête de licence d'origine .
Comme ci-dessus, si un logiciel/code dans son ensemble contient plusieurs licences facultatives, veuillez envisager l'une des options suivantes :
Donnez la priorité à la licence libre de classe A d'Apache la plus appropriée comme en-tête de licence pour éviter des problèmes inutiles ;
Si plusieurs licences optionnelles ont été mentionnées dans l' en-tête de licence du code d'origine, il n'est pas nécessaire de le modifier (car généralement l'auteur du code d'origine a le droit de le modifier).
*Licence permissive de classe A :
https://www.apache.org/legal/resolved.html#category-a
2.2 Cas particulier
ASF stipule que certains fichiers n'ont pas besoin d'ajouter un en-tête de licence . Le principe est basé sur "il n'y a pas de créativité dans le contenu/la structure". Si vous n'êtes pas sûr, vous devez l'ajouter par défaut . Exemples qui doivent être ajoutée:
Informations textuelles courtes (type README, CONTRIBUTING, *.txt, *.md, *.log et divers fichiers de charpie ) ;
Ajout de commentaires d'en-tête pouvant signaler des erreurs ( fichiers json typiques) ;
Fichiers pouvant être exclus lors de l'empaquetage du code source, tels que les fichiers d'action dédiés sous .github , .git ou des fichiers similaires.
Voici des exemples plus typiques d'ajouts recommandés (mais pas obligatoires) :
Fichiers de configuration de gestion/dépendance des packages, tels que Makefile/pom.xml , etc. ASF recommande de les ajouter si ce n'est pas nécessaire pour éviter les litiges ( voir discussion par e-mail )
Le modèle généré par le programme/les fichiers *.conf et *.properties utilisés par l'utilisateur peuvent être discutés dans le PMC en fonction de la situation spécifique, et les fichiers de configuration utilisés dans les tests incertains ou unitaires sont suggérés pour être apportés par défaut (ou consulté) ;
S'il existe des fichiers css/js compressés et d'autres fichiers, s'ils sont générés par votre propre développement de projet, il est recommandé d'utiliser la version courte de la déclaration au lieu de la version d'en-tête d'origine.
En bref, ASF recommande d'ajouter un en-tête de licence pour indiquer l'autorisation, sauf pour les cas qui ne sont clairement pas utilisés/difficiles à ajouter.
*Certains fichiers qui n'ont pas besoin d'ajouter d'en-tête de licence :
https://www.apache.org/legal/src-headers.html#faq-exceptions
* Discussion par e-mail sur l'opportunité d'ajouter un en-tête de licence aux fichiers de configuration de la gestion des packages/des dépendances :
https://lists.apache.org/thread/l6w0ytfodywfsb6ky0gd41qfzb148r50
*Déclaration de la version courte des fichiers css/js compressés et d'autres fichiers générés par des projets auto-développés :
https://www.apache.org/legal/src-headers.html#is-a-short-form-of-the-source-header-available
3. AVIS
Il est plus facile de comprendre que LICENSE/Header stocke ses propres licences + tierces parties. Que fait le fichier NOTICE ? En termes simples, il peut stocker les exigences de licence obligatoires Copyright + (légales) :
Le fichier AVIS doit suivre la spécification standard ASF, et le format ne peut pas être modifié à volonté (il est recommandé de se référer au projet d'incubation publié , et le projet diplômé peut avoir des raisons historiques, veuillez ne pas le copier directement) ;
L'année de copyright du fichier NOTICE doit être aussi cohérente que possible (par exemple, il existe plusieurs dépôts) et la dernière année doit être mise à jour avec la version (par exemple, 2017-20xx, la version doit vérifier l'année xx) ;
Si nous nous référons à d'autres projets ASF, reportez-vous ici ( https://infra.apache.org/licensing-howto.html#bundle-asf-product, notez que cela n'est pas équivalent aux projets faisant référence au protocole Apache2.0 normal ) ;
Gardez l'AVIS aussi concis que possible. Veuillez consulter la communauté/mentor pour les références incertaines. Vous ne devez pas supposer le besoin ici, car cela apportera un fardeau supplémentaire (transitif) à l'utilisateur (en aval) ;
L'avis de droit d'auteur intégré dans la licence BSD/MIT ne nécessite pas de récitation (LEGAL-59) ;
Si le fichier NOTICE sur lequel le tiers s'appuie cite incorrectement LICENSE ou d'autres informations, comment devons-nous choisir ?
En général, vous n'avez pas besoin de copier la mauvaise partie, sélectionnez simplement la partie requise/conforme ( voir le problème : https://github.com/apache/incubator-hugegraph-computer/pull/227#discussion_r1081107569 ) ;
Si vous n'êtes pas sûr, vous pouvez consulter le tuteur/envoyer un e-mail à la communauté de l'incubateur .
*LÉGAL-59：
https://issues.apache.org/jira/browse/LEGAL-59
3.1 Exemple officiel + incubateur :
Le modèle minimal officiel (recommandé)
https://www.apache.org/licenses/NOTICE-2.0.txt
tunnel de siège (recommandé)
https://github.com/apache/incubator-seatunnel/blob/dev/NOTICE
Serveur HTTP (non recommandé)
https://www.apache.org/licenses/example-NOTICE.txt
4. Clause de non-responsabilité
Tout package de distribution (y compris le site Web) du projet en incubation doit contenir le fichier DISCLAIMER (disclaimer). Il existe deux options pour ce fichier à consonance légale : (voir la description officielle pour plus de détails)
Version standard : un projet d'incubation qui peut suivre toutes les politiques de publication d'ASF, nommé fichier DISCLAIMER (la priorité doit être donnée si les conditions le permettent) ;
Version WIP (Work In Progress) : Cela signifie qu'il y aura des politiques de publication qui ne pourront pas répondre aux exigences d'ASF pendant le processus de publication, appelées DISCLAIMER-WIP, où les conditions "non satisfaites" sont plus lâches, telles que *GPL/CC -BY , etc. Des licences incompatibles X Class peuvent être tolérées (dans des cas plus particuliers, il est préférable de consulter l'instructeur/email).
Le contenu des modèles pour les deux descriptions est différent, en particulier la version WIP doit répertorier spécifiquement la "liste des problèmes connus", ce qui signifie rappeler aux utilisateurs que ces endroits peuvent nécessiter une vérification attentive. que les projets d'incubation doivent être mis à jour avant l'obtention du diplôme.Converti en une déclaration de CLAUSE DE NON-RESPONSABILITÉ standard (ce qui signifie que la version WIP mentionne que les problèmes de publication associés ont été résolus).
*Description officielle :
https://incubator.apache.org/policy/incubation.html#disclaimers
5. Droits d'auteur
Les avis de droits d'auteur ne sont déplacés que s'ils sont donnés à l'ASF dans le cadre d'une subvention de logiciel.
Une note distincte sur le droit d'auteur :
Les projets ASF exigent que Copyright soit placé dans le fichier NOTICE au lieu de l'en-tête de la licence . Ceci est requis par ASF seul et n'a rien à voir avec d'autres projets qui utilisent et ajoutent librement Copyright. Ce n'est pas l' exigence initiale de la licence Apache ( ASL2.0). Afin d'éviter tout malentendu, c'est aussi l'une des différences significatives entre le projet ASF et le projet Apache mentionné au début.
6. GPL
Fondamentalement, les références de code/binaire représentées par les licences *GPL ne peuvent pas être incluses dans les projets ASF, ou simplement : les licences qui limitent strictement la distribution/commercialisation/ne sont fondamentalement pas autorisées à être introduites (pour une liste détaillée, reportez-vous à la liste officielle des références interdites )
Ce qui ne peut pas être inclus ici n'est pas seulement que le code source n'est pas inclus, mais le paquet binaire généré par la compilation ne peut pas être inclus théoriquement, donc certains codes qui utilisent des dépendances/plugins similaires doivent être supprimés/refactorisés, sinon ce sera très délicat Les éléments suivants sont disponibles : Pratiques courantes pour référence :
Rendez ce type de références qu'ASF n'autorise pas à transporter en option, comme le package ojdbc.jar d'Oracle, vous pouvez écrire un document pour dire aux utilisateurs qui en ont besoin de le télécharger et de l'associer/l'activer par eux-mêmes ;
Si un accord de projet autorise plusieurs licences, il peut être utilisé tant qu'il contient des licences compatibles ASL2.0 et que la licence que nous choisissons est spécifiée dans le fichier LICENSE du projet ;
De plus, faites attention à la licence CC (Creative Commons) Si ASF apparaît seul, ce n'est pas autorisé (https://www.apache.org/legal/resolved.html#cc-by) (cela peut être facilement négligé par tout le monde, il est recommandé d'utiliser le plug-in de numérisation ).
*ASF interdit officiellement de citer la liste des logiciels tiers sous contrat de licence open source :
https://www.apache.org/legal/resolved.html#category-x
7. Binaire/Archive
Les fichiers binaires + packages jar séparés (considérés comme des fichiers d'archive ) nécessitent également une attention particulière, ce qui peut éviter de nombreux problèmes inutiles lors de la publication :
Dans la mesure du possible, les fichiers binaires ne doivent pas apparaître dans le package de code source. Si les fichiers existants sont considérés comme étant remplacés par téléchargement ou génération temporaire lors de la compilation/test (les nouveaux PR doivent éviter leur réintroduction) ;
Pour les fichiers compressés relativement volumineux/difficiles à réviser (par exemple, swagger-ui est un package frontal sous licence Apache), essayez de ne pas les importer directement dans le code source, mais téléchargez-les et décompressez-les plutôt lors de la compilation.
La plupart des images seront également considérées comme des fichiers binaires. Si cette partie n'est pas nécessaire pour le code source, elle peut être considérée comme exclue lors de l'emballage.
S'il s'agit d'une image/binaire nécessaire, il doit y avoir une description de référence séparée dans le fichier LICENSE (exemple à ajouter).
8. Git/GitHub/site officiel lié
Voici principalement quelques détails divers faciles à mal comprendre, mais des erreurs peuvent également entraîner l'annulation de la version :
La branche de version peut être mise à jour séparément, mais une fois que l' e-mail VOTE de version est envoyé, il doit être solidifié/arrêter toute soumission de mise à jour ultérieure (sinon, il sera considéré comme non conforme) ;
Lors de la publication de la version, car il est probable qu'il y ait plusieurs tours, il est recommandé d'utiliser le suffixe rc pour la balise, par exemple, 1.0.0-rc1 représente le premier vote, et le nombre de rc sera incrémenté s'il est retourné (pas obligatoire mais recommandé);
La branche (branche) n'est pas nécessaire comme mentionné dans le courrier ASF (https://lists.apache.org/thread/k08vq5r4nfos2ptn69w2fbm2mvmkb91n) , donc gardez la version-1.0.0 pour la réutiliser ;
Vous pouvez porter le dernier Commit-ID (abréviation) de la balise dans l'e-mail de publication pour une confirmation facile ;
Avant la fin de la publication, la page de téléchargement du site Web officiel ne peut pas contenir d'adresse de téléchargement temporaire (de même, la page de publication de Github doit utiliser la pré-version au lieu de la dernière version ;
Il est préférable d'avoir une documentation de base "contrôle d'intégrité" + "comment compiler le code source" sur la page de téléchargement du site officiel ou le projet README (pas nécessaire mais recommandé).
8.1 Contrôles automatisés (fortement recommandés)
Afin d'éviter un grand nombre de petits problèmes inutiles et de dangers cachés causés par la négligence de l'utilisation manuelle/manuelle, il est fortement recommandé d'ajouter des CI/Actions automatisées pour nous aider dans notre inspection :
maven RAT check binaries/header/archives (maven plugin, Java only - required);
skywalking-license-header check (peut également fournir un rappel de commentaire dans PR, super - nécessaire);
génération et vérification des dépendances skywalking (il est recommandé d'activer au moins la partie vérification, le document est le même que ci-dessus - facultatif);
valider le package de version (reportez-vous à l' action de vérification automatique écrite par HugeGraph , vérifiez à l'avance les fichiers GPG/SHA/binaires/fichiers vides (dossiers), etc. - recommandé );
dependency-review-action (GitHub fournit officiellement une action qui peut vérifier/exclure la licence - facultatif).
Ensuite, l'inspection manuelle principale se concentre sur certains endroits qui ne peuvent pas être couverts par des scripts, en se concentrant sur des problèmes tels que "LICENSE + NOTICE + déclarations d'en-tête dépendantes de tiers", ce qui peut réduire beaucoup d'efforts.
*vérification de l'en-tête de la licence de skywalking ：
https://github.com/apache/skywalking-eyes
Action de vérification automatique écrite par *HugeGraph :
https://github.com/apache/incubator-hugegraph-doc/blob/master/.github/workflows/validate-release.yml
*dépendance-examen-action：
https://github.com/actions/dependency-review-action
9. Dépannage
Voici quelques problèmes/suggestions gênants que les responsables d'ASF n'expliquent pas directement/manquent de définitions claires, mais peuvent en fait rencontrer. Il y a quelques conclusions à titre de référence, et des suggestions complexes sont discutées avec les mentors/communautés :
Après avoir cité du code tiers (code source), dois-je ajouter des citations dans différents fichiers LICENSE de version source et binaire en même temps ?
R : Oui, les deux sont nécessaires (voir le problème).
Quelques points sur l'en-tête de la licence :
(Principe) Il est déconseillé d'utiliser du code tiers en fragments. Privilégiez de le séparer ou de le réécrire vous-même. Lorsque vous devez le citer, vous devez conserver l'en-tête de licence du code d'origine ;
(Principe) La conversion de code tiers d'un langage de programmation à un autre n'est pas une modification majeure, et l' en-tête de licence d'origine doit être conservé (commun dans certains codes liés à l'algorithme) ;
(Cas particulier) Si le code tiers importé n'est qu'une petite partie d'un fichier de code, son en-tête de licence doit-il être utilisé comme en-tête du fichier entier ?
-
Si vous importez une définition/sous-classe/structure d'interface, pouvez-vous directement importer son en-tête de licence sur cette partie du fragment de code ;
Si l'en-tête de licence ne peut pas être introduit au milieu du code , est-il permis de conserver deux en-têtes de licence dans l'en-tête (l'un est ASF, l'autre est importé) ;
Si un seul en-tête de licence est réservé, devez-vous spécifier la plage de lignes de code importées dans le fichier LICENSE ? Si vous ne l'importez pas, il semble que les autres ne sachent pas quelle partie du code est référencée ;
R : La situation ci-dessus doit être introduite séparément via des fichiers d'en-tête/classes indépendantes autant que possible. Si une petite quantité de code/fonction doit être référencée, il est recommandé de donner la priorité à la réécriture (sinon, il doit être extrait séparément pour éviter tomber dans les problèmes ci-dessus).
Balayez vers le haut pour voir les références de cet article
https://incubator.apache.org/guides/releasemanagement.html (Guide de publication du projet Incubator ①)
https://www.apache.org/foundation/preFAQ.html (Questions courantes sur l'utilisation du protocole ASL2.0)
https://www.apache.org/legal/src-headers.html (problèmes de référence d'en-tête de licence commune, y compris les références tierces)
https://infra.apache.org/licensing-howto.html (Comment écrire votre fichier LICENSE/NOTICE)
https://www.apache.org/legal/resolved.html#category-x (liste officielle des références interdites, y compris CC-BY)
https://lists.apache.org/[email protected] (liste de diffusion ASF-incubateur)
…
Réimprimé de丨ALC Beijing
Auteur丨imbajin
Modifier 丨 Luo Ruiyan
Lecture connexe | Lecture connexe
La réunion du premier trimestre 2023 du comité consultatif de Kaiyuanshe s'est tenue avec succès !
Logiciel open source de type ChatGPT, les développeurs peuvent-ils l'utiliser ?
Présentation de Kaiyuanshe
Fondée en 2014, Kaiyuan Society est composée de membres individuels qui contribuent volontairement à la cause de l'open source. Elle est formée selon le principe de "contribution, consensus et co-gouvernance". Elle a toujours maintenu les caractéristiques de neutralité des fournisseurs, bien-être public et à but non lucratif. Intégration internationale, développement communautaire, incubation de projets" est une fédération communautaire open source avec la mission. Kaiyuanshe coopère activement et étroitement avec les communautés, les entreprises et les unités gouvernementales qui soutiennent l'open source.Avec la vision de "Basé en Chine et contribuant au monde", il vise à créer un écosystème open source sain et durable et à promouvoir la communauté open source en Chine. devenir une force active dans le système open source mondial Participation et Contributeurs.
En 2017, Kaiyuanshe a été transformé en une organisation entièrement composée de membres individuels, fonctionnant en référence au modèle de gouvernance des principales fondations open source internationales telles que ASF. Au cours des neuf dernières années, il a connecté des dizaines de milliers de personnes open source, rassemblé des milliers de membres et de bénévoles de la communauté, des centaines de conférenciers nationaux et étrangers et coopéré avec des centaines de sponsors, médias et partenaires communautaires.
