├── .github ├── ISSUE_TEMPLATE │ └── translate.md └── pull_request_template.md ├── .gitignore ├── LICENSE ├── README.md ├── apache.md ├── apache ├── SkyWalking_translation.md ├── community │ └── newcommitter.md ├── incubator │ ├── Apache项目毕业指南.md │ ├── cookbook-zh.md │ └── new-propsoal-zh.md ├── license │ ├── ASF CLA FAQ.md │ ├── ASF第三方许可政策.md │ ├── ASF许可证常见问题.md │ ├── Apache产品发版规则.md │ ├── README.md │ ├── licensing-howto.md │ └── 代码头和Copyright声明.md ├── marks │ ├── Apache 商标使用管理原则.md │ ├── Apache 软件基金会商标使用指南.md │ ├── Apache下游项目的品牌使用原则.md │ ├── README.md │ └── 项目管理委员针对商标的管理职责.md └── securityreport │ ├── Apache软件安全报告.md │ ├── Apache软件安全报告2019.md │ ├── Apache软件安全报告2020.md │ └── Apache软件安全报告2022.md ├── docs ├── CONTRIBUTING.md ├── GLOSSARY.md ├── GUIDE.md ├── TODOLIST.md ├── WORKFLOW.drawio ├── WORKFLOW.md └── images │ ├── WORKFLOW.svg │ ├── clone.jpg │ ├── fork.jpg │ └── pull-request.jpg └── subtitles ├── ApacheEverywhere.srt ├── ApacheInnovation.srt ├── Trillions and Trillions Served - - documentary feature on The Apache Software Foundation.srt └── Trillions and Trillions Served - Why Apache.srt /.github/ISSUE_TEMPLATE/translate.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Translate 3 | about: Template of translate 4 | title: "[翻译] Apache 文档中文翻译计划" 5 | labels: status/pending 6 | assignees: 7 | --- 8 | 9 | ## 翻译必读 10 | 11 | * [ **工作流程**]( https://github.com/alc-beijing/translation/blob/master/docs/WORKFLOW.md) 12 | * [**翻译指南**](https://github.com/alc-beijing/translation/blob/master/docs/GUIDE.md) 13 | * [**术语表**](https://github.com/alc-beijing/translation/blob/master/docs/GLOSSARY.md) 14 | * * #[**格式语法**](https://docs.github.com/cn/free-pro-team@latest/github/writing-on-github/basic-writing-and-formatting-syntax) 15 | 16 | ## 文档信息 17 | 18 | * **原文标题：** The_original_title_of_the_documentation 19 | * **原文链接：** The_original_link_of_the_documentation 20 | * **提交路径：** translation/apache/license.md 21 | * **翻译收益：** 22 | * **翻译难度：** 23 | * **中文链接：** The_target_link_of_the_translation 24 | -------------------------------------------------------------------------------- /.github/pull_request_template.md: -------------------------------------------------------------------------------- 1 | 18 | 19 | * [相关链接（建议）]：Issue #1 20 | * [描述信息（可选）]： 21 | * [备注说明（可选）]： 22 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Creative Commons Legal Code 2 | 3 | CC0 1.0 Universal 4 | 5 | CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE 6 | LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN 7 | ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS 8 | INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES 9 | REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS 10 | PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM 11 | THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED 12 | HEREUNDER. 13 | 14 | Statement of Purpose 15 | 16 | The laws of most jurisdictions throughout the world automatically confer 17 | exclusive Copyright and Related Rights (defined below) upon the creator 18 | and subsequent owner(s) (each and all, an "owner") of an original work of 19 | authorship and/or a database (each, a "Work"). 20 | 21 | Certain owners wish to permanently relinquish those rights to a Work for 22 | the purpose of contributing to a commons of creative, cultural and 23 | scientific works ("Commons") that the public can reliably and without fear 24 | of later claims of infringement build upon, modify, incorporate in other 25 | works, reuse and redistribute as freely as possible in any form whatsoever 26 | and for any purposes, including without limitation commercial purposes. 27 | These owners may contribute to the Commons to promote the ideal of a free 28 | culture and the further production of creative, cultural and scientific 29 | works, or to gain reputation or greater distribution for their Work in 30 | part through the use and efforts of others. 31 | 32 | For these and/or other purposes and motivations, and without any 33 | expectation of additional consideration or compensation, the person 34 | associating CC0 with a Work (the "Affirmer"), to the extent that he or she 35 | is an owner of Copyright and Related Rights in the Work, voluntarily 36 | elects to apply CC0 to the Work and publicly distribute the Work under its 37 | terms, with knowledge of his or her Copyright and Related Rights in the 38 | Work and the meaning and intended legal effect of CC0 on those rights. 39 | 40 | 1. Copyright and Related Rights. A Work made available under CC0 may be 41 | protected by copyright and related or neighboring rights ("Copyright and 42 | Related Rights"). Copyright and Related Rights include, but are not 43 | limited to, the following: 44 | 45 | i. the right to reproduce, adapt, distribute, perform, display, 46 | communicate, and translate a Work; 47 | ii. moral rights retained by the original author(s) and/or performer(s); 48 | iii. publicity and privacy rights pertaining to a person's image or 49 | likeness depicted in a Work; 50 | iv. rights protecting against unfair competition in regards to a Work, 51 | subject to the limitations in paragraph 4(a), below; 52 | v. rights protecting the extraction, dissemination, use and reuse of data 53 | in a Work; 54 | vi. database rights (such as those arising under Directive 96/9/EC of the 55 | European Parliament and of the Council of 11 March 1996 on the legal 56 | protection of databases, and under any national implementation 57 | thereof, including any amended or successor version of such 58 | directive); and 59 | vii. other similar, equivalent or corresponding rights throughout the 60 | world based on applicable law or treaty, and any national 61 | implementations thereof. 62 | 63 | 2. Waiver. To the greatest extent permitted by, but not in contravention 64 | of, applicable law, Affirmer hereby overtly, fully, permanently, 65 | irrevocably and unconditionally waives, abandons, and surrenders all of 66 | Affirmer's Copyright and Related Rights and associated claims and causes 67 | of action, whether now known or unknown (including existing as well as 68 | future claims and causes of action), in the Work (i) in all territories 69 | worldwide, (ii) for the maximum duration provided by applicable law or 70 | treaty (including future time extensions), (iii) in any current or future 71 | medium and for any number of copies, and (iv) for any purpose whatsoever, 72 | including without limitation commercial, advertising or promotional 73 | purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each 74 | member of the public at large and to the detriment of Affirmer's heirs and 75 | successors, fully intending that such Waiver shall not be subject to 76 | revocation, rescission, cancellation, termination, or any other legal or 77 | equitable action to disrupt the quiet enjoyment of the Work by the public 78 | as contemplated by Affirmer's express Statement of Purpose. 79 | 80 | 3. Public License Fallback. Should any part of the Waiver for any reason 81 | be judged legally invalid or ineffective under applicable law, then the 82 | Waiver shall be preserved to the maximum extent permitted taking into 83 | account Affirmer's express Statement of Purpose. In addition, to the 84 | extent the Waiver is so judged Affirmer hereby grants to each affected 85 | person a royalty-free, non transferable, non sublicensable, non exclusive, 86 | irrevocable and unconditional license to exercise Affirmer's Copyright and 87 | Related Rights in the Work (i) in all territories worldwide, (ii) for the 88 | maximum duration provided by applicable law or treaty (including future 89 | time extensions), (iii) in any current or future medium and for any number 90 | of copies, and (iv) for any purpose whatsoever, including without 91 | limitation commercial, advertising or promotional purposes (the 92 | "License"). The License shall be deemed effective as of the date CC0 was 93 | applied by Affirmer to the Work. Should any part of the License for any 94 | reason be judged legally invalid or ineffective under applicable law, such 95 | partial invalidity or ineffectiveness shall not invalidate the remainder 96 | of the License, and in such case Affirmer hereby affirms that he or she 97 | will not (i) exercise any of his or her remaining Copyright and Related 98 | Rights in the Work or (ii) assert any associated claims and causes of 99 | action with respect to the Work, in either case contrary to Affirmer's 100 | express Statement of Purpose. 101 | 102 | 4. Limitations and Disclaimers. 103 | 104 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 105 | surrendered, licensed or otherwise affected by this document. 106 | b. Affirmer offers the Work as-is and makes no representations or 107 | warranties of any kind concerning the Work, express, implied, 108 | statutory or otherwise, including without limitation warranties of 109 | title, merchantability, fitness for a particular purpose, non 110 | infringement, or the absence of latent or other defects, accuracy, or 111 | the present or absence of errors, whether or not discoverable, all to 112 | the greatest extent permissible under applicable law. 113 | c. Affirmer disclaims responsibility for clearing rights of other persons 114 | that may apply to the Work or any use thereof, including without 115 | limitation any person's Copyright and Related Rights in the Work. 116 | Further, Affirmer disclaims responsibility for obtaining any necessary 117 | consents, permissions or other rights required for any use of the 118 | Work. 119 | d. Affirmer understands and acknowledges that Creative Commons is not a 120 | party to this document and has no duty or obligation with respect to 121 | this CC0 or use of the Work. 122 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 翻译 2 | 这里是ALC Beijing的翻译工作空间，我们现在有大量 Apache 文档需要翻译成中文，我们需要你的帮助。 3 | 4 | 您可以随时翻阅您想做的任务，您只需[issue](https://github.com/alc-beijing/translation/issues)下面添加评论认领，我们会很快将任务分配给您。 5 | 6 | 如果您是新手，**请仔细[阅读指南](docs/GUIDE.md)、[术语表](docs/GLOSSARY.md)和[工作流程](docs/WORKFLOW.md)**，它们将给您的翻译工作带来很大便利。 7 | 8 | 欢迎您的加入！ 9 | 10 | # Translation 11 | This is the translation workplace of ALC Beijing, we have plenty of materials need to be translated into Chinese, and WE NEED YOUR HELP! 12 | 13 | Please feel free to go through [the issues](https://github.com/alc-beijing/translation/issues) to pick up the tasks you want to do. Just add a comment on the issue, then we will assign the task to you shortly. 14 | 15 | Please go through the [the GUIDE](docs/GUIDE.md), [the GLOSSARY](docs/GLOSSARY.md) and [the WorkFlow](docs/WORKFLOW.md) if you are new to this translation project, they are VERY helpful! 16 | 17 | Welcome！ 18 | 19 | ## Contributors 20 | [![contributors](https://badges.implements.io/api/contributors?org=alc-beijing&repo=translation&width=1280&size=48&padding=6&type=jpeg)](https://github.com/alc-beijing/translation/graphs/contributors) 21 | 22 | -------------------------------------------------------------------------------- /apache.md: -------------------------------------------------------------------------------- 1 | ## 庆祝Apache®软件基金会22年以来基于“Apache之道”的开源创新 2 | 3 | 资料来源：Apache软件基金会 https://blogs.apache.org/foundation/entry/the-apache-software-foundation-celebrates4 4 | 5 | 翻译：单致豪 6 | 7 | 它是世界上最大的开源基金会，提供超过220亿美元社区主导软件，并且100％公益免费 8 | 9 | 美国东部时间2021年3月24日09:00 10 | 11 | 2021年3月24日，美国特拉华州威尔明顿市（全球新闻）Apache软件基金会（ASF）所有的志愿开发人员、管理人员、孵化人员带领350多个开源项目和计划，今天宣布基金会成立22周年。 12 | 13 | ASF最初由21个成员的Apache Group成立，负责监督当时已有3年历史的Apache HTTP Server。如今，ASF是世界上最大的，与供应商无关的开放源代码基金会，由800多个个人成员，8,100多个提交者，在每个大洲都有40,000多个代码贡献者。保守地估计价值超过220亿美元以上，Apache的350多个项目和37个孵化项目都是免费向广大公众开放的，100％免费提供，并且没有许可费用。 14 | 15 | Apache软件基金会董事会主席Sander Striker说：“在过去的22年中，ASF不断发展，可以满足更大社区的不断增长的需求。” “ ASF使来自世界各地的人们能够合作、开发和管理那些正在帮助个人、维持业务和转变产业的项目和社区。” 16 | 17 | ASF的项目推进了为公共利益提供软件的使命，几乎是现代计算各个方面不可或缺的一部分，使全球数十亿人受益。社区主导的并且协作发展而成的“ Apache Way”引领了人工智能和深度学习、大数据、构建管理、云计算、内容交付和管理、边缘计算和物联网、金融科技、身份管理、集成、库、消息中间件、移动终端、搜索引擎、安全、服务器、Web框架以及其他类别的突破性创新。在Apache孵化器中进行开发的项目涉及AI、大数据、区块链、云计算、加密、深度学习、电子邮件、IoT、机器学习、微服务、移动终端、操作系统、测试、可视化等等。 18 | 19 | 将近50万人参加了ASF的项目和计划，包括ASF的官方全球会议系列ApacheCon。社区发展方面，负责监督贡献者的入职和指导，如谷歌编程之夏之类；以及“多样性与包容性”，其计划促进整个Apache社区的多样性，公平性和包容性。 20 | 21 | ASF的影响无处不在，Apache项目为数十个行业中无处不在的关键任务应用程序提供了支持。Apache License 2.0是2020年排名第一的开源许可证（来源：WhiteSource）；Apache Way是开放式开发和内部开源环境的基础。并且新用户、开发人员和爱好者每天都加入更大的Apache社区（自该计划启动以来，过去16年来，ASF一直是谷歌编程之夏的指导组织）。ASF是排名最高的开源非营利组织，在GitHub上拥有最多的Star数（来源：GitHub）。 22 | 23 | FOSSlife [1]刚刚发布的专题指出：“ Apache项目无可否认地改变了世界……Apache仍然是至关重要的Web服务器，在该领域最受欢迎。对于建立开源社区，通过学习创建项目获得的经验，在整个开源世界引起共鸣。建议每个项目都尊重Apache的“社区高于代码”的价值观。” 24 | 25 | ASF运营通过基础架构支持、带宽、连接、服务器、硬件、开发环境、法律顾问、会计服务、商标保护、营销和宣传、教育活动以及相关的管理帮助Apache项目及其社区。作为美国的一家 private 501(c)(3) 非营利性慈善组织，ASF的日常运营费用可通过可扣税的赞助、公司捐款和个人捐款来抵消。当前的ASF赞助商有： 26 | 27 | * 铂金：AWS，Facebook，谷歌，华为，微软，Namebase，Pineapple Fund，腾讯 和 Verizon Media。 28 | * 金牌：匿名，百度，彭博，Cloudera，Confluent，IBM，Indeed，Reprise Software，Union Investment 和 Workday。 29 | * 银牌：Aetna，阿里云，Capital One，Comcast，滴滴出行，Red Hat 和 Target。 30 | * 铜牌：Bestecasinobonussen.nl, Bookmakers, Casino2k, Cerner, Curity, GridGain, Gundry MD, Host Advice, HotWax Systems, Journal Review, LeoVegas Indian Online Casino, Miro-Kredit AG, Mutuo Kredit AG, Online Holland Casino, ProPrivacy, PureVPN, RX-M, RenaissanceRe, SCAMS.info, SevenJackpots.com, Start a Blog by Ryan Robinson, Talend, The Best VPN, The Blog Starter, The Economic Secretariat, Top10VPN, Twitter, and Writers Per Hour. 31 | 32 | * 目标铂金：Amazon Web Services，CloudBees，DLA Piper，Fastly，JetBrains，Leaseweb，Microsoft，OSU Open Source Labs，Sonatype和Verizon Media。 33 | * 目标金牌：Atlassian，Datadog，Docker，PhoenixNAP和Quenda。 34 | * 目标银牌：HotWax Systems, Manning Publications, and Rackspace. 35 | * 目标铜牌：Bintray, Education Networks of America, Friend of Apache Cordova, Google, Hopsie, No-IP, PagerDuty, Peregrine Computer Consultants Corporation, Sonic.net, SURFnet, and Virtru. 36 | > 译注：这类目标赞助商不直接提供资金赞助，而是通过向ASF提供云服务或者软件授权的方式提供赞助。JetBrains就为Apache的Committer提供了免费的IDE全家桶软件授权。」 37 | 38 | > “百度一直与Apache软件基金会保持着密切的合作。过去，我们捐赠了Apache ECharts，Apache Doris，Apache brpc和Apache Teaclave。我们非常感谢Apache促进这些项目的增长并使百度能够与ASF一起为开源世界做出更大的贡献。” 39 | > 40 | > -侯震宇，百度集团公司副总裁 41 | 42 | > “恭喜Apache软件基金会成立22周年！如果不是ASF致力于孵化和管理开源项目的工作，那么互联网社区将无法达到同样的发展水平。开源正在推动我们的数字繁荣，并且ASF在此方面扮演着重要的幕后角色。我们与他们分享可信赖的开源软件的可用性，并为成为赞助商而感到自豪。” 43 | > 44 | > —Travis Spencer，Curity首席执行官 45 | 46 | >“恭喜Apache软件基金会成立22周年！今年滴滴出行荣幸地以公司赞助商身份加入Apache家族。在滴滴，我们的开发人员利用Hadoop，Kylin和Flink等许多Apache项目并为之做出贡献等。我们秉持相同的“社区高于代码”原则，我们希望与Apache一起推动更多的创新，我们期待进一步的合作！” 47 | > 48 | > —滴滴出行技术社区和开源总监 王蕴博 49 | 50 | >“ Facebook最初是使用Apache HTTP Server构建技术栈的，这是我们在过去10年中一直赞助、倡导、利用并为ASF做出贡献的众多原因之一。我们为成为其中的一员而感到自豪，并希望继续支持其为公众利益提供开源软件的使命。” 51 | > 52 | > —Facebook的开源开发者倡导者和生态系统负责人 Joel Marcey 53 | 54 | > “我们很荣幸能成为ASF的一份子，并为能支持ASF而感到自豪！Apache社区仍然是HotWax宝贵的资源。为ASF做出贡献并从中获得收益仍然是我们业务的核心，也是我们团队理念的重要组成部分。” 55 | > 56 | > — HotWax Systems首席执行官 Mike Bates 57 | 58 | > “很荣幸支持Apache，这是一个负责数量如此之多的开源项目的组织，这些项目真正构成了互联网的结构。这是过去22年中已完成的所有工作，我们迫不及待地看到开放式开发的未来将带来什么。” 59 | > 60 | > — Leaseweb全球产品策略主管Robert Van der Meulen 61 | 62 | > “我们对Apache软件基金会成立22周年表示极大的祝贺！在过去的20多年中，ASF一直是开源软件模型和社区主导开发成功的关键推动力。微软荣幸地与之合作。在我们业务的各个方面为Apache社区做出贡献，包括Azure大数据，Hadoop和Spark –我们期待着继续合作。” 63 | > — Stormy Peters，Microsoft开源项目办公室主任 64 | 65 | [1] FOSSlife“ Apache项目如何促进自由和开源软件运动” https://www.fosslife.org/how-apache-project-boosted-free-and-open-source-software-movements 66 | 67 | 其他ASF资源: 68 | * 无所不在的Apache纪录片 https://s.apache.org/Trillions-Feature 69 | * 关于Apache之路 http://apache.org/theapacheway/ 70 | * 可持续开源成功的Apache之路 https://s.apache.org/GhnI 71 | * 2020财年年度报告 https://s.apache.org/FY2020AnnualReport 72 | * 支持ASF的方法http://apache.org/foundation/contributing.html 73 | 74 | ### 关于Apache软件基金会（ASF） 75 | Apache软件基金会（Apache Software Foundation）成立于1999年，是全球最大的开源基金会，管理着2.27亿行代码，并以100％免费的向公众提供了价值超过220亿美元的软件。ASF的全民社区从21个最初监督Apache HTTP Server的创始人发展到813个个人成员和206个项目管理委员会，他们通过ASF的精英制（称为“ Apache之道”）成功地领导了350多个Apache项目和计划，与近8,100个提交者合作”。从笔记本电脑到平板电脑再到企业和关键任务应用程序中的移动设备，几乎所有最终用户计算设备都必须使用Apache软件。Apache为大多数互联网提供了强大的功能，管理了数十亿字节的数据，执行了数百万亿次的操作，并在几乎每个行业中存储数十亿个对象。商业上友好且宽松的Apache License v2是开源行业标准，它帮助创立了数十亿美元的公司，并惠及了全球无数用户。ASF是美国501(c)(3)非营利性慈善组织，由个人捐款和公司赞助商资助，包括Aetna，阿里云，Amazon Web Services，Anonymous，百度，Bloomberg，Capital One，Cloudera，Comcast， Confluent，滴滴出行，Facebook，Google，华为，IBM，Indeed，Microsoft，Namebase，Pineapple Fund，Red Hat，Reprise Software，Target，腾讯，Union Investment，Verizon Media和Workday。有关更多信息，请访问 http://apache.org/ 和 https://twitter.com/TheASF 76 | 77 | ©Apache软件基金会。“ Apache”，“ Apache HTTP Server”和“ ApacheCon”是Apache软件基金会在美国和/或其他国家的注册商标或商标。所有其他品牌和商标均为其各自所有者的财产。 78 | -------------------------------------------------------------------------------- /apache/SkyWalking_translation.md: -------------------------------------------------------------------------------- 1 | # SkyWalking 8.2中的新特性:浏览器端监控;使用标签查询;指标分析语言 2 | * 作者：柯振旭、吴晟、高洪涛、Tevah Platt（Tetrate） 3 | * 原文：[What's new with Apache SkyWalking 8.2? Browser monitoring and more](https://tetrate.io/blog/whats-new-with-apache-skywalking-8-2-browser-monitoring-and-more/) 4 | * 2020年10月29日 5 | ![介绍图][overview_img] 6 | Apache SkyWalking，一个可观测性平台，亦是一个开源的应用性能监视器（APM）项目，今日宣布 8.2 发行版全面可用。该发行版拓展了核心功能，并将其监控边界拓展到浏览器端。 7 | 8 | ### 背景 9 | SkyWalking 是一个观测平台和 APM 工具。它可以选择性的与 Service Mesh 协同工作，为微服务、云原生和基于容器的应用提供自动的仪表盘。该项目是全球社区支持的 Apache 顶级项目，阿里巴巴、华为、腾讯、百度、字节跳动等许多公司都在使用。 10 | 11 | ### 浏览器端监控 12 | APM 可以帮助 SRE 和工程团队诊断系统故障，亦能在系统异常缓慢之前优化它。但它是否足以让用户总是满意呢？ 13 | 14 | 在 8.2.0 版本中， SkyWalking 将它的监控边界拓展到了浏览器端，比如 Chrome ，或者 Chrome 和后端服务之间的网络。这样，我们不仅可以像以前一样监控浏览器发送给后端服务的与请求，还能看到前端的渲染速度、错误日志等信息——这些信息是获取最终用户体验的最有效指标。（目前此功能尚未拓展到物联网设备中，但这项功能使得 SkyWalking 向着这个方向前进了一步） 15 | 16 | ![监控展示图1][func_1] 17 | 18 | 此外，SkyWalking浏览器监视也提供以下数据: 19 | PV（page views，页面浏览量）， UV（unique visitors，独立访客数），浏览量前N的页面（Top N Page Views）等。这些数据可以为产品队伍优化他们的产品提供线索。 20 | 21 | ![监控展示图2][func_2] 22 | 23 | ### 按标签查询trace 24 | 在SkyWalking的Span数据模型中，已经有了许多被索引并可供用户查询的重要字段。但出于性能考虑，使用Span标签查询的功能至今尚未被支持。在SkyWalking 8.2.0 中，我们允许用户查询被特定标签标记的trace，这非常有用。SRE 工程师可以在生产环境中运行测试，将其打上仿真流量的标签，并稍后通过该标签查找它。 25 | 26 | ### 指标分析语言 27 | 在 8.2.0 中，仪表系统提供了一项名为MAL（Meter Analysis Language，指标分析语言）的强大分析语言。该语言允许用户在OAP流系统中分析并聚合（aggregate）仪表数据。 28 | 表达式的结果可以被Agent分析器或OpenTelemetry/Prometheus分析器获取。 29 | 30 | ### 复合警报规则 31 | 警报是及时发现系统失效的有效方式。一个常见的问题是，为了避免错过任何可能的问题，我们通常会配置过多的触发器（triggers）。没有人喜欢半夜被警报叫醒，结果只是因为触发系统太敏感。这种警报很嘈杂并毫无帮助。 32 | 33 | 在 8.2.0 版本中，用户选择可以配置考虑了多个度量维度的复合警报规则。使用复合报警规则，我们可以根据需要添加尽可能多的指标来更精确地判断是否存在真正的问题，或者只是一个偶发的小问题。 34 | 35 | 一些常见的情况，如 `成功率 < 90%但只有 1~2个请求`现在可以被复合规则解决，如`traffic(calls per minute) > n && successful rate < m%`。 36 | ### 其它值得注意的改进 37 | 1. agent-toolkit SDK 公开了某些 API，供用户发送自定义指标。 38 | 2. Agent`exclude_plgins`允许您排除某些插件（plugins）;`mount`使您能够加载一套新的插件。 39 | 3. 社区贡献了超过10个新Agent插件。 40 | 4. 报警系统原生支持发送消息到Slack，企业微信，钉钉。 41 | 42 | ### 附加资源 43 | * 阅读更多关于[SkyWalkng 8.2 发行版重点][e1]。 44 | 45 | * 在[推特][tw]上获取更多关于SkyWalking的更新。 46 | 47 | ### Apache SkyWalking DevCon报名信息 48 | 49 | Apache SkyWalking DevCon 2020开始报名了。 50 | 11月14日，欢迎大家来线下[参加活动和交流][offline], 或者[报名][online]观看线上直播。 51 | 52 | 53 | 54 | [overview_img]:https://skywalking.apache.org/assets/img/apache-skywalking.87a0b9b4.jpg 55 | [func_1]:https://skywalking.apache.org/assets/img/apache-skywalking-web-app-monitoring.b6364269.png 56 | [func_2]:https://skywalking.apache.org/assets/img/apache-skywalking-web-pages-monitoring.e6de5515.png 57 | [e1]:https://github.com/apache/skywalking/blob/v8.2.0/CHANGES.md 58 | [tw]:https://twitter.com/ASFSkyWalking 59 | [offline]:https://www.huodongxing.com/event/3567284406200 60 | [online]:https://www.itdks.com/Home/Act/apply?id=5392&mUid=57437 61 | 62 | -------------------------------------------------------------------------------- /apache/community/newcommitter.md: -------------------------------------------------------------------------------- 1 | 2 | # Committer 迎新指南 3 | >原文地址 : https://community.apache.org/newcommitter.html 4 | > 5 | >翻译 : @L-Y-L/87 6 | > 7 | >校对 : @tuohai666, @ShawnJim, @6freeair2016, @willemjiang 8 | 9 | 10 | 发现潜在的新 Committer，发起提名他们是 Committer 的投票并处理相关文档，是整个社区成员可以致力的任务。 11 | 12 | 每个项目都有不同的方法来管理 Committer。本页面描述了在许多 Apache 项目中常见的过程，同时还提供了各种必要的沟通模板。 13 | 14 | {{% toc %}} 15 | 16 | ## 评估新候选人是否适合成为提交者的指南 17 | 18 | 在投票时，所有 PMC 成员都需要自己决定是否批准候选人成为 committer。他们可能会搜索邮件列表和 JIRA，以查看候选人如何与他人互动，以及他们所做的贡献（代码或文档补丁、建议、参与对话）。 19 | 20 | 所有新提交者都**必须**遵守[Apache 行为准则](https://www.apache.org/foundation/policies/conduct.html)。 21 | 22 | 每个 PMC 可能希望创建自己的补充提交者指南；这是[Apache Forrest 提交者指南](https://forrest.apache.org/committed.html)。 23 | 24 | 以下是在评估候选人的 Committer 资格时需要考虑的一些要点。 25 | 26 | ### 与同行合作的能力。 27 | 28 | 我们如何评估？ 29 | 30 | - 通过他们通过电子邮件进行的互动。 31 | - 通过他们如何回应批评。 32 | - 通过他们如何参与群体决策。 33 | 34 | ### 有能力成为导师。 35 | 36 | 我们如何评估？ 37 | 38 | - 通过他们通过电子邮件进行的互动。 39 | - 通过他们的清晰程度以及他们识别甚至创建适当的背景材料的意愿。 40 | 41 | ### 社区 42 | 43 | 我们如何评估？ 44 | 45 | - 通过他们通过电子邮件进行互动情况。 46 | - 他们是否帮助回答邮件列表中提出的问题？他们是否表现出乐于助人的态度，是否尊重他人的想法？ 47 | 48 | ### 投入 49 | 50 | 我们如何评估？ 51 | 52 | - 按已经给项目的时间。 53 | - 通过他们如何坚持这个过程来解决棘手的问题。 54 | - 通过他们如何帮助完成不那么有趣的任务。 55 | 56 | ### 个人技能/能力 57 | 58 | 我们如何评估？ 59 | 60 | - 对项目有扎实的总体了解。 61 | - 电子邮件中讨论的质量。 62 | - 他们的补丁（如适用）是否仅需粗略审查即可轻松应用。 63 | 64 | ## 新提交者过程 65 | 66 | 本节描述了一个典型的 Apache 项目处理投票以添加新提交者的过程。该过程中提到的模板出现在本文档的后面。 67 | 68 | ### 概括 69 | 70 | 1. 讨论提议的 Committer/PMC 成员。如果是肯定的，请进行投票（templates/committerVote.txt） 71 | 2. 关闭投票 (templates/closeVote.txt) 72 | 3. 如果结果是肯定的，请邀请新的提交者 (templates/committerInvite.txt) 73 | 74 | 如果他们接受，那么： 75 | 76 | 1. 如果他们已经有一个 Apache id，授予适当的提交权限。使用 Whimsy 工具通过[https://whimsy.apache.org/roster/committee/](https://whimsy.apache.org/roster/committee/)或[https://whimsy.apache.org/roster/ppmc/](https://whimsy.apache.org/roster/ppmc/)更新名册。 77 | 2. 如果他们已经提交了 ICLA，请求创建提交者帐户。如果他们需要更改之前提交的 ICLA 中的任何内容，请等待新的 ICLA 提交，然后申请帐户。 78 | 1. 等 root 确认完成 79 | 2. PMC Chair 更新 LDAP 组成员资格，启用 svn、gitbox 和其他访问。如果提交者使用 GitHub，他们有责任将其链接到他们的 ASF 帐户。 80 | 3. 将提交者添加到 JIRA 和 CWiki 中的相应分组 81 | 3. 通知提交者完成（template/committerDone.txt） 82 | 4. 如果提交者也将成为 PMC 成员，PMC 主席将发送电子邮件至 board@ 请求确认新的 PMC 成员 (templates/email-member-ack.txt) 83 | 5. 宣布新的提交者（template/committerAnnounce.txt） 84 | 85 | ### 讨论 86 | 87 | 我们在邮件列表上进行讨论和投票，`private@`以进行坦率的讨论。 88 | 89 | 我们邀请人们以提交者/PMC 成员的身份加入，而不是 github id。可以参考候选人的 github id 来了解上下文，但是应该用他们的名字来称呼这个人。没有必要提供他们的法定全名（这将被保密），但使用他们的名字很重要，因为他们在电子邮件中是这样称呼自己的。如果一个人只知道他们的 github id，那么可以在举行投票之前询问他们的真实姓名。 90 | 91 | 为每个新人启动一个单独的 \[VOTE\] 线程。这会使查看电子邮件存档变得更容易。 92 | 93 | 我们需要确保他们是忠诚的人，我们可以与之共事。他们将是我们的同龄人。我们已经观察到他们致力于项目并且对用户和其他开发人员很友善。 94 | 95 | 提议不要拖太久，也不能过于匆忙，需要考虑时效性的问题。时机来临，很显然我们应该邀请他们，这会鼓舞他们，令之保持热情。如果我们拖得太久，就有可能让他们感到失望。 96 | 97 | 在`private@`名单上，我们每个人都可以毫无保留地准确地说出我们对每个人的感受。保持讨论简洁。表扬部分可以稍后公开进行。但是请记住，如果该成员以后成为 PMC 成员，他们将有权访问此讨论。 98 | 99 | 让投票线程运行一周。 100 | 101 | **共识批准**取得了积极的结果：至少 3 +1 票且没有否决权。 102 | 103 | 任何否决都必须附有理由，并且否决者必须准备好为其辩护。其他成员可以尝试鼓励他们改变主意。 104 | 105 | 新提交者可以选择安静或活跃。如果我们发现某些人失效并且从未做出贡献，那么该项目可以采取措施让他们退休。 106 | 107 | 获得肯定结果后，将结果记录在 PMC 列表中，主题为 \[RESULT\]\[VOTE\]，然后邀请候选人。我们让候选人有机会私下拒绝提交者身份。他们可以回复 PMC 邮件列表。 108 | 109 | 在我们对列表做出决定`private@`并完成上述步骤后，我们会在列表中宣布新的提交者`dev`。然后我们每个人都可以在公开场合进行称赞。 110 | 111 | [有关该过程的其他说明可在Apache](https://www.apache.org/dev/pmc.html#newcommitter)主站点上找到。 112 | 113 | ## 电子邮件模板 114 | 115 | ### 提交者投票模板 116 | 117 | 这是开始对新提交者进行投票的电子邮件。一些项目自动使提交者成为 PMC 成员。如果是这种情况，请将此模板与以下模板（PMC 投票模板）合并。 118 | 119 | ``` 120 | ------------------------------------------------------------ 121 | To: private@[PROJECT].apache.org 122 | Subject: [VOTE] New committer: Jo Bloggs 123 | 124 | [ add the reasons behind your nomination here ] 125 | 126 | Voting ends one week from today, i.e. midnight UTC on YYYY-MM-DD 127 | https://www.timeanddate.com/counters/customcounter.html?year=YYYY&month=MM&day=DD 128 | 129 | See voting guidelines at 130 | https://community.apache.org/newcommitter.html 131 | 132 | ------------------------------------------------------------ 133 | ``` 134 | 135 | ### PMC 投票模板 136 | 137 | **这是开始对新的PMC 候选人**进行投票的电子邮件。新的 PMC 成员需要由现有的 PMC 成员投票选出，然后由董事会（或用于孵化项目的孵化器 PMC）批准。 138 | 139 | ``` 140 | ------------------------------------------------------------ 141 | To: private@[PROJECT].apache.org 142 | Subject: [VOTE] New PMC candidate: Jo Bloggs 143 | 144 | [ add the reasons behind your nomination here ] 145 | 146 | Voting ends one week from today, i.e. midnight UTC on YYYY-MM-DD 147 | https://www.timeanddate.com/counters/customcounter.html?year=YYYY&month=MM&day=DD 148 | 149 | See voting guidelines at 150 | https://community.apache.org/newcommitter.html 151 | ``` 152 | 153 | ### 关闭投票 154 | 155 | 此邮件结束投票并将结果报告给项目。 156 | 157 | ``` 158 | ------------------------------------------------------------ 159 | To: private@[PROJECT].a.o 160 | Subject: [RESULT] [VOTE] New committer (or PMC candidate): Jo Bloggs 161 | 162 | The vote has now closed. The results are: 163 | 164 | Binding Votes: 165 | 166 | +1 [TOTAL BINDING +1 VOTES] 167 | 0 [TOTAL BINDING +0/-0 VOTES] 168 | -1 [TOTAL BINDING -1 VOTES] 169 | 170 | The vote is ***successful/not successful*** 171 | ``` 172 | 173 | ### 通知董事会新的 PMC 成员 174 | 175 | 请参阅[https://www.apache.org/dev/pmc.html#newpmc](https://www.apache.org/dev/pmc.html#newpmc) 176 | 177 | ### 提交者邀请模板 178 | 179 | 这是建议发送给新当选的提交者的邀请电子邮件，在新提交者投票获得积极结果后发送。 180 | 181 | ``` 182 | ------------------------------------------------------------ 183 | To: JoBloggs@foo.net 184 | Cc: private@[PROJECT].apache.org 185 | Subject: Invitation to become [PROJECT] committer: Jo Bloggs 186 | 187 | Hello [invitee name], 188 | 189 | The [Project] Project Management Committee (PMC) 190 | hereby offers you committer privileges to the project 191 | [as well as membership in the PMC]. These privileges are 192 | offered on the understanding that you'll use them 193 | reasonably and with common sense. We like to work on trust 194 | rather than unnecessary constraints. 195 | 196 | Being a committer enables you to more easily make 197 | changes without needing to go through the patch 198 | submission process. [Being a PMC member enables you 199 | to guide the direction of the project.] 200 | 201 | Being a committer does not require you to 202 | participate any more than you already do. It does 203 | tend to make one even more committed. You will 204 | probably find that you spend more time here. 205 | 206 | Of course, you can decline and instead remain as a 207 | contributor, participating as you do now. 208 | 209 | This personal invitation is a chance for you to accept or decline in private. 210 | Please let us know in reply to this message whether you accept or decline. 211 | 212 | If you accept, you will need an Apache account (id) with privileges. 213 | Please follow these instructions. 214 | 215 | A. If you already have an ICLA on file: 216 | 217 | 1. If you already have an Apache account, let us know your id and we 218 | will grant you privileges on the project repositories. 219 | 220 | 2. If you have previously sent an ICLA, let us know the email address 221 | and public name used on the ICLA and your preferred Apache id, and 222 | we will request your account. 223 | 224 | 3. If the email address on the previously submitted ICLA is no longer 225 | valid, let us know the email address and public name used on the new ICLA, 226 | and your preferred Apache id. Continue to step B below and file your new ICLA. 227 | 228 | Look to see if your preferred ID is already taken at 229 | https://people.apache.org/committer-index.html 230 | 231 | B. If there is not already an ICLA on file, you need to submit an ICLA: 232 | 233 | 1. Details of the ICLA and the forms are found 234 | through this link: https://www.apache.org/licenses/#clas 235 | 236 | 2. Instructions for its completion and return to 237 | the Secretary of the ASF are found at 238 | https://www.apache.org/licenses/contributor-agreements.html#submitting 239 | 240 | Do not copy the project or any other individual on your message 241 | to Secretary, as the form contains Personally Identifiable Information 242 | that should be kept private. 243 | 244 | 3. When you complete the ICLA form, be sure to include in the form 245 | the Apache [Project] project and choose a 246 | unique Apache ID. Look to see if your preferred 247 | ID is already taken at 248 | https://people.apache.org/committer-index.html 249 | This will allow the Secretary to notify the PMC 250 | when your ICLA has been recorded. 251 | 252 | When recording of your ICLA is noted, you will 253 | receive a follow-up message with the next steps for 254 | establishing you as a committer. 255 | ``` 256 | 257 | ### Committer 帐户创建 258 | 259 | [按照此处的](https://www.apache.org/dev/pmc.html#newcommitter)说明进行操作 。 260 | 261 | 总之： 262 | 263 | 如果 ICLA 标识了项目和有效的 Apache ID，并且 [RESULT][VOTE] 消息已发布到 PMC 私有邮件列表，则帐户创建请求由提交 ICLA 的秘书或助理提出。 264 | 265 | 否则，新帐户请求应由 PMC 主席（如果主席不在，则由任何[ASF 成员提出）。](https://www.apache.org/foundation/glossary.html#Member) 266 | 267 | PMC 主席需要使用[ASF 新账户申请](https://id.apache.org/acreq/pmc-chairs/)表来发送新账户申请。会员可以使用[ASF 新帐户请求](https://id.apache.org/acreq/members/)页面。 268 | 269 | 对于在公共列表上举行的选举，请提供 [mail-archives.apache.org](https://mail-archives.apache.org/) url。对于私人列表，您可以使用[邮件搜索工具](https://mail-search.apache.org/)找到合适的 url。 270 | 271 | ### Committer 公告模板 272 | 273 | `[PROJECT]-dev`这是在创建帐户后向其宣布新 Committer 的电子邮件。 274 | 275 | ``` 276 | ------------------------------------------------------------ 277 | To: dev@[PROJECT].apache.org 278 | Subject: new committer: ###Jo Bloggs 279 | 280 | The Project Management Committee (PMC) for Apache [PROJECT] 281 | has invited Jo Bloggs to become a committer and we are pleased 282 | to announce that they have accepted. 283 | 284 | ### add specific details here ### 285 | 286 | Being a committer enables easier contribution to the 287 | project since there is no need to go via the patch 288 | submission process. This should enable better productivity. 289 | A PMC member helps manage and guide the direction of the project. 290 | ``` 291 | 292 | ### Committer 账号创建完成模板 293 | 294 | Committer 账户建立后。 295 | ``` 296 | ------------------------------------------------------------ 297 | To: private@[PROJECT].a.o, ###JoBloggs@foo.net 298 | Subject: account request: ###Jo Bloggs 299 | 300 | ####, as you know, the ASF Infrastructure has set up your 301 | committer account with the username '####'. 302 | 303 | Please follow the instructions to set up your SSH, 304 | svn password, svn configuration, email forwarding, etc. 305 | https://www.apache.org/dev/#committers 306 | 307 | [If your project automatically adds committers to the PMC] 308 | Please subscribe to the [PROJECT] Project Management 309 | Committee mailing list private@[PROJECT].apache.org. 310 | [/If] 311 | 312 | You have commit access to specific sections of the 313 | ASF repository, as follows: 314 | 315 | [PROJECT] has various resources at: 316 | https://svn.apache.org/repos/asf/[PROJECT] 317 | https://gitbox.apache.org 318 | 319 | The general "committers" at: 320 | https://svn.apache.org/repos/private/committers 321 | 322 | If using svn, you will probably need to 'svn switch" previous checkouts to now use https, 323 | for example: 324 | 325 | svn switch --relocate https://svn.apache.org/repos/asf/[PROJECT] https://svn.apache.org/repos/asf/[PROJECT] 326 | 327 | The developer section of the website describes roles within the ASF and provides other 328 | resources: 329 | https://www.apache.org/foundation/how-it-works.html 330 | https://www.apache.org/dev/ 331 | 332 | The incubator also has some useful information for new committers 333 | in incubating projects: 334 | https://incubator.apache.org/guides/committer.html 335 | https://incubator.apache.org/guides/ppmc.html 336 | 337 | Just as before you became a committer, participation in any ASF community 338 | requires adherence to the ASF Code of Conduct: 339 | https://www.apache.org/foundation/policies/conduct.html 340 | 341 | [PROJECT should insert its own guidelines here; if none are available, 342 | the Apache Forrest guidelines are available as a template.] 343 | https://forrest.apache.org/guidelines.html 344 | 345 | If you have any questions during this phase, then please 346 | see the following resources: 347 | 348 | Apache developer's pages: https://www.apache.org/dev/ 349 | Incubator committer guide: https://incubator.apache.org/guides/committer.html 350 | 351 | Naturally, if you don't understand anything be sure to ask us on the [PROJECT] dev mailing list. 352 | Documentation is maintained by volunteers and hence can be out-of-date and incomplete - of course 353 | you can now help fix that. 354 | 355 | A PMC member will announce your election to the dev list soon. 356 | ``` 357 | -------------------------------------------------------------------------------- /apache/incubator/Apache项目毕业指南.md: -------------------------------------------------------------------------------- 1 | * **原文标题：** Guide :: Guide to Successful Graduation 2 | * **原文链接：** http://incubator.apache.org/guides/graduation.html 3 | * **提交路径：** translation/apache/incubator/Apache项目毕业指南.md 4 | 5 | # Apache 项目毕业指南 6 | 7 | ## 目录 8 | 9 | - [毕业意味着什么](#毕业意味着什么) 10 | 11 | - [毕业成为子项目还是顶级项目](#毕业成为子项目还是顶级项目) 12 | 13 | - [毕业之前](#毕业之前) 14 | 15 | - [毕业检查清单](#毕业检查清单) 16 | - [检查状态文件](#检查状态文件) 17 | 18 | - [确保合适的项目名称和产品名称](#确保合适的项目名称和产品名称) 19 | 20 | - [创建 Apache 发行版](#创建-Apache-发行版) 21 | 22 | - [创建一个开放和多样化的社区](#创建一个开放和多样化的社区) 23 | 24 | - [其他事宜](#其他事宜) 25 | 26 | - [毕业流程](#毕业流程) 27 | 28 | - [毕业成为顶级项目](#毕业成为顶级项目) 29 | - [社区的毕业投票](#社区的毕业投票) 30 | - [准备提案](#准备提案) 31 | - [推荐投票](#推荐投票) 32 | - [向董事会提交决议](#向董事会提交决议) 33 | - [新顶级项目的新闻稿](#新顶级项目的新闻稿) 34 | 35 | - [毕业成为子项目](#毕业成为子项目) 36 | 37 | - [社区的毕业投票](#社区的毕业投票) 38 | - [子项目验收投票](#子项目验收投票) 39 | - [毕业批准投票](#毕业批准投票) 40 | - [最后步骤](#最后步骤) 41 | 42 | 本文档的目的是帮助正在孵化的项目了解毕业流程，并提供一些关于如何实现毕业的看法。它还与孵化器[退出政策](http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating_from_the_Incubator)有关。这不是一个一成不变的标准，但代表了孵化器 general 邮件列表上以往讨论中凝结的共识。它还描述了毕业后应该如何迈出第一步。 43 | 44 | 本文只是一个指南。更具体的政策[在此](http://incubator.apache.org/policy/incubation.html)说明。 45 | 46 | 通过在 JIRA 的 Incubator 部分发布本文件的补丁或在孵化器的[general](http://incubator.apache.org/guides/lists.html#general_at_incubator.apache.org)邮件列表中发表评论来帮助改进本文。 47 | 48 | ## 毕业意味着什么 49 | 50 | 毕业是指一个正在孵化的项目成为已经存在的 Apache 项目下的一个子项目，或者成为一个顶级 Apache 项目的行为。毕业是一个民主的过程：最终要通过[投票](http://www.apache.org/foundation/voting.html)来决定。请注意，在你加入孵化器期间，你已经在忙于毕业的过程了：采用 Apache 的步骤、培养你的社区使之成长、就代码风格（制表符和空格）进行（有礼貌的）争论和创建发行版等等。所有这些行为都会对项目的毕业产生影响。 51 | 52 | 通往毕业的道路是非常清晰的：根据你的项目是想成为一个顶级项目，还是作为一个已经存在的项目下的子项目加入进去，步骤相当简单，但确实需要时间和努力。本文提供了使这个过程能够顺利进行的指南。 53 | 54 | 本文件仅用于指导和教育。实际政策记录在[孵化政策指南](http://incubator.apache.org/incubation/Incubation_Policy.html)中[这个](http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating_from_the_Incubator)章节。关于毕业的任何问题，请在[孵化器 general 邮件列表](http://incubator.apache.org/guides/lists.html#general_at_incubator.apache.org)中发布。 55 | 56 | ## 毕业成为子项目还是顶级项目 57 | 58 | 每个提案都有一个[发起人](http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor)。发起人的身份表明了项目的目的地。对于由[董事会](http://incubator.apache.org/guides/roles_and_responsibilities.html#the_board)或[孵化器项目管理委员会（IPMC）](http://incubator.apache.org/guides/roles_and_responsibilities.html#incubator_project_management_committee_ipmc)发起的提案，这是一个顶级项目。对于其他提案，则作为发起项目的一个子项目。然而，目的地只在毕业时固定下来，而不是刚孵化的时候。项目在毕业过程中不断成长和发展。随着毕业的临近，应该根据项目当前的情况来重新审视最初的目标。 59 | 60 | 只有当子项目仍然属于某项目的范围并需要该项目[PMC](http://www.apache.org/foundation/how-it-works.html#structure)的同意时，才有可能作为子项目毕业。而作为一个顶级项目毕业，则需要[董事会](http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#board)来组建新的项目。 61 | 62 | [IPMC](http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC)也将发表民主意见。对于那些寻求毕业为子项目的人来说，这些意见是为了批准项目迁移。对于那些寻求毕业成为顶级项目的人来说，这些意见将是对[董事会](http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#board)的建议。我们期待 IPMC 成员提出关于项目的问题，包括目的地的选择。这也是正常程序的一部分。 63 | 64 | ## 毕业之前 65 | 66 | 在开始考虑毕业之前，你需要确保已经准备好了，并且符合 Apache 对项目提出的要求。本节将为正在孵化的项目提供一个简短清单，以确定他们是否符合毕业标准。 67 | 68 | ### 毕业检查清单 69 | 70 | 以下是一个简短的检查清单，给出了一个总览，不能代替阅读之后的内容。 71 | 72 | - 准备工作 73 | 74 | - 完成（并签收）[状态文件](http://incubator.apache.org/guides/graduation.html#notes-status)中记录的任务 75 | - 确保项目和产品的[合适名称](http://incubator.apache.org/guides/graduation.html#notes-names) 76 | - 展示[创建 Apache 发行版](http://incubator.apache.org/guides/graduation.html#releases)的能力 77 | - 展示[社区的准备情况](http://incubator.apache.org/guides/graduation.html#community) 78 | - 确保[导师](http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Mentor)和[IPMC](http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC)没有[遗留问题](http://incubator.apache.org/guides/graduation.html#notes-issues) 79 | 80 | - 决定项目的[目的地](http://incubator.apache.org/guides/graduation.html#subproject-or-top-level) 81 | 82 | - 准备一份[决议](http://incubator.apache.org/guides/graduation.html#tlp-resolution)（只限于候选的顶级项目） 83 | 84 | - 目的地项目的[验收投票](http://incubator.apache.org/guides/graduation.html#subproject-acceptance)（只限于候选的子项目） 85 | 86 | - 孵化器项目管理委员会（IPMC） 87 | 88 | - 对于候选的顶级项目，这是一个[建议投票](http://incubator.apache.org/guides/graduation.html#ipmc-top-level-recommendation) 89 | - 对于候选的子项目，这是一个[毕业批准投票](http://incubator.apache.org/guides/graduation.html#subproject-graduation) 90 | 91 | - 最后[交接](http://incubator.apache.org/guides/graduation.html#notes-on-hand-over) 92 | 93 | - 考虑毕业后的[任务](http://incubator.apache.org/guides/graduation.html#project-first-steps) 94 | 95 | ### 检查状态文件 96 | 97 | 状态文件记录并总结了项目孵化的相关信息。[PPMC](http://incubator.apache.org/guides/ppmc.html#Incubator_ASF_Board_Reports)负责保持该文件的最新状态。在你能够毕业之前，所有的任务都需要完成。 98 | 99 | 状态文件是一个很好的方法，可以随时了解你的项目是如何进行的，以及为达到毕业标准需要做什么。[孵化器项目管理委员会](http://incubator.apache.org/guides/ppmc.html#Incubator_ASF_Board_Reports)将在投票决定你的项目是否毕业时检查这个文件。一旦所有的任务都完成了，并且符合标准，你的项目就可以毕业了。 100 | 101 | JUDDI 项目的状态文件就是一个[例子](http://incubator.apache.org/projects/juddi.html)。 102 | 103 | ## 确保合适的项目名称和产品名称 104 | 105 | 请阅读这个[文档](http://www.apache.org/foundation/marks/naming.html)。"确保合适的项目和产品名称的过程 "是每个想毕业的正在孵化的项目的必修课。 106 | 107 | ## 创建 Apache 发行版 108 | 109 | > 早发布，多发布 110 | 111 | > — Eric Steven Raymond 112 | 113 | > http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html 114 | 115 | 发布工作有两个不同的部分: 116 | 117 | - **准备发布** 是由发布经理来完成的。有些文档将此称为 "切割 "发布（cutting a release）。**准备发布**是指按照项目的发布文档来创建发布产物，并把它们放在临时仓库里，以便作为投票和后续发布使用。 118 | 119 | - **发布版本** 需要在孵化项目 PPMC 和 IPMC 使用正式的[VOTE]程序，批准已经准备好的版本后才能进行。如果投票失败，发布经理可以重新准备一个改进的版本。发布意味着发布产物被转移到官方发布仓库，并被镜像系统接收。 120 | 121 | 在孵化器中，展示发版能力是一个重要步骤。这意味着即将毕业的孵化项目： 122 | 123 | - 明白包含进项目的源码的许可证要求 124 | - 明白在哪里临时存储发布的源代码 125 | - 明白如何对发版进行投票 126 | - 明白如何对旧版本进行归档 127 | 128 | 请阅读[孵化器发布管理指南](http://incubator.apache.org/guides/releasemanagement.html)，以了解发布一个能获得[IPMC](http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC)批准的版本的提示、技巧和指南。 129 | 130 | ## 创建一个开放和多样化的社区 131 | 132 | 毕业的一个主要标准是发展一个开放和多样化的[由精英管理的](http://www.apache.org/foundation/glossary.html#Meritocracy)社区。时间已经证明，这类社区比封闭的社区更加强大和富有成效。 133 | 134 | Apache 项目是自我维持和自我管理的社区。长期的成功和良性发展，需要社区了解如何： 135 | 136 | - 招募用户、开发者、提交者和 PMC 成员 137 | - 积极开展线上线下活动 138 | - 在不破坏人际关系的情况下，在公开场合就技术问题提出不同意见 139 | - 在邮件列表中创造一个开放、积极和包容的氛围 140 | 141 | 毕业需要评估（IPMC 角度）一个正在孵化的项目是否学到了足够的知识，是否有足够的责任感来维持这样一个社区。 142 | 143 | 可以在[社区指南](http://incubator.apache.org/guides/community.html)中阅读如何为你的孵化项目建立一个开放和多样化的社区。 144 | 145 | 随着项目的发展，社区需要通过接受新的提交者来提高活力。一个项目需要学习如何招募新的开发者和提交者进入社区。接受新的提交者通常会增强项目的多样化。所以，这个过程是非常有益的。[社区建设](http://incubator.apache.org/guides/community.html)需要耗费精力，这些精力本可以用在代码开发上，但这一成本对项目的未来来说是一项重要的投资。 146 | 147 | 社区的开放性不仅仅是由贡献者的数量来衡量的。在邮件列表上的开放和互相尊重的讨论是至关重要的。必须学会在不破坏人际关系的情况下解决技术冲突。学习如何有效地使用邮件列表是非常重要的。如果能做到这一点，那么你们已经展现出一个活泼、活跃和成功的社区。未来将会很光明。 148 | 149 | 当项目不高度依赖任何一个贡献者（至少有 3 个法律上独立的提交者，并且没有某一个公司或实体单独掌控项目的命脉）时，该项目被认为有一个多样化的社区。基本上，这意味着当一个项目主要由一个公司的贡献者组成时，这是一个不够多样化的信号。你可以通过接纳更多的外部贡献者来满足这一要求。 150 | 151 | 培养一个开放的、多样化的、精英管理的社区不可能一蹴而就，我们需要努力。请阅读[社区建设指南](http://incubator.apache.org/guides/community.html)，了解实现这一目标的指南、提示和技巧。 152 | 153 | ### 其他事宜 154 | 155 | 孵化器更多的是依靠人而不是规则：并不试图创造规则来涵盖所有情况，而是根据需要制定和编写规则。在优化流程和政策的时候，人是可信的。本指南只能记录最常见的问题，有可能还有其他需要解决的问题没有被包括在内。 156 | 157 | 不确定是否准备好毕业的孵化项目可以参考[Apache 项目成熟度模型](http://community.apache.org/apache-way/apache-project-maturity-model.html)。当你评估社区的各种细节时，你可能会发现这是个有用的指南。 158 | 159 | ## 毕业流程 160 | 161 | ### 毕业成为顶级项目 162 | 163 | 顶级项目是由董事会创建的。因此，孵化器项目管理委员会（IPMC）只能向董事会建议该项目已经准备好毕业成为顶级项目。 164 | 165 | 毕业成为顶级项目需要： 166 | 167 | - 项目的提案 168 | - 一个正向的毕业[投票](http://www.apache.org/foundation/voting.html) 169 | - 一个正向的 IPMC 建议[投票](http://www.apache.org/foundation/voting.html) 170 | - 董事会接受的[决议](http://incubator.apache.org/guides/graduation.html#tlp-resolution) 171 | 172 | 这个过程可能需要一些时间，因为它通常会在社区内引起一些讨论，也可能在 IPMC 中引起讨论。 173 | 174 | 下面是一个毕业过程的大概时间表。它应该能帮助你了解你应该什么时候开始加强你的社区，以获得及时的毕业，并使这个过程顺利进行。 175 | 176 | ![graduation-timeline-cn](https://user-images.githubusercontent.com/24643893/118795792-8be85e00-b8cd-11eb-9b23-8aae4f9438b4.png) 177 | 178 | 对于每个事件，我们都安排了一到两周的时间。即使投票通常被限制在 72 小时内，你也应该为讨论和修改提案后的重新投票做准备。 179 | 180 | ### 社区的毕业投票 181 | 182 | 成为一个顶级项目之前，社区需要有自我管理的意愿。证明这一点的一个好方法是，由社区对毕业提案自由投票。 183 | 184 | 这个投票并不是一个要求，而是建议。除非[导师](http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Mentor)和社区积极地表达他们对毕业的准备，否则 IPMC 成员不太可能投票批准毕业。明智的做法是通知[孵化器 general 邮件列表](http://incubator.apache.org/guides/lists.html#general_at_incubator.apache.org)，社区内部投票正在开始。请不要将投票抄送至孵化器 general 邮件列表，因为这样会造成混乱。相反，你可以： 转发投票邮件到孵化器 general 邮件列表，或者向孵化器 general 邮件列表发送一份不同的副本，表明毕业社区投票正在进行中。 185 | 186 | ### 准备提案 187 | 188 | 因此，在这种情况下，应该由社区在导师的建议下起草一份合适的董事会决议。提交者可以在[提交者 svn 仓库](https://svn.apache.org/repos/private/committers/board/templates/podling-tlp-resolution.txt)中访问孵化项目决议模板。你的[花名册](https://whimsy.apache.org/roster/ppmc/)也包括起草决议的功能。此外，决议还包括在董事会会议记录中，这些会议记录在[这里](http://www.apache.org/foundation/board/calendar.html)公开发布，这里包含了许多例子。 189 | 190 | 在创建这个文件时，应该参考原始提案和状态文件。项目随着时间的推移而发展，与原始提案的一些偏差很可能是可以接受的。董事会决议将对 Apache 项目范围做最终定义。因此，重要的是，它要反映出项目在毕业前夕的愿景。 191 | 192 | 一个好的决议既不能太窄也不能太宽。如果项目的范围太窄，那么其活力就会受到不必要的限制。如果一个项目的范围太广，那么它可能缺乏重点，并遭受不容易治理的困扰。 193 | 194 | 如果你阅读了这些决议，你还会发现你需要为你的项目任命一个[主席](http://www.apache.org/foundation/glossary.html#Chair)。由[PPMC](http://incubator.apache.org/guides/ppmc.html)来选择一个人在毕业后担任主席。 195 | 196 | ### 推荐投票 197 | 198 | 在开始投票之前，应在[孵化器 general 邮件列表上](mailto:general@incubator.apache.org)提出决议，以允许反馈。一旦达成共识，就应该由 PPMC 的一名成员在孵化器 general 邮件列表中开始投票，提议 IPMC 向董事会推荐该决议。 199 | 200 | ### 向董事会提交决议 201 | 202 | 顶级项目是由董事会的一项[决议](http://incubator.apache.org/guides/graduation.html#tlp-resolution)创建的。一旦决议定稿并达成共识，应提交给董事会。为了列入下一次会议的议程，该决议应在会议前至少 72 小时提交。可提供一份[会议日程](http://www.apache.org/foundation/board/calendar.html)。 203 | 204 | 董事会的事务应该通过董事会的邮件列表提交。建议使用Apache邮箱发送邮件。不建议在一个主题中混合公开的和私有的邮件列表地址。 205 | 206 | 董事会邮件列表是私有的。应该遵守 Apache 私有邮件列表的一般[网络礼仪](http://www.apache.org/foundation/how-it-works.html#management)。因此，建议只抄送孵化项目和 IPMC 的私有邮件列表（而不是孵化器 general 邮件列表）。请以适当的保密性对待回复。 207 | 208 | 提交的内容应包括： 209 | - 一个明确的主题（例如建立 Foo 顶级项目） 210 | - 一个简短的介绍 211 | - 拟议的 VP 的名字 212 | - 投票历史邮件的链接 213 | - 投票结果的摘要 214 | - [决议文本](http://incubator.apache.org/guides/graduation.html#tlp-resolution) 215 | 216 | 例如： 217 | 218 | ``` 219 | From: 220 | To: 221 | CC: <-private _at_ incubator dot apache dot org> 222 | Subject: Proposed Resolution: Establish TLP 223 | 224 | Dear Apache Board, 225 | 226 | is ready for graduation out of the incubator. So, please 227 | consider the draft resolution below at your next meeting. 228 | 229 | 230 | 231 | 232 | 233 | -- 234 | References: 235 | 236 | Home: 237 | Vote by project: 238 | Vote by incubator: 239 | 240 | Resolution draft: 241 | 242 | <> 244 | 245 | -- 246 | 247 | ``` 248 | 249 | 请尽量保持董事会邮件列表低流量。不要在列表中提醒或询问是否已经收到信息。[Apache 成员](http://www.apache.org/foundation/members.html)可以访问董事会档案，并可以查看董事会会议。如果想了解某个决议的进展情况，请询问友好的导师、Apache 成员或[董事](http://www.apache.org/foundation/board/)。 250 | 251 | ### 新顶级项目的新闻稿 252 | 253 | 一旦有了明确的共识，推荐就会水到渠成，PPMC 的成员应该联系 ASF 市场和宣传部，如果你对宣布项目毕业的正式新闻稿感兴趣，请联系 press(at)apache(dot)org。在董事会决议发布的同时，你就可以着手进行了。 254 | 255 | ## 毕业成为子项目 256 | 257 | 子项目是由项目管理委员会接受的。IPMC 将会批准孵化项目毕业为一个子项目。 258 | 259 | ### 社区的毕业投票 260 | 261 | 成为子项目是一个自愿的过程，社区应该接受该项目成为一个子项目。孵化项目的 PPMC 和提交者应该清楚新的子项目的结构，例如，谁将成为 PMC，谁将成为提交者。由于这种性质，重要的是，孵化项目要经过投票来成为一个子项目。这个投票应该发生在公开的开发者邮件列表中。 262 | 263 | ### 子项目验收投票 264 | 265 | 为了接受孵化项目为子项目的一个先决条件是，由项目[PMC](http://www.apache.org/foundation/how-it-works.html#structure)发起正式投票。有时，项目可能会觉得孵化项目的规模太大，作为一个顶级项目会更好。遇到这种情况，请联系项目的主席。 266 | 267 | ### 毕业批准投票 268 | 269 | 一旦一个顶级项目投票接受孵化项目并成为一个子项目，应通过孵化器 general 邮件列表向 IPMC 发送通知，表明孵化项目将成为一个子项目。如果在 72 小时后没有提出任何问题，那么孵化项目可以被认为成功的成为了一个子项目。同样的，如果任何 IPMC 成员提出问题，就需要进行讨论。如果问题得到解决，提出问题的人应表示收回他们的顾虑，或以其他方式表示问题已经解决。 270 | 271 | ### 最后步骤 272 | 273 | 请阅读[《孵化器资源迁出指南》](http://incubator.apache.org/guides/transferring.html) 274 | -------------------------------------------------------------------------------- /apache/incubator/cookbook-zh.md: -------------------------------------------------------------------------------- 1 | ### ASF孵化器指南 2 | 原文地址: https://incubator.apache.org/cookbook/ 3 | ## 译文版 4 | # Apache孵化器指南 5 | ## 目录 6 | [一、我们的项目适合 Apache 孵化器吗？](一、我们的项目适合Apache孵化器吗？) 7 | 8 | [二、成为ASF顶级项目的步骤是什么？](二、成为ASF顶级项目的步骤是什么？) 9 | 10 | [三、与孵化器沟通](三、与孵化器沟通) 11 | 12 | [四、寻找领路人和导师](四、寻找领路人和导师) 13 | 14 | [五、创建孵化提案](五、创建孵化提案) 15 | 16 | [六、讨论孵化提案](六、讨论孵化提案) 17 | 18 | [七、孵化提案投票](七、孵化提案投票) 19 | 20 | [八、配置基础设施](八、配置基础设施) 21 | 22 | [九、宣传和公告](九、宣传和公告) 23 | 24 | [十、导入初始代码](十、导入初始代码) 25 | 26 | [十一、社区构建](十一、社区构建) 27 | 28 | [十二、项目发布](十二、项目发布) 29 | 30 | [十三、关于项目版本发布的两轮投票](十三、关于项目版本发布的两轮投票) 31 | 32 | [十四、孵化项目与顶级项目的区别是什么？](十四、孵化项目与顶级项目的区别是什么？) 33 | 34 | [十五、毕业就绪评估](十五、毕业就绪评估) 35 | 36 | [十六、毕业讨论](十六、毕业讨论) 37 | 38 | [十七、将商标转让给ASF](十七、将商标转让给ASF) 39 | 40 | [十八、毕业投票](十八、毕业投票) 41 | 42 | [十九、ASF董事会决议](十九、ASF董事会决议) 43 | 44 | [二十、毕业后任务](二十、毕业后任务) 45 | 46 | 该指南与[孵化器主页](http://incubator.apache.org/)为大家提供了在 ASF 孵化项目所需的必要信息。该指南汇集了所有孵化器的相关问题，给出了孵化器目标和过程的概述，并提供了更多详细信息的链接。 47 | 48 | 该指南内容按照项目从被接收孵化到毕业成为顶级项目（Top-Level Project，TLP）的时间顺序进行组织。 49 | 50 | 欢迎大家通过 [general@incubator.a.o](https://lists.apache.org/list.html?general@incubator.apache.org) 邮件列表或 [INCUBATOR-234](https://issues.apache.org/jira/browse/INCUBATOR-234) 任务单对该指南提出反馈意见，也可以向该指南所在的[项目仓库](https://github.com/apache/incubator/tree/master/pages/cookbook)提交补丁。 51 | 52 | ## 一、我们的项目适合Apache孵化器吗？ 53 | 54 | 正如 ASF 在[2018年的愿景声明](https://blogs.apache.org/foundation/entry/the-apache-software-foundation-2018)中所讲的那样，ASF 为公共利益提供软件。 55 | 56 | ASF 的项目会遵循 [Apache 之道](http://www.apache.org/theapacheway/index.html)进行运转，Apache 之道是一套指导原则和最佳实践。 57 | 58 | ASF 非常重视“社区重于代码”（Community Over Code）这一理念，ASF 严格独立于公司和组织，并强调在工作各方面保持开放。 59 | 60 | 捐赠项目到ASF，意味着您将放弃对该项目以及项目商标（如果有）的控制。非常欢迎您参与该项目，但是除了成为 PMC（Project Management Committee，项目管理委员会）成员之外，您没有其他特殊的地位。好消息是，由于 ASF 的独立性和对项目可持续性的重视，您的项目可以自己成长，并可能具有更广泛的影响力。 61 | 62 | 假设您的项目符合这种观念模式，我们不会根据项目功能来判断项目的接收情况，这是由 ASF 特意不设置技术策略所决定的。如果您的项目与[ASF已有项目](https://projects.apache.org/)非常相似，我们可能会要求你考虑加入该项目。尽管如此，我们仍然有一些项目具有相似的目标，但这并不一定是一个问题。 63 | 64 | 为了给“podlings”（incubating projects，孵化项目）带来最大的成功机会，我们通常要求他们进入孵化器，并至少有一个围绕现有代码库构建的社区的开端。 65 | 66 | ## 二、成为ASF顶级项目的步骤是什么？ 67 | 68 | 孵化的目标是成为 ASF 的顶级项目。您可以通过 [How the ASF works](https://www.apache.org/foundation/how-it-works.html) 页面，了解孵化以及不同角色（提交者committers、PMC成员等）的内涵。 69 | 70 | 为此，孵化项目（incoming project，podling）需要执行以下步骤： 71 | 72 | - 寻找领路人（champion）和孵化导师（mentor），讨论并准备孵化提案； 73 | - 决定在 ASF 孵化； 74 | - 与孵化器 PMC 讨论提案； 75 | - 如果需要，完善提案中的初始提交者和导师列表； 76 | - 如果需要，基于孵化器 PMC 的反馈，完善提案； 77 | - 孵化器 PMC 对提案进行投票； 78 | - 配置项目的基础设施； 79 | - 围绕项目代码开始构建社区； 80 | - 邀请新的提交者和 PPMC 成员； 81 | - 发布项目并记录，完善代码和发布过程； 82 | - 当准备毕业时，与导师一起评估项目的就绪情况； 83 | - 准备将现有商标转让给 ASF（如果情况符合）； 84 | - 与孵化器 PMC 讨论毕业； 85 | - 孵化器 PMC 开始毕业投票，这会使 ASF 董事会决议建立 TLP。 86 | 87 | 以上描述的是乐观的情况，概述了典型的孵化流程，项目真正孵化的顺序可能会与该流程略有不同。以下是该流程的详细内容： 88 | 89 | ## 三、与孵化器沟通 90 | 91 | 孵化器PMC负责管理孵化器，帮助孵化项目完成孵化过程。 92 | 93 | 可以通过公开链接：[general@incubator.a.o](https://lists.apache.org/list.html?general@incubator.apache.org)访问邮件列表，与孵化器PMC进行沟通。 94 | 95 | ## 四、寻找领路人和导师 96 | 97 | 为了进入孵化器，您的项目需要一名领路人（只有 Apache officer 或 member 可以做领路人）和至少2-3名导师。这些人还需要是孵化器PMC中的成员，ASF 成员只需提出即可加入孵化器PMC。（孵化过程涉及的各角色及其职责请参见 [Roles and Responsibilities](http://incubator.apache.org/guides/roles_and_responsibilities.html)） 98 | 99 | 领路人负责在创建提案过程中帮助孵化项目，他们在前面的步骤中（至少直到项目提案被接收）充当孵化项目与孵化器PMC之间的联络员，之后可能会继续担任导师。 100 | 101 | 导师则会在项目成长为顶级项目的道路上全程陪伴。 102 | 103 | 起点通常是寻找领路人，您可以在 [general@incubator.a.o](https://lists.apache.org/list.html?general@incubator.apache.org)邮件列表中提交项目的简短介绍，附上相关链接，并说明您正在寻找领路人，努力引起大家的兴趣。如果您认识任何ASF成员或孵化导师，可以直接询问他们是否愿意提供帮助。 104 | 105 | ## 五、创建孵化提案 106 | 107 | 领路人会帮助项目准备孵化提案，提案会对新项目进行描述，以便后续与孵化器 PMC 进行初步讨论。 108 | 109 | 提案需要包含若干标准段落，详情请参考 [podling proposal template](https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal). 110 | 111 | ASF 项目的孵化提案都保存在 [Incubator wiki](https://cwiki.apache.org/confluence/display/INCUBATOR/Proposals)页面上，可以将它们作为示例进行参考，上一自然段中的链接给出的是方案的最新模板。 112 | 113 | ## 六、讨论孵化提案 114 | 115 | 提案准备好后，项目代表需将其发送至 [general@incubator.a.o](https://lists.apache.org/list.html?general@incubator.apache.org)进行讨论，主题行应如下，以引起孵化器PMC的注意。 116 | 117 | `[DISCUSS] Foo Proposal` 118 | 119 | 该讨论通常会要求提案进行一些改动。 120 | 121 | 该讨论阶段没有规定讨论时长，通常会持续几天，直到所有关注问题都被妥善讨论并形成解决方案。 122 | 123 | 以下是最近的讨论，请参考： 124 | 125 | - [Nuttx proposal](https://lists.apache.org/thread.html/7ed194c45460a3941ae6713b20e742ec7af398c5414de7b17d188c3b@) (in progress) 126 | - [StreamPipes proposal](https://lists.apache.org/thread.html/1cf79ef65888f695b4b925fd67ef8a2b845f6b0931c251a0ff1115e1@) (accepted) 127 | - [Sparkr proposal](https://lists.apache.org/thread.html/ff9874f5353d319152f09aa9c1aa1a673b84acdaeb9932432d58d5ab@) (withdrawn) 128 | - [TubeMQ proposal](https://lists.apache.org/thread.html/21c5453b40765cf1d5a06540fcf6d76c0d5b6b7df7ade5c29d31aa3e@) (accpeted) 129 | - [MetaObjects proposal](https://lists.apache.org/thread.html/dbdbc6bd8e238d9dbf16604d5fa13500523d6e812fcd863444f99842@) (on hold) 130 | 131 | ## 七、孵化提案投票 132 | 133 | 讨论阶段一结束，领路人或项目代表就会在 [general@incubator.a.o](https://lists.apache.org/list.html?general@incubator.apache.org) 邮件列表中创建 [VOTE] 帖子。 134 | 135 | 投票过程依据 [ASF 投票规则](https://www.apache.org/foundation/voting)进行。简言之，投票发生在孵化器邮件列表中，持续至少72小时，由孵化器 PMC 成员进行投票，遵循多数投票法，也欢迎其他人进行投票。 136 | 137 | ## 八、配置基础设施 138 | 139 | 孵化器PMC投票决定创建该项目后，就可以为其配置基础设施。 140 | 141 | 通常，领路人或孵化导师会推动这一过程。但是，如果项目社区成员知道如何进行操作的话，也可以由社区成员推动这一过程。 142 | 143 | 详情请参考[Infra and the Incubator](https://infra.apache.org/infra-incubator.html)。 144 | 145 | ## 九、宣传和公告 146 | 147 | 在孵化器 PMC 接收该项目之前，项目不能发布有关加入 ASF 的新闻稿或其他公开声明。 148 | 149 | 关于项目如何为自己做广告方面也有一些限制，特别是在孵化项目的新闻稿方面。[Incubator Branding Guide](http://incubator.apache.org/guides/branding.html) 和 [Apache Podling Publicity/Media Guidelines](https://incubator.apache.org/guides/publicity.html) 页面对项目宣传规则有更详细的解读。 150 | 151 | ## 十、导入初始代码 152 | 153 | 项目需遵循特定流程将代码捐赠给 ASF，该流程基于[软件授权协议](https://www.apache.org/licenses/software-grant.txt)和/或[CCLA](https://www.apache.org/licenses/cla-corporate.txt)。 154 | 155 | 关于初始代码导入的更多信息，请参考 [Initial Code Import](http://incubator.apache.org/guides/transitioning_asf.html)。 156 | 157 | ## 十一、社区构建 158 | 159 | 在孵化过程中，项目有望构建并扩大其社区，包括投票选拔新的提交者和 PPMC 成员。 160 | 161 | 候选者的讨论和投票过程都发生在项目的私有 PPMC 邮件列表中，这是该邮件列表为数不多的功能之一，因为通常所有的讨论都是公开的。 162 | 163 | 扩大社区，特别是重建项目社区是 ASF 治理的重要组成部分，因为社区可以提升项目的持续性。 164 | 165 | ## 十二、项目发布 166 | 167 | 在项目孵化过程中，我们期待项目可以**发布多个软件版本**，这些版本会朝着完全符合 [ASF 发布政策](http://www.apache.org/legal/release-policy.html)的方向逐渐发展。版本发布完全符合 ASF 发布政策是项目毕业的条件之一。 168 | 169 | 按照[孵化器发布指南](https://incubator.apache.org/guides/releasemanagement.html#choice_of_disclaimers)要求，项目发布版本时，任何发布文件名中必须包含“incubating”一词，并且必须要包含DISCLAIMER或DISCLAIMER-WIP免责声明，以避免混淆项目状态。由于孵化项目还不是真正的ASF项目，设置适当的期望值很重要。 170 | 171 | 请注意Apache版本发布仅包含源代码。为了给用户提供方便，项目通常也会一同分发[编译过的软件包](http://www.apache.org/legal/release-policy.html#compiled-packages)。但重点仍是实际发布的源码，所有分发的编译过的软件包都是基于这些正式发布的源码。 172 | 173 | ## 十三、关于项目版本发布的两轮投票 174 | 175 | 项目版本发布的投票分为两个阶段： 176 | 177 | - 首先，在开发人员邮件列表（dev list）上对版本发布进行投票，该轮投票主要是为了让项目社区练习和学习版本发布的投票过程。只要PPMC成员给出至少三张赞成票（+1），并且赞成票多于反对票（-1），就算投票通过。 178 | 179 | - 如果第一次投票通过，则孵化器PMC在孵化器常规邮件列表上进行第二轮投票，与所有ASF版本发布一样，这是使投票成为基金会行为的规定动作。 180 | 181 | 在孵化器 PMC 的[VOTE]消息中，需明确将第一轮开发人员邮件列表中的投票情况报告给孵化器 PMC，包括投票结果，以及指向项目投票记录的 [lists.apache.org] (http://lists.apache.org/)链接。这样，导师和其他孵化器 PMC 成员的投票将与孵化器 PMC 投票绑定，而不用投两次票。 182 | 183 | 项目和孵化器的投票都要遵循 [ASF 投票规则](https://www.apache.org/foundation/voting)：多数投票法；投票过程持续至少72小时；如果有人多次投票，以最后一次投票为准。 184 | 185 | ## 十四、孵化项目与顶级项目的区别是什么？ 186 | 187 | 顶级项目是成熟的 ASF 项目，由自己的 [PMC](http://www.apache.org/foundation/governance/pmcs) 进行管理，并且向 [ASF 董事会](https://www.apache.org/foundation/board/)进行报告。 188 | 189 | 孵化项目是正在训练中的顶级项目。它们所做的大部分工作与顶级项目相同，特别是它们在孵化过程中的工作。 190 | 191 | 主要的区别如下： 192 | 193 | - 和 PMC 相反，孵化项目不能代表 ASF 做出正式决定，因为他们不是 ASF 架构的正式组成部分（比如，孵化项目没有在[ASF章程](https://www.apache.org/foundation/bylaws)中被提及）。这意味着孵化器PMC需要扮演孵化项目代理人的角色，使项目的操作（比如 ASF 发布）正式化，并使其成为[基金会的行为](https://blogs.apache.org/foundation/entry/success-at-apache-the-apache1)。 194 | - 孵化项目会有一个 PPMC（Podling Project Management Committee），像顶级项目 PMC 一样进行运转，但需要将一些事情委托给孵化器 PMC 执行，比如 ASF 版本发布的最终投票权。 195 | - 提交者、PPMC 成员的选拔与顶级项目中的做法类似。孵化项目可以直接选拔候选人进入 PPMC，也可以先将候选人选为提交者，之后再将他们提为 PPMC 成员。提交者没有正式的决策权，所以通常采用“两步走”的流程，但这不是必需的。详情请参阅[How the ASF works](https://www.apache.org/foundation/how-it-works.html)。 196 | - 顶级项目向 [ASF 董事会](https://www.apache.org/foundation/board/reporting)进行报告，而孵化项目向[孵化器 PMC](https://cwiki.apache.org/confluence/display/INCUBATOR/Reports)进行报告。两种汇报最初都是每月一次，之后是每季度一次。 197 | - 每个顶级项目都有一个 [PMC 主席](https://apache.org/dev/pmc.html)，PMC 主席是顶级项目与董事会间的联络人。PMC 主席不是项目的领导者，而是一个管理角色，即使他们在ASF组织架构中拥有VP（Vice President）的头衔。孵化项目中没有孵化导师的角色，导师是社区成员中的志愿者，在项目和孵化器 PMC 间充当联络员。 198 | - 孵化项目的版本发布需要两轮投票。 199 | 200 | ASF强烈鼓励项目有规律地成长，并更新社区的名单（提交者、PMC、PPMC），以促进项目可持续发展。孵化项目和顶级项目都应该留意社区中活跃的成员，积极选拔新的提交者和PMC成员。 201 | 202 | ## 十五、毕业就绪评估 203 | 204 | 当项目社区准备毕业时，应该先对就绪情况进行自评估。 205 | 206 | ASF社区发展PMC（Community Development PMC）维护的[成熟度模型](https://community.apache.org/apache-way/apache-project-maturity-model.html)为此提供了一个很好的模板，可以帮助发现项目在孵化中忽略的事情。成熟度模型页面给出了项目毕业的案例。 207 | 208 | ## 十六、毕业讨论 209 | 210 | 基于就绪情况的自评估，当社区和导师认为项目已经准备好毕业了，导师或PPMC成员要在孵化器常规邮件列表中创建一个[DISCUSS]帖子，提议毕业并请求孵化器PMC审查项目。 211 | 212 | 讨论中最好包含毕业提案，为接下来的投票做好准备。 213 | 214 | ## 十七、将商标转让给 ASF 215 | 216 | 捐赠项目给ASF的个人或组织如果持有项目必需的商标，则需在项目毕业前将其转让给ASF。 217 | 218 | ## 十八、毕业投票 219 | 220 | 毕业提案讨论结束后，导师或 PPMC 成员在孵化器常规邮件列表中创建一个[VOTE]帖子，孵化器 PMC 在该进程上对是否向董事会推荐项目进行投票。 221 | 222 | 该投票遵循标准的 [ASF 投票规则](https://www.apache.org/foundation/voting)，即多数投票法，持续至少72小时，如果重复投票，以最后一次投票为准。 223 | 224 | ## 十九、ASF董事会决议 225 | 226 | 一旦孵化器PMC投票通过项目毕业，孵化器 PMC（IPMC）将会创建并向ASF董事会发送董事会决议的帖子，以供董事会进行投票。 227 | 228 | 董事会会在每月的第三个周三召开会议，并在例行会议上对此类决议进行投票。 229 | 230 | 董事会表决会立即生效，不过董事会会议的[公开会议记录](https://www.apache.org/foundation/board/calendar.html)相对较晚，但通常会在一个月之内。 231 | 232 | ## 二十、毕业后任务 233 | 234 | 项目毕业后，需要在孵化器状态页面上更新项目状态，并对其资源和流程进行一些更改。 235 | 236 | [Life after Graduation](http://incubator.apache.org/guides/transferring.html) 指南列出了相应的任务。 237 | 238 | 239 | ## 表格版 240 | **成为ASF顶级项目的步骤** 241 | 步骤 | 内容 | 详情 242 | -- | -- | -- 243 | 1 | 与孵化器沟通 | 孵化器 PMC 管理孵化器，帮助项目孵化。 244 | 2 | 寻找领路人（champion）和孵化导师，讨论并准备孵化提案 | 项目要进入孵化器，需要一个领路人（Apache officer 或 member）和至少2-3个导师(IPMC member)（孵化过程涉及的各角色及其职责请参见[Roles and Responsibilities](http://incubator.apache.org/guides/roles_and_responsibilities.html)）。 245 | 3 | 创建孵化提案 | 领路人会帮助项目准备孵化提案，该提案将用于下一步与孵化器PMC的讨论。提案可以根据模板编写，需要包含几个标准部分。 246 | 4 | 与孵化器 PMC 讨论孵化提案 | 提案准备好后，项目代表要将其发送至[general@incubator.a.o](https://lists.apache.org/list.html?general@incubator.apache.org)邮件列表，孵化器 PMC 会对该方案进行讨论。 247 | 5 | 如有需要，完善提案中初始提交者和导师列表 | - 248 | 6 | 如有需要，基于孵化器 PMC 的反馈完善提案 | - 249 | 7 | 孵化器PMC对提案进行投票 | 讨论阶段结束后，领路人或项目代表会在[general@incubator.a.o](https://lists.apache.org/list.html?general@incubator.apache.org)邮件列表中创建【投票】帖，投票按照ASF的投票规则进行。 250 | 8 | 配置该项目的基础设施（JIRA等） | 如果孵化器 PMC 同意接受该项目，就可建立该项目的基础设施了，该过程通常由领路人或导师进行推动，如果社区成员熟悉该操作，也可由社区成员来推动。 251 | 9 | 导入初始代码 | 企业捐赠的项目，在导入初始代码前，需要提交软件授权协议（SGA）或企业贡献者许可协议（CCLA）；个人捐赠的项目，在导入初始代码前，需要主要贡献者提交个人贡献者许可协议（ICLA）或SGA。导入过程中，需要检查和报告代码中受美国出口管制法管制的密码技术。除此以外，代码以及二进制发行版还需要按照Apache License合规要求，进行清理。 252 | 10 | 围绕该项目代码构建社区 | 包括投票产生新的提交者和 PPMC 成员（Podling Project Management Committee）。 253 | 11 | 发布项目，记录并完善发布过程 | 在孵化期间，预计将发布多个版本，这些版本将逐渐符合ASF发布政策。 **完全合规的发布是项目毕业的条件之一。** 孵化中的项目进行发布还必须在任何发布文件名中包含 “incubating” 一词，并根据孵化器发布指南包含免责声明或免责声明-WIP，以防止对项目状态产生任何混淆。由于孵化中的项目还不是“真正的”ASF项目，所以设定正确的期望值是很重要的。 孵化中的项目版本发布需要两次投票，一次是在开发者邮件列表上进行的投票，如果PPMC成员中至少有3个赞成票（+1），并且赞成票比反对票（-1）多就算通过了。第二次是在孵化器常规邮件列表上进行的投票，这次投票由孵化器PMC进行投票。 Apache 发布仅包含源代码，但是项目通常也会分发一些编译过的软件包。软件源代码发布是发布重点，所有分发的编译过的软件包均基于这些发布的“正式”的源代码。 254 | 12 | 准备毕业，与导师一起评估项目的就绪情况 | 准备毕业的项目需要根据 ASF 提供的[成熟度模型](https://community.apache.org/apache-way/apache-project-maturity-model.html)进行自我评估，这可以帮助发现在孵化过程中被忽略的事务。 255 | 13 | 将商标转让给 ASF | 将代码捐赠给 ASF 的企业或个人，如果持有该项目需要的商标，则需在项目毕业前，将商标转让给ASF。 256 | 14 | 与孵化器 PMC 讨论毕业 | 项目毕业需要 PPMC 先进行投票以达成共识，如果社区和导师根据自我评估认为项目已经做好准备，可以毕业，会在孵化器常规邮件列表上创建一个【讨论】帖，提议毕业并请求孵化器PMC审查该项目。 257 | 15 | 孵化器PMC进行毕业投票 | 毕业提议的【讨论】进程结束后，导师或 PPMC 成员会在孵化器常规邮件列表上创建一个【投票】贴，孵化器 PMC 对该项目进行投票，投票依据 ASF 投票规则进行。 258 | 16 | ASF 董事会决议 | 孵化器投票通过后，将会创建董事会决议的帖子并发送给 ASF 董事会，供董事会投票。董事会每月第三个周三会召开会议，会上会对此类决议进行投票，投票结果即刻生效。 259 | 17 | 毕业后的任务 | 毕业后，项目需要在孵化器状态页面上更新状态，并对其资源和流程进行一些更改。项目毕业后，将由新组建的 PMC 定期向董事会进行报告，最初三个月每月一次，之后是每季度一次。毕业后的项目如果发展停滞，将进入 Attic，即归档退休。关于项目毕业后资源转移的步骤及 Attic 的详细内容，之后会一一奉上，敬请期待。 260 | -------------------------------------------------------------------------------- /apache/license/ASF CLA FAQ.md: -------------------------------------------------------------------------------- 1 | # ASF CLA FAQ 2 | 3 | 本页回答了我们收到的有关贡献协议的常见问题。 4 | 5 | * 其他许可问题，请参阅我们的[许可常见问题]( https://www.apache.org/foundation/license-faq.html)。 6 | * 非许可问题，请参阅我们的[一般常见问题]( https://www.apache.org/foundation/faq)。 7 | 8 | # 关于 ASF 贡献协议的常见问题 9 | 1. [我是否可以为个人目的再使用（和修改）《ASF 贡献者许可协议》(CLAs)？](###我是否可以为个人目的再使用（和修改）《ASF贡献者许可协议》(CLAs)？) 10 | 11 | 2. [向 ASF 授予的专利许可范围有多大？](###向ASF授予的专利许可范围有多大？) 12 | 13 | 3. [贡献者的雇主是否必须签署 CCLA？](###贡献者的雇主是否必须签署CCLA？) 14 | 15 | 4. [我没有打印机。我该如何“打印、签名、扫描并通过电子邮件发送”许可文件？](###我没有打印机。我该如何“打印、签名、扫描并通过电子邮件发送”许可文件？) 16 | 17 | 5. [我要如何上传我的公钥？](###我要如何上传我的公钥？) 18 | 19 | 如果以上都不能解决您的问题，请查看[本页底部的资源](##其他浏览地址)，了解一般性信息。 20 | 21 | ## 回答 22 | 23 | ### 我是否可以为个人目的再使用（和修改）《ASF 贡献者许可协议》(CLAs)？ 24 | 是的，您可以再使用和修改它们。但是，如果这些文件不完全符合您的预期，您不能要求 ASF 承担法律责任。我们建议您自行获取法律意见，以便清楚地了解您自己会面临的问题。 25 | 26 | 如果您的确为个人目的改写了这些协议，请确保“Apache 软件基金会”以及任何令人混淆的、专门指代 Apache 组织的类似用语或其部分，不会在您的协议版本中出现（除非您是为说明您的版本是衍生自且不同于 ASF 提供的原始版本）。 27 | 28 | ### 向 ASF 授予的专利许可范围有多大？ 29 | 本问题包含四个部分： 30 | 31 | **问题1**：如果我拥有一项专利并向某一“作品”作出了贡献，而在我的贡献被纳入该“作品”之时，我的专利中没有任何权利要求落入 Apache 的“专利许可授予”范围内，那么任何这些权利要求是否有可能仅因其他方（该方并非该专利的被许可方）随后作出的贡献而落入“专利许可授予”范围内？ 32 | 33 | **回答1**：不会的。 34 | 35 | **问题2**：如果在我作出贡献之后的任何时候，我能够许可其他的专利权利要求，而这些权利要求假如在我贡献之时即可由我许可，当时就会落入 Apache “专利许可授予”条款的范围内，那么这些（在我作出贡献之后持有的）其他权利要求是否受“专利许可授予”条款之约束？ 36 | 37 | **回答2**：是的。 38 | 39 | **问题3**：如果我拥有或控制一项可许可的专利，并为某一特定的 Apache 产品贡献代码，我的哪些专利权利要求会落入 Apache 的“专利许可授予”条款的约束范围内？ 40 | 41 | **回答3**：许可给 ASF 的专利权利要求，仅限于您拥有或者有权许可的专利权利要求，且该些权利要求系在您贡献之时，从您的贡献或从您的贡献与您所贡献的该特定 Apache 产品的组合中，可以解读出的权利要求。您的贡献与任何其他软件后续的组合，不会导致您作出额外的专利权利要求许可。但是，请注意，可许可的专利权利要求包括您将来获得专利权的权利要求，只要在当初贡献时您的贡献落入这些专利权利要求的范围。一旦一项专利权利要求落入 Apache 的“专利许可授予”条款的约束范围内，那么该专利权利要求将根据“专利许可授予”条款，许可给 ASF 以及 ASF 分发的任何软件的接收者，以用于任何 Apache 软件产品。 42 | 43 | **问题4**：什么是 Apache 产品？ 44 | 45 | **回答4**：Apache 产品指的是 ASF 开发的、计划修改并作为独立发行版予以发布的一套软件。 46 | 47 | ### 贡献者的雇主是否必须签署 CCLA？ 48 | 仅限于他们的雇佣情形要求必须签署 CCLA，才需要签署。具体内容请参见 ICLA 第 4 条。 49 | 50 | 提交者(Committer)必须签署 ICLA。他们以个人名义声明他们有权许可其贡献的代码。依据其雇主的所有权权益、可适用的各州和各国法律，以及其雇佣合同和业务政策的具体内容来审查提交者的 ICLA，就能发现他们是否可以就其所参与的特定项目中的任何特定提交作出该声明。 51 | 52 | _译者注：“提交者/Committer”是由 ASF 定义的一种具有提交代码和审核已提交代码权限的角色，详情请见：https://infra.apache.org/new-committers-guide.html， 而非普通意义上的代码贡献的提交者。_ 53 | 54 | 提交者/ICLA 签署方可以将 CCLA 作为后备文件，以在相互冲突的法律、合同、政策和工作安排之间，消除所有的模糊之处。但我们从未要求必须这样做。许多提交者对他们在 ICLA 中的个人陈述很有信心，而许多其他提交者则认为，他们的公司用这份统括性文件来为他们自己的 ICLA 兜底能让他们放心。 55 | 56 | 是否有必要签署 CCLA，由 ICLA 签署方来决定，但对于许多受雇于 IT/软件行业的提交者来说这并非是个容易的决定。 57 | 58 | 最后，请参见 ICLA 第 8 条，该条款要求签署方在其身份发生变化，可能导致需要重新评估时通知基金会。 59 | 60 | ### 我没有打印机。我该如何“打印、签名、扫描并通过电子邮件发送”许可文件？ 61 | ICLA、CCLA、SGA 和“成员”的许可文件，是包含了输入表格字段的 PDF 表格。这些文件中同时还包含签名的位置，但不能以打字的方式签名。提交者可以使用 PDF 编辑器在不打印的情况下填写表格并进行签名。所需的具体步骤取决于提交者的操作系统。 62 | 63 | **MaxOSX 用户:** 64 | 1. 使用浏览器访问 [.pdf 表格](https://www.apache.org/licenses/contributor-agreements.html)，并使用另存为功能将表格下载到本地文件。 65 | 66 | 2. 使用标准 PDF 查看器/编辑器 **预览（Preview）** 打开文件。 67 | 68 | 3. 使用键盘填写表格字段。使用 **工具-注解-签名（ Tools-Annotate-Signature ）** 功能添加签名。 69 | 70 | 4. 保存填写完成的表格。 71 | 72 | 5. 打开电子邮件客户端，新建邮件，收件人为 secretary@apache.org，附上填写完成的表格并发送。 73 | 74 | 6. 保留填写完成的表格以作存档。 75 | 76 | **苹果 iOS 用户:** 77 | 78 | 1. 使用浏览器访问 [.pdf 表格](https://www.apache.org/licenses/contributor-agreements.html)，并使用 **文件（Files）** 功能下载表格。 79 | 80 | 2. 使用标准 PDF 查看器 **文件（Files）** 打开表格。 81 | 82 | 3. 使用键盘填写表格字段。使用 **签名（Signature）** 功能添加您的签名。 83 | 84 | 4. 保存填写完成的表格。 85 | 86 | 5. **分享（Share）** 文件至电子邮件客户端，将表格作为附件发送邮件给 secretary@apache.org。 87 | 88 | 6. 保留填写完成的表格以作存档。 89 | 90 | **安卓用户** 需要使用第三方工具来填写和添加签名。首先，安装一个 PDF 工具，如 **Adobe Acrobat** 。如果您不是使用 **Adobe Acrobat** ，这些说明可能会有所不同。 91 | 92 | 1. 使用浏览器访问 [.pdf 表格](https://www.apache.org/licenses/contributor-agreements.html)，并将表格下载到本地文件。该文件会默认通过 PDF 工具打开。 93 | 94 | 2. 使用键盘填写表格字段。使用 **编辑（Edit）** 功能并选择 **填写并签名（Fill & Sign）** 以添加签名。 95 | 96 | 3. 保存填写完成的表格。 97 | 98 | 4. 通过 **分享副本（Share a copy）** 功能分享文件至电子邮件客户端，将表格作为附件发送邮件给 secretary@apache.org。 99 | 100 | 5. 保留填写完成的表格以作存档。 101 | 102 | ### 我要如何上传我的公钥？ 103 | 104 | 将您的公钥上传至任意一个下列共享公钥仓中： 105 | 106 | * [Ubuntu 密钥服务器](https://keyserver.ubuntu.com/) 107 | 108 | * [OpenGPG 密钥服务器](https://keys.openpgp.org/) 109 | 110 | 111 | ## 其他浏览地址 112 | 113 | 如果您对 ASF、其项目或软件有任何疑问，我们推荐您通过以下链接获取更多信息或帮助： 114 | 115 | * 基金会的前置常见问题：[联系 Apache FAQ](https://www.apache.org/foundation/faq) 116 | 117 | 如果您有关于 Apache 许可证或 Apache 软件分发的特定问题未能在本页面获得回答，[请联系法律事务委员会](https://www.apache.org/legal/)。 118 | 119 | --- 120 | 121 | _原文地址：https://www.apache.org/licenses/cla-faq.html_ 122 | 123 | _中文翻译内容由开放原子法务与知识产权团队和 ALC 北京基于 CC-BY 4.0贡献：JesseZhou-1翻译，薛杨洁修订，姜宁、曹阳、郭雪雯审校。_ 124 | 125 | -------------------------------------------------------------------------------- /apache/license/ASF第三方许可政策.md: -------------------------------------------------------------------------------- 1 | ### 2 | 原文地址：https://www.apache.org/legal/resolved.html 3 | 4 | ## 译文版 5 | 6 | - [目的](#目的) 7 | 8 | - [许可证标准](#许可证标准) 9 | 10 | - [宏观分类](#宏观分类) 11 | 12 | - [A 类：我们能在 ASF 项目中纳入什么？](#A-类：我们能在-ASF-项目中纳入什么？) 13 | 14 | - [对于“已许可”至公共领域的作品](#对于“已许可”至公共领域的作品) 15 | 16 | - [B 类：我们或许能在 ASF 项目中纳入什么？](#B-类：我们或许能在-ASF-项目中纳入什么？) 17 | 18 | - [恰当标记的条件](#恰当标记的条件) 19 | 20 | - [仅以二进制形式纳入的条件](#仅以二进制的形式纳入的条件) 21 | 22 | - [“弱著佐权”许可证](#“弱著佐权”许可证) 23 | 24 | - [纳入知识共享署名许可下的内容](#纳入知识共享署名许可下的内容) 25 | 26 | - [在知识共享署名-相同方式共享下所许可的未经修改的媒体内容](#在知识共享署名-相同方式共享下所许可的未经修改的媒体内容) 27 | 28 | - [我能从 Stack Overflow 复制代码并将其贡献给 ASF 项目吗？](#我可以从-Stack-Overflow-复制代码并将其贡献给-ASF-项目吗) 29 | 30 | - [Doug Lea 并发库](#Doug-Lea-并发库) 31 | 32 | - [将 OSGi 元数据添加到弱著佐权许可下的二进制文件中](#将-OSGi-元数据添加到弱著佐权许可下的二进制文件中) 33 | 34 | - [Cobertura 报告](#Cobertura-报告) 35 | 36 | - [对于禁止修改的许可证](#对于禁止修改的许可证) 37 | 38 | - [在 ASF 产品中纳入构建工具](#在-ASF-产品中纳入构建工具) 39 | 40 | - [在创建动态加载的 XS 模组时纳入 Perl 许可的头文件](#在创建动态加载的-XS-模组时纳入-Perl-许可的头文件) 41 | 42 | - [纳入 Doxygen 生成的配置文件](#纳入-Doxygen-生成的配置文件) 43 | 44 | - [Apache 项目能够包含基于 Ruby 许可作品的外部依赖吗？](#Apache-项目能够包含基于-Ruby-许可作品的外部依赖吗？) 45 | 46 | - [X 类：我们不能在 ASF 项目中纳入什么？](#X-类：我我们不能在-ASF-项目中纳入什么？) 47 | 48 | - [它们不能被分发](#它们不能被分发) 49 | 50 | - [当它们支持可选功能时，您可以依赖它们](#当它们支持可选功能时，您可以依赖它们) 51 | 52 | - [常见问题](#常见问题)： 53 | 54 | - [Apache 产品在什么平台运行重要吗？](#Apache-产品在什么平台运行重要吗？) 55 | 56 | - [库依赖是否必须进行知识产权审查？](#库依赖是否必须进行知识产权审查？) 57 | 58 | - [当有许可证可供选择时，我应该如何管理作品？](#当有许可证可供选择时，我应该如何管理作品？) 59 | 60 | - [什么是必要的第三方声明？](#什么是必要的第三方声明？) 61 | 62 | ## 目的 63 | 64 | 本政策向 Apache 软件基金会的项目提供许可指引，列出了第三方开源组件纳入 Apache 软件基金会产品时可接受的许可证。 65 | 66 | 项目可将许可问题提交给法务委员会 JIRA space。 67 | 68 | #### 许可证标准 69 | 70 | 下列标准作为本页许可证分类指引。 71 | 72 | - 1、许可证必须符合[开源定义](https://opensource.org/osd-annotated)₁。 73 | 74 | - 2、在实践中适用的许可证不得在 Apache 2.0许可证所设限制之外再设置实质限制。 75 | 76 | ₁.（最后访问：2019-02-16） 77 | 78 | #### 宏观分类 79 | 80 | 本政策在宏观上将许可证分为三类。 81 | 82 | - **A 类**：Apache 软件基金会产品中可以纳入 A 类许可证。它们可称之为“类 Apache”的许可证。 83 | 84 | - **B 类**：Apache 软件基金会产品在特定条件下可以纳入 B 类许可证。该类许可证“有可能”被纳入。 85 | 86 | - **X 类**：Apache 软件基金会产品中不得纳入 X 类许可证。 87 | 88 | ## A 类：我们能在 ASF 项目中纳入什么？ 89 | 90 | 从可否纳入 Apache 软件基金会产品的角度考虑，我们认为以下许可证与 Apache 2.0许可证条款类似： 91 | 92 | - [Apache 许可证2.0](http://apache.org/licenses/LICENSE-2.0) 93 | 94 | - [Apache 软件许可证1.1](http://apache.org/licenses/LICENSE-1.1)，包括其变体： 95 | 96 | - [PHP 许可证3.01](http://www.php.net/license/3_01.txt) 97 | 98 | - [MX4J 许可证](http://mx4j.sourceforge.net/docs/ch01s06.html) 99 | 100 | - BSD（不含广告条款）- 包括其变体： 101 | 102 | - [BSD 2条](http://opensource.org/licenses/bsd-license.php) 103 | 104 | - [BSD 3条](https://opensource.org/licenses/BSD-3-Clause) 105 | 106 | - [DOM4J 许可证](http://dom4j.sourceforge.net/dom4j-1.6.1/license.html) 107 | 108 | - [PostgreSQL 许可证](https://opensource.org/licenses/postgresql) 109 | 110 | - [Eclipse 分发许可证1.0](http://www.eclipse.org/org/documents/edl-v10.php) 111 | 112 | - [Lawrence Berkeley 国家实验室 BSD](https://spdx.org/licenses/BSD-3-Clause-LBNL.html) 113 | 114 | - [MIT / X11](https://opensource.org/licenses/mit-license.php) 115 | 116 | - [ISC](https://opensource.org/licenses/ISC) 117 | 118 | - [新泽西州标准 ML](https://www.smlnj.org/license.html) 119 | 120 | - [杯形语法分析器生成器](http://www2.cs.tum.edu/projects/cup/licence.php) 121 | 122 | - [ICU](http://source.icu-project.org/repos/icu/icu/trunk/LICENSE) 123 | 124 | - [伊利诺伊大学/ NCSA](https://opensource.org/licenses/UoI-NCSA.php) 125 | 126 | - [W3C 软件许可证](https://opensource.org/licenses/W3C.php) 127 | 128 | - [W3C 社区贡献者许可协议](https://www.w3.org/community/about/agreements/cla/)-在发布至少45天后适用 129 | 130 | - [X.Net](https://opensource.org/licenses/xnet.php) 131 | 132 | - [zlib/libpng](https://opensource.org/licenses/zlib-license.php) 133 | 134 | - FSF autoconf 许可证 135 | 136 | - [DejaVu 字体（Bitstream Vera / Arev 许可证）](https://dejavu-fonts.org/) 137 | 138 | - [学术自由许可证3.0](https://opensource.org/licenses/afl-3.0.php) 139 | 140 | - [服务+组件+架构+技术规范](http://web.archive.org/web/20080704184203/http://www.osoa.org/xmlns/sca/1.0/license.txt) 141 | 142 | - OOXML XSD ECMA 许可证 143 | 144 | - [Microsoft 公共许可证（MsPL）](https://opensource.org/licenses/ms-pl.html) 145 | 146 | - [知识共享仅版权贡献](https://creativecommons.org/licenses/publicdomain/deed.zh) 147 | 148 | - [Python 软件基金会许可证](http://www.opensource.org/licenses/PythonSoftFoundation.php) 149 | 150 | - [Python Imaging 库软件许可证](https://github.com/python-pillow/Pillow/blob/master/LICENSE) 151 | 152 | - [Adobe Postcript（R）AFM 文件](https://spdx.org/licenses/APAFML.html) 153 | 154 | - [Boost 软件许可证1.0版](https://opensource.org/licenses/BSL-1.0) 155 | 156 | - [COLT 中 CERN 程序包许可证](https://dst.lbl.gov/ACSSoftware/colt/license.html)，但请注意，这**仅**适用于 COLT 中的 CERN 软件包，**不**适用于其他 157 | 158 | - [英国开放政府许可证](https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/)。该许可允许许可方提供自定义归属通知。如有，请在 NOTICE 中注明。如果没有提供，那么在 NOTICE 上注明“包含根据开放政府许可证3.0版许可的公共部门信息”。 159 | 160 | - [WTF 公共许可证](http://www.wtfpl.net/) 161 | 162 | - [浪漫 WTF 公共许可证](https://github.com/pygy/gosub/blob/master/LICENSE) 163 | 164 | - [UNICODE 公司许可协议-数据文件和软件](http://www.unicode.org/copyright.html#Exhibit1) 165 | 166 | - [Zope 公共许可证2.0](https://opensource.org/licenses/ZPL-2.0) 167 | 168 | - [ACE 许可证](http://www.cs.wustl.edu/~schmidt/ACE-copying.html) 169 | 170 | - [Oracle 通用宽松许可证（UPL）1.0版](https://oss.oracle.com/licenses/upl/) 171 | 172 | - [开放网格论坛许可证](https://www.ogf.org/ogf/doku.php/about/copyright) 173 | 174 | - [谷歌“附加知识产权授权(专利)”文件](https://chromium.googlesource.com/external/webrtc/+/master/PATENTS) 175 | 176 | - [零限制许可证](https://chromium.googlesource.com/external/webrtc/+/master/PATENTS) 177 | 178 | - [历史许可声明和免责声明](https://opensource.org/licenses/HPND) 179 | 180 | - [木兰宽松型软件许可证, 第2版](https://license.coscl.org.cn/MulanPSL2/) 181 | 182 | - [蓝橡树模型许可证1.0.0](https://blueoakcouncil.org/license/1.0.0) 183 | 184 | 此类中多个许可证都包含项目需要遵守的特定署名条款，通常是[将其添加到 NOTICE 文件中](https://www.apache.org/dev/licensing-howto.html)。请确保您在纳入这些作品时有这样做。 185 | 186 | #### 对于“已许可”至公共领域的作品 187 | 188 | 您可以将处于公共领域（或被与之具有相似效果的许可证所覆盖）的作品纳入 Apache 产品中。您必须（以与 A 类清单相似的方式）提供署名。 189 | 190 | 满足下列条件之一的作品应被视为处于公共领域： 191 | 192 | - 该作品带有 193 | 194 | - 知识共享[公共领域标识](https://creativecommons.org/publicdomain/mark/1.0/deed.zh) 195 | 196 | - 由作者提供的适当的贡献（至公共领域）声明 197 | 198 | - 有明确的证据证明该作品的美国版权 199 | 200 | - 保护期届满 201 | 202 | - 无法被主张 203 | 204 | 我们视为与公共领域具有相似效果的许可证有： 205 | 206 | - 知识共享 [CC0 “无权利保留”](https://creativecommons.org/about/cc0) 207 | 208 | - 知识共享[公共领域证明](https://creativecommons.org/licenses/publicdomain/) 209 | 210 | **请注意**某作品是否处于公共领域可能是个[疑难](http://fairuse.stanford.edu/Copyright_and_Fair_Use_Overview/chapter8/)问题。判断某作品的版权保护期是否届满可能很重要，并且在不同的司法管辖区中可能有不同的结论。如果您对某作品是否属于公共领域存疑，请在 legal-discuss@ 上或者通过 JIRA 议题来提交话题。 211 | 212 | ## B 类：我们或许能在 ASF 项目中纳入什么？ 213 | 214 | 您可以在 Apache 软件基金会产品中纳入本节所述的许可证和/或项目，前提是其满足特定条件。 215 | 216 | #### 恰当标记的条件 217 | 218 | 在所有 B 类相关情形下，其被纳入我们的产品这一事实都不应使我们的用户感到意外。如果我们能为发行版附上恰当且显著的标记，用户更有可能知道存在与 219 | Apache 许可证明显不同的限制。恰当且显著的标记是指用户在了解发行版时会读到的标记（例如在 README 文件中），且该标记应该指明第三方产品及其许可证，并且提供其主页链接。也请遵守该特定许可证中的任何署名/声明要求。 220 | 221 | #### 仅以二进制形式纳入的条件 222 | 223 | 任何 B 类许可下的作品仅得以二进制的形式纳入 Apache 软件基金会的便利二进制发行版中。不得将 B 类许可下的作品纳入源代码形式的发行版本中。 224 | 225 | #### “弱著佐权”许可证 226 | 227 | 本节中提及的每个许可证都要求某种程度的互惠性。这可能要求采取额外行动，以尽量减少 Apache 产品的用户在不了解适用要求的情况下对 Apache 产品中基于不同许可要求部分进行衍生创作的可能性。 228 | 229 | 如果您进行恰当标记（见上文），您可以在 Apache 产品中以二进制形式纳入基于以下许可证的软件： 230 | 231 | - 通用发展和分发许可证：[CDDL 1.0](https://opensource.org/licenses/CDDL-1.0)和 [CDDL 1.1](https://spdx.org/licenses/CDDL-1.1.html) 232 | 233 | - 通用公共许可证：[CPL 1.0](https://opensource.org/licenses/cpl1.0.php) 234 | 235 | - Eclipse 公共许可证：[EPL 1.0](http://www.eclipse.org/legal/epl-v10.html) 236 | 237 | - IBM 公共许可证：[IPL 1.0](http://www.opensource.org/licenses/ibmpl.php) 238 | 239 | - Mozilla 公共许可证：[MPL 1.0](https://website-archive.mozilla.org/www.mozilla.org/mpl/mpl/1.0/)，[MPL 1.1](https://www.mozilla.org/en-US/MPL/1.1/)和 [MPL 2.0](https://www.mozilla.org/en-US/MPL/2.0/) 240 | 241 | - Sun 公共许可证：[SPL 1.0](https://opensource.org/licenses/SPL-1.0) 242 | 243 | - [开放软件许可证3.0](https://opensource.org/licenses/OSL-3.0) 244 | 245 | - [Erlang 公共许可证](https://www.erlang.org/EPLICENSE) 246 | 247 | - [UnRAR 许可证](https://github.com/jukka/java-unrar/blob/master/license.txt)（仅用于解压缩） 248 | 249 | - [SIL 开放字体许可证](https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL) 250 | 251 | - [Ubuntu 字体许可版本 1.0版](https://ubuntu.com/legal/font-licence) 252 | 253 | - [IPA 字体许可协议 1.0版](https://fedoraproject.org/wiki/Licensing/IPAFontLicense) 254 | 255 | - [Ruby 许可证](https://www.ruby-lang.org/en/about/license.txt)（包括将 GPLv2 列为可选的 [Ruby 1.9.2 旧版本许可证](https://svn.ruby-lang.org/cgi-bin/viewvc.cgi/tags/v1_9_2_320/COPYING?view=markup) 256 | 257 | - Eclipse 公共许可证2.0：[EPL 2.0](https://www.eclipse.org/legal/epl-2.0/) 258 | 259 | 通过仅以目标码/二进制形式纳入，减小了基于第三方作品进行衍生创作的可能。这回应了本政策的第二个指导原则。 260 | 261 | 对于 ASF 产品在运行时直接使用的少量源代码的情况，该源代码未经修改且无论如何也不太可能被修改的（如因被某一标准所规定），您可以纳入经过适当标记的源代码。例如 web-facesconfig_1_0.dtd，纳入此代码是 JSR 127:JavaServer Faces 技术参数的强制规定。 262 | 263 | #### 纳入知识共享署名许可下的内容 264 | 265 | [知识共享署名（CC-BY）](https://creativecommons.org/licenses/by/4.0/deed.zh)许可证（第2.5、3.0和4.0版）下的作品包含与“有效技术措施”相关的条款，这可能会让用户感到意外。因此您应当对其作出恰当标记并且仅以二进制形式纳入。 266 | 267 | #### 在知识共享署名-以相同方式分享下所许可的未经修改的媒体内容 268 | 269 | 您可以在 Apache 产品中纳入在[知识共享署名-以相同方式共享2.5版](https://creativecommons.org/licenses/by-sa/2.5/deed.zh)、[知识共享署名-以相同方式共享3.0版](https://creativecommons.org/licenses/by-sa/3.0/deed.zh)和[知识共享署名-以相同方式共享4.0版](https://creativecommons.org/licenses/by-sa/4.0/deed.zh)下许可的未经修改的媒体内容，只要您遵守许可证中的署名条款，这可能要求对 LICENSE/NOTICE/README 作出修改。如果涉及其他类型知识共享-以相同方式分享许可证下许可的作品，请联系 Legal PMC。 270 | 271 | 请注意，媒体内容是指在我们的文档中使用的二进制视觉/视频/音频元素。我们无意将其纳入源代码中。 272 | 273 | #### 我能从 Stack Overflow 复制代码并将其贡献给 ASF 项目吗？ 274 | 275 | 不能，除非您联系原作者并从其处获得在 Apache 项目中根据 Apache 2.0许可证使用其代码的权利。 276 | 277 | #### Doug Lea 并发库 278 | 279 | Doug Lea 并发库属于公共领域，但其中包含的某些 Sun 文件不属于公共领域。您可以按类似上述“弱著佐权”列表资源的纳入方式将该库纳入 ASF 产品中。“如果进行恰当标记，可以将其以二进制形式纳入 Apache 产品中”。如果要使用源代码，则请移除 Sun 许可给 Doug 的文件，并将其按 A 类处理（或者从 [Harmony](http://svn.apache.org/repos/asf/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/) 获取文件）。 280 | 281 | #### 将 OSGi 元数据添加到弱著佐权许可下的二进制文件中 282 | 283 | 您可将 OSGi 元数据插入“B 类”许可下的 Jar 文件中，只要您在对 Jar 文件的显著标记中说明您这样做了。 284 | 285 | #### Cobertura 报告 286 | 287 | 您可以将 Cobertura 报告纳入 ASF 发行版中。 288 | 289 | #### 对于禁止修改的许可证 290 | 291 | 有些许可证对**未经修改**的副本的再分发赋予了广泛的权利。此类许可证不是开源的，但它们确实满足上述第二条和第三条指导原则。 292 | 293 | Apache 项目不得在版本控制或发布的源码包中包含此类许可证下许可的材料。但在构建过程中自动下载诸如字体和标准化数据之类的非软件材料，并将它们纳入生成的二进制文件中的情况是允许的。此种使用方式明确表明，这些依赖不是该项目开源代码的一部分。 294 | 295 | 如上所述，您可以使用基于下列许可证许可的材料： 296 | 297 | - [用于 PDF CJK 字体的 CMaps](https://www.adobe.com/devnet/font.html#pcfi) 298 | 299 | - JCR API jar 文件（[Day Spec 许可证](http://www.day.com/maven/jsr170/licenses/day-spec-license.htm)+[附加许可](http://www.day.com/maven/jsr170/jars/LICENSE.txt)） 300 | 301 | - [WSDL（2004）schema 文件许可证](https://issues.apache.org/jira/browse/LEGAL-385) 302 | 303 | #### 在 ASF 产品中纳入构建工具 304 | 305 | 许多语言已经发展出相关工具的生态，这些工具帮助构建发行版的构件。鉴于这些工具可能并不总在其他兼容许可证下可得，我们已经批准了允许纳入 Apache 产品发行版的特定工具，以便其用于该特定目的。 306 | 307 | 请注意，该工具不得影响项目源代码的许可。我们也期望使用该工具构建源代码也是该工具的典型用途。 308 | 309 | 截至目前，我们已经为此类用途批准下列工具： 310 | 311 | - Autotools 产品族，特别是： 312 | - [Autoconf](http://www.gnu.org/software/autoconf/) 313 | - [Automake](http://www.gnu.org/software/automake/) 314 | - [Libtool](http://www.gnu.org/software/libtool/) 315 | - [mkinstalldirs.sh](http://www.gnu.org/software/hello/manual/gettext/mkinstalldirs.html) 316 | - [OCamlMakefile](http://hg.ocaml.info/release/ocaml-make/) 317 | - [setup.rb](https://i.loveruby.net/en/projects/setup/) 318 | 319 | #### 在创建动态加载的 XS 模组时纳入 Perl 许可的头文件 320 | 321 | 对链接已编译的 C 语言代码以创建动态加载的 XS 模组的 Perl 绑定程序进行开发，需要纳入 Perl 许可证（http://dev.perl.org/licenses/- GPL-any/Artistic1, 包含例外）下许可的头文件。 322 | 323 | 您可以纳入这些头文件—— XSUB.h, perl.h 和 EXTERN.h (参见：[LEGAL-79](https://issues.apache.org/jira/browse/LEGAL-79))。 324 | 325 | #### 纳入 Doxygen 生成的配置文件 326 | 327 | 您可以使用这些文件，只要您移除了生成的注释。 328 | 329 | #### Apache 项目能够包含基于 Ruby 许可作品的外部依赖吗？ 330 | 331 | 一个主要且明显使用 Ruby 编写的项目可以依赖于 Matz's Ruby Interpreter (MRI)，也可以依赖于任何 [Ruby 许可证](http://www.ruby-lang.org/en/LICENSE.txt)许可的 Gem。 332 | 333 | 当然，依赖于其他许可证（如 MIT）下编写的其他 Gem 可能也可以，这取决于具体的许可证。 334 | 335 | 还请注意，Ruby 许可证是被列在上述用于二进制形式的“B 类”弱著佐权列表中（例如 JRuby）。 336 | 337 | #### 从 Java 9开始，Javadoc 允许纳入搜索功能，该功能包含在其他开源许可证下许可的 JavaScript。Apache 项目可以包含Javadoc 吗? 338 | 339 | 从 Java 9开始，Javadoc 可以包含在 MIT、MIT OR GPL-3.0或 GPL-2.0 WITH classpath Exception-2.0下许可的 JavaScript。Apache 二进制发行版本（包括 Maven javadoc jar）和 Apache 网站可能会因使用 javadoc 而包含这个 JavaScript。但其不得包含在源代码发行版本中。 340 | 341 | ## X 类：我们不能在 ASF 项目中纳入什么？ 342 | 343 | 您**不得**在 Apache 产品中包含下列许可证： 344 | 345 | - 不符合“开源定义”： 346 | 347 | - 二进制码许可证（BCL） 348 | 349 | - 英特尔简化软件许可证 350 | 351 | - [JSR-275许可证](https://software.intel.com/content/www/us/en/develop/articles/end-user-license-agreement.html#inpage-nav-3) 352 | 353 | - 对使用领域有限制： 354 | 355 | - [微软限制公共许可证](https://www.openhub.net/licenses/mslpl) 356 | 357 | - [亚马逊软件许可证（ASL）](https://aws.amazon.com/cn/asl/) 358 | 359 | - [Satori RTM 的 Java SDK 许可证](https://aws.amazon.com/cn/asl/) 360 | 361 | - [Redis 可用源代码许可证（RSAL）](https://redislabs.com/legal/licenses/) 362 | 363 | - [Booz Allen 公共许可证](http://boozallen.github.io/licenses/bapl) 364 | 365 | - [Confluent 社区许可证 1.0版](https://www.confluent.io/confluent-community-license/) 366 | 367 | - [商业源代码许可证 1.1](https://spdx.org/licenses/BUSL-1.1.html) 368 | 369 | - 任何包含[共享条款许可条件 1.0版的许可证](https://commonsclause.com/) 370 | 371 | - 非商业许可证： 372 | 373 | - [知识共享非商用](https://en.wikipedia.org/wiki/Creative_Commons_license#Non-commercial_licenses)变体 374 | 375 | - [Sun 社区源代码许可证3.0](http://jcp.org/aboutJava/communityprocess/SCSL3.0.rtf) 376 | 377 | - 对更大的作品施加限制： 378 | 379 | - [GNU GPL 1,2,3](http://www.opensource.org/licenses/gpl-license.php) 380 | 381 | - 本页其他部分明确允许的 GNU GPL 的特殊例外(例如 GNU Classpath)。 382 | 383 | - [GNU Affero GPL 3](http://www.opensource.org/licenses/agpl-v3.html) 384 | 385 | - [GNU LGPL 2,2.1,3](http://www.opensource.org/licenses/lgpl-license.php) 386 | 387 | - [QPL](https://opensource.org/licenses/QPL-1.0) 388 | 389 | - [Sleepycat 许可证](http://www.opensource.org/licenses/sleepycat.php) 390 | 391 | - [服务器端公共许可证（SSPL）第1版](https://www.mongodb.com/licensing/server-side-public-license) 392 | 393 | - [代码项目开放许可证（CPOL）](http://www.codeproject.com/info/cpol10.aspx) 394 | 395 | - 其他关切： 396 | 397 | - [BSD-4条款](https://spdx.org/licenses/BSD-4-Clause.html) / [BSD-4条款（加州大学专用）](https://spdx.org/licenses/BSD-4-Clause-UC.html) 398 | 399 | - [Facebook BSD + 专利许可证](https://code.facebook.com/pages/850928938376556) 400 | 401 | - [NPL1.0](https://spdx.org/licenses/NPL-1.0.html) / [NPL1.1](https://spdx.org/licenses/NPL-1.1.html) 402 | 403 | - 荒唐的许可证： 404 | 405 | - The Solipsistic Eclipse 公共许可证 406 | 407 | - [“不要做个鸟人”公共许可证](https://dbad-license.org/) 408 | 409 | - [JSON 许可证](http://www.json.org/license.html) 410 | 411 | “其他关切”的详细说明： 412 | 413 | **Facebook BSD + 专利许可证** 414 | 415 | Facebook BSD + 专利许可证中包含一份 PATENTS 文件的详细说明，以有利于许可方而非被许可方的方式将风险转嫁给我们软件的下游消费者，因而违反了 Apache 法律政策关于[普适性捐赠者](http://www.apache.org/legal/ramblings.html#head-62def7ee9e2cb64eb757533133a99da472b1e88a)的要求。Facebook BSD + 专利许可证的条款内容并非 ALv2 条款的一个子集，它们也不能像 ALv2 那样进行分许可。 416 | 417 | **NPL** 418 | 419 | Netscape 公共许可证是 Mozilla 原始许可证，包含针对 Netscape 适用的修订内容。这些修订内容允许 “Netscape”（现在是 AOL 的一部分）无需遵守其他被许可方所必须遵守的互惠性要求。这使得该许可证不符合开源定义第5条（“不歧视个人或团体”）。 420 | 421 | **荒唐的许可证** 422 | 423 | 这些许可证尽管对其创作者来说很有趣味，但从法律上看存在问题。它们通常包含一些主观的使用领域限制，例如“不要作恶”，却没有给出确定该主观限制的定义。在某些情形中，它们甚至可能没有给出符合 OSI 开源定义的充分授权。我们不希望让我们的下游消费者感到意外，所以我们禁止使用这样的许可证。 424 | 425 | **JSON 许可证** 426 | 427 | 从2016年11月3日起，JSON license 被归到“X 类”许可证列表中。在此之前，是允许使用 [Json Java 库](https://github.com/stleary/JSON-java)。请参阅 Debian 的页面获得[替代选择列表](https://wiki.debian.org/qa.debian.org/jsonevil)。 428 | 429 | #### 它们不能被分发 430 | 431 | Apache 项目不得在 ASF 源代码版本或便利二进制版本中分发 X 类许可证下许可的组件，不论该组件是源码形式还是二进制形式。与有关平台的问题一样，如果组件适用的许可证条款不影响 Apache 产品的许可，您可以依赖该组件。例如，在构建过程中使用 GPL 下许可的工具是可以的，但是不可以纳入 GPL 下许可的源代码。 432 | 433 | #### 当它们支持可选功能时，您可以依赖它们 434 | 435 | Apache 项目可以依赖于在禁止类许可证下许可的组件，如果该组件在可选功能上。在这样做时，项目应向用户说明如何获取和安装不包含该组件的作品。可选就意味着该组件不是产品标准使用或产品达到理想质量水平所必需的。在这种情况下，您需要问自己的问题是: 436 | 437 | - “大多数用户是否希望使用我未添加可选组件的产品？” 438 | 439 | ## 常见问题： 440 | 441 | #### Apache 产品在什么平台运行重要吗？ 442 | 443 | 不重要，除非该平台的条款影响到 Apache 产品的许可。例如，创建一个在 Windows 或 Java 上运行的产品、创建一个使用网络服务（如 Google Services 或 Yahoo Search）的产品、或是创建一个产品（如 JBoss 或 JIRA）的插件都是可以的，而创建一个 Linux 内核模块则不行，因为 Apache 产品本身在这种情况下将不得不以 Apache 许可证第2.0版之外的其他许可证进行许可。 444 | 445 | 请注意，这并不意味着您可以重新分发平台代码本身。这当然地取决于所述代码的许可证。如果您对平台的许可证是否会影响到 Apache 代码有任何疑问，请查阅 legal-discuss@ 邮件列表归档看是否之前存在此类问题，如果没有，请给 legal-discuss@ 发送邮件以解决您的疑问。 446 | 447 | #### 库依赖是否必须进行知识产权审查？ 448 | 449 | 不用。 450 | 451 | [知识产权审查](https://incubator.apache.org/ip-clearance/index.html)适用于从 Apache 之外导入代码库以在 Apache 进一步开发的情形。 452 | 453 | #### 当有许可证可供选择时，我应该如何管理作品？ 454 | 455 | 在纳入作品许可证时，请说明您所用的许可证，并只纳入您所选的许可证。优先选择 A 类，其次是 B 类，再次是 X 类。如果（比如说）作品在源代码头部已提及有多种许可证可选，则您不必修改作品本身。 456 | 457 | #### 什么是必要的第三方声明？ 458 | 459 | 当一个发行版包含第三方作品时，覆盖这些作品的许可证可能会要求您以特定的方式告知消费者。这些第三方声明因许可证而异。Apache 发行版应当包含每个许可证的副本，这些副本通常包含在 LICENSE 文档中。对于很多许可证来说，这种声明方式足以满足声明要求。某些许可证要求某些额外声明。在很多情况下，您可以在所依赖的该构件中包含此声明。 460 | 461 | 一个必要的第三方声明是指上述情况以外的任何第三方声明。 462 | 463 | 当发行版包含另一个 Apache 产品时，请参阅[绑定其他 ASF 产品](https://infra.apache.org/licensing-howto.html#bundle-asf-product)，获得所需声明的指引。 464 | 465 | --- 466 | 467 | *Chinese translation contributed under CC-BY 4.0 by ALC Beijing and OpenAtom Legal & IP Team: translated by missing-9，modified by Vanessa Guo and Hazel Xue, and reviewed by Willem Jiang and Lotus Wang.中文翻译内容由 ALC 北京和开放原子法务与知识产权团队基于 CC-BY 4.0贡献：missing-9翻译，郭雪雯、薛杨洁修改，姜宁、王荷舒审校* 468 | -------------------------------------------------------------------------------- /apache/license/ASF许可证常见问题.md: -------------------------------------------------------------------------------- 1 | 本页回答了我们收到的大多数关于我们的许可证、软件的许可以及软件的打包或再分发的常见问题。对于非许可问题，请参见我们的[一般常见问题]( http://www.apache.org/foundation/preFAQ.html)。 2 | 3 | # 关于 APACHE 许可的常见问题 4 | 5 | 1. [我在哪里可以找到 Apache 许可证?](#我在哪里可以找到-apache-许可证) 6 | 7 | 2. [为什么不同的 Apache 软件基金会项目的许可证文件是不同的？](#为什么不同的-apache-软件基金会项目的许可证文件是不同的) 8 | 9 | 3. [“Apache”是商标吗？](#apache是商标吗) 10 | 11 | 4. [Apache 软件基金会的软件是免费的吗？](#apache-软件基金会的软件是免费的吗) 12 | 13 | 5. [各种 Apache 软件包的美国出口管制分类号码(ECCNs)是什么？](#各种-apache-软件包的美国出口管制分类号码eccns是什么) 14 | 15 | 6. [我可以用 Apache 许可证授权我自己的软件吗？](#我可以用-apache-许可证授权我自己的软件吗) 16 | 17 | 7. [我应该如何将 Apache 许可证应用到我自己的软件中？](#我应该如何将-apache-许可证应用到我自己的软件中) 18 | 19 | 8. [我可以为自己的目的重复使用（和修改）ASF 贡献者许可协议（CLA）吗？](#我可以为自己的目的重新使用和修改asf-贡献者许可协议cla吗) 20 | 21 | 9. [我可以重新使用（和修改）Apache 许可证2.0本身吗？](#我可以重新使用和修改apache-许可证20本身吗) 22 | 23 | 10. [我对 APACHE 代码进行了改进，我可以发布修改后的结果吗？](#我对-apache-代码进行了改进我可以发布修改后的结果吗) 24 | 25 | 11. [我可以把我修改后的代码称为"Apache"吗？](#我可以把我修改后的代码称为apache吗) 26 | 27 | 12. [我对一个 Apache 包做了修改，我想发布它们。我需要把它们贡献给 Apache 软件基金会吗？](#我对一个-apache-包做了修改我想发布它们我需要把它们贡献给-apache-软件基金会吗) 28 | 29 | 13. [我可以将 Apache 许可证翻译成我当地的语言来重新发布 Apache 软件包吗？](#我可以将-apache-许可证翻译成我当地的语言来重新发布-apache-软件包吗) 30 | 31 | 14. [Apache 许可证与 GPL（GNU 公共许可证）兼容吗？](#apache-许可证与-gplgnu-公共许可证兼容吗) 32 | 33 | 15. [授予 ASF 的专利范围是什么？](#授予-asf-的专利范围是什么) 34 | 35 | 16. [ASF 的 PMC 可以托管不属于 Apache 许可证下的项目吗？](#asf-的-pmc-可以托管不属于-apache-许可证下的项目吗) 36 | 37 | 17. [贡献者的雇主是否需要签署 CCLA？](#贡献者的雇主是否需要签署-ccla) 38 | 39 | 18. [什么是 ASF 源代码的证明？](#什么是-asf-源代码的证明) 40 | 41 | 如果以上都不能解决您的问题，请查看[本页底部的资源](#其他地址以供参考)来获得一般信息。 42 | 43 | # 回答 44 | 以下是对上述问题的详细解答。 45 | 46 | # 我在哪里可以找到 APACHE 许可证？ 47 | 您可以在这里找到 Apache License 2.0 (当前版本)。 48 | * Apache License 2.0: [http://www.apache.org/licenses/LICENSE-2.0.txt]( http://www.apache.org/licenses/LICENSE-2.0.txt) 49 | 这是我们不再使用的两个旧版本。 50 | * Apache 软件许可证 1.1：[http://www.apache.org/licenses/LICENSE-1.1.txt](http://www.apache.org/licenses/LICENSE-1.1.txt) 51 | * Apache Software License 1.0: [http://www.apache.org/licenses/LICENSE-1.0.txt](http://www.apache.org/licenses/LICENSE-1.0.txt) 52 | 53 | # 为什么不同的 APACHE 软件基金会项目的许可证文件是不同的？ 54 | 虽然 Apache 核心开发的代码是在 Apache 许可证下的，但其他第三方作品也可能被包含在内，它们的许可证文本可能已经被添加到 Apache 项目的 LICENSE 或 NOTICE 文件中。另外，它们也可能是单独存在的。 55 | 56 | # “APACHE”是商标吗？ 57 | “Apache”、"Apache 软件基金会"（“Apache Software Foundation”）、多色羽毛以及各种 Apache 项目名称和标识都是 Apache 软件基金会在美国和其他国家的注册商标或商标。请参阅我们的[商标政策]( http://www.apache.org/foundation/marks/)了解如何使用 Apache 项目商标的细节，或参考我们的[商标资源网站地图]( http://www.apache.org/foundation/marks/resources)。 58 | 59 | # APACHE 软件基金会的软件是免费的吗？ 60 | 是免费的。由 Apache 软件基金会**所有**项目开发的**所有**软件都可以从基金会的网站上免费获得。这在基金会的[公司章程](http://www.apache.org/foundation/records/incorporator.html)中已经明确规定，并详细解释了[为什么我们的软件总是免费的]( http://www.apache.org/free/)（不收费）。 61 | 62 | 无论软件的使用情况如何，都是如此。我们在软件的使用上不区分个人、内部或商业用途，也不收取任何费用。但要提醒您的是，[我们的许可证]( http://www.apache.org/foundation/license-faq.html#License)条款始终适用。 63 | 64 | # 各种 APACHE 软件包的美国出口管制分类号码(ECCNs)是什么？？ 65 | 请参阅[ASF出口分类和来源链接页面]( http://www.apache.org/licenses/exports/)。 66 | 67 | # 我可以用 APACHE 许可证授权我自己的软件吗？ 68 | 当然可以。2.0 版本的许可证被设计为可重复使用，并经常在ASF以外的其他方重复使用。 69 | 70 | # 我应该如何将 APACHE 许可证应用到我自己的软件中？ 71 | 您应该在您的作品中包含一份 Apache 许可证的副本，通常是在一个叫做 LICENSE 的文件中，并且考虑也包含一个 NOTICE 文件。 72 | 73 | 给您的每一个源代码文件打上标签也是很重要的，这样能以防它们从 LICENSE 文件中脱离。要将 Apache 许可证应用到您的源代码文件中，一种方法是在文件的顶部附加以下模板通知作为注释。您应该用您自己的识别信息来替换 Copyright 模板。 74 | 75 | > Copyright [yyyy] [版权人姓名] 76 | > 77 | >Licensed under the Apache License, Version 2.0 (the "License"); 78 | >you may not use this file except in compliance with the License. 79 | >You may obtain a copy of the License at 80 | > 81 | >https://www.apache.org/licenses/LICENSE-2.0 82 | > 83 | >Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, 84 | >WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 85 | >See the License for the specific language governing permissions and limitations under the License. 86 | 87 | 您可能希望使用的一个较短的变体是: 88 | 89 | > Copyright [yyyy] [版权人姓名] 90 | > SPDX-License-Identifier。Apache-2.0 91 | 92 | 请注意，Apache 软件基金会使用了一个不同的源码头，这与我们使用的 CLA 有关。我们项目的源码头说明在[这里]( https://www.apache.org/legal/src-headers.html#headers)。 93 | 94 | # 我可以为自己的目的重新使用（和修改）ASF 贡献者许可协议（CLA）吗？ 95 | 是的，您可以重复使用和修改它们。只是如果这些文件与您的意图不符，您不能要求ASF承担法律责任。我们建议您获得您自己的法律建议，以便您清楚地知道您自己在做什么。 96 | 97 | 如果您为了您的目的而修改这些协议，您必须确保 "Apache软件基金会 "的短语或任何令人困惑的类似参考资料或特别提到Apache组织的部分不会出现在您的协议版本中（除了要标明您的版本是由ASF提供的原始版本衍生出来，并且与之不同的）。 98 | 99 | # 我可以重新使用（和修改）APACHE 许可证2.0本身吗？ 100 | 是的，您可以重新使用和修改它。如果本文件（无论是否修改）与您的意图不符，您显然不能要求 ASF 承担法律责任。我们建议您获得自己的法律意见，这样您就会清楚地知道自己在做什么。 101 | 102 | 如果您为了您的目的而修改协议，您必须确保 "Apache 许可证"、"Apache"、或任何令人困惑的类似参考资料或特别提到 Apache 组织的部分**不会出现**在您的许可证版本中（除了要标明您的版本是由ASF提供的原始版本衍生出来，并且与之不同的）。 103 | 104 | # 我对 APACHE 代码进行了改进，我可以发布修改后的结果吗？ 105 | 当然可以。不过要遵守[Apache 许可证的条款]( http://www.apache.org/licenses/LICENSE-2.0#redistribution)。您可以免费提供您的修改后的代码，或者卖掉它，或者自己保留它，或者任何您喜欢的。只要记住，原始代码仍然受 Apache 许可证的保护，您必须遵守它的条款。即使您改变了您所使用的 Apache 代码的每一行，结果仍然是基于基金会的授权代码。您可以在不同的许可证下发布结果，但您必须承认使用了基金会的软件。否则将构成偷窃。 106 | 107 | 如果您认为您的修改会对其他人有用，我们鼓励您把它们提交给合适的 Apache 项目，以便于被收录。 108 | 109 | # 我可以把我修改后的代码称为"APACHE"吗？ 110 | 简而言之，**不可以**。但是，您可以使用诸如 "基于 Apache"、"由 Apache 驱动"或 "基于 Apache 技术 "这样的措辞。您**绝对不得**以任何方式使用基金会的标志来表示和暗示，或可能被理解为表示和暗示最终产品是由Apache软件基金会认可或创建的。例如，使用 "SuperWonderServer 由 Apache 技术驱动"这样的名称是可以接受的，但绝对不能使用 "Apache SuperWonderServer "这样的名称。这类似于产品命名为 "Microsoft Burp "和 "Burp for Microsoft Windows "之间的区别。 111 | 112 | 同样，您也可以识别您正在使用的特定基金会项目的代码，例如 "基于 Apache Xerces "或 "由 Apache Tomcat技术驱动"。 113 | 114 | 如果您想使用包含基金会标志的名称，比如 "Apache"，最好先征得我们的同意。请参阅我们的[商标政策](http://www.apache.org/foundation/foundation/marks/)以了解更多细节。 115 | 116 | # 我对一个 Apache 包做了修改，我想发布它们。我需要把它们贡献给 Apache 软件基金会吗？ 117 | 不需要。如果您愿意，您可以为您的修改保密。也许您的修改差强人意，也许您会通过出售这些改进而大赚一笔。这都无所谓。但请您务必考虑把您的改动分享出来！当您这样做时，我们都会受益。 118 | 119 | # 我可以将 APACHE 许可证翻译成我当地的语言来重新发布 APACHE 软件包吗？ 120 | 是的，您可以将许可证文本翻译成您当地的语言。**但是**，任何此类翻译文本只是为了方便理解，并不具有法律约束力。只有英文版本的许可证（您必须继续将其包含在您的包装中）才具有权威性，并在需要法律解释时适用。 121 | 122 | # Apache 许可证与 GPL（GNU 公共许可证）兼容吗？ 123 | 来自[自由软件基金会]( http://www.fsf.org/licensing/licenses/#SoftwareLicenses)网站。 124 | 125 | > ## [Apache许可证，2.0 版]( http://www.apache.org/licenses/LICENSE-2.0) 126 | > 127 | > ### 这是一个自由软件许可证，与 GPL 的第 3 版兼容。请注意，这个许可证与 GPL 第 2 版不兼容，因为它有一些旧版本中没有的要求。这些要求包括某些专利终止和赔偿条款。 128 | 129 | # 授予 ASF 的专利范围是什么？ 130 | 这是一个分为四部分的问题。 131 | 132 | **Q1**: 如果我拥有一项专利，并为一项著作做出了贡献，而当我的贡献被包含在该作品中时，我的任何一项专利权的要求都不受Apache的专利授权许可的约束，那么这些权利要求是否有可能仅仅因为其他专利的非持有者的后续贡献而受专利授权许可的约束。 133 | 134 | **A1**: 不存在。 135 | 136 | **Q2**: 在我贡献后的任何时候，如果我能够许可其他本可能受专利授权许可的约束的专利权的要求，而这些权利在我贡献时是我有权许可的，那么这些权利要求是否会成为专利授权许可的对象？ 137 | 138 | **A2**: 是的。 139 | 140 | **Q3**: 如果我拥有或控制一项可授权的专利，并为特定的 Apache 产品贡献了代码，那么我的哪些专利要求是受Apache的专利授权许可约束的？ 141 | 142 | **A3**: 唯一被许可给 ASF 的专利权利要求是那些您拥有的或有权许可的专利权利要求，这些专利权利要求在您的贡献上或在您的贡献与您所贡献的特定 Apache 产品的组合上被读取，因为它在您的贡献时已经存在。您的贡献与任何其他软件的后续组合不会导致额外的专利要求被授权。但是，请注意，可授权的专利权利要求包括那些您在未来获得的专利权利要求，只要这些专利权利要求在您最初的贡献中被读作您最初提出的。一旦一项专利申请受到Apache专利授权许可的约束，它就会根据该授权条款被许可给 ASF 和 ASF 为任何 Apache 软件产品发布的任何软件的接受者。 143 | 144 | **Q4**: 什么是 Apache 产品？ 145 | 146 | **A4**: Apache 产品是指由ASF开发的，且ASF计划更改并作为一个单独的发布系列发布的软件主体。 147 | 148 | # ASF 的 PMC 可以托管不属于 APACHE 许可证下的项目吗？ 149 | 不可以。如果您是ASF PMC，并遇到这样的特殊情况，请创建一个 JIRA 问题。 150 | 151 | # 贡献者的雇主是否需要签署 CCLA？ 152 | 只有当他们的就业情况需要签署 CCLA 时才需要。详见 ICLA 第 4 节。 153 | 154 | 提交者（Committer）必须签署 ICLA。他们提出个人要求，即他们贡献的代码是他们自己的授权。根据雇主的所有权利益、适用的州和国家法律、雇佣合同的具体内容和商业政策来审查 ICLA，展现了他们可以或不可以对任何特定项目的任何特定承诺做出这种声明。 155 | 156 | CCLA 是一份备份文件，提交者/ICLA 签署者可以用它来消除所有这些相互冲突的法律、合同、政策和工作分配之间的模糊性。我们从来没有要求过它，许多提交者对他们在 ICLA 协议下的个人代表很有信心，还有许多其他提交者发现他们的公司已经用这个保护伞文件来支持他们自己的 ICLA，这使他们感到自己获得了保障。 157 | 158 | 这份协议是否必需是由ICLA签署者自己决定的，但对于许多受雇于 IT/软件行业的提交者来说，这并不是一个轻松的决定。 159 | 160 | 最后，请参看 ICLA 的第 8 条，它要求签署人在其状态发生可能需要重新评估的变化时，通知基金会。 161 | 162 | # 什么是 ASF 源代码的证明？ 163 | Apache 资源库中的源代码（包括机器可读的文档、发布说明、指南、测试用例、运行手册和脚本）分为三种分类（仅出于讨论的目的划分）。 164 | 165 | ## 在 APACHE 管理下在 APACHE 开发的，由 APACHE 的开发者根据 CLA 协议授权给 APACHE 的，由 APACHE 分发的，以及根据 APACHE 许可协议授权给 DOWNSTREAM 用户的代码。 166 | 这代表了 Apache 的大部分代码。这些代码包含一个标准的 Apache 许可证头，它指的是发行版中的标准 Apache 许可证。 167 | 168 | ## 在其他地方开发的，根据软件授权协议授权给 APACHE 的，纳入 APACHE 项目的，由 APACHE 分发的，并根据 APACHE 许可授权给 DOWNSTREAM 用户的代码。 169 | 这是作为 Apache 项目的一部分，被带入 Apache 进行未来开发的代码。所有文件的头都被改成标准的Apache头。大多数孵化器项目都是从外部开发的代码开始的，知识产权清算过程是作为孵化的一部分来完成的。 170 | 171 | 原本在其他地方开发的，如果作为现有项目的一部分被引入 Apache 进行未来的开发，则必须在孵化器 PMC 的主持下，由接受项目的 PMC 明确地完成知识产权清算过程，而 PMC 必须批准这一过程。 172 | 173 | ## 在其他地方开发的，根据 A 类许可收到的，被纳入 APACHE 项目的，由 APACHE 分发的，并根据其原始许可授权给下流用户的代码。 174 | 这段代码保留了它的外部身份，为了方便起见，将它并入 Apache 项目，以避免引用一个内容不受项目控制的外部仓库。该代码保留了它的原始许可证；并且作为 Apache 项目的一部分发布时明确地调用了该许可证。代码保留了它原来的头，它在发行版中引用了自己的许可证。如果在 Apache 的时候对代码进行了修改，那么标准的 Apache 头就会被添加到每个修改后的文件中。此外，任何与代码相关的法律要求的声明都会在发行版中发布。 175 | 176 | # 其他地址以供参考 177 | 如果您对 Apache 软件基金会、它的项目或它的软件有任何疑问，我们推荐以下链接为您提供更多信息或帮助。 178 | 179 | * 基金会前期 FAQ。联系[Apache FAQ](http://www.apache.org/foundation/preFAQ.html) 180 | 181 | 如果您对 Apache 许可证或 Apache 软件的发布有具体的问题，而本页面没有回答，请[联系法律顾问]( https://www.apache.org/legal/)。 182 | 183 | -------------------------------------------------------------------------------- /apache/license/Apache产品发版规则.md: -------------------------------------------------------------------------------- 1 | 原文链接 ：http://www.apache.org/legal/release-policy.html 2 | 翻译：@taskmgr 3 | 校对：@JesseZhou-1，@WillemJiang 4 | 5 | 本页记录软件版本的 ASF 政策。本文档的内容针对 ASF 发版经理和 [PMC][uPMC] 成员。还提供了供 [最终用户][uend_user] 和 [分发镜像操作员][umirror] 使用的信息。 6 | 7 | 8 | 其他文档总结了该政策的 [发行过程][urelease] 和 [设计目标][udesign]。 9 | # 目录 10 | - [**发行政策**](#发行政策) 11 | - [**“发行版” 的定义**](#发行版-的定义) 12 | - [**发行版的批准**](#发行版的批准) 13 | - [**出版物**](#出版物) 14 | - [**构件**](#构件) 15 | - [**源码包**](#源码包) 16 | - [**发行签名**](#发行签名) 17 | - [**已编译的包**](#已编译的包) 18 | - [**许可证（Licensing）**](#许可证licensing) 19 | - [**许可证文档**](#许可证文档) 20 | - [**LICENSE 文件**](#license-文件) 21 | - [**NOTICE 文件**](#notice-文件) 22 | - [**许可证头**](#许可证头) 23 | - [**发行版的分发**](#发行版的分发) 24 | - [**发行存档**](#发行存档) 25 | - [**发行政策管理**](#发行政策管理) 26 | - [**TODO 事项**](#todo-事项) 27 | - [**发行常见问题**](#发行常见问题) 28 | - [**为什么我们需要一项基金会级别的政策？**](#为什么我们需要一项基金会级别的政策) 29 | - [**什么是发行版？**](#什么是发行版) 30 | - [**Apache 软件分发的类型有什么不同？**](#apache-软件分发的类型有什么不同) 31 | - [**发行管理问题**](#发行管理问题) 32 | - [**发行版到哪里去了？**](#发行版到哪里去了) 33 | - [**每个 ASF 发行版必须包含哪些内容？**](#每个-asf-发行版必须包含哪些内容) 34 | - [**ASF 对批准发行版有哪些要求？**](#asf-对批准发行版有哪些要求) 35 | - [**应该怎样发行发行版？**](#应该怎样发行发行版) 36 | - [**有最佳实践指南吗？**](#有最佳实践指南吗) 37 | - [**发行版必须在提交者控制的硬件上被构建吗？**](#发行版必须在提交者控制的硬件上被构建吗) 38 | - [**发行版分发和镜像问题**](#发行版分发和镜像问题) 39 | - [**我们在哪里可以托管测试包（每晚构建和候选发行版）？**](#我们在哪里可以托管测试包每晚构建和候选发行版) 40 | - [**我们可以在哪里托管公共（GA）发行版？**](#我们可以在哪里托管公共ga发行版) 41 | - [**发行版如何归档？**](#发行版如何归档) 42 | - [**旧的发行版应何时归档？**](#旧的发行版应何时归档) 43 | - [**如何上传发行版？**](#如何上传发行版) 44 | - [**在哪里可以发行候选版本？**](#在哪里可以发行候选版本) 45 | - [**分发某个发行版之前，我需要与基础设施进行沟通吗？**](#分发某个发行版之前我需要与基础设施进行沟通吗) 46 | - [**目录和发行版如何一一对应？**](#目录和发行版如何一一对应) 47 | - [**如何将旧版本移至存档库？**](#如何将旧版本移至存档库) 48 | - [**如何发行 Maven 构件？**](#如何发行-maven-构件) 49 | - [**发行版许可证问题**](#发行版许可证问题) 50 | - [**哪些文件必须包含 ASF 许可证文档？**](#哪些文件必须包含-asf-许可证文档) 51 | - [**所有源文件中都需要许可证的完整副本吗？**](#所有源文件中都需要许可证的完整副本吗) 52 | - [**属性声明的正确位置在哪里？**](#属性声明的正确位置在哪里) 53 | - [**NOTICE 文件适合什么内容？**](#notice-文件适合什么内容) 54 | - [**纯 ASF 代码是否需要属性文件？**](#纯-asf-代码是否需要属性文件) 55 | - [**如果文件包含多个许可证下的代码，它是否应该包含多个许可证文件？**](#如果文件包含多个许可证下的代码它是否应该包含多个许可证文件) 56 | - [**除了源代码包之外，分发其他文件还有什么要求？**](#除了源代码包之外分发其他文件还有什么要求) 57 | - [有关发行统计信息的问题](#有关发行统计信息的问题) 58 | - [有什么方法可以测量某软件包被下载了多少次吗？](#有什么方法可以测量某软件包被下载了多少次吗) 59 | 60 | 61 | ## **发行政策** 62 | ### **“发行版” 的定义** 63 | 通常，“发行版” 是指由拥有者之外（的人）发行的任何东西。对于 Apache 项目，这意味着开发社区之外的任何发行版，都会定义为参与开发者或是出现在开发人员名单上个体的个人活动。 64 | 65 | 狭义地讲，Apache 的正式发行版是被 PMC 认可为 “基金会的行为”。 66 | 67 | ### **发行版的批准** 68 | 每个 PMC 在批准任何发行时都必须遵循 ASF 的要求。 69 | 70 | 一个发行版的通过至少需要三个赞成票，并且赞成票数多于反对票数。发行版可能不会被否决。PMC 成员的投票具有约束力。 71 | 72 | 在进行 + 1 约束力投票之前，**要求**个人将所有已签名的源代码包下载到自己的硬件上，验证它们是否符合 ASF 关于发行版的政策的所有要求：验证所有加密签名，按提供的方式进行编译，然后在自己的平台上测试结果。 73 | 74 | 发行投票至少应该开放 72 小时。 75 | 76 | ### **出版物** 77 | 项目**必须**发行官方发行版本，且**不得**发行未在开发社区发行的资料。 78 | 79 | 在开发软件和准备发行版时，开发社区将出于测试目的生产多种软件包。**项目必须将其他人引导到正式版本，而不是原始源代码仓库、每夜构建版本、快照、候选发行版本或任何其他类似软件包。**唯一应该了解此类开发人员资源的人是积极参与开发或遵循开发人员列表并因此了解未发行资料所处条件的个人。 80 | 81 | ### **构件** 82 | #### **源码包** 83 | 每个 ASF 发行版**必须**包含一个或多个源代码包，只要用户能够访问适当的平台和工具，这些源代码包就足以让用户构建和测试版本。 84 | 85 | #### **发行签名** 86 | 所有提供的软件包必须由发版经理使用分离的签名进行加密签名。对发行进行 + 1 投票的人们**可以**提供自己的加密签名，并在发行之前将其与分离的签名文件连接（由发版经理决定）。 87 | 88 | #### **已编译的包** 89 | ASF 生产开源软件。所有发行版都包含修改自身所需的源代码。 90 | 91 | 为了方便那些可能没有适当工具来构建源代码的编译版本的用户，**可以**将二进制 / 字节码包与官方 Apache 发行版一起分发。在所有这些情况下，二进制 / 字节码包**必须**与源版本具有相同的版本号，并且**必须**仅添加二进制 / 字节码文件，这些文件是该版本的源代码及其依赖项的编译结果。 92 | 93 | ### **许可证（Licensing）** 94 | 每个 ASF 发行版都必须遵守 ASF 许可政策。此要求极其重要，在创建任何完整版本之前都**应当**进行审核。特别地，根据 [Apache 许可政策][apache-licensing-policy]，每个 Apache 分发的文件都必仅包含适当许可的代码。 95 | 96 | ### **许可证文档** 97 | 每个软件包必须提供一个 LICENSE 文件和一个 NOTICE 文件，这些文件说明了该软件包的确切内容。 LICENSE 并且 NOTICE**不得**提供未与包内文件绑定的不必要信息，例如单独下载的依赖项。 98 | 99 | 对于源代码包，LICENSE 并且 NOTICE 必须位于发行版的根目录。对于其他软件包，它们必须位于特定分发格式中许可证的常规位置，例如 Java “jar” 文件的 META-INF 目录。 100 | 101 | #### **LICENSE 文件** 102 | 该 LICENSE 文件必须包含 Apache License 2.0 的全文。 103 | 104 | 当软件包在多个许可证下捆绑代码时，LICENSE 文件必须包含所有这些许可证的详细信息。对于未经 Apache 许可的每个组件，必须将组件的详细信息附加到 LICENSE 文件中。组件许可证本身必须附加或存储在包中的其他位置，并带有从 LICENSE 文件指向它的指针，例如，如果许可证很长。 105 | 106 | #### **NOTICE 文件** 107 | NOTICE 文件必须符合 [Apache 许可政策][Apache-licensing-policy] 的要求。 108 | 109 | 另请参阅 Apache License 2.0 的 [4 (d) 小节][al20-4d]。 110 | 111 | #### **许可证头** 112 | 如果源文件包含由版权所有者或所有者的代理人直接向 ASF 提交的代码，该源文件必须包含正确的 [ASF 许可证头][ASF-license-header]。 113 | 114 | ### **发行版的分发** 115 | 一旦发行被批准，所有文件必须上传到规范的 Apache 发行渠道中项目的子目录内，`downloads.apache.org`。 116 | 117 | PMC 对项目分发目录负责，并且**必须**能够说明它的所有内容。目录中的所有发行文件**必须**由提交者（最好是 PMC 成员）签名。 118 | 119 | 在上传到规范的分发渠道之后，项目（或其他任何人）**可以**依照他们的许可证在其它渠道重新分发文件。 120 | 121 | #### **发行存档** 122 | 所有正式发行版都必须在 archive.apache.org 上永久存档。 123 | 124 | （上传到规范的分发渠道可满足此要求，因为存档会作为 “副作用” 自动进行。） 125 | 126 | ### **发行政策管理** 127 | 如果和任何建议或要求的政策指令有偏差，项目必须通知董事会。 128 | 129 | 更改发行政策必须得到法务部的批准。 130 | 131 | ### **TODO 事项** 132 | 正式制定其他官方政策，并从此政策中引用它们： 133 | 134 | *ASF 许可政策（由法务部门策划，适用于已发行和未发行的代码）* 135 | 136 | ## **发行常见问题** 137 | 138 | ### **为什么我们需要一项基金会级别的政策？** 139 | 140 | 在像 Apache 这样的，实行志愿者责任有限制的传统开源开发方法学的组织中，有必要将 “开发中” 和 “适合多数人群消费” 的两种公共资源区分开来。明确区分的目的是告知我们为正式参与发行的参与者提供的法律保护政策 —— 这将在下一节中进行定义。“开发中” 的资产被看作为自识别的开发者开发项目而准备的的受控分发，这些开发者通过项目开发列表来注明。此政策文档旨在涵盖不受控制的分发（也称为发行版）。 141 | 142 | 如果我们不做这种区分，而是鼓励用户直接与源代码管理或每夜构建版本进行交互，那么组织将很难向 Apache 提交者和 PMC 成员提供法律保护。因为他们在进行软件修改时仅仅凭借自己的判断就批准将这些工件按原样分发给公众，而没有参考**授权商业决定**的帮助。Apache 的大部分 “官僚主义” 和项目治理结构都是为了促进该政策的目标，因此，此文档非常值得仔细研读。 143 | 144 | 偏离本政策可能会对法律保障的有效性产生不利影响，或影响 Apache 为保护高级成员和董事而支付的保险费用，因此在未经董事会事先明确批准的情况下，强烈建议不要这样做。但请注意，在组织上我们喜欢稳健、可审查的决策胜过高效的决策。因此，如果您正在考虑提出一个供董事会考虑的替代流程，请确保您的目标反映了这一点。 145 | 146 | ### **什么是发行版？** 147 | 148 | 根据定义，发行版是拥有该发行版的组织之外发行的任何内容。对于我们来说，这包括产品开发人员名单之外任何人的任何出版物。如果公众已经可以下载软件包，则该软件包已发行。每个 PMC 在批准任何发行时都必须遵守 ASF 的要求。而如何给发行包的标注标签则是次要问题，这将在下文讨论。 149 | 150 | 在开发软件和准备发行版的过程中，开发人员可以使用各种软件包进行测试。**不要在项目网站上包含任何可能鼓励非开发人员下载和使用的每夜构建版本、快照、候选发行版本或任何其他类似软件包的链接。**唯一应该了解此类软件包的人是关注开发人员列表（或搜索其存档）的人员，因为他们了解软件包上附加的条件。如果发现公众正在下载此类测试包，请删除它们。 151 | 152 | 在任何情况下，未经批准的构建都不适合做发行版。如果这样做不太方便，那就请更频繁的发行。适当的发行管理是 Apache 软件开发的关键。 153 | 154 | Apache 软件基金会生产开源软件。所有发行版均以更改发行软件所需的原始资料的形式出现。在某些情况下，还会生成二进制 / 字节码包，便于那些可能没有适当工具来构建已编译产品的用户。在所有这些情况下，二进制 / 字节码软件包必须与源发行版具有相同的版本号，并且只能添加由该版本的源代码编译的二进制 / 字节码文件。 155 | 156 | ### **Apache 软件分发的类型有什么不同？** 157 | 158 | -**测试软件包**不是 Apache 发行版。所有发行都需要经过适当程序和官方批准。测试包用于开发过程中，并且仅应在项目开发列表上进行讨论。 159 | 160 | -**每夜构建版本**仅通过 Subversion/Git trunk/branch 构建，通常每天一次。这些软件包用于定期测试构建过程，并为自动测试人员提供用于回归测试的通用构建。它们不适合大众使用。 161 | 162 | -**发行候选版**是已经申请批准为发行版但尚未得到项目批准的软件包。这些软件包供开发人员（和关注开发讨论的用户）测试，并就该发行版与先前发行版的质量的对比意见向项目报告。在发行批准之前，可能有许多候选发行。对开发测试不感兴趣的用户应等待，直到正式批准发行。 163 | 164 | -**发行版(Releases)** 是已批准用于一般公众发行的程序包，通常伴随着不同程度的警告，包括已知的产品质量或潜在的改变。供非开发人员日常使用的发行版通常称为 “稳定版 (stable)” 或 “一般可用性（GA）” 发行版。对于另外一些发行版，它们可供项目外的测试和开发人员使用，但就功能或特性而言可能还不稳定，这些发行通常称为 “测试版 (beta)” 或 “不稳定版 (unstable)”。还有一些仅代表项目里程碑，并且仅面向在项目外部工作的前沿开发人员的发行版称为 “alpha” 版。 165 | 166 | ### **发行管理问题** 167 | #### **发行版到哪里去了？** 168 | 169 | 直到发行版位于项目的分发目录（该目录是 `downloads.apache.org` 的子目录）中，才算是被 “发行” 了。除了发行目录外，使用 Maven 或相关构建工具的项目有时还会将其发行版放在 `repository.apache.org`，和一些方便使用的二进制文件放在一起。分发目录是必需的，而存储库系统是可选的便利措施。 170 | 171 | #### **每个 ASF 发行版必须包含哪些内容？** 172 | 每个 ASF 版本**必须**包含一个源代码包，如果用户有权访问适当的平台和工具，则该源码包必须足以使用户构建和测试该版本。源代码包必须由 Release Manager 用分离的签名进行 [加密签名][cryptographically-sign]；并且源代码包及其签名必须先被测试，然后进行 + 1 进行投票来发行。对发行进行 + 1 投票的人们可以提供自己的加密签名，并在发行之前将其与分离的签名文件连接（由发版经理决定）。 173 | 174 | 注意：PMC 对其分发目录中的所有文件负责。分发目录是 `downloads.apache.org` 的子目录；放置目录中的所有构件必须由提交者（最好是 PMC 成员）签名。PMC 还必须确保源代码包足以构建与该发行版关联的任何二进制文件。 175 | 176 | 每个 ASF 版本都**必须**遵守 ASF 许可政策。此要求无比重要，并且任何完整发行版都应在创建之前被审核。特别地，分发的每个文件都必须仅包含 [适当][appropriately-][许可][licensed-] 的代码。可以在 [基金会网站][apache-index] 和 [发行许可常见问题][faq-relaese] 中找到更多信息。 177 | 178 | #### **ASF 对批准发行版有哪些要求？** 179 | 投票决定是否准备好发行软件包，请使用 [少数服从多数][MajorityApproval]。即，至少三个 PMC 成员必须投肯定票，并且肯定票要多于否定票。发行可能不会被否决。在 PMC 成员进行 + 1 投票之前，他们必须下载签名的源代码包并按原样进行编译。之后在他们自己的平台上测试生成的可执行文件，并还要验证该包是否符合 ASF 发行政策的要求。 180 | 181 | #### **应该怎样发行发行版？** 182 | 请确保您在上传新版本后至少等待 24 小时，然后再更新项目下载页面并发送公告电子邮件。这样一来，镜像服务器就有足够的时间同步。（对于时间紧迫的安全修复版本，下载页面脚本支持 [绕过][bypass-24h] 此要求。） 183 | 184 | 告知人们新版本的可用性很重要。公告必须包含指向源的相关下载页面的链接。至少，应该向所有适当的邮件列表发送电子邮件来宣布此消息。为此，许多顶级项目都有公告列表。还有一个适用于 [ASF 内][asf-wide] 的公告列表。 185 | 186 | 请注意，如果不使用 “apache.org” 邮件地址，则无法在 [ASF 内][asf-wide] 进行公告。另外，请确保已经放置了 3-5 行的项目简介。（因为大多数订阅了 announce.AT.apache.DOT.org 列表的用户通常不知道什么是 XX 项目） 187 | 188 | 建议将 SHA-1 OpenPGP 兼容的签名添加到公告邮件中。请确保您的公钥已经上传到知名度较高的 pgp 网站（例如 http://pgp.mit.edu/）。该密钥应该给发行版签名过，或是被给发行版签名过的密钥交叉签名过。 189 | 190 | #### **有最佳实践指南吗？** 191 | 请参阅 [孵化器发布管理指南（草稿）][incubator-relaese-draft]。或者，请参阅任何已建立的 Apache 项目的 “如何发行” 开发人员文档。（该文章的作者对 [这个指南][best-practice] 比较熟悉，这来自他的项目。） 192 | 193 | #### **发行版必须在提交者控制的硬件上被构建吗？** 194 | 严格来说，发行必须在提交者控制的硬件上进行 [验证][verify-build]。这意味着提交者在物理上拥有硬件、硬件控制权、以及完全的管理 / 超级用户访问权限。因为只有这样的硬件才有资格持有 PGP 私钥。并且应该在私钥所在的计算机上验证发行版是否可信。 195 | 196 | 实际上，当发行包含源代码控制标签的存档文件（例如 tarball 或 zip 文件）之外的任何内容时，验证该存档的唯一实用方法是在本地构建该存档。手动检查生成的文件（尤其是二进制文件）是不可行的。因此，基本上可以说，这个问题的答案是 “是”。 197 | 198 | * 注意：此回答是指用于从源代码控制标签产生发行构建的过程。它不是指测试该文件的技术质量。* 199 | 200 | ### **发行版分发和镜像问题** 201 | 202 | #### **我们在哪里可以托管测试包（每晚构建和候选发行版）？** 203 | 204 | 测试程序包仅供经同意的开发人员和感兴趣的社区成员使用，因此不应将其托管或链接到面向终端用户的页面。它们不应该被镜像；只有获准的 GA 版本应该被镜像。 205 | 206 | 项目应使用存储库的 [`dist` 仓库的 `dev` 目录][dist-dev] 或者 `repository.apache.org` 的暂存功能来托管候选发行版本，以供开发人员测试 / 投票（在将要潜在或正式获准发行 GA 版本之前）。 207 | 208 | 不是候选版本的每夜构建可以在 [ci.apache.org 项目区域](https://ci.apache.org/projects) 托管，只需提交 INFRA 票即可。 209 | 210 | #### **我们可以在哪里托管公共（GA）发行版？** 211 | 目前必须通过 ASF 镜像系统来提供发行版。请将文件放在 `https://downloads.apache.org/` 下。（请参阅 [如何上载版本？][upload-release]）。 212 | 213 | 项目下载页面必须链接到镜像而非 Apache 主站。更多详细信息请参考 [创建下载页面的说明][create-download-page]。这些网站的软件文档必须包含指向源下载页面的链接。 214 | 215 | 项目网站（`http://{project}.apache.org`），VM（`http://{project}.zones.apache.org` 和 `http://{project}-vm.apache.org`）和源代码控制存储库（`svn.apache.org` 和 Git 存储库）不得用于分发发行版 —— 也就是说，不应从其中下载发行版。 216 | 217 | #### **发行版如何归档？** 218 | 219 | 所有发行版本都必须归档在 [http://archive.apache.org/dist/](http://archive.apache.org/dist/) 上。 220 | 221 | 在发行首次出现在 [https://downloads.apache.org/](https://downloads.apache.org/) 大约一天后，自动化流程会将发行添加到存档中。一旦发行版被放在 [https://downloads.apache.org/](https://downloads.apache.org/) 后，发行版会被自动复制到 [http://archive.apache.org/dist/](http://archive.apache.org/dist/)。即使将其从 [https://downloads.apache.org/](https://downloads.apache.org/) 中删除，发行文件也会被永久保存。 222 | 223 | 如果您有（旧版？）从未存档的发行版，请要求基础设施将其复制到 `http://archive.apache.org/dist/`。 224 | 225 | #### **旧的发行版应何时归档？** 226 | `downloads.apache.org` 应该包含 * 正在开发的每个分支中的最新版本 *。当版本的分支不再开发时，应从项目的下载目录中删除该分支的发行版。 227 | 228 | （如果项目使用 svnpubsub，则通过从中以下目录中删除文件来完成此操作 `https://dist.apache.org/repos/dist/release//`。） 229 | 230 | 例如，如果 Apache Foo 1.2.x 是与 Foo 1.1.a 相同但更新一些的版本，则应在发行 1.2.x 时删除 1.1.a。请注意，所有版本都会自动存档，请参阅 [如何将旧版本移至存档][old-version-to-archives]。 231 | 232 | 如果 Apache Foo 1.2 是一个新的分支，并且 Foo 1.1.a 将继续并行开发，那么可以从 `/dist` 同时提供 1.1.a 和 1.2.x 的发行版。 233 | 234 | #### **如何上传发行版？** 235 | 可以将发行版压缩打包文件提交到 `https://dist.apache.org/repos/dist/release/` 存储库下相应的子目录中（即 TLP 名称）来完成上传。我们的同步过程将在 15 分钟内将文件推送到 [主镜像站点][master-mirror]。不过，仍然需要 24 小时等待镜像（因为 [镜像使用每天 1/N 的重同步][1/n-rsync] 来保持和 dist / 目录的同步）。 236 | 237 | 存储库目录 `https://dist.apache.org/repos/dist/release//` 仅适用于**正式发行版**，即 PMC 已批准的存档（+ 签名，哈希）。因此，**默认情况下，只有 PMC 成员才能更新 dist/release 目录树。** 238 | 239 | 如果发版经理不是 PMC 成员，他们将需要请 PMC 成员来完成实际的发行版发布工作。 240 | 241 | PMC 还可以投票让非 PMC 成员更新 dist/release 区域。要进行此设置，请在 [INFRA JIRA][INFRA-JIRA] 上打开一个引用 PMC 投票的工单。 242 | 243 | #### **在哪里可以发行候选版本？** 244 | 还有一个开发区域在 `https://dist.apache.org/repos/dist/dev//`，可用于开发目的的发行版本。例如，快照和候选版本可以存储在这里。需要注意的一个重要事项是，该目录不会通过 svnpubsub 发行到镜像中。它旨在充当正式发行前的准备发行目录。 245 | 246 | 项目上的所有提交者都可以写入该项目的 dist/dev 区域。 247 | 248 | 如果用于候选版本，则在成功投票后，可以将适当的文件从 dev/ 目录移动到 release/ 目录中以进行发行。 249 | 250 | 将邮件提交到 `dist/` 存储库将转到常规项目邮件列表。 251 | 252 | #### **分发某个发行版之前，我需要与基础设施进行沟通吗？** 253 | 如前两个问题所述，大多数项目只能分发发行版。但是，可能会使镜像和下载资源紧张的发行版**必须**与基础结构协调。 254 | 255 | 发行超过 1GB 的文件需要提前了解基础架构。 256 | 257 | 来自其他 dist 政策的特定豁免（例如，可以 / 必须 / 禁止通过镜像分发的内容）也必须与基础架构进行协调。 258 | 259 | #### **目录和发行版如何一一对应？** 260 | | 类型 | 地址 | 261 | |:-----:|:------:| 262 | | 每晚构建 | ci.apache.org/projects | 263 | | 最新发行 | downloads.apache.org | 264 | | 旧版本 | archive.apache.org/dist | 265 | 266 | #### **如何将旧版本移至存档库？** 267 | `downloads.apache.org` 上的内容会自动存档。因此，存档中将已经存在一个正式发行版的副本。要将发行版移至存档，只需删除项目 dist 目录中的副本即可。记住要更新下载页面上的所有链接。 268 | 269 | #### **如何发行 Maven 构件？** 270 | 请参阅 [Maven 发行指南][maven-publish]。 271 | 272 | ### **发行版许可证问题** 273 | 请阅读 [使用 Apache 许可证，2.0 版][use-apache-license-v2]，并查看 [Apache 许可证][Apache-License] 和 [Apache 法律信息][apache-legal] 页面以获取当前信息。 274 | 275 | #### **哪些文件必须包含 ASF 许可证文档？** 276 | 每个源文件都必须包含适当的 ASF 许可证文档。 277 | 278 | #### **所有源文件中都需要许可证的完整副本吗？** 279 | 简而言之，每个发行版仅需要一份许可证副本。完整的许可证文件应放在名为 LICENSE 的文件里，该文件应当位于发行版根目录下。对于由 ASF 开发的软件，每个源文件仅需包含 [范例声明][boilerplate]。 280 | 281 | #### **属性声明的正确位置在哪里？** 282 | 新许可证允许包含此类属性声明（包括 Apache 属性声明）的 NOTICE 文件。阅读 [这里](http://apache.org/legal/src-headers.html#notice)。 283 | 284 | 现有源文件中包含的所有属性声明都应移入文件中。NOTICE 文件必须和 LICENSE 文件一同打包在发行版内。 285 | 286 | 确保在创建的任何新 NOTICE 文件中都包含标准的 ASF 属性通知。 287 | 288 | #### **NOTICE 文件适合什么内容？** 289 | 阅读 [这里](http://apache.org/legal/src-headers.html#notice)。 290 | 291 | 只有产品许可证强制性要求的信息才需要放在这里。不适合放常规文档。 292 | 293 | #### **纯 ASF 代码是否需要属性文件？** 294 | 是！NOTICE 文件必须包含标准的 ASF 属性，如下所示： 295 | 296 | This product includes software developed at 297 | The Apache Software Foundation (http://www.apache.org/). 298 | 299 | 注意：不幸的是，此文档在 2013-01-30（r1440650）之前的版本不正确，因为它们使用了短语：“developed by”(由 xx 开发) 而不是 “developed at”(在 xx 开发)。正式措辞在 2006 年 5 月 24 日的董事会会议记录第 6C 节中确定。 300 | 301 | #### **如果文件包含多个许可证下的代码，它是否应该包含多个许可证文件？** 302 | 当文件包含多个许可证下的代码时，LICENSE 文件应包含所有这些许可证的详细信息。对于非 Apache 许可证的每个组件，应将组件的详细信息附加到 LICENSE 文件中。组件许可证本身可以被附加在文件后，或者存储在构建的其它地方，并在 LICENSE 文件中用指针指向它。例如，如果许可证文本太长。 303 | 304 | [这里](https://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE) 305 | 是一个附加许可证的示例。 306 | 307 | #### **除了源代码包之外，分发其他文件还有什么要求？** 308 | ASF 发行版通常包括源代码包及附加材料。附加材料可以包括有关该发行版的文档，但必须包含 LICENSE 和 NOTICE 文件。正如前文所述，如果要将这些文件放置在项目的分发目录中，则必须由提交者使用分离的签名进行签名。 309 | 310 | 同样，仅当这些构件包含 LICENSE 和 NOTICE 文件时，才可以分发它们。例如，Java 构件格式基于压缩的目录结构。那些希望分发 jar 的项目必须将 LICENSE 和 NOTICE 文件放置在 jar 的 META-INF 目录中。 311 | 312 | 本节中的所有内容都不能取代 313 | [这里](https://www.apache.org/legal/release-policy.html#what) 314 | 和 315 | [这里](https://www.apache.org/legal/release-policy.html#what-must-every-release-contain) 316 | 定义的要求：所有发行版都主要基于一个签名的源源代码包。 317 | 318 | ### 有关发行统计信息的问题 319 | 320 | #### 有什么方法可以测量某软件包被下载了多少次吗？ 321 | 322 | 没有直接分发。文件是从镜像下载的。Apache 不需要镜像来收集有关下载的统计信息。 323 | 324 | 计算 [下载脚本][download-script] 的点击数 应该可以得出合理的估计。[Vadim Gritsenko][VG] 收集了各种类似的统计数据。 325 | 326 | 还有由 closer.cgi 记录的一些日志，存储在： 327 | 328 | `https://www-eu.apache.org/dyn/stats/rocketmq.log https://www-us.apache.org/dyn/stats/rocketmq.log` 329 | 330 | 这些列显示：- 时间戳 - IP 地址的一部分 - 国家（估计）-URL 331 | 332 | 请注意，该日志仅记录对 CGI 脚本的访问。这样的访问可能不会导致下载，并且下载可能不会完成。 333 | 334 | **** 335 | 336 | * 译者注：某些部分没有精确按字面翻译，因为英语和中文表达习惯并不相同，完全字字翻译会显得文章逻辑诡异、不通顺且令人费解。受译者水平所限，产生不恰当的翻译在所难免，还请批评指正。可以在 https://github.com/alc-beijing/translation/issues 提交改进意见，或发送电邮至 wwwwyccom at 163 . com 337 | 338 | [uPMC]:http://www.apache.org/foundation/governance/pmcs.html 339 | 340 | [uend_user]:https://infra.apache.org/release-download-pages.html##best_practice 341 | 342 | [umirror]:http://www.apache.org/info/how-to-mirror 343 | 344 | [urelease]:http://www.apache.org/dev/release-publishing 345 | 346 | [udesign]:http://www.apache.org/dev/mirrors 347 | 348 | [apache-licensing-policy]:https://www.apache.org/legal/resolved 349 | 350 | [Apache-licensing-policy]:http://apache.org/legal/src-headers.html#notice 351 | 352 | [al20-4d]:https://www.apache.org/legal/licenses/LICENSE-2.0.html#redistribution 353 | 354 | [ASF-license-header]:http://www.apache.org/legal/src-headers.html#headers 355 | 356 | [cryptographically-sign]:https://www.apache.org/dev/release-signing.html 357 | 358 | [appropriately-]:https://www.apache.org/legal/resolved#category-a 359 | 360 | [licensed-]:https://www.apache.org/legal/resolved#category-x 361 | 362 | [apache-index]:https://www.apache.org/ 363 | 364 | [faq-relaese]:https://www.apache.org/legal/release-policy.html#license 365 | 366 | [MajorityApproval]:http://www.apache.org/foundation/glossary.html#MajorityApproval 367 | 368 | [bypass-24h]:https://www.apache.org/legal/release-download-pages#less-than-24hr 369 | 370 | [asf-wide]:http://www.apache.org/foundation/mailinglists.html#foundation-announce 371 | 372 | [incubator-relaese-draft]:http://incubator.apache.org/guides/releasemanagement.html#best-practice 373 | 374 | [best-practice]:http://subversion.apache.org/docs/community-guide/releasing#release-creating 375 | 376 | [verify-build]:https://svn.apache.org/repos/private/committers/tools/releases/compare_dirs.pl 377 | 378 | [dist-dev]:https://dist.apache.org/repos/dist/dev 379 | 380 | [upload-release]:https://www.apache.org/legal/release-policy.html#upload-ci 381 | 382 | [create-download-page]:https://www.apache.org/dev/release-download-pages 383 | 384 | [old-version-to-archives]:https://www.apache.org/legal/release-policy.html#how-to-archive 385 | 386 | [master-mirror]:https://downloads.apache.org/ 387 | 388 | [1/n-rsync]:https://www.apache.org/info/how-to-mirror 389 | 390 | [INFRA-JIRA]:https://issues.apache.org/jira/browse/INFRA 391 | 392 | [maven-publish]:http://www.apache.org/dev/publishing-maven-artifacts.html 393 | 394 | [use-apache-license-v2]:https://www.apache.org/legal/apply-license 395 | 396 | [Apache-License]:https://www.apache.org/licenses/ 397 | 398 | [apache-legal]:https://www.apache.org/legal/ 399 | 400 | [boilerplate]:http://www.apache.org/legal/src-headers.html#headers 401 | 402 | [download-script]:https://www.apache.org/dev/release-download-pages.html#download-scripts 403 | 404 | [VG]:http://home.apache.org/~vgritsenko/ 405 | -------------------------------------------------------------------------------- /apache/license/README.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alc-beijing/translation/e12f3bab848b3f4a4164fd601bcf66a904115611/apache/license/README.md -------------------------------------------------------------------------------- /apache/license/licensing-howto.md: -------------------------------------------------------------------------------- 1 | ### 2 | 原文地址：https://infra.apache.org/licensing-howto.html 3 | 4 | ## 译文版 5 | 6 | ## 撰写 LICENSE 和 NOTICE 文件 7 | 8 | 这是 Apache 提交者为其项目产品撰写 LICENSE 和 NOTICE 文件的“操作方法”指南。 9 | 10 | ## 概述 11 | 12 | LICENSE 文件传达 Apache 产品分发包中所有内容的许可。它始终包含 Apache 许可证的文本，有时还包含更多信息。 13 | 14 | 在 Apache 许可证版本2.0的[4.4节](https://www.apache.org/licenses/LICENSE-2.0.html#redistribution)中描述了 NOTICE 文件。这是[ ASF 政策](https://www.apache.org/legal/src-headers.html#notice)所要求的。 15 | 16 | 它提供了 LICENSE 和 NOTICE 文件的[完整要求](https://www.apache.org/legal/)。 17 | 18 | ## 指导原则 19 | 20 | LICENSE 和 NOTICE 文件必须**准确表示**分发包中包含的内容。只有分发包中实际包含的组件和资源才对该分发的 NOTICE 和 LICENSE 的内容有影响。 21 | 22 | ## 位置 23 | 24 | LICENSE 和 NOTICE 文件位于源代码树的顶层。ASF 倾向于文件使用裸名，但是 PMC 可以选择将它们命名为 LICENSE.txt 和 NOTICE.txt。 25 | 26 | ## 分步说明 27 | 28 | 要针对具有复杂要求的产品从头开始撰写 LICENSE 和 NOTICE 文件，请按照下列步骤操作： 29 | 30 | - 将完整的[Apache 2.0许可证](https://www.apache.org/licenses/LICENSE-2.0.txt)文本复制到 LICENSE 文件中。 31 | - 根据您的产品详细信息创建一个“NOTICE”文件，并遵守以下说明。[示例 NOTICE 文件](https://infra.apache.org/licensing-howto.html#example-notice)位于此页面的底部。 32 | * 添加专属于您产品 IP 的所有[强制性](https://infra.apache.org/licensing-howto.html#mod-notice)法律通知。 33 | * 对于任何[绑定](https://infra.apache.org/licensing-howto.html#bundled-vs-non-bundled)的依赖项，考虑是否需要修改 LICENSE 和 / 或 NOTICE。**不要**为非绑定的依赖项修改 LICENSE 或 NOTICE。 34 | 35 | ## 绑定许可的依赖关系 36 | 37 | 假设许可对依赖项中的所有文件都统一适用，那么根据以下许可之一发布的依赖项是很简单的: 38 | 39 | - BSD (没有广告条款) 40 | - MIT/X11 41 | 42 | 在 LICENSE 中，在发行版中添加一个指向依赖关系许可的指针，并简要说明其许可: 43 | 44 | ```$xslt 45 | 该产品绑定了 SuperWidget 1.2.3，可在“3-clause BSD”许可下使用。 相关详细信息，请参见 deps/superwidget/。 46 | ``` 47 | 48 | 通常情况下，无需修改 NOTICE 即可提交绑定的依赖。 49 | 50 | **注意**：它也可能包括你的产品的 LICENSE 文件中的第三方许可证的文本。最好为短期许可证保留。指定依赖项的版本很重要，因为许可证有时会随着产品版本的更改而更改。 51 | 52 | ASF 法律事务委员会已[批准](https://www.apache.org/legal/resolved.html#category-a)使用其他许多“宽松”许可证。其中一些可能需要在 NOTICE 上添加一些内容 —— 如有疑问，[请寻求帮助](https://www.apache.org/legal/resolved.html#asking-questions)。 53 | 54 | ## 绑定 Apache 2.0许可的依赖项 55 | 56 | 假设绑定的依赖项本身在其他许可下不包含绑定的子组件，那么 ALv2 统一应用于所有文件，则无需修改 LICENSE。 但是，出于完整性考虑，列出产品及其版本是非常有用的，就像其他许可下列出的产品一样。 57 | 58 | 如果依赖项提供了 NOTICE 文件，则必须分析其内容，并将相关部分撰写到顶级 NOTICE 文件中。 59 | 60 | ## 绑定其他 ASF 产品 61 | 62 | 尽管必须考虑 ASF 版权和 NOTICE 的任何其他部分，但不必重复“此产品包括由 Apache 软件基金会开发的软件...”。 63 | 64 | ## 对 NOTICE 的修改 65 | 66 | NOTICE 文件是为法律要求的通知的某些子集保留的，这些通知既不满足 LICENSE 文本的要求，也不满足嵌入在绑定依赖项中的许可证信息的存在。除了提供自己的 NOTICE 文件的 apache 许可依赖之外，很少有依赖需要添加 NOTICE。 67 | 68 | 在 NOTICE 中必须保留已从源文件中[重新定位](https://www.apache.org/legal/src-headers.html#headers)而不是删除的版权通知。但是，BSD 和 MIT 许可证中嵌入的版权通知之类的部分[不需要在 NOTICE 中重复](https://issues.apache.org/jira/browse/LEGAL-59)。您可以将这些通知留在其原始位置。 69 | 70 | 保持 NOTICE 尽可能简短和简单是很重要的，因为每次添加都会给下游消费者带来负担。 71 | 72 | **不要**添加任何法律上没有要求的内容到 NOTICE 里。 73 | 74 | ## 绑定依赖与非绑定依赖 75 | 76 | 必须根据它们所在的特定发行版的内容来自定义 LICENSE 和 NOTICE 文件。不要把分发包中未包含的依赖项写进 LICENSE 和 NOTICE 里。 **只有绑定的才重要**。 77 | 78 | 例如：如果 Apache-FOO-1.0.tgz 和 Apache-FOO-1.1.tgz 之间的唯一区别是一个绑定了 SuperWidget 而另一个强制用户单独下载 SuperWidget，LICENSE 和 NOTICE 就需要修改以匹配不同的绑定项。 79 | 80 | ## 依赖关系的依赖关系 81 | 82 | 为了撰写 LICENSE 和 NOTICE，依赖关系的依赖关系（包括所谓的“传递性依赖关系”）与一阶依赖关系没有什么不同：**仅在它们部分被绑定在一起的情况下**，才需要修改 LICENSE 和 NOTICE 以符合它们。 83 | 84 | ## 二进制发行版 85 | 86 | 适用于规范的源代码分发的内容也适用于所有的再分配，包括二进制重新分配： 87 | 88 | **所有重新分发都必须遵守内容的许可要求。** 89 | 90 | 撰写二进制发行版时，通常会引入并绑定未与源代码发行版绑定在一起的其他依赖项。必须在 LICENSE 和 NOTICE 中说明这些附加的依赖性。因此，二进制发行版的 LICENSE 和 NOTICE 文件可能与构建它的源代码发行版中的不同。 91 | 92 | 在任何情况下，原理都是一样的：LICENSE 和 NOTICE 必须**准确**表示它们所包含的分发内容。 93 | 94 | ## NOTICE文件示例 95 | 96 | 以下是 [Apache Royale](https://royale.apache.org/) 的 NOTICE 文件的内容： 97 | 98 | ```aidl 99 | Apache Royale 100 | Copyright 2020 The Apache Software Foundation 101 | 102 | This product includes software developed at 103 | The Apache Software Foundation (http://www.apache.org/). 104 | 105 | The Initial Developer of some parts of the framework, which are copied from, derived from, or 106 | inspired by Adobe Flex (via Apache Flex), is Adobe Systems Incorporated (http://www.adobe.com/). 107 | Copyright 2003 - 2012 Adobe Systems Incorporated. All Rights Reserved. 108 | 109 | The Initial Developer of the examples/mxroyale/tourdeflexmodules, 110 | is Adobe Systems Incorporated (http://www.adobe.com/). 111 | Copyright 2009 - 2013 Adobe Systems Incorporated. All Rights Reserved. 112 | 113 | The ping sound effect (ping.mp3) in 114 | examples/mxroyale/tourdeflexmodules/src/mx/effects/assets 115 | was created by CameronMusic. (http://www.freesound.org/people/cameronmusic/sounds/138420/) 116 | ``` -------------------------------------------------------------------------------- /apache/license/代码头和Copyright声明.md: -------------------------------------------------------------------------------- 1 | ## 目的和目标受众 2 | 3 | 本文档描述了 Apache 提交者和 PMC 成员应如何处理源文件许可和版权声明。 4 | 它并不适用于 ASF 以外的开发者在他们的工作中应用 Apache 许可证。[Apache 许可证](http://apache.org/licenses/LICENSE-2.0.html#apply)的[附录](http://apache.org/licenses/LICENSE-2.0.html#apply)描述了其他人如何将许可证应用于他们的工作。该页面没有描述与每个 Apache 产品发布时发布[的标准 LICENSE 文件中的内容的](http://apache.org/dev/apply-license.html#new)要求，也没有描述 [发布第三方组件](http://www.apache.org/legal/resolved.html)时[可接受的许可证](http://www.apache.org/legal/resolved.html)。 5 | 6 | ## 概述 7 | 8 | Apache 产品是通过多个源文件中的许多代码组成，这些代码由不同的作者授权给 ASF，他们对自己的贡献拥有所有权。当 PMC 通过选择、协调和安排所有这些不同的贡献到一个产品中的过程时，这个集体作品也受到版权法的保护，并由 ASF 拥有——即使每一段代码仍然由贡献者拥有。Apache 产品还可能包括其他未直接提交给 ASF 的组件，但[以这种方式获得许可](http://www.apache.org/legal/resolved.html)，符合 ASF 的许可做法。 9 | 10 | 考虑到所有这些因素，本文档介绍了如何：- [标注贡献源的源码头](http://www.apache.org/legal/src-headers.html#headers)， - [处理第三方作品的版权和许可](http://www.apache.org/legal/src-headers.html#3party)，以及 - [使用 NOTICE 文件收集版权声明和所需的归属](http://www.apache.org/legal/src-headers.html#notice)。 11 | 12 | 本文件还包括： - [常见问题解答](http://www.apache.org/legal/src-headers.html#faq)。 13 | 14 | 当[法律讨论](http://www.apache.org/foundation/mailinglists.html#foundation-legal)邮件列表中提出新的问题时，将对其进行更新。 15 | 16 | ## 该页面更新通知 17 | 18 | 该页面的更新将发送到[法律讨论](http://www.apache.org/foundation/mailinglists.html#foundation-legal)邮件列表。 19 | 20 | ## ASF 下开发的代码所适用的源文件头 21 | 22 | 0.本部分仅指版权所有者或所有者的代理人直接提交给 ASF 的作品。 23 | 24 | 1.如果提交的源文件中包含版权声明，则版权所有者（或所有者的代理人）必须： 25 | 26 | ​ a.删除此类声明，或 27 | 28 | ​ b.将它们移至与每个适用项目版本关联的 NOTICE 文件，或 29 | 30 | ​ c.提供书面的许可，让 ASF 可以删除或重新放置通知。 31 | 32 | 2.每个源文件都应包括以下许可证标题 -- -- 注意标题中不应有版权声明： 33 | 34 | Licensed to the Apache Software Foundation (ASF) under one 35 | or more contributor license agreements. See the NOTICE file 36 | distributed with this work for additional information 37 | regarding copyright ownership. The ASF licenses this file 38 | to you under the Apache License, Version 2.0 (the 39 | "License"); you may not use this file except in compliance 40 | with the License. You may obtain a copy of the License at 41 | 42 | http://www.apache.org/licenses/LICENSE-2.0 43 | 44 | Unless required by applicable law or agreed to in writing, 45 | software distributed under the License is distributed on an 46 | "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 47 | KIND, either express or implied. See the License for the 48 | specific language governing permissions and limitations 49 | under the License. 50 | 51 | ## 第三方作品的处理办法 52 | 53 | 0.“第三方作品"指的是版权所有者或所有者的代理人没有直接提交给 ASF 的作品，这包括直接提交给 ASF 的作品的一部分，但提交者不是版权所有者或所有者的代理。 54 | 55 | 1.不要修改或删除第三方作品中的任何版权声明或许可。 56 | 57 | 2.请确保每个第三方作品都包含其相关的许可证，即使这需要将第三方下载网站的许可证副本添加到发行版中。 58 | 59 | 3.不要将标准的 Apache License 标头添加到第三方源文件的顶部。 60 | 61 | 4.为方便起见，通常应使用与其余第三方源文件相同的条款来许可对第三方源文件进行较小的修改/添加。 62 | 63 | 5.对第三方的重大修改/添加，应由 PMC 根据具体情况处理。 64 | 65 | ## 声明文件 66 | 67 | 0.每个 Apache 发行版都应该在顶部目录中包含一个 NOTICE 文件，以及标准的 LICENSE 文件。 68 | 69 | 1.每个 NOTICE 文件的顶部应该包括以下文本信息，并对其进行适当修改，以反映产品的当前和过去版本的产品名称和发布年份： 70 | 71 | ``` 72 | Apache [PRODUCT_NAME] 73 | Copyright [XXXX-XXXX] The Apache Software Foundation 74 | 75 | This product includes software developed at 76 | The Apache Software Foundation (http://www.apache.org/). 77 | ``` 78 | 79 | 2. NOTICE 文件的其余部分用于[所需的第三方通知](http://apache.org/legal/resolved.html#required-third-party-notices)。 80 | 81 | 通知文件还可包括[从提交给 ASF 的源文件](http://www.apache.org/legal/src-headers.html#header-existingcopyright)移来的版权通知。 82 | 83 | 3. 另请参阅[对通知的修改](http://www.apache.org/dev/licensing-howto.html#mod-notice)。 84 | 85 | ## 常见问题解答 86 | 87 | ### 在哪里可以找到每个 ASF 发布中必须包含的 NOTICE 文件的示例？ 88 | 89 | 请参阅[ httpd 项目 NOTICE 示例](http://www.apache.org/licenses/example-NOTICE.txt)或[ Boilerplate NOTICE 文件](http://www.apache.org/licenses/NOTICE-2.0.txt) 90 | 91 | ### 此政策是否适用于发行版中包含的文档文件？ 92 | 93 | 是。 94 | 95 | ### 此政策是否也适用于我们网站上显示的内容？ 96 | 97 | 不，我们的网站没有相关的 NOTICE 文件。作为替代，我们可能很快就会通过网页页脚的 "使用条款 "或 "法律信息 "链接来明确这些内容的条款。在这一点上，Apache 网站不需要采取任何措施。 98 | 99 | ### 如果我的项目在产品发布中包含其网站，该怎么办？ 100 | 101 | 除了[少数例外](http://www.apache.org/legal/src-headers.html#faq-exceptions)，分发中包含的所有可供人阅读的 Apache 开发文件都必须包含[标题文本](http://www.apache.org/legal/src-headers.html#header-text)。文档，包括与发行版一起发布的网站文档，可能会在某种形式的元数据（如 HTML 注释）中包含标题文本，也可以在可见文档中包含标题或页脚。 102 | 103 | ### APACHE 发行版中哪些文件不需要许可证头信息？ 104 | 105 | 在文字元素或结构上没有任何程度的创造性的文件，不受版权法的保护；因此，这样的文件不需要许可证头信息。如果对文件的创造性程度有疑问，请将许可证头信息添加到文件中。 106 | 107 | 其他文件没有许可证头信息也可能是合理的。三个示例是： 108 | 109 | - 简短的信息文本文件，例如 README，INSTALL 文件。期望这些文件可以使它们明显了解与之相关的产品。 110 | - 增加源码头会导致测试失败的测试数据。 111 | - 合并为较大文件的“片段”文件，其中较大文件将具有重复的许可标头。 112 | 113 | PMC 应该根据自己的判断，优先选择使用完整的代码头，如果不确定，请联系legal-discuss@。 114 | 115 | ### 代码头的简短形式是否可用？ 116 | 117 | 有时，文件出现以下情况并不建议使用 Apache 代码头。 例如图像，缩小的 JavaScript 或 PDF 文件中。 在这些情况下，可以使用以下较短的形式。 118 | 119 | ``` 120 | "Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements; and to You under the Apache License, Version 2.0. " 121 | ``` 122 | 123 | 任何与文件相关的附加许可信息（即通常会在通知中出现的信息）应在使用简表时直接在文件中注明。 124 | 125 | PMC 应该根据自己的判断，优先选择使用完整的代码头，如果不确定，请联系legal-discuss@。 126 | 127 | ### 此政策是否适用于 ASF 发行版中包含的第三方二进制/对象文件？ 128 | 129 | 是的。即使发行版中没有源文件，LICENSE 文件和 NOTICE 文件仍然是每个 ASF 发行版中所需要的 -- -- 无论发行单元是：jar、.msi、.tar.gz、.zip、.exe 安装程序，还是任何其他用于发行的文件格式。例如，Windows .exe 文件不得用作分发单位，除非它们是安装程序，并在安装中包含 LICENSE 和 NOTICE 文件。 130 | 131 | ### 本政策是否适用于 ASF 发行版中包含的第三方底层/对象文件？ 132 | 133 | 是的。请参阅政策的“[第三方作品](http://www.apache.org/legal/src-headers.html#3party)”部分，尤其是确保每个第三方作品都具有许可证的 [要求](http://www.apache.org/legal/src-headers.html#3party-addlicense)。 134 | 135 | ### 图像或其他媒体是否需要在 NOTICE 文件中添加版权行？ 136 | 137 | 如果媒体是直接为 ASF 项目贡献的，则贡献者可以选择将其版权声明插入 NOTICE 文件，如[源文件所述](http://www.apache.org/legal/src-headers.html#header-existingcopyright)。如果媒体来自第三方（未直接贡献给项目），则任何明显与媒体相关的版权声明都应复制到 NOTICE 文件中。 138 | 139 | ### 为什么需要许可证头信息？ 140 | 141 | 许可证头信息允许检查文件的人知道作品的条款，即使在没有分发其余内容的情况下进行分发也是如此。在没有许可通知的情况下，必须假定作者保留了所有权利，包括复制，修改和重新分发的权利。 142 | 143 | ### 此政策是否适用于 ASF 之外使用 APACHE 许可证的项目？ 144 | 145 | 不可以。严格来说，这是一项 ASF 政策。使用 Apache 许可证的其他项目仍应参考 [许可证的附录，](http://www.apache.org/licenses/LICENSE-2.0.html#apply)以获取有关将标头应用于其源文件的指导。 146 | -------------------------------------------------------------------------------- /apache/marks/Apache 商标使用管理原则.md: -------------------------------------------------------------------------------- 1 | # Apache 商标使用管理原则 2 | 3 | 翻译: 聂帅 4 | 5 | 原文出处:http://www.apache.org/foundation/marks/ 6 | 7 | 本文档概述了**允许使用 Apache® 商标的其他方的政策。** 8 | 9 | Apache 软件基金会（ASF）拥有所有与 Apache 相关的商标，服务标志，代表我们 Apache 社区的标志，**所有 Apache 项目的名称都是 Apache 的商标。** 10 | 11 | 以下信息有助于确保其他方以经许可的方式使用我们的商标和徽记，确保我们能够合法的保护我们的项目品牌，并且鼓励第三方以所批准的方式使用 Apache 软件和我们的品牌。如果您对此政策或者 Apache 商标有任何疑问，可以[联系我们](http://www.apache.org/foundation/marks/contact),并请**阅读我们的[商标资源列表](http://www.apache.org/foundation/marks/resources)。** 12 | 13 | # 商标政策快速链接 14 | 15 | * [基本原则](#基本原则) 16 | 17 | * [关键商标原则的描述](#关键商标原则的描述) 18 | 19 | * [特定的 Apache 商标政策](#特定的-Apache-商标政策) 20 | 21 | * [软件产品政策](#在软件产品品牌中使用Apache商标) 22 | 23 | * [出版书籍或文章的政策](#在出版的书籍和文章中使用Apache商标) 24 | 25 | * [域名政策](#在域名中使用Apache商标) 26 | 27 | * [活动政策](#在会议和活动中使用Apache商标) 28 | 29 | * [Apache 的商标名单](http://www.apache.org/foundation/marks/list/) 30 | 31 | * [常问问题](http://www.apache.org/foundation/marks/faq/) 32 | 33 | * [关于我们](#关于我们) 34 | 35 | * [更多 Apache 商标资源](http://www.apache.org/foundation/marks/resources) 36 | 37 | 38 | 39 | # 基本原则 40 | 41 | Apache® 商标，服务标记和图形标记是质量以及与 ASF 项目相关联的社区支持的象征。为确保 Apache 商标的使用不会导致我们软件的混乱，我们必须控制这些商标和其他组织的软件以及相关服务的联合使用。另外，作为一家美国公司，我们有法律责任和法律权力来指定使用我们商标的政策。 42 | 43 | Apache 软件基金会和我们的许多软件产品必须与其他任何和 ASF 竞争的软件以及任何与 ASF 无关的企业和个人的软件与服务区分开来。 44 | 45 | 不得使用 Apache 商标贬损 Apache 软件基金会、我们的项目、会员、赞助者以及社区。也不得使用 Apache 商标以任何方式暗示对任何与 ASF 相关的项目或任意类型的倡议的所有权，支持和赞助。作为一个中立性组织，我们品牌的重要组成部分是[ Apache 的项目是独立管理的](http://community.apache.org/projectIndependence)。 46 | 47 | # 关键商标原则的描述 48 | 49 | 本部分并不是为了总结商标的复杂法律，而是为了帮助读者了解一些关键的商标原则。更多信息，请参见我们的[商标资源列表](http://www.apache.org/foundation/marks/resources)。 50 | 51 | **商标是什么？** 52 | 53 | **商标**是用于区分一方与另一方商品来源的一个单词、短语、符号、设计或是单词、短语、符号、设计所组成的整体。**服务标志**与商标相同，只不过服务标志是用于区分服务的来源的。在整个文档中术语“商标”( trademark )和“标记”( mark )均指商标和服务商标。 54 | 55 | 这些规则可以归纳为，使用商标“ Apache *ProjectName* ”来描述与 ASF 相关的软件，或者当使用商标来描述我们特定的 Apache *ProjectName* 软件产品时，使用商标“ *ProjectName* ”来描述。与大多数 ASF 软件一样，“ *ProjectName* ”的软件是由“ Apache *ProjectName* ”项目或者另一个“ *ProjectName* ”的项目（例如“ Apache Incubator ”（本身就是 ASF 的商标））进行维护的。 56 | 57 | ASF 的商标是文字（例如，“ *Apache* ”和“ *Apache ProjectName* ”）或者是旨在用于充当 Apache 软件的商标的图形徽记。 Apache 羽毛也是 Apache 软件的 ASF 商标，但其对 ASF 有特殊含义，所以也拥有与其使用相关的特殊规则。 58 | 59 | 在 ASF 中，在我们的产品发布活动期间和 ASF 网站上，我们会确保我们的商标标有（ TM ）或（ R ）标记或者在适当的时候显示商标声明，我们提供了 ASF 商标列表，以便所有人都可以认出这是 ASF 的商标。这里提供了有关如何引用 Apache 品牌的[详细指南](http://www.apache.org/foundation/marks/guide)。 60 | 61 | **什么是商标的合理指示性使用？** 62 | 63 | 只要对商标的使用是指示性的，则任何人都可以使用 ASF 商标。对商标侵权的“指示性使用”（或“名义合理使用”）抗辩是一项法律原则，只要遵守以下三个条件，那么所有人（甚至商业公司）都可以使用他人的商标： 64 | 65 | 1. 所涉及的产品或服务必须是一种不使用商标就无法轻易识别的产品或服务； （例如，不使用商标“ Hadoop ”就很难识别出 ApacheHadoop® 软件） 66 | 2. 只有当使用的数量有限，并且该数量对于识别产品和服务来说是必要的； 67 | 3. 使用该商标的组织不得采取任何与该商标相关的，建议商标持有人赞助或背书的行为。 68 | 69 | 商标指示性合理使用抗辩旨在鼓励人们通过使用商标本身来引用商标商品和服务。这种商标抗辩与版权的合理使用无关，不应该与这些规则混淆。 70 | 71 | **什么是“混淆相似性”或“混淆可能性”测试？** 72 | 73 | 有些对他人商标的使用是名义上的合理使用，但有些使用就只是侵权。事实上，如果商标用可能会使相关消费者对使用该商标销售或提供的产品和服务的来源产生混淆或者误解的方式来使用，那么就存在混淆的可能性，那么该商标就被侵权了。 74 | 75 | 请注意，即使不存在混淆的可能性，如果您根据州和/或联邦稀释法对另一家公司的商标进行模糊或玷污，您仍可能对使用该公司的商标承担责任。 76 | 77 | 为了避免侵犯 ASF 的商标，您应该确认您使用我们的商标是指示性的，并且您的使用不会使消费者产生您的软件与 ASF 的软件相同，或是您的软件受到了 ASF 认可的错觉。此策略已经在 Apache 许可证的第六节中概述，因此，这是您使用 Apache 软件的条件： 78 | 79 | > 本许可证不允许使用许可方的商标名称、商标、服务标志或产品名称，除非是在描述作品来源和复制通知文件内容时的合理的惯常使用。 80 | 81 | # 特定的 Apache 商标政策 82 | 83 | 以下具体政策适用于“ Apache ”一词的商标和“ Apache 羽毛”图形商标，以及所有 ASF 项目生产的所有“ *Apache ProjectName* ”和“ *ProjectName* ”软件的商标和图形徽记。您可以参考我们的[ Apache 标记列表。](http://www.apache.org/foundation/marks/list/) 84 | 85 | 被允许的指示性使用的示例： 86 | 87 | * “ Apache 许可证下的 Apache *ProjectName* 软件的免费副本以及 Apache *ProjectName* 的支持服务可在我公司的网站上获得。” 88 | * “ Apache *ProjectName* 软件的衍生产品和这些衍生产品的支持服务以我们的商标在我们的网站上提供。”请注意，根据商标法，您不得将与“ *ProjectName* ”或“ Apache *ProjectName* ”或 *ProjectName* 图形徽标商标可能发生混淆的相似的商标应用于 *ProjectName* 软件的衍生产品。 89 | * “ *ProjectName* 软件比Myco软件更快（或更慢）”。 90 | * ”对于您的业务我向您推荐（或不推荐） *ProjectName* 软件“。 91 | * “这是 Apache *ProjectName* 软件的图形徽标。” 92 | * ASF 希望您对我们所有的项目使用[ Apache *ProjectName* 的全称](http://www.apache.org/foundation/marks/guide)。 93 | 94 | # 在软件产品品牌中使用 Apache 商标 95 | 96 | 一般来说，您[不能在任何软件产品品牌中使用 Apache 商标](http://www.apache.org/foundation/marks/faq/#products)。但是，在非常特定的情况下，您可能会对软件产品使用[ Powered By 命名表单](http://www.apache.org/foundation/marks/faq/#poweredby)。 97 | 98 | # 在出版的书籍和文章中使用 Apache 商标 99 | 100 | 您可以撰写有关 Apache Foo 软件的文章，并在书籍或文章标题中使用我们的商标。 您无需征求我们的许可就可以引用 Foo（ *ProjecName* ），例如《 Foo for Dummies 》，《 Expooning Foo 》，《 Foo Simplified 》，《 O'Reilly Foo指南 》甚至《 避开 Foo 》。 101 | 102 | 我们希望您在标题中引用“ Apache Foo ”而不是简单的“ Foo ”，并且我们希望凡是您通常在书或文章中认为重要的地方都能够明确标识“ Apache ”，“ Apache Foo ”和“ Foo ”都是 Apache 软件的商标。 103 | 104 | 有关更多详细信息，请参见我们发布中的[有关 Apache 商标的常见问题解答](http://www.apache.org/foundation/marks/faq/#booktitle)。 105 | 106 | **使用 Apache 羽毛徽标表示 ASF 并且链接到[www.apache.org](http://www.apache.org/):** 107 | 108 | Apache 羽毛徽标是 Apache 软件基金会成员的特殊商标，我们希望防止将其与其他公司的软件或相关服务结合使用。 109 | 110 | 您无需向我们请求许可，就可以在您自己的网站上使用 Apache 羽毛徽标（用我们在这里发布的版本）作为 [www.apache.org](http://www.apache.org/) 或者是一个合适的 Apache 项目的超链接，又或是在其他的材料，比如演示和幻灯片中，仅仅是为了指代 ASF 本身。 111 | 112 | Apache 羽毛徽标的所有其他用途必须得到 VP，Apache 品牌管理或品牌管理委员会成员的[书面批准](http://www.apache.org/foundation/marks/contact#other)。 113 | 114 | **使用 Apache Foo 或类似的项目图形徽标：** 115 | 116 | 图形徽标由艺术家贡献给 ASF ，作为一种可以识别 Apache 项目软件的符号而被创造。徽标的示例包括 Hadoop 大象， SpamAssassin 箭头，甚至是将“ Maven ”一词拼写为橙色字母“ a ”的图形方式。 这些图形徽标是 Apache 项目专用的，这些项目使用这些徽标来代表其软件和项目网站。 117 | 118 | 您无需向我们请求许可，就可以在您自己的网站上使用 Apache 的图形徽标（使用发布在各个网站上的版本）作为 指向一个特定的项目或者 [www.apache.org](http://www.apache.org/) 的超链接。所有其他使用 Apache Foo （以及类似的）图形徽标的行为必须得到 VP，Apache 品牌管理或品牌管理委员会成员或者相关的 Apache 项目的 VP 的[书面批准](http://www.apache.org/foundation/marks/contact#other)。 119 | 120 | 与 ASF 的文字商标（例如“ Apache ”和“ Foo ”）不同，我们的图形徽标也根据 Apache 许可向公众许可。 该许可证允许您与其他任何 Apache 受版权保护的作品一样创建这些徽标的衍生作品。 但是，如果相关消费者可能会因使用该衍生徽标而被误导，那么商标法不允许您将任何“易混淆的相似”衍生徽标应用于软件。 121 | 122 | 如果您对任何 ASF 图形商标的使用或更改有任何疑问或疑虑，请[联系我们](http://www.apache.org/foundation/marks/contact)。 123 | 124 | **在商品上使用 Apache 商标：** 125 | 126 | 您必须事先获得 VP、Apache 品牌管理或指定人员的[书面批准](http://www.apache.org/foundation/marks/contact#swag)，才能将“ Apache ”、“ Apache Foo ”或“ Foo ”商标或其图形徽标应用于任何与 Apache Foo 软件和 Apache 软件或任何在人们的普遍认识中与两者相关联的商品。 127 | 128 | 对于推广 Apache 软件基金会、Apache Foo 项目和 Foo 软件的商品，可以申请并获取 ASF 商标（包括图形徽标）的许可。 129 | 130 | 对于贬低 Apache 软件或项目的商品，或有损 Apache 软件及其品牌价值的商品，通常会拒绝其申请 ASF 商标使用的许可。 131 | 132 | **ASF 商标的以下使用可能是侵权的：** 133 | 134 | * 令人产生困惑的相似软件产品名称。 135 | * 除 ASF 官方发布的软件以外的任何其他软件服务。 136 | * 在用户心中可能与 ASF 或其商标项目软件相关联的公司名称。 137 | 138 | # 在域名中使用 Apache 商标 139 | 140 | 如果未经 VP、Apache 品牌管理或指定人员的书面批准，您不得在您自己的域名中使用 ASF 商标，比如“ Apache ”或“ Apache Foo ”或“ Foo ”或是其他可能会使相关消费者对您的网站提供的软件或是服务的来源产生困惑的表达。您应该使用上述“混淆可能性”测试，并请注意在您的域名中使用 ASF 商标通常不是“指示性使用” 141 | 142 | 有关更多详细信息并请求批准，请参阅我们的[域名品牌政策](http://www.apache.org/foundation/marks/domains.html)。 特别是，不允许将 Apache 产品名称用作第二级域名（example.com）。 143 | 144 | # 在会议和活动中使用 Apache 商标 145 | 146 | 某些 ASF 商标专用于 Apache 软件基金会的正式活动。 例如，“ ApacheCon ”是我们在常规 ASF 会议上的专有商标，而 Apache 羽毛旨在在我们所参加的活动中给 ASF 使用。 147 | 148 | 单独的 ASF 项目（例如“ Apache Foo ”）经常创建自己的会议和活动，或者与其他组织或公司联合举办联合会议或活动。与会议或活动相关的 ASF 商标（包括与我们的项目或产品相关的商标）的任何冲突使用，必须获得 VP，Apache 品牌管理或指定人员的书面批准。 149 | 150 | 更多详情或请求批准，请参阅我们的[活动品牌政策](http://www.apache.org/foundation/marks/events.html)。 请提前申请批准，以避免与 ApacheCon 举办日期冲突。 151 | 152 | # 关于我们 153 | 154 | [VP , Apache 品牌管理](http://www.apache.org/foundation/)及相关品牌管理委员会是 ASF 中的正式组成部分，负责制定政策并回答有关徽标和商标使用的问题以及其他责任。委员会由已经在品牌和商标方面展现特长的 ASF 的当选成员组成。 现任 Apache 品牌管理副总裁是马克·托马斯（ Mark Thomas ），是由总裁任命担任该职位的。 查看[委员会成员名单以及联系我们](http://www.apache.org/foundation/marks/contact)。 155 | 156 | [关注 @ASFBrands](https://twitter.com/ASFBrands) 157 | 158 | # 重要说明 159 | 160 | **本 ASF 政策声明中的任何内容不得解释为允许任何第三方声称与 Apache 软件基金会或其任何项目有任何关联，或暗示 ASF 对任何第三方产品或服务的任何批准或支持。** 161 | 162 | # 政策版本 163 | 164 | 这是2014年发布的 Apache 策略文档的1.1版。 165 | 166 | 重大更改将使用新版本号。 167 | 168 | **v1.1**更新以获得 VP、品牌**或**指定人员的许可 169 | -------------------------------------------------------------------------------- /apache/marks/Apache 软件基金会商标使用指南.md: -------------------------------------------------------------------------------- 1 | # Apache 软件基金会品牌使用指南 2 | 3 | 翻译: 王堉琛 4 | 5 | 原文出处:http://www.apache.org/foundation/marks/ 6 | 7 | Apache® 品牌被 200 多个 Apache 软件基金会（ASF）项目社区共享，它也是我们使命——为公众利益提供软件——的重要组成部分。本品牌使用指南为引用 Apache® 软件项目和产品提供了示例。 8 | 9 | **重要提示：** 如果您请求在域名、活动或服务中使用 Apache 品牌，则**必须**遵循本指南。 10 | 11 | **术语：** *项目（ Projects）* 是 ASF 中开发并管理软件的组织委员会（PMC）。*产品（ Products）* 是提供给公众的软件代码和下载。在大多数情况下，Apache 项目的名称与 Apache 软件的名称相同，且遵循 “Apache Projectname” 命名格式。 12 | 13 | **目录** 14 | 15 | 16 | - [关于 Apache 品牌](#关于-apache-品牌) 17 | - [如何引用 Apache 项目和产品](#如何引用-apache-项目和产品) 18 | - [使用 Apache Hadoop 与 Hadoop](#使用-apache-hadoop-与-hadoop) 19 | - [如何使用 Apache 项目 logo](#如何使用-apache-项目-logo) 20 | - [如何使用Apache “Powered By”项目 logo](#如何使用Apache-“Powered-By”项目-logo) 21 | - [如何使用 Apache 羽毛 logo](#如何使用-apache-羽毛-logo) 22 | - [其他品牌指南](#其他品牌指南) 23 | - [重要提示](#重要提示) 24 | 25 | 另请参阅：[品牌资源网站地图。](http://www.apache.org/foundation/marks/resources) 26 | 27 | # 关于 Apache 品牌 28 | 29 | Apache 品牌和我们的 羽毛 logo 代表我们构建软件的 Apache Way 过程。Apache Way 的一些元素包括有一个协作的、共识驱动的志愿者社区，这些志愿者共同治理该项目。这也意味着要有一个厂商中立（vendor-neutral）且独立的治理方式，这种治理方式欢迎所有有益的贡献，而不考虑贡献者的雇主是谁。Apache 品牌的项目托管在 ASF，并且必须被 [独立管理](http://community.apache.org/projectIndependence)。 30 | 31 | 作为一个非盈利的公共慈善机构，ASF 的董事会和成员是真正的 [独立管理机构](http://www.apache.org/foundation/governance/)，监督许多 Apache 项目社区的运作。有了这一层的监督，可以确保 Apache 项目以符合整个用户社区最佳利益的方式运作，并且可以通过提供一个可以让不同的供应商一同协作的，中立的合作空间来充当创新加速器。 32 | 33 | 为了确保 Apache 志愿者社区因提供 Apache 软件而获得应有的荣誉，并维持 ASF 和 Apache 项目独立治理的形象，您应该使用一些特定的方法来引用 Apache 项目和产品。 34 | 35 | # 如何引用 Apache 项目和产品 36 | 37 | Apache 项目总是以 “Apache Hadoop” 的形式命名。虽然我们在这里以 Hadoop® 项目为例，但这些准则适用于所有 Apache 项目。确保始终引用 “Apache Hadoop” 可以确保所有 Apache 项目都与主导它们的非盈利组织共享关系。 38 | 39 | ## 使用 Apache Hadoop 与 Hadoop 40 | 41 | 当以任何个人用途（如网页、讲义、幻灯片等）引用品牌时，第一个引用和最突出的引用 **必须** 使用全称：“Apache Hadoop®”。您应该尽可能多（具体取决于上下文和您的写作风格）的使用名称的完整形式，以确保读者清楚地理解 Hadoop 项目、 Hadoop 软件产品和作为父组织的 ASF 之间的关联。 42 | 43 | 在这之后的每个特定文档中，您可以使用名称的*裸形式*，即 Hadoop，因为它最适合您的写作风格。 44 | 45 | **更具体地说：** 46 | 47 | 对于 **软件供应商或软件相关服务提供商** 的使用，或当组织（或者带有组织品牌的页面）正在讨论与 Hadoop（或任何其他 Apache 品牌）相关的，但却不是 Apache 提供的软件产品或服务时，需要格外小心，以维护 Apache 品牌独立与厂商中立的声誉。 48 | 49 | *至少* 在以下情况下必须使用全称形式： 50 | 51 | - 标题或副标题，包括网页标题或描述元数据。 52 | 53 | - 任何主要文档部分中第一个且最突出的标题元素。 54 | 55 | - 第一个且最突出的标注、侧边栏，以及其他突出显示给用户的内容块。 56 | 57 | - 第一个且最突出的，在移动文字中的文档或文档正文文本中的使用。 58 | 59 | - 对于图形标题或图表，如果可以，名称的完整形式必须在图形中清晰可见；如果不清晰，则名称的完整形式必须用在突出的标题标题中，或附在对图形的说明中。 60 | 61 | - 对于视频内容，在标题、第一次使用、最后一次使用或在任何详细使用名单中，必须使用名字的完整形式。 62 | 63 | - [适当的品牌属性](http://www.apache.org/foundation/marks/faq/#attribution) 也必须提供，要么在页脚，或在一个网站内明确标记的，说明条款，法律，品牌，或其他一般性命名的次要网页。 64 | 65 | 供 **其他类型的用户** 使用（即*不是* 与所讨论的 Apache 软件产品相关的软件产品或服务的主要提供者，包括组织或个人）： 66 | 67 | - 对于学术性或学术性的工作：在标题、副标题中，页眉、标注中的第一个且最突出的引用，或高亮部分，以及在移动文字或正文中使用第一个且最突出的引用，需要使用完整格式。之后允许使用裸模板。 68 | 69 | - 对于定期出版的媒体（书籍、杂志、通讯刊物）：确保在标题、子标题，页眉、标注中的第一个且最突出的引用，高亮部分，以及在移动文字或正文中使用第一个且最突出的引用中，使用完整格式。除此之外，请遵循你们通常在引用软件产品名称时的规则。 70 | 71 | - 对于个人博客作者或个人：我们感激在标题中，移动文字或正文中第一个且最突出的地方引用全称形式。 72 | 73 | - Apache 品牌在 [域名](http://www.apache.org/foundation/marks/domains) 或 [事件名与品牌](http://www.apache.org/foundation/marks/events) 中的使用和品牌包含在他们自己的政策中。 74 | 75 | # 如何使用 Apache 项目 logo 76 | 77 | 最重要的一点是使用 Apache 项目本身未经修改的 logo，并确保 logo 不会与其他公司 logo 一起使用。查看 Apache 项目 logo 的人应该始终清楚地知道，该 logo 指的是实际的 Apache 项目（社区）或软件产品（实际下载），而不是某个第三方组织或产品。 78 | 79 | # 如何使用Apache “Powered By”项目 logo 80 | 81 | 为了使许多基于 Apache 软件构建解决方案的组织能够正确地展示它们之间的关系，ASF 为所有 Apache 项目提供了一行 [下载“Powered By” 图形logo](http://www.apache.org/foundation/press/kit/#poweredby)。Powered By logos 可以比官方项目 logo 更自由、更广泛地使用，包括用来直接表明 Apache 软件产品与各种第三方产品和服务之间的关系。 82 | 83 | # 如何使用 Apache 羽毛 logo 84 | 85 | Apache 羽毛 logo 对 ASF 和每个 Apache 项目都是一个重要的品牌。作为一个厂商中立的公共慈善机构，“羽毛” 只应被用来指代作为一个独立的组织的 ASF ，绝不能用在似乎认可任何其他组织或与任何其他组织有关联的情况下。除非是在制作物理内容时为了有限的物理印刷技术做出妥协，否则羽毛标志不得修改。羽毛 logo 决不能与其他组织 logo 或图像直接结合使用。 86 | 87 | ASF 新闻团队维护着官方的 [Apache 羽毛标识](http://www.apache.org/foundation/press/kit/#policy)。 88 | 89 | # 其他品牌指南 90 | 91 | 请参阅我们的 [正式品牌政策](http://www.apache.org/foundation/marks/) 和我们的 [品牌资源网站地图](http://www.apache.org/foundation/marks/resources)。 92 | 93 | # 重要提示 94 | 95 | **本 ASF 政策声明中的任何内容不得解释为允许任何第三方声称与 Apache 软件基金会或其任何项目有任何关联，或暗示 ASF 对任何第三方产品、服务或事件的任何批准或支持。** 96 | -------------------------------------------------------------------------------- /apache/marks/Apache下游项目的品牌使用原则.md: -------------------------------------------------------------------------------- 1 | # Apache下游项目的品牌使用原则 2 | 3 | 翻译: 王福政 4 | 5 | 原文地址: http://www.apache.org/foundation/marks/downstream.html 6 | 7 | # 初稿 ~ 初稿 ~ 初稿 8 | 9 | 本**下游发行品牌政策**定义了希望以原始 Apache® 产品名称分发 Apache® 软件产品的下游软件发行商的要求。希望使用其他名称的发行商应遵循我们[正式商标政策](http://www.apache.org/foundation/marks/)。 10 | 11 | # 下游发行品牌政策 12 | 13 | Apache 软件产品由一些为其平台提供软件包的下游实体分发。例如，Docker 镜像、Linux 发行商和云平台供应商。 14 | 15 | Apache 软件基金会认识到这些下游发行商的重要性，并乐于看到他们在遵循这一政策的前提下，以 Apache 的原始名称发布 Apache 产品。 16 | 17 | ## 命名 18 | 19 | 该名称必须与 Apache 软件基金会使用的名称相同。所有 Apache 软件产品的全称都具有 "Apache *ProjectName*" 的形式。请注意，"Apache"、"*ProjectName*" 和 "Apache *ProjectName*" 是 Apache 软件基金会的商标。 20 | 21 | ## 源代码 22 | 23 | 软件所基于的源代码必须与 Apache 软件基金会的源代码版本相同，或者以下所有条件都必须符合： 24 | 25 | - 所有源代码更改必须至少满足以下列出的可接受更改标准之一。 26 | - 必须使用一个版本号，该版本号既要明确区别于 Apache 软件基金会发布的版本，又要明确标识软件所基于的 Apache 软件基金会版本。 27 | - 文档必须明确标识软件所基于的 Apache 软件基金会版本。 28 | - 最终用户希望发行渠道能够移植修复。并非所有的修复程序都必须进行反向移植。选择要反向移植的修复程序必须符合该分发渠道的更新政策。 29 | 30 | 可接受的变更必须至少满足以下标准之一： 31 | 32 | - 该变更已被相关的 Apache 项目社区接受，并被纳入未来的版本中。请注意，接受变更的过程以及接受变更的方式因项目而异。 33 | - 更改是针对未公开的安全问题的修复程序；该修复程序未公开披露为安全修复程序；Apache 项目已 [收到](http://www.apache.org/security/)有关该问题和建议的修复程序的[通知](http://www.apache.org/security/)；PMC 既未拒绝漏洞报告也未拒绝建议的修复程序。 34 | - 变更是对 bug 的修复；并且 Apache 项目已经被通知了 bug 和建议的修复；并且 PMC 既没有拒绝 bug 报告也没有拒绝建议的修复。 35 | - 为与目标平台整合而做的小改动（例如，对启动和关闭脚本、配置文件、文件布局等的改动），Apache 项目不反对这些改动。 36 | 37 | ## 其他依赖关系 38 | 39 | 在发行版中包含的任何额外的依赖关系必须按照[第三方许可政策](https://www.apache.org/legal/resolved.html)的条款进行许可，允许 Apache 项目将该依赖关系包含在 Apache 发行版中。 40 | 41 | Apache 软件基金会提供的可选依赖项、模块、附加组件等可以包含在发行版中。 42 | 43 | 第三方提供的可选依赖项、模块、附加组件等扩展了 Apache 项目的功能，应该通过单独的包来提供，但如果项目不反对，可以包含在发行版中。 44 | 45 | 第三方提供的可选依赖项、模块、附加组件等，如果取代了 Apache 项目中的默认功能，则必须通过单独的包来提供，除非 Apache 项目已经批准将其包含在发行版中。 46 | 47 | # 使用示例 48 | 49 | 基于上述政策，以下用法是可以接受的，除非项目的具体要求不允许： 50 | 51 | - 从开发分支发布任何特定的版本。 52 | - 包含从开发分支移植的修复或功能。 53 | - 修改默认配置。 54 | - 应用那些需要做一些琐碎的改动才能应用的后端移植。 55 | - 包括一系列第三方 JDBC 驱动程序或类似库，以方便与其他系统的通信。 56 | 57 | 基于上述政策，除非项目的具体要求允许，否则以下用法将不被接受： 58 | 59 | - 包含从个人提交者的特性分支或其他分支移植过来的修正或特性，但这些修正或特性还没有被项目接受并包含在未来的版本中。 60 | - 应用当前不在 ASF 源代码管理中的修补程序。 61 | - 添加目前不在 ASF 源码控制中的功能。 62 | - 应用需要进行非频繁改动才能应用的后端口。 63 | - 默默地修复已发现的安全问题，而不通知 PMC 该问题。 64 | - 用第三方持久化库替换数据库的默认持久化层。 65 | 66 | # 项目具体要求 67 | 68 | 个别项目可以修改上述修改后的软件发行版的默认要求。 69 | 70 | 以下项目使用了上述政策的修改版本。 71 | 72 | - Apache Subversion 73 | 74 | 在以 Apache 产品名称分发 Apache 软件项目的修改版之前，发行商必须向相关项目检查任何项目特定的策略。 75 | 76 | # 其他商标政策和资源。 77 | 78 | 请参阅我们的[正式商标政策](http://www.apache.org/foundation/marks/)和[商标资源网站地图](http://www.apache.org/foundation/marks/resources)。 79 | 80 | # 重要说明 81 | 82 | **本 ASF 政策声明中的任何内容都不得解释为允许任何第三方声称与 Apache 软件基金会或其任何项目有任何关联，或暗示 ASF 对任何第三方产品、服务或活动的任何批准或支持。** 83 | 84 | # 政策版本 85 | 86 | 这是此 2020 年 6 月发布的 Apache 政策文件草案的 0.4 版。 87 | 88 | 重大更改将用新的版本号标记。 89 | 90 | 从 1.0 版开始将跟踪更改。 91 | 92 | # [初稿 ~ 初稿 ~ 初稿](http://www.apache.org/foundation/marks/downstream.html#draft-draft-draft_1) 93 | -------------------------------------------------------------------------------- /apache/marks/README.md: -------------------------------------------------------------------------------- 1 | 本目录存储Apache商标管理原则。 2 | -------------------------------------------------------------------------------- /apache/marks/项目管理委员针对商标的管理职责.md: -------------------------------------------------------------------------------- 1 | # Apache 项目网站商标原则 2 | 3 | 翻译: 王皓月 4 | 5 | 原文地址: http://www.apache.org/foundation/marks/pmcs 6 | 7 | 本文定义了商标原则，定义了 Apache®projects 网站显示的元素，以及如何正确地对待 Apache 和其他组织的商标。[PMC 商标责任](http://www.apache.org/foundation/marks/responsibility.html)还解释了 PMC 成员应该以何种方式管理项目商标。 8 | 9 | **目录** 10 | 11 | - [项目网站和 URL 原则：使用 * .apache.org](#项目网站和-url-原则使用--apacheorg) 12 | - [项目命名和描述原则](#项目命名和描述原则) 13 | - [网站导航链接原则](#网站导航链接原则) 14 | - [https 还是 http？](#https-还是-http) 15 | - [商标归属原则](#商标归属原则) 16 | - [logo 和图形原则](#logo和图形原则) 17 | - [技术支持...Logo](#技术支持logo) 18 | - [项目元数据](#项目元数据) 19 | - 其他商标要求 20 | - [与项目相关的 Non-apache.org 域名](#与项目相关的-non-apacheorg-域名) 21 | - [项目商标清单](#项目商标清单) 22 | - [理由](#理由) 23 | - [重要说明](#重要说明) 24 | 25 | # 项目网站和 URL 原则：使用 * .APACHE.ORG 26 | 27 | - Apache 项目必须在 `apache.org` 域上托管官方网站，包括由项目 PMC 监督的内容（包括顶级网站，下载和 Wiki），并确保 ASF 基础架构团队可以维护服务，同时告知用户该内容是官方的并且来自 ASF 和项目 PMC，而不是来自第三方。 28 | - 任何 *ProjectName* 的主页都必须由 `http[s]://ProjectName.apache.org` 提供服务，以确保商标一致，且允许自动生成链接（例如 [https://projects.apache.org](https://projects.apache.org/)）。项目的所有主链接都必须直接指向主页，而不是其他站点或域。 29 | - 项目可以自由地使用基础架构支持的[技术](http://www.apache.org/dev/project-site.html)来管理和部署网站，并且可以自由使用设计中的外观。未来，我们可能会要求项目添加特定的样式或者图形元素（从多种变体中选择），以使其返回链接 www.apache.org，这将有助于用户更好地了解 Apache 项目之间的联系。 30 | - 拥有悠久的开源开发历史和庞大的用户群新社区进入 Apache 孵化器前，应该阅读[使用 non-apache.org 域的限制](http://www.apache.org/foundation/marks/pmcs#nonapache)。 31 | 32 | # 项目命名和描述原则 33 | 34 | *存在[新项目名称](http://www.apache.org/dev/project-names)的选择准则，但尚未进行审查并合并到此原则文档中。* 35 | 36 | - 任何项目或产品名称的主要商标必须采用“Apache *Projectname* ”的形式，这样可以确保在用户心中，项目或产品与 ASF 相关联，并确保第三方不能轻易滥用项目名称。项目或产品的每个页面中第一个最重要的引用，以及页面标题中的引用，都必须使用其名称的“Apache *Projectname* ”形式。其他引用可以根据主题使用“ Apache *Projectname* ”或“ *Projectname* ”。 37 | - 该产品的每个产品主页和任何概述下载页面都必须包含对该产品的突出引用，称为“ Apache Foo 软件”，并且必须包含对该软件产品本身的用途和功能的简短描述。例如： 38 | 39 | > Apache Xerces XML 解析库软件提供了 XML 1.0解析规范的完整实现，并且易于配置，符合当前标准。 40 | 41 | 该描述对于页面的新读者非常有用，并有助于 ASF 维护软件产品商标的完整列表。仅在与特定种类的商品关联时，商标才重要：在案例中，这是 ASF 和 PMC 提供的可实际下载的软件产品。 42 | 43 | 请注意，共享关于商标 @ 的示例描述是有帮助的，可以确保它是正确的商标商品描述。 例如，在过去 Apache Tomcat 的网站上，它是“实现”和“协作”，而不是具有功能的产品。 Apache Spam Assassin 的网站将自己描述为一个“项目”和“版本”，并将其称为“it”。 两者都没有包含正确的商标商品描述（即执行功能的计算机软件）。 虽然这种商标描述风格有时在技术文档中显得笨拙，但这是我们强制实施商标原则的一种重要方法。对于每个项目，只需要在网站上的显眼位置进行即可。 44 | 45 | - 项目和产品名称应该使用一致的大写字母和形容词，而不是名词或动词，这是所有商标应该使用的。 在项目主页和下载页面上进行此操作很重要；在网站或技术产品文档的其他地方，它是不需要的。 46 | - 我们认为所有项目、子项目和产品的名称都是 ASF 的商标。尽管并非所有暴露出的产品名称（即“ Foo”）都可能是 ASF 的专有商标，但所有“Apache Foo”形式的名称都应该是 ASF 的专有商标。 47 | 48 | **术语**：**项目**或**子项目**是由 PMC 管理的社区和任何相关产品；同一商标指南适用于两者。**产品**是一种特定的、可下载的软件产品，我们的用户可能希望以某种方式进行使用。产品商标有一些具体的要求。注意，大多数项目和子项目发布的产品名称相同（例如 Apache Foo 项目发布了一个名为 Apache Foo 的软件产品)。 49 | 50 | # 网站导航链接原则 51 | 52 | 无论您的项目网站使用哪种主导航系统，它都必须具有指向主网站 `www.apache.org` 关键页面的文本链接。这些链接可以出现在项目或子项目的所有顶级页面使用的主导航系统中。 53 | 54 | - “许可证”应链接到： `www.apache.org/licenses/` 55 | - “赞助”或“捐赠”应链接到： `www.apache.org/foundation/sponsorship.html` 56 | - “赞助商”、“感谢”或“感谢我们的赞助商”应链接到： `www.apache.org/foundation/thanks.html` 57 | - “安全性”应该链接到项目的特定页面，该页面详细描述用户如何安全地报告潜在漏洞，或者链接到主页面 [www.apache.org/security/](http://www.apache.org/security/) 58 | - 所有项目都必须有指向 ASF 主页 `www.apache.org` 的链接。这可能是主导航系统中的精选链接，也可能是主页文本中的文本链接。最佳做法是在首页上包含简短的句子或段落，以表明该项目是 Apache 项目，是更大的开发人员和用户社区的一部分。 59 | 60 | 如果您对指向 ASF 主页的链接有更适合项目 Web 展示的建议，请告知商标@。 61 | 62 | **包括指向第三方的“感谢”链接**-如果您的项目通常有公司捐赠软件许可证或支持项目提交人，请遵循[公司认可准则](http://www.apache.org/foundation/marks/linking)。重要的是要确保与正式赞助计划相关的材料以截然不同的方式公开展示此类页面。 63 | 64 | # HTTPS 还是 HTTP？ 65 | 66 | 项目可以免费使用 http，https 或协议的相关链接作为网站导航链接所需的强制链接。 67 | 68 | 建议（但不是要求）项目： 69 | 70 | - 使用 https 链接，使用 http 时目标自动切换到 https 71 | - 对所有其他目标使用协议相关链接 72 | 73 | # 商标归属原则 74 | 75 | - 所有项目或产品主页必须具有所有可用的 Apache 商标的显著商标归属。其他项目页面应显示其上任何标记的归属。例如： 76 | 77 | > Apache Foo、Foo、Apache、Apache 羽毛 logo 和 Apache Foo 项目 logo 是 Apache 软件基金会在美国和其他国家的注册商标。 78 | 79 | 它可能出现在页面页脚或任何其他合适的位置。 80 | 81 | - 在每个项目或产品主页的顶部，以及项目名称出现的每个页面的顶部横幅上，无论是标题文本还是在运行文本中第一次出现的名称，都应该在“Apache Foo”项目名称的首要位置旁边添加合适的™或®符号。这突出了我们的商标主张，并强调了它对我们的重要性。 82 | - 必须对网站上引用的任何其他组织的商标给予正确的归属。当在 ASF 项目网站上显示时，所有非 ASF 商标都必须归所有人所有。可以针对每个引用的标记专门执行此操作，或者一般地，在网页的页脚中执行此操作。具体举例： 83 | 84 | > FooBar 和 FooBar logo 是 Yoyodyne，Inc. 的商标。 85 | 86 | 要提供通用的商标归属（以涵盖使用大量商标的情况，或者在我们不确定哪些词是哪个组织的商标的情况下），您可以添加： 87 | 88 | > 提及的所有其他标记可能是其各自所有者的商标。 89 | 90 | # LOGO和图形原则 91 | 92 | - Logo 也是识别商标的重要方式。对于项目的官方 logo（如果有，特别是使用 ASF 羽毛 logo），请确保在图形有一个小的“TM”符号与它相邻。对于包含项目 logo 的页面，请确保在属性中“... 和项目 logo 是商标...”。 93 | - 项目可以选择在 logo 中使用 Apache 羽毛。有关正确的 Apache [视觉标识和羽毛图形](http://www.apache.org/foundation/press/kit/#links)的详细信息，请使用press @。 94 | 95 | # 技术支持...Logo 96 | 97 | 鼓励项目将主 logo 改为“Powered By ...”或“Project Inside” logo。第三方可以使用此 logo 来表示他们使用了相关产品构建产品或服务。虽然我们必须确保主要产品 logo 与 Apache 项目提供的产品相关联，但我们允许第三方与自己的产品一起更广泛地使用[“Powered by ...” logo](http://www.apache.org/foundation/marks/faq/#poweredby) 。 98 | 99 | [由 Apache 支持的 logo](http://www.apache.org/foundation/press/kit/#poweredby) 可供所有项目使用（或请求更新）。 100 | 101 | # 项目元数据 102 | 103 | 所有项目都必须为项目本身或它们所制作的所有产品版本提供 DOAP（项目描述）文件或条目，或者提供结构化的数据，以便 projects.apache.org 网站可以找到它。按照[指南](https://projects.apache.org/about.html)制作 DOAP 文件并注册，可以使 ASF 更好地以各种方式展示其所有项目和产品。 104 | 105 | 更新 [Apache 商标列表](http://www.apache.org/foundation/marks/list/)，简要描述每个软件产品。未来，我们希望从所有产品的 DOAP 文件中生成此列表。 106 | 107 | # 其他商标要求 108 | 109 | 如果您的项目有特定软件语言的子项目，请确保恰当地命名项目。例如，“Apache Xerces Perl”不合适，因为它没有正确地使用商标“Perl”。更好的项目名称是“Apache Xerces for Perl”。例如，ASF 可以允许名为 FooBar 的第三方发布名为“Foo Bar Software for Apache Xerces”或“Bar Foo Services for Apache Xerces”的软件产品。由于 Xerces 是我们的商标，因此 ASF 不允许 FooBar 使用名称“Foo Bar Xerces”或“BarFoo Xerces”。“ Perl”（[Perl Foundation 商标](https://www.perlfoundation.org/trademarks.html)）一词的使用也是如此。 110 | 111 | **注册商标** 如果PMC想要请求对其项目商标进行合法注册，请注册其商标，请遵循 [REGREQUEST 指南](http://www.apache.org/foundation/marks/register#register)。 112 | 113 | ## 与项目相关的 NON-APACHE.ORG 域名 114 | 115 | 为了确保商标一致，以及用户知道 ASF 和 PMC 提供的官方内容，所有的项目都必须托管在 ProjectName.apache.org 域中，并由 PMC 管理所有内容。 116 | 117 | **重要说明：**项目不得使用第三方拥有的域名托管官方项目内容。必须迁移内容，或者将域注册转移到 ASF。 118 | 119 | 如果进入 Apache 孵化器的新社区使用了很长时间的现有域名，并且拥有庞大的用户群，那么一旦该被孵化项目毕业进入 TLP，可能会请求保留这些名称以供有限使用。 120 | 121 | **非 apache.org 域的孵化步骤** 122 | 123 | - 在孵化期间，PPMC 必须与 Apache Infrastructure 合作，将所有需要的域名注册正式转移到 ASF。作为一个非营利组织，ASF 期望这些域名是会被捐赠给 ASF 的。 124 | 125 | 创建 INFRA JIRA 来向 ASF 申请接管捐赠的域名所有权。 126 | 127 | - PPMC 应该将其打算如何使用非 apache.org 域名的计划发送给 Brand Management / trademarks @ 进行批准。 128 | 129 | - 在孵化期间，PPMC 必须将所有面向开发的信息以及主要项目主页转换为官方 ProjectName.apache.org 主页。在项目毕业之前，需要完成这些转换。 130 | 131 | **使用 non-apache.org 域要考虑的因素** 132 | 133 | - 主要的开发主页必须托管在 ProjectName.apache.org，该主页包含潜在贡献者在决定是否加入该项目前需要了解的所有常见事项。 134 | - 向潜在贡献者推广该项目的主要链接应该始终直接指向 ProjectName.apache.org 资源，而不是非 apache.org 域。 135 | - 在大多数情况下，non-apache.org 域应该简单地重定向到 ProjectName.apache.org/path 域内的某个地方，除非被孵化项目有使用非 apache.org 域的充分理由： 136 | 137 | -- 在项目进入 ASF 之前，用户和贡献者社区就已经非常熟悉该域。 138 | 139 | -- 域仅用于提供终端用户级别的信息。 140 | 141 | -- 该域在外观上与 Apache 网站一样都是 Apache 商标，并为所有可能的贡献者话题（例如下载，API文档，邮件列表等）提供直接指向 project.ao/path 的清晰链接。 142 | 143 | **non-apache.org 域批准示例** 144 | 145 | 这些是例外，大多数新项目并非如此： 146 | 147 | - openoffice.org 是一个面向用户的门户网站，具有悠久的历史和数百万的用户。继续作为用户门户为现有的非技术用户提供服务很重要。 148 | - groovy-lang.org 是长期运行的面向用户的门户。该域仍被用作终端用户门户，包括 Groovy 语言本身的信息。开发人员信息（供 Groovy 代码库的贡献者使用），讨论和下载都在 groovy.apache.org 网站上。 149 | 150 | # 项目商标清单 151 | 152 | 所有 Apache 顶级项目都应该完全符合这些指南。任何不符合要求的项目都必须使用商标 @，以确保它们符合要求。所有孵化器项目要么在毕业前符合所有要求，要么制定具体的短期行动计划，以在毕业后短期内完成要求（如果网站更新存在技术问题等）。 153 | 154 | 如有品牌问题，请直接与商标 @ 联系 - 不再需要在董事会报告中包括此内容。 155 | 156 | **项目品牌报告清单** - [项目网站基础](http://www.apache.org/foundation/marks/pmcs#websites)：主页为 project.apache.org 157 | 158 | - [项目命名和描述](http://www.apache.org/foundation/marks/pmcs#naming)：使用正确的 Apache 形式描述产品等。 159 | - [网站导航链接](http://www.apache.org/foundation/marks/pmcs#navigation)：包括导航栏链接，包括 www.apache.org 的链接 160 | - [商标属性](http://www.apache.org/foundation/marks/pmcs#attributions)：包括页脚中所有 ASF 商标的归属 161 | - [Logo 和图形](http://www.apache.org/foundation/marks/pmcs#graphics)：包括 TM，在您的网站上使用一致的产品 logo 162 | - [项目元数据](http://www.apache.org/foundation/marks/pmcs#metadata)：DOAP 文件签入且更新 163 | - [阅读 PMC 商标职责](http://www.apache.org/foundation/marks/responsibility.html) 164 | 165 | # 理由 166 | 167 | 该原则有助于提升和改善 ASF 中所有项目的形象，并表明所有 Apache® 项目都是“开发人员和用户社区”的一部分，我们认为这是我们成功的重要因素。虽然每个项目都按照 Apache Way 的准则来管理自己的事务，但一个一致的公共品牌和网络的存在，能够将所有的项目与知名的 `www.apache.org` 主页联系在一起，通过确保终端用户和未来贡献者了解如何找到官方项目资源，这将使我们都受益。 168 | 169 | 同样，在我们的项目页面上正确显示 Apache 名称和 logo 有助于维护我们对其所包含商标的合法权利。使用合适的 ™ 和 ® 符号，并正确使用商标来指代真实软件产品，是我们告诉世界（和律师）这些商标对我们有价值的关键方式。 170 | 171 | **有问题吗** 有疑问的 Apache Committer 可以联系[商标委员会](http://www.apache.org/foundation/marks/contact#pmc)。[官方的商标原则](http://www.apache.org/foundation/marks/)解释了其他组织应该如何引用 Apache 项目商标和 logo。还提供了 [ASF 商标列表](http://www.apache.org/foundation/marks/list)和 [潜在商标滥用准则](http://www.apache.org/foundation/marks/reporting.html)。 172 | 173 | Apache 孵化器中的孵化项目有详细的[孵化项目商标指南](http://incubator.apache.org/guides/branding.html)。有关这些指南的问题直接发送至 general@incubator 列表。毕业进入顶级项目之前，孵化项目必须遵守所有项目商标要求。 174 | 175 | # 重要说明 176 | 177 | **本 ASF 政策声明中的任何内容不得解释为允许任何第三方声称与 Apache 软件基金会或其任何项目有任何关联，或暗示 ASF 对任何第三方产品、服务或事件的任何批准或支持。** 178 | 179 | 本文档针对 ASF 的内部社区和管理我们项目的 PMC，并且不覆盖或替代我们的[正式商标政策](http://www.apache.org/foundation/marks/)。如果您有一个未解决的问题或者想进一步了解，请[与我们联系](http://www.apache.org/foundation/marks/contact#pmc)。可获取更多有关商标法律和政策的更多[资源](http://www.apache.org/foundation/marks/resources)。 180 | -------------------------------------------------------------------------------- /apache/securityreport/Apache软件安全报告.md: -------------------------------------------------------------------------------- 1 | - **原文标题：** The Apache Software Foundation Blog 2 | - **原文链接：** https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report2 3 | - **提交路径：** translation/apache/securityreport/Apache软件安全报告.md 4 | 5 | # Apache软件基金会博客 6 | Apache 软件基金会安全报告：2021年 7 | 8 | 概要：本报告探讨了2021年 Apache 软件基金会所有项目的安全状况。我们回顾了关键指标、特定漏洞以及 ASF 项目用户受安全问题影响的最常见方式。 9 | 10 | 发布时间：2022 年 1 月 11 | 12 | 作者：Mark Cox，Apache软件基金会安全副总裁 13 | 14 | ## 背景 15 | 16 | Apache 软件基金会 (ASF) 的安全委员会负责监督和协调所有 350 多个 Apache 项目中漏洞的处理。我们成立于 2002 年，由所有志愿者组成，我们对如何处理问题有一个[标准流程](https://s.apache.org/cveprocess)，这个流程包括我们的项目必须如何披露安全问题。 17 | 18 | 在 Apache 项目中发现安全问题的任何人都可以将它们报告给 security@apache.org，在那里它们会被记录下来并传递给相关的[专门安全团队](https://apache.org/security/projects.html)或项目管理委员会 (PMC) 来处理。安全委员会监控所有项目报告的所有问题，并在整个漏洞生命周期中跟踪问题。 19 | 20 | 安全委员会负责确保问题得到妥善处理，并积极提醒项目突出的问题和责任。作为董事会委员会，我们有能力采取行动，包括阻止其未来的发布，或者在最坏的情况下，如果项目对处理其安全问题没有响应，则将项目退休归档。这与 Apache 许可证 v2.0一起，是 ASF 围绕官方发布的一般治理功能的关键部分，使 ASF 能够保护个人开发人员，并让用户有信心部署和依赖 ASF 软件。 21 | 22 | 对所有安全报告的监督以及我们开发的工具使我们能够轻松创建有关问题的指标。我们的上一份报告[涵盖了2020年的指标](https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1)。 23 | 24 | ## 2021年统计数据 25 | 26 | 2021 年，我们的安全电子邮件地址总共收到了约 18,500 封电子邮件。在垃圾邮件过滤和讨论主题分组之后，有 1272 个（2020年：946个，2019年：620个）非垃圾邮件主题。不幸的是，安全报告有时确实看起来像垃圾邮件，尤其是当它们包含大量附件或大型视频时，因此安全团队会仔细审查所有邮件，以确保真实安全报告不会错过太长时间。 27 | ![img](https://lh4.googleusercontent.com/JkcSHlIicN0zI32I7IObMaAMJKNhGiOyIONHk2PpOTjNH2xO69iLKhx57es3x4wwTlHvF1mXt1o-OVXiFHQ647vjhxsp6XQ_bkL6F4Kl3zcwwz43H2C4DxihbFvUZ5rWPc7e-CgS) 28 | 29 | *图1：2021 年 ASF 安全电子邮件主题的细分* 30 | 31 | 图1给出了这 1272 个电子邮件主题的细分。359 个电子邮件主题 (28%) 与 Apache 许可证使用困惑相关的问题。由于许多项目都使用 Apache 许可证，而不仅仅是那些在 ASF 保护伞下的项目，当人们看到 Apache 许可证并且他们不明白它是什么时，他们可能会感到困惑。这在手机上最常见，例如在设置菜单中显示许可证的手机上，通常是由于包含 Google 根据 Apache 许可证发布的软件。我们不再回复这些电子邮件。这比 2020 年收到的 257 个有所增加。 32 | 33 | 接下来的 1272 个（26%）中，337 个电子邮件主题是大家询问非安全（通常是支持类型）问题。 34 | 35 | 接下来的 135 份报告是研究人员在 Apache 网站上报告的问题。这些几乎总是误报；研究人员报告我们启用了目录列表、源代码可见、公共“.git”目录等等。这些报告通常是一些公开可用的扫描工具的未经过滤的输出，并且通常是报告者要求我们为他们的报告提供某种金钱奖励（赏金）的地方。 36 | 37 | 剩下的 441 份（2020年：376份，2019年：320份）报告，涉及2021年的新漏洞，涵盖99个顶级项目。这 441 份报告是外部报告者和内部报告者的混合体。例如，如果一个项目自己发现了一个问题，并按照ASF流程为其分配了一个 CVE（通用漏洞和暴露）名称并解决了它，我们仍然会在这里计算它。我们不会保留能够提供内部报告与外部报告细分的指标。 38 | 39 | 下一步是相应的项目对报告进行分类，以查看它是否真的是一个问题。无效的报告和实际上不是漏洞的报告将被拒绝返回给报告者。在接受的其余问题中，它们被分配了适当的CVE名称，并最终发布了修复程序。 40 | 41 | 截至 2022 年 1 月 1 日，这 441 份报告中有 50 份仍在分类和调查中。这是指一个项目正在处理一个问题，但截至 2022 年 1 月 1 日的快照，还没有拒绝该问题或为其分配一个 CVE。这个数字高于我们通常的预期，这是由于 2021 年 12 底有大量的报告涌入造成的。 42 | 43 | 剩下的 391 个（2020：341 份、2019：301 份）报告导致我们分配了 183 个（2020：151、2019：122）个 CVE 名称。有些漏洞报告可能包含多个问题，有些报告跨多个项目，有些报告是重复的，即不同的报告者发现了相同的问题，因此所接受的报告与 CVE 名称之间并没有一个精确的一对一的映射。Apache 安全委员会负责处理 CVE 名称分配，并且是 MITRE 候选命名机构 (CNA)，因此任何 ASF 项目中所有关于 CVE 名称的请求都要通过我们来处理，即使报告者不知道，直接联系 MITRE 或者在联系我们之前公开一个问题。 44 | 45 | ## 值得注意的事件 46 | 47 | 2021 年有几件事值得讨论；要么是因为它们是严重的、高风险的，它们有现成的漏洞利用情况，要么是受到媒体的关注。这些事件包括： 48 | 49 | - 1 月：在 Apache Velocity ( [CVE-2020-13959](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13959) )的默认错误页面中发现了一个跨站点脚本 (XSS) 漏洞，该[漏洞](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13959)影响了许多公共可访问的网站。尽管已经有了修复方法，但需要几个月的时间才能制作一个包含修复程序的新版本，导致报告者提前公布了它。因此，安全团队深入研究了受影响 PMC 的所有未解决问题，以确保它们都得到处理。 50 | - 1 月：发布了一份报告，显示[恶意软件](https://www.redpacketsecurity.com/new-pro-ocean-crypto-miner-targets-apache-activemq-oracle-weblogic-and-redis-installs/)仍在利用(https://www.redpacketsecurity.com/new-pro-ocean-crypto-miner-targets-apache-activemq-oracle-weblogic-and-redis-installs/)超过 5 年未打补丁的[Apache ActiveMQ](https://www.redpacketsecurity.com/new-pro-ocean-crypto-miner-targets-apache-activemq-oracle-weblogic-and-redis-installs/)实例 ( [CVE-2016-3088](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3088) ) 51 | - 6 月：Airflow PMC 发布了一篇博客(https://blogs.apache.org/foundation/entry/success-at-apache-security-in)，介绍了他们如何处理安全问题，用户有时部署更新的速度很慢 ( [CVE-2020-17526](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2020-17526) ) ，以及依赖关系中的缺陷会如何影响 Airflow[的博客](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2020-17526)。 52 | - 7 月：第三方博客解释了[威胁参与者](https://www.trendmicro.com/en_us/research/21/g/threat-actors-exploit-misconfigured-apache-hadoop-yarn.html)如何[利用配置错误的 Apache Hadoop YARN](https://www.trendmicro.com/en_us/research/21/g/threat-actors-exploit-misconfigured-apache-hadoop-yarn.html)服务 53 | - 8 月：一位研究人员发现了[ HTTP/2 实现中](https://portswigger.net/research/http2)的[一些问题](https://portswigger.net/research/http2)。Apache HTTP 服务器受到中等漏洞 ( [CVE-2021-33193](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33193) ) 的影响 54 | - 9 月：在[ApacheCon 2021 的主题演讲](https://www.youtube.com/watch?v=1bExbql_-AI)中，讨论了安全委员会、美国关于改善国家网络安全的行政命令，以及第三方安全项目，例如 OpenSSF 下的安全项目。 55 | - 9 月：Apache OpenOffice 中的一个漏洞可能允许恶意文档在打开后运行任意代码 ( [CVE-2021-33035](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-33035) ) 56 | - 10 月：在 Apache HTTP 服务器中发现了一个严重问题。默认配置保护了这个漏洞，但在没有这些保护的自定义配置中，如果启用了 CGI 支持，这可能导致远程代码执行 ( [CVE-2021-41773](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41773) )。在向安全团队报告该问题 5 天后，该问题在一个更新中得到修复，但很快发现该修复不充分，并在 3 天后发布了进一步的更新来完全解决该问题 ( [CVE-2021-42013](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42013) )。对于这个问题存在一个 MetaSploit 漏洞。 57 | - 10 月：HackerOne的互联网漏洞悬赏[Internet Bug Bounty](https://hackerone.com/ibb)计划扩展到(https://lists.apache.org/thread/k27wqlr1zpppmorvo36r1nvxrg1yolq1)，包括 Apache Airflow、Apache HTTP Server 和 Apache Commons。与其他许多项目不同，该项目依赖于漏洞发现者遵循标准的 ASF 通知流程，并允许发现者在修复后和问题公开后为符合条件的问题索取奖励。 58 | - 12 月：Log4J 2（[CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228)，“Log4Shell”）是一个流行和常见的Java日志库，其中的一个[漏洞](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228)允许远程攻击者在默认和可能的安装中实现远程代码执行。该问题被广泛利用，在发布修复程序的前一天就开始了。有一个 MetaSploit 模块来解决这个问题。在修复版发布后，一些后续的 Log4J 漏洞也被修复，但没有一个具有相同的影响或默认条件。 59 | - 12 月：ASF 受邀参加 2022 年的一个围绕开源安全的论坛。[白宫发出邀请以提高开源安全性](https://www.bloomberg.com/news/articles/2021-12-23/white-house-extends-invitation-to-improve-open-source-security)。我们在会议之前制作了一份[立场文件](https://cwiki.apache.org/confluence/display/COMDEV/Position+Paper)。 60 | - 2021年还发布了其他RCE漏洞，这些漏洞在 Apache OFBiz ( [CVE-2020-9496](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9496)、[CVE-2021-26295](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-26295) )、Apache Airflow（例如[CVE-2020-11978](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11978)）、Apache Druid ( [CVE-2021-25646](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25646) )、 Apache Tapestry ( [CVE-2021-27850](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27850) ) 和 Apache Storm ( [CVE-2021-38294](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38294) )得到修复。 61 | 62 | ## 时间表 63 | 64 | 我们的安全团队和项目管理团队都是志愿者，因此我们不会就问题的处理给出任何正式的 SLA。但是，我们可以分解流程每个部分的目的和目标： 65 | 66 | 分类：我们的目标是在三个工作日内处理发送到[security@apache.org](mailto:security@apache.org)的邮件。我们不会对此流程进行度量或报告，因为我们会评估每个接受到问题的严重性，并适当地应用我们拥有的有限资源。该团队由来自不同项目 PMC 的极少数志愿者组成。安全团队将报告转发给 PMC 后，PMC 将回复报告者。有时，由于收到电子邮件的大小限制，报告者发送的报告附有大型 PDF 文件甚至是开发视频，但由于收到的电子邮件的大小限制，这些文件无法发送给我们，所以请确保任何后续行动是一个简单的纯文本电子邮件。 67 | 68 | 调查：一旦将报告发送到项目管理委员会的私有邮件列表中，分类和调查的过程会根据项目、资源的可用性和要评估的问题数量而有所不同。由于安全问题是私下处理的，我们会将报告发送到仅由 PMC 组成的私有邮件列表中。因此，这些报告不会传达给每个项目提交者，因此每个项目中只有一小部分人能够进行调查并作出响应。作为一般准则，我们尽量确保项目在报告后 90 天内对问题进行分类。ASF 安全团队会跟进任何超过 90 天的未处理问题。 69 | 70 | 修复：一旦安全问题被分类和接受，修复问题的时间表取决于项目本身的时间表。严重程度较低的问题最常被保留到预先计划的版本。 71 | 72 | 公告：我们的流程允许项目在发布修复版本和发布漏洞之间最多有几天的时间。所有漏洞和缓解软件版本都通过[announce@apache.org](mailto:announce@apache.org)列表[公布](mailto:announce@apache.org)。我们现在的目标是让它们在发布后的一天内出现在公共 CVE 项目列表中，对于关键问题甚至更快。 73 | 74 | ## 结论 75 | 76 | Apache 软件基金会的项目是高度多样化和独立的。他们有不同的语言、社区、管理和安全模式。然而，每个项目都有一个共同点，那就是在处理报告的安全问题时有一个一致的流程。 77 | 78 | ASF 安全委员会与项目团队、社区和报告者密切合作，以确保问题得到快速、正确的处理。这种负责任的监督是 The Apache Way 的一项原则，有助于确保Apache软件的稳定性和可信赖性。 79 | 80 | 该报告提供了 2021 年的指标，显示从收到的18500封电子邮件中，我们筛选出超过 390 份与 ASF 项目相关的漏洞报告，从而修复了 183 (CVE) 问题。与 2020 年相比，处理的非垃圾邮件主题数量增加了 34%，实际漏洞报告数量增加了 17%，分配的 CVE 增加了 21%。 81 | 82 | 虽然 ASF 经常会快速推出关键问题的更新，但报告显示，用户正被 ASF 软件中多年未能更新的旧问题所利用，而供应商（以及他们的用户）仍然在使用有已知未修复漏洞的生命周期结束的版本。这将继续是一个大问题，我们致力于解决这个全行业的问题，以找出我们可以做些什么来提供帮助。 83 | 84 | 如果您有想要分享的漏洞信息，[请与我们联系](http://apache.org/security/#reporting-a-vulnerability)或对此报告发表评论，请参阅[公共安全讨论邮件列表](https://lists.apache.org/list.html?security-discuss@community.apache.org)。 85 | -------------------------------------------------------------------------------- /apache/securityreport/Apache软件安全报告2019.md: -------------------------------------------------------------------------------- 1 | - **原文标题：** The Apache Software Foundation Blog 2 | - **原文链接：** https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report 3 | - **提交路径：** translation/apache/securityreport/Apache软件安全报告2019.md 4 | 5 | # Apache软件基金会博客 6 | Apache 软件基础安全报告：2019 年 7 | 8 | 概要：本报告探讨了2019日历年所有Apache软件基金会项目的安全状况。我们回顾了关键指标、特定漏洞以及 ASF 项目用户受安全问题影响的最常见方式。 9 | 10 | 发布时间： 2020 年 1月 31日 11 | 12 | 作者：Mark Cox，Apache 软件基金会安全副总裁 13 | 14 | ## 背景 15 | Apache软件基金会（ASF）的安全委员会负责监管和协调所有 300 多个Apache项目中漏洞的处理。我们成立于 2002 年，由所有志愿者组成，我们对如何处理问题有一个[标准流程](https://s.apache.org/cveprocess)，这个过程包括我们的项目必须如何披露安全问题。 16 | 17 | 在Apache项目中发现安全问题的人都可以将其报告给 security@apache.org，在那里它们被记录下来并传递给相关的[专门安全团队](https://apache.org/security/projects.html)或项目管理委员会（PMC）进行处理。安全委员会查看所有地址中报告的所有问题，并在整个漏洞生命周期中跟踪问题。 18 | 19 | 安全委员会负责确保问题得到妥善处理，并将积极提醒各项目其悬而未决的问题和责任。作为董事会委员会，我们有能力采取行动，包括阻止其未来的发布，或者在最坏的情况下，如果项目对处理其安全问题没有响应，则将项目归档。这与 Apache 软件许可证一起，是 ASF 围绕官方发布的通用治理的关键组成部分，使 ASF 能够保护个人开发人员，并让用户有信心部署和依赖 ASF 软件。 20 | 21 | 对所有安全报告的监管以及我们开发的工具使我们能够轻松创建有关问题的统计信息。 22 | 23 | ## 2019年统计数据 24 | 25 | 2019年，我们的安全地址总共收到了超过 18，000 封电子邮件。在垃圾邮件过滤和主题分组之后，会出现 620 个非垃圾邮件主题。不幸的是，许多安全报告确实看起来像垃圾邮件，因此安全团队会仔细检查所有邮件，以确保不会长时间错过真实的报告。 26 | ![img](https://blogs.apache.org/foundation/mediaresource/fa9b3fe8-0616-40ee-a93e-b96b5dce460f) 27 | 28 | *图表 1：2019 年 ASF 安全电子邮件主题细分* 29 | 30 | 图 1 给出了这 620 个主题的细分。138 个主题（22%）是 Apache 许可证使用困惑相关的问题。由于许多项目使用 Apache 许可证，而不仅仅是 ASF 保护伞下的项目，因此当用户看到 Apache 许可证并且他们不了解它是什么时，他们可能会感到困惑。这在手机上最常见，例如在设置菜单中显示许可证的手机上，通常是由于包含 Google 根据 Apache 许可证发布的软件。 31 | 32 | 接下来 620 个（26%）中，162 个是电子邮件主题，它们不是垃圾邮件，但也不是新漏洞的报告。这些人通常会询问支持类型的问题或如何处理旧的漏洞。 33 | 34 | 剩下的 320 份关于 2019 年新漏洞的报告，这些报告涵盖了 84 个顶级项目。这 320 份报告既来源于外部报告者也来源内部报告者;例如，如果项目自己发现了问题，并按照 ASF 流程为其分配了 CVE 名称并解决了它。请注意，我们不跟踪报告者隶属关系，并且 ASF 报告者经常使用非 ASF 电子邮件地址进行报告，因此我们不会对内部报告与外部报告进行细分。 35 | 36 | 下一步是相应的项目对报表进行分类，以查看它是否确实是一个问题。在此阶段，无效报告或实际上根本不是漏洞的内容会被拒绝返回给报告者。在接受的其余问题中，它们被分配了适当的 CVE 名称，并最终发布了修复程序。 37 | 38 | 截至 2020 年 1 月 1 日，这 320 份报告中有 19 份仍在分类中（即项目尚未确定该报告是被接受还是被拒绝）。分类和调查的过程在时间上有所不同，具体取决于项目、资源的可用性和要评估的问题数量。作为一般准则，我们努力确保项目在报告后的 90 天内对问题进行分类。解决问题的时间表取决于项目本身的时间表，而严重程度较低的问题通常保留到将来预先计划的版本中。 39 | 40 | 其余已关闭的 301 报告导致我们分配了 122 个 CVE 名称。某些漏洞报告可能包含多个问题，某些报告跨多个项目，并且某些报告是重复的，其中不同的报告者发现了相同的问题，因此所接受的报告与 CVE 名称之间并没有一个精确的一对一的映射。Apache 安全委员会负责处理 CVE 名称分配，并且是 Mitre 候选命名机构 （CNA），因此任何 ASF 项目中对 CVE 名称的所有请求都将通过我们来处理，即使报告者不知道，并直接与 Mitre 联系或在联系我们之前公开提出问题。 41 | 42 | ## 值得注意的事件 43 | 44 | 在2019年期间，有一些事件值得讨论;要么是因为它们是严重和高风险的，要么因为它们有现成的漏洞，要么是由于媒体的关注。其中包括： 45 | 46 | 2019 年 1 月：Securonix [发布了一份报告](https://www.securonix.com/resources/securonix-threat-research-detecting-persistent-cloud-infrastructure-hadoop-yarn-attacks-using-security-analytics-moanacroner-xbash/)，概述了尚未配置身份验证的 Apache Hadoop 实例的攻击增加。公共漏洞和Metasploit模块的存在是为了在未受保护的Hadoop YARN系统上执行远程代码执行。 47 | 48 | 2019 年 4 月：Apache HTTP Server 2.4 中的一个漏洞 （[CVE-2019-0211](https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2019-0211)）。有权在 Web 服务器上编写脚本的用户可以将这些权限提升为 root。此问题有一个公共漏洞利用。 49 | 50 | 2019 年 4 月：旧版 Apache Axis 中的一个漏洞，该漏洞解析了[从过期域中不安全检索到的文件](https://rhinosecuritylabs.com/application-security/cve-2019-0227-expired-domain-rce-apache-axis/)，从而允许远程执行代码（CVE-2019-0227）。 51 | 52 | 2019 年 6 月：Jonathan Leitschuh 在发现许多 Java [构建依赖项通过不安全的路径](https://twitter.com/JLLeitschuh/status/1138116614623244288)（即 HTTP 而不是 HTTPS）下载后与我们联系。我们本身没有将这些漏洞归类为安全漏洞，因为利用它们需要在构建时进行 MITM 攻击。我们与 ASF 项目合作，包括报告者确定的项目，以确保我们使用安全的URL。现在，在 2020 年，许多存储库需要安全URL。 53 | 54 | 2019 年 8 月：Black Duck Synopsys 团队审查了较旧的 Struts 版本和公告，发现报告的受影响版本中存在一些差异。Struts团队仔细研究了他们的发现，并在需要时[发布了更正](https://cwiki.apache.org/confluence/display/WW/S2-058)。如果用户运行的是旧版本，而他们认为这些版本不受基于公告的问题的影响，但实际上确实如此，则这可能很重要。但是，这些相同的用户可能容易受到已修复的其他问题的影响，因此我们始终建议用户升级到最新版本的 Struts，以确保他们拥有的版本包含所有已发布的安全问题的修补程序。 55 | 56 | 2019 年 8 月：Netflix 发现了许多影响各种 HTTP/2 实现的拒绝服务漏洞。对包含 HTTP/2 实现的 ASF 项目进行了调查，并分析了报告的问题。Apache HTTP Server和Apache TrafficServer都[发布了](https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2019-9517)[更新](https://lists.apache.org/thread/sv7wjbqsfcb7c2jm4ndxxls6j7lk63fr)，以解决影响它们的拒绝服务问题。Apache Tomcat还对HTTP / 2处理进行了性能改进，但这些问题[未被归类为拒绝服务](https://lists.apache.org/thread/shfnf6c86z82z2k5lgn934hy88rdp46o)。 57 | 58 | 2019 年 9 月：[RiskSense 报告](https://www.ivanti.com/lp/security/assets/s2/enterprise-ransomware-through-the-lens-of-threat-and-vulnerability-management?rsredirect=)强调了已知被勒索软件使用的漏洞，其中包括 ASF 项目中的四个漏洞。这四个漏洞在前几年都已修复，并且在任何勒索软件利用它们之前都有可用的更新和缓解措施。用户应始终确保他们关注他们使用的任何 ASF 项目中的安全更新，并优先针对任何远程或关键漏洞进行更新。这四个漏洞是： 59 | 60 | - Apache ActiveMQ中的CVE-2016-3088。以 [XBash](http://blog.nsfocusglobal.com/threats/vulnerability-analysis/xbash-malware-security-advisory/) 为目标，这个问题很容易被利用。它在 Active MQ 5.14.0 中已修复，并且还提供了缓解措施。 61 | 62 | - Apache Tomcat 中的 CVE-2017-12615。在列表中看到此问题令人惊讶，因为它会影响非默认且不太可能出现的缺陷。但是，这是 Lucky（“Satan”的变体）探讨的一个问题，因此如果有一个以这种方式配置的服务器，它将被暴露。此问题仅影响非默认配置的 Windows 平台，已在 Tomcat 7.0.81 中修复，并且还提供了缓解措施。请注意，Lucky 还将针对可访问的 Tomcat Web 管理控制台上的弱密码进行暴力攻击。 63 | 64 | - CVE-2017-5638在Apache Struts中。已知此问题[在外部被利用](https://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html)，但是在发布咨询和修复后发现了第一个利用。由[ Lucky（“Satan”的变体）使用](https://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html)。它在 Struts 2.3.32 和 2.5.10.1 中已修复，并且还提供了缓解措施。 65 | 66 | - CVE-2018-11776在Apache Struts中。Lucky 也使用过这个问题。它在Struts 2.3.35，2.5.17中已修复，可以使用可能的缓解措施，但建议进行升级。 67 | 68 | 2019 年 12 月：Apache Olingo 中存在一个允许 XML 外部实体 （XXE） 攻击的漏洞 （[CVE-2019-17554](https://lists.apache.org/thread/lkpr8f4bgydjxx4dy5m8cxwshyxgylc5)）。例如，此问题可用于从服务器检索任意文件。此问题存在一个公共漏洞利用示例。 69 | 70 | Apache Solr 在过去一年中出现了许多缺陷，这些缺陷可能允许远程代码执行。一些问题以及 Metasploit 模块都存在公开漏洞。 71 | 72 | 欧盟委员会EU-FOSSA 2项目赞助了漏洞赏金计划，供用户在 Apache Kafka 和 Apache Tomcat 中发现安全问题。Apache Kafka 中没有修复任何问题。Apache Tomcat 中修复了两个问题：[CVE-2019-0232](https://tomcat.apache.org/security-9.html#CVE-2019-0232)（严重性高，影响Windows平台，包括Metasploit模块在内的公开攻击是可用的）和 [CVE-2019-0221](https://tomcat.apache.org/security-9.html#CVE-2019-0221)（严重性低）。除了运行漏洞赏金外，EU-FOSSA 2还在 2019 年 6 月[赞助了一次成功的黑客马拉松](https://joinup.ec.europa.eu/collection/eu-fossa-2/news/eu-fossa-2-apache-hackathon)。 73 | 74 | # 结论 75 | 76 | Apache软件基金会的项目是高度多样化和独立的。它们具有不同的语言、社区、管理和安全模型。但是，每个项目的共同点之一是如何处理报告的安全问题的一致过程。 77 | 78 | ASF 安全委员会与项目团队、社区和报告者密切合作，确保问题得到快速、正确的处理。这种负责任的监管是 The Apache Way 的一项原则，有助于确保Apache软件的稳定性和可信赖性。 79 | 80 | 该报告提供了 2019 年的指标，显示了我们从收到的 18，000 封电子邮件中分类了 300 多个漏洞报告，从而修复了 100 多个（CVE）问题。如果您有想要分享的漏洞信息或对此报告的评论，[请与我们联系](http://apache.org/security/#reporting-a-vulnerability)。 81 | -------------------------------------------------------------------------------- /apache/securityreport/Apache软件安全报告2020.md: -------------------------------------------------------------------------------- 1 | - **原文标题：** The Apache Software Foundation Blog 2 | - **原文链接：** https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1 3 | - **提交路径：** translation/apache/securityreport/Apache软件安全报告2020.md 4 | 5 | # Apache软件基金会博客 6 | Apache 软件基础安全报告：2020 年 7 | 8 | 概要：本报告探讨了 2020 年所有Apache软件基金会项目的安全状况。我们回顾了关键指标、特定漏洞以及 ASF 项目用户受安全问题影响的最常见方式。 9 | 10 | 发布时间：2021 年 1 月 11 | 12 | 作者：Mark Cox，Apache 软件基金会安全副总裁 13 | 14 | ## 背景 15 | 16 | Apache 软件基金会（ASF）的安全委员会负责监管和协调所有 340 多个Apache项目中漏洞的处理。我们成立于 2002 年，由所有志愿者组成，我们对如何处理问题有一个[标准流程](https://s.apache.org/cveprocess)，这个过程包括我们的项目必须如何披露安全问题。 17 | 18 | 在 Apache 项目中发现安全问题的人都可以将其报告给 security@apache.org，在那里它们会被记录下来并传递给相关的[专门安全团队](https://apache.org/security/projects.html)或项目管理委员会（PMC）来处理。安全委员会监控所有项目报告的所有问题，并在整个漏洞生命周期中跟踪问题。 19 | 20 | 安全委员会负责确保问题得到妥善处理，并积极提醒项目突出的问题和责任。作为董事会委员会，我们有能力采取行动，包括阻止其未来的发布，或者在最坏的情况下，如果项目对处理其安全问题没有响应，则将项目归档。这与 Apache 软件许可证一起，是 ASF 围绕官方发布的通用治理的关键组成部分，使 ASF 能够保护个人开发人员，并让用户有信心部署和依赖 ASF 软件。 21 | 22 | 对所有安全报告的监管以及我们开发的工具使我们能够轻松创建有关问题的指标。我们的上一份报告[涵盖了2019年的指标](https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report)。 23 | 24 | ## 2020年统计数据 25 | 26 | 2020 年，我们的安全电子邮件地址共收到 18，000 封电子邮件。在垃圾邮件过滤和讨论主题分组之后，有 946个（2019：620个）非垃圾邮件主题。不幸的是，许多安全报告看起来像垃圾邮件，因此安全团队会仔细检查所有邮件，以确保真实报告不会错过太长时间。 27 | ![img](https://lh5.googleusercontent.com/oNWUqrENFNXhWmIgpq1Sq9LLO9LbJdOXcxf0M4LomAYDGiENfs60pIdAHkttKM4kMDf2IfKVja-IjJA9lYOwabmW-xyIwxvuC0D4LEaA9LLp57HWONyR3VscbR80ndJMXz7Zr2jA) 28 | 图表 1：2020 日历年 ASF 安全电子邮件主题细分 29 | 30 | 31 | 图 1 给出了这 946 个主题的细分。257 个主题（27%）是 Apache 许可证使用困惑相关的问题。由于许多项目使用 Apache 许可证，而不仅仅是那些在 ASF 保护伞下的项目，当人们看到 Apache 许可证并且他们不明白它是什么时，他们可能会感到困惑。这在手机上最常见，例如在设置菜单中显示许可证的手机上，通常是由于包含 Google 根据 Apache 许可证发布的软件。我们不再回复这些电子邮件。这几乎是我们在 2019 年看到的数字的两倍。 32 | 33 | 接下来的 946 个（23%）中，220 个电子邮件主题是大家询问非安全（通常是支持类型）问题。 34 | 35 | 接下来的 93 份报告是研究人员在 Apache 网站上报告问题。这些几乎总是误报;研究人员报告我们启用了目录列表、源代码可见或缺少各种域标头。这些报告通常是一些公开可用的扫描工具的未经过滤的输出，并且经常是报告者要求我们为他们的报告提供某种金钱奖励（赏金）的地方。 36 | 37 | 剩下的 376（2019年：320份）份关于 2020 年新漏洞的报告，这些报告涵盖了 101 个顶级项目。这 376 份报告既来源于外部报告者也来源内部报告者。例如，如果一个项目自己发现了一个问题，并按照 ASF 流程为其分配了一个 CVE 名称并解决了它，我们仍然会在这里计算它。我们不会保留能够提供内部报告与外部报告细分的指标。 38 | 39 | 下一步是相应的项目对报告进行分类，以查看它是否确实是一个问题。无效报告和实际上不是漏洞的报告将被拒绝返回给报告者。在接受的其余问题中，它们被分配了适当的 CVE 名称，并最终发布了修复程序。 40 | 41 | 截至 2021 年 1 月 1 日，这 376 份报告中有 35 份仍在分类中（即项目尚未确定该报告是被接受还是被拒绝）。 42 | 43 | 剩下的已关闭的341 个（2019：301个）报告导致我们分配了 151 个（2019：122个）CVE名称。某些漏洞报告可能包含多个问题，某些报告跨多个项目，并且某些报告是重复的，其中不同的报告者发现了相同的问题，因此所接受的报告与 CVE 名称之间并没有一个精确的一对一的映射。Apache 安全委员会负责处理 CVE 名称分配，并且是 Mitre 候选命名机构 （CNA），因此任何 ASF 项目中对 CVE 名称的所有请求都将通过我们来处理，即使报告者不知道，并直接与 Mitre 联系或在联系我们之前公开提出问题。 44 | 45 | ## 值得注意的事件 46 | 47 | 2020 年有几件事件值得讨论;要么是因为它们是严重和高风险的，要么因为它们有现成的漏洞，要么是由于媒体的关注。其中包括： 48 | 49 | - 2 月：Tomcat ([CVE-2020-1938](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1938))中的一个问题引起了媒体的兴趣，因为它被赋予了品牌和名称（"Ghostcat"），并在 Tomcat 发布公告之前由第三方协调中心披露（尽管在 Tomcat 的新版本中修复了该问题）。虽然这个漏洞如果被利用会很后果严重，但它只会影响 Tomcat 安装，它将未受保护的 AJP 连接器暴露给不受信任的网络（即使没有此问题，这也不是一件好事）。这限制了受影响的安装数量。针对此问题，各种概念验证漏洞都是公开的，包括 Metasploit 漏洞。 50 | 51 | - 5 月：网络安全和基础设施安全局（CISA）发布了[十大经常被利用的漏洞列表](https://www.cisa.gov/uscert/ncas/alerts/aa20-133a)，包括([CVE-2017-5638](https://nvd.nist.gov/vuln/detail/CVE-2017-5638))，这是 Apache Struts 2中的远程命令执行（RCE）漏洞，于2017年披露并修复。已知此问题[在外部被利用](https://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html)，但是第一次利用是在发布公告和修复程序后发现的。 52 | 53 | - 7 月：Apache Guacamole 1.1.0 及更早版本的版本容易受到 RDP、[CVE-2020-9497](https://lists.apache.org/thread/syfbkgg9ct1bkhm35lgr7ry6cswlvnwy) 和 [CVE-2020-9498](https://lists.apache.org/thread/zn57pp47fft5hjdm09trdny64mryf7bf) 中的问题的影响。如果用户连接到恶意或受损的 RDP 服务器，则可能导致内存泄露和可能的远程代码执行。 54 | 55 | - 8 月：Apache Struts 中存在一个漏洞 （[CVE-2019-0230](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0230)），可能导致任意代码执行。为了利用此漏洞，攻击者需要将恶意对象图导航语言 （OGNL） 表达式注入到 OGNL 表达式中使用的属性中。尽管 Struts 具有解决潜在注入表达式的缓解措施，但 2.5.22 之前的版本保留了一个打开的攻击界面，该攻击媒介已在此问题的[更新中修复](https://cwiki.apache.org/confluence/display/WW/S2-059)。存在一个针对此问题的 metasploit 漏洞利用。 56 | 57 | - 11 月：以前，每个ASF项目都负责编写自己的CVE条目并将其提交给Mitre。因为使用了旧格式导致 CVE 条目被拒绝 ，导致很多 Apache 项目提交的 CVE 没有及时更新到 CVE 数据库中。我们发布了一个内部工具，为处理安全问题的项目提供了一种编辑、验证和提交其条目到 Mitre 的方法。我们的目标是在问题发布后的一天内更新 CVE 数据库。 58 | 59 | - 12 月：CVE 项目发布了新的自动化 API，ASF 成为第一个使用它获取实时 CVE 名称的组织。现在，我们按需分配它们，而不是让安全团队持有预先请求的名称池，而该服务负责处理发送给 PMC 的电子邮件和自动化处理之前需要手动完成的功能。我们预计在 2021 年将实现更多自动化，使我们能够进一步简化项目的 CVE 流程。 60 | 61 | Metasploit 漏洞利用还针对 Apache OFBiz（CSRF，[CVE-2019-0235](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0235)）、Apache OpenMeetings（DoS、[CVE-2020-13951](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13951)）、Apache Flink（任意读/写 RCE [CVE-2020-17518](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17518) ）中的 2020 年问题发布, [CVE-2020-17519](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17519) ) 62 | 63 | ## 时间表 64 | 65 | 我们的安全团队和项目管理团队都是志愿者，因此我们不会在处理问题时提供任何正式的 SLA 。但是，我们可以分解流程每个部分的目的和目标： 66 | 67 | 分类：我们的目标是在三个工作日内处理发送到 [security@apache.org](mailto:security@apache.org) 的邮件。我们不会对此流程进行度量或报告，因为我们会评估每个接受到问题的严重性，并适当地应用我们拥有的有限资源。该团队由来自不同项目 PMC 的极少数志愿者组成。在安全团队将报告转发给 PMC 后，他们将回复报告者。因此，如果您向我们报告了问题，并且在一周后未收到任何回复，请向我们发送后续电子邮件。有时，报告者会发送报告，附上大型PDF文件，甚至是开发视频，而这些文件甚至视频都没有提交给我们，因此请确保任何后续行动都是简单的纯文本电子邮件。 68 | 69 | 调查：一旦报告被发送到项目管理委员会的私人列表，分类和调查的过程在时间上会有所不同，具体取决于项目，资源的可用性和要评估的问题的数量。由于安全问题是私下处理的，我们会将报告发送到私有邮件列表中。因此，这些报告不会传达给每个项目提交者，因此每个项目中只有一小部分人能够进行调查并作出响应。作为一般准则，我们努力确保项目在报告后的 90 天内对问题进行分类。ASF 安全团队会追踪超过 90 天的所有未处理问题。 70 | 71 | 修复：一旦对安全问题进行分类并接受，解决问题的时间表取决于项目本身的计划。严重性较低的问题最常保留到将来预先计划的版本中。 72 | 73 | 公告：我们的流程允许项目在推送修复版本和漏洞公告之间最多几天的时间内，让镜像赶上来。所有漏洞都通过[announce@apache.org](mailto:announce@apache.org) 列表[公布](mailto:announce@apache.org)。我们现在的目标是让它们在公告后的一天内出现在公开的 Mitre 列表中。 74 | 75 | ## 结论 76 | Apache软件基金会的项目是高度多样化和独立的。他们有不同的语言、社区、管理和安全模型。但是，每个项目的共同点之一是如何处理报告的安全问题的一致过程。ASF 安全委员会与项目团队、社区和报告者密切合作，确保快速正确地处理问题。这种负责任的监管是 The Apache Way 的一项原则，有助于确保Apache软件的稳定性和可信赖性。 77 | 78 | 该报告提供了 2020 年的指标，显示我们从收到的 18，000封电子邮件中对与 ASF 项目相关的 370 多个漏洞报告进行了分类，从而修复了 151（CVE）问题。处理的非垃圾邮件主题数量比 2019 年增加了 53%，实际漏洞报告的数量增加了 13%，分配的 CVE 数量增加了 24%。 79 | 80 | 如果您有想要分享的漏洞信息或对此报告的评论，[请与我们联系](http://apache.org/security/#reporting-a-vulnerability)。 81 | -------------------------------------------------------------------------------- /apache/securityreport/Apache软件安全报告2022.md: -------------------------------------------------------------------------------- 1 | # Apache Security 2022 年度报告 2 | 3 | - **原文标题：** ASF Security Report: 2022 4 | - **原文链接：** https://blogs.apache.org/security/entry/asf-security-report-2022 5 | - **提交路径：** apache/securityreport/asf-security-report-2022 6 | - **翻译：** 王嘉树 7 | - **校对：** 姜宁 8 | 9 | 10 | 11 | # Apache Security 2022 年度报告 12 | 13 | > 本报告探讨了 2022 年所有 Apache 软件基金会 (Apache Software Foundation ASF) 项目的安全状况。我们回顾了关键指标、特定漏洞以及 ASF 项目用户受安全问题影响的最常见方式。 14 | 15 | 阅读大约需要8分钟 16 | 17 | 发表于：2023 年 1 月 31 日 18 | 19 | ## 背景 20 | 21 | **Apache 软件基金会** （ASF） 的安全委员会负责监督和协调 350 多个 Apache 项目中的漏洞处理，每天要处理收到的60多封电子邮件。成立于 2002 年，我们对于如何处理问题有一个[一致流程](https://s.apache.org/cveprocess)，这个流程包括我们的项目必须如何披露安全问题。2022 年期间，ASF 聘请了一名管理员来帮助处理接收到的漏洞响应工作，团队的其他成员都是志愿者。 22 | 23 | 在任何 ASF 项目中发现安全问题的任何人都可以将其报告给 [security@apache.org](mailto:security@apache.org)，这些问题将被记录下来并传递给相关的[专门安全团队](https://apache.org/security/projects.html)或**项目管理委员会** （project management committees PMC）在私下里进行处理。一般来说; 每个社区或 PMC 负责处理自己的漏洞。安全委员会监控所有项目报告的所有问题，并在整个漏洞生命周期中跟踪问题。它还帮助各个社区进行安全响应和流程。最后，安全委员会将此情况向 ASF 董事会报告，作为 ASF 监督和治理职能的一部分。 24 | 25 | 安全委员会负责确保问题得到妥善处理，并积极提醒项目方未解决的问题和责任。作为董事会委员会，我们有能力采取行动，包括阻止项目未来的发布；或者在最坏的情况下，如果项目对处理其安全问题没有回应，则将项目存档。它与 Apache License v2.0 一起，是 ASF 围绕官方版本进行总体监督功能的关键部分，使 ASF 能够保护个人开发人员，并让用户有信心部署和依赖 ASF 软件。 26 | 27 | 对所有安全报告的监管以及我们开发的工具使我们能够轻松创建有关问题的指标。我们的上一份报告[涵盖了 2021 年的指标](https://news.apache.org/foundation/entry/apache-software-foundation-security-report2)。 28 | 29 | ## 2022年统计数据 30 | 31 | 2022 年，我们的安全电子邮件地址总共收到了 22,600 多封电子邮件（2021 年：18,500 封）。在垃圾邮件过滤和讨论主题分组之后，有 1402 个非垃圾邮件主题（2021 年：1272 个、2020 年：946 个、2019 年：620 个）。不幸的是，安全报告有时看起来像垃圾邮件，特别是当它们包含大量附件或大视频时，因此我们会仔细审查所有邮件，以确保不会错过真实的报告。 32 | 33 | ![image](https://github.com/alc-beijing/translation/assets/39830125/d7917507-9a42-4512-8f68-a176b00cbd6d) 34 | 35 | 36 | 图 1 给出了这 1402 个主题的细分。305 个主题（22%）是人们对 Apache 许可证感到困惑的地方。由于许多项目都使用 Apache 许可证，而不仅仅是 ASF 项目，因此人们在看到 Apache 许可证时可能会感到困惑，不明白它是什么。这是最常见的，例如，在设置菜单中显示许可证的手机上，通常是由于包含 Google 根据 Apache 许可证发布的软件。我们不会回复这些电子邮件。这与我们 2021 年收到的 359 份类似。 37 | 38 | 1402 个中的接下来的 415 个 (30%) 是电子邮件主题，人们询问非安全（通常是支持类型）问题。我们会向这些电子邮件发送模板回复。 39 | 40 | 接下来的 83 份报告（6%）是研究人员报告的基础设施问题，例如影响我们网站的问题。这些几乎总是误报；研究人员报告我们启用了目录列表、源代码可见、公共“.git”目录等等。这些报告通常是某些公开可用的扫描工具的未经过滤的输出，并且通常伴随着某种金钱奖励（赏金）的请求。 41 | 42 | 到 2022 年，新漏洞报告数量为 599 个（42%）（高于 2021 年：441 个、2020 年：376 个、2019 年：320 个），涵盖 122 个顶级项目。这 599 份报告既包括外部报告，也包括项目及其社区内部发现的问题。我们不跟踪这些类别之间的细分。例如，如果项目自己发现了问题，他们将遵循相同的 ASF 流程为其分配 **CVE**（Common Vulnerabilities and Exposures 常见漏洞和暴露）名称并解决它，我们仍然在这里计算它。 43 | 44 | 下一步是让项目对报告进行分类，看看这是否确实是一个问题。无效报告和实际上不是漏洞的报告将被拒绝返回给报告者。对于已接受的其余问题，它们会被分配适当的 CVE 名称，并最终发布修复程序。 45 | 46 | 截至 2023 年 1 月 1 日，这 599 份报告中的 109 份仍在分类和调查中。这是项目正在处理某个问题但尚未拒绝该问题或为其分配 CVE 的情况。这个数字看起来相当高，但它确实在这年中有所不同，并且在年末往往会更高，当时许多开发商都在休假。严重程度较低的问题在成为新版本的一部分之前需要一段时间的情况并不罕见，因此在任何给定时间总会有许多问题处于开放状态并且当前正在处理中。 47 | 48 | 其余 490 份报告（2021 年：391 个、2020 年：341 个、2019 年：301 个）导致我们分配了 210 个 CVE 名称（2021 年：183 个、2020 年：151 个、2019 年：122 个）。有些漏洞报告可能包含多个问题，有些报告跨多个项目，有些报告是重复的，不同的报告者发现相同的问题，因此接受的报告与 CVE 名称之间不存在精确的一对一映射。 49 | 50 | 2022 年报告最多的四个项目是 Airflow，有 49 份报告（2022 年发布了 19 个 CVE），Commons 有 37 份报告（4 个 CVE），HTTP Server 有 36 份报告（13 个 CVE），Tomcat 有 26 份报告（6 个 CVE）。Airflow 和 HTTP Server 是 [HackerOne Internet Bug Bounty 计划](https://hackerone.com/ibb)的一部分。 51 | 52 | Apache 安全委员会负责处理 CVE 名称分配，并且是 MITRE **候选命名机构** （Candidate Naming Authority CNA），因此任何 ASF 项目中对 CVE 名称的所有请求都通过我们进行路由，即使报告者不知情并直接联系 MITRE 或公开问题在联系我们之前。 53 | 54 | ## 值得注意的漏洞和事件 55 | 56 | 2022 年有一些漏洞值得强调；要么是因为它们严重且高风险，要么是因为它们容易被利用，要么是因为受到了媒体的关注。其中包括： 57 | 58 | - 1 月：Apache ShenYu 中的一个缺陷可能允许未经身份验证的访问（[CVE-2022-23944](https://www.cve.org/CVERecord?id=CVE-2022-23944)） 59 | - 2 月：Apache APISIX 中存在允许绕过 IP 限制的缺陷 ( [CVE-2022-24112](https://www.cve.org/CVERecord?id=CVE-2022-24112)），这可能会影响仍在使用默认 API 密钥的实例。针对此问题有各种公开的漏洞利用。 60 | - 4 月：**网络安全和基础设施安全局**（Cybersecurity and Infrastructure Security Agency CISA）将 Log4Shell 列入其[15 个经常利用的漏洞](https://www.cisa.gov/uscert/ncas/current-activity/2022/04/27/2021-top-routinely-exploited-vulnerabilities)列表中。 61 | - 4 月：Apache APISIX 中的缺陷可能允许攻击者通过泄露的机密获得访问权限 ( [CVE-2022-29266](https://www.cve.org/CVERecord?id=CVE-2022-29266) ) 62 | - 4 月：如果 CouchDB 在安装时没有得到适当的保护，Apache CouchDB 中的一个缺陷 ( [CVE-2022-24706](https://www.cve.org/CVERecord?id=CVE-2022-24706) ) 可能会允许远程用户无需进行身份验证即可获得管理员权限。针对此问题存在许多公共漏洞，包括 MetaSploit 漏洞。 63 | - 4 月：4 月份 Apache Camel 中报告了一个影响 GitHub 工作流程使用的配置/脚本文件的缺陷，第二天修复了，几个月后在媒体上提到：[合并请求和不安全的 GitHub 工作流程可能会导致供应链攻击](https://www.theregister.com/2022/09/01/google_firebase_apache_camel_github/)。没有发布 CVE，因为 Camel 本身不存在安全漏洞，最终用户也无需采取任何行动。 64 | - 7 月：Apache Spark UI（[CVE-2022-33891](https://www.cve.org/CVERecord?id=CVE-2022-33891)）中的缺陷可能允许恶意授权用户在启用 ACL 的情况下执行任意代码。针对此问题存在公共漏洞，包括 MetaSploit 漏洞。 65 | - 9 月：Apache Pulsar 中存在缺陷（[CVE-2022-33682](https://www.cve.org/CVERecord?id=CVE-2022-33682)），无法启用 TLS 主机名验证。 66 | - 10 月：Apache Commons Text 已更新，默认删除变量插值 ( [CVE 2022-42889](https://www.cve.org/CVERecord?id=CVE-2022-42889) )。这被其他人称为 “Text4Shell”，但此问题与 Log4Shell (CVE-2021-44228) 不同，因为在 Log4Shell 中，字符串插值是可能来自日志消息正文，其中通常包含不受信任的输入。在 Apache Common Text 问题中，相关方法是明确意图并明确记录的，以执行字符串插值，因此应用程序在未经适当验证的情况下无意中传递不受信任的输入的可能性要小得多。 67 | - 12 月：[微软报告称 Zerobt 僵尸网络](https://www.microsoft.com/en-us/security/blog/2022/12/21/microsoft-research-uncovers-new-zerobot-capabilities/)已更新，试图利用 CVE-2021-43013（Apache HTTP Server）和 CVE-2022-33891（Apache Spark）。 68 | 69 | ## 结论 70 | 71 | Apache软件基金会的项目是高度多样化和独立的。他们有不同的语言、社区、管理和安全模型。但是，每个项目的共同点之一是如何处理报告的安全问题的一致过程。 72 | 73 | ASF 安全委员会与项目团队、社区和报告者密切合作，确保快速正确地处理问题。2022 年，我们聘请了一名管理员与志愿者资源一起处理问题。这种负责任的监督是 Apache Way 的一项原则，有助于确保 Apache 软件稳定且值得信赖。 74 | 75 | 该报告提供了 2022 年的指标，显示我们从收到的 22,600 封电子邮件中对超过 599 个与 ASF 项目相关的漏洞报告进行了分类，最终解决了 210 个（CVE）问题。与 2021 年相比，处理的非垃圾邮件主题数量增加了 23%，实际漏洞报告数量增加了 36%，分配的 CVE 数量增加了 15%。我们还重点介绍了我们在帮助组织了解 Log4Shell 问题以及 ASF 等基金会的作用方面所做的工作，并重点介绍了我们开展的一些新的安全举措。 76 | 77 | 如果您有想要分享的漏洞信息，[请联系我们](https://apache.org/security/#reporting-a-vulnerability)，或者使用[公共安全讨论邮件列表](https://lists.apache.org/list.html?security-discuss@community.apache.org)来获取对此报告的评论。 78 | 79 | 由安全副总裁 Mark Cox 发布 2023 年 1 月 31 日 全文1560个单词。 80 | -------------------------------------------------------------------------------- /docs/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ## CONTRIBUTING 2 | 3 | * [工作流程](WORKFLOW.md) [~~DONE~~] 4 | * [翻译指南](GUIDE.md) [TODO] 5 | * [术语表](GLOSSARY.md) [WIP] (持续更新ing) 6 | * [TODOLIST](TODOLIST.md) [WIP] 7 | -------------------------------------------------------------------------------- /docs/GLOSSARY.md: -------------------------------------------------------------------------------- 1 | # 约定书写格式、常见词语和术语表等 2 | 3 | ## 约定书写格式 4 | 5 | - 中文和英文之间 _**加空格**_ 6 | - 中文标点与英文之间 _**不需要加空格**_ 7 | - 中文与数字之间、英文与数字之间都 _**需要加空格**_ 8 | - 出现并列的词请使用 _**中文顿号**_ 9 | - 文中遇到的超链接，_**不需要**_ 跳转超链接进行翻译 10 | - 针对术语词语，可同时附上相对应的中英文（使用中文括号）方便对照理解，格式如下：中文词语（英文词语/英文缩略语） 11 | 12 | ## 常用词语表（即统一翻译列表） 13 | 14 | > 常用词语（即统一翻译列表）指常见的技术类专用词语、固定术语翻译及 Apache 相关专用词语等（欢迎补充完善本定义）。 15 | > 建议在翻译过程中，若遇到下表英文相关词语，尽可能统一使用本表译文。 16 | 17 | | 英文原文 | 中文译文 | 18 | | ------------------------------------------------------- | ------------------------------------------ | 19 | | ASF Vice President for Legal Affairs | ASF 法务副总裁 | 20 | | ASF release | ASF 发行版 | 21 | | ASF product distribution | ASF 产品发行包 | 22 | | ASF Exports Page | ASF 出口商品页 | 23 | | Notification of Updates to this Page | 本页更新通知 | 24 | | Overview | 总览 | 25 | | Frequently Asked Questions | 常见问题列表（FAQs） | 26 | | U.S. export control | 美国政府出口管控 | 27 | | Export Control Classification Number (ECCN) | 美国政府出口管控分类编号（ECCN） | 28 | | Export Administration Regulations (EAR) | 美国政府出口管控条例（EAR） | 29 | | U.S. Government's Bureau of Industry and Security (BIS) | 美国政府工业安全局（BIS） | 30 | | ENC Encryption Request Coordinator | ENC 加密请求协调员 | 31 | | champion | （在孵化器中专指介绍项目进入ASF的）领路人 32 | | cryptography | 密码学技术 | 33 | | encryption | 加密 | 34 | | symmetric algorithm | 对称加密算法 | 35 | | asymmetric algorithm | 非对称加密算法 | 36 | | factorization of integers | 因式分解 | 37 | | discrete logarithms | 离散对数 | 38 | | a multiplicative group of a finite field | 有限域乘法组 | 39 | | Diffie-Hellman over Z/pZ | 基于有限循环群`Z/pZ`的 Diffie-Hellman 算法 | 40 | | Diffie-Hellman over an elliptic curve | 基于椭圆曲线的 Diffie-Hellman 算法 | 41 | | data confidentiality | 数据保密性 | 42 | | source code | 源码 | 43 | | object code | 目标码 | 44 | | Permanent link | 固定链接 | 45 | | XSLT transformer | XSLT 转换器 | 46 | | substring | 子串 | 47 | | script file | 脚本文件 | 48 | | top-level directory | 根目录 | 49 | | distribution's README file | 发行包中的 README 文件 | 50 | | the components of the release | 发行版中组件 | 51 | | License Header | 许可证头 | 52 | | Source Header | 源码头 | 53 | | Contributor | 贡献者 | 54 | | Committer | 提交者 | 55 | | podling | 孵化项目（incubating project） | 56 | | assets | 资产 | 57 | | tarball | 打包文件 | 58 | 59 | ## 术语表 60 | 61 | > 术语：术语，在维基百科中指的是特定专业领域中一般概念的词语，一个术语表示一个概念。在本定义中，特指那些不需要翻译（直接使用英文原文）的专有名词，或 Apache 基金会项目中特指词语、关键字，例如：Apache SkyWalking 等（欢迎补充完善本定义）。 62 | > 建议在翻译过程中，若遇到下表相关英文词语，可以使用英文原文（不需要翻译）。 63 | 64 | - ASF 65 | - PMC 66 | - Apache Foo 67 | - Apache HTTP Server 68 | - Apache SkyWalking 69 | - Apache ShardingSphere 70 | - NOTICE （出现形式为“NOTICE file”时，不翻译 NOTICE） 71 | - LISENCE （出现形式为“LICENSE file”时，不翻译 LISENCE） 72 | 73 | ## 参考 74 | 75 | - [Project listing - Apache](https://projects.apache.org/projects.html) 76 | - [Glossary of Apache-Related Terms - Apache](https://www.apache.org/foundation/glossary.html) 77 | - [术语表 - cloudnativeio/envoy](https://github.com/cloudnativeto/envoy/tree/zh/docs/root/term.md) 78 | -------------------------------------------------------------------------------- /docs/GUIDE.md: -------------------------------------------------------------------------------- 1 | ## 翻译指南 2 | 3 | 1、进入 issue 中指定的链接页面。 4 | 5 | 2、对照页面中英文内容进行翻译。如果追求更高效率的翻译，可以将页面中英文内容复制到 Google Translate 或 DeepL 中，然后再**人工逐字逐句校对一遍，确保没有难以理解、意思不明的句子**。 6 | 7 | 3、将翻译好的文字内容调整为 Markdown 格式（所需语法可以暂且参考[这份指南](https://github.com/JesseZhou-1/Markdown-Grammar-Instruction/blob/main/README.md)）。 8 | 9 | 4、将完成的 Markdown 格式下的翻译文件按照[工作流程](https://github.com/alc-beijing/translation/blob/master/docs/WORKFlOW.md)提交PR。 10 | 11 | ## 注意事项 12 | 13 | 1、翻译之前一定要事先参考[术语表](https://github.com/alc-beijing/translation/blob/master/docs/GLOSSARY.md)，以避免不必要的错误。 14 | -------------------------------------------------------------------------------- /docs/TODOLIST.md: -------------------------------------------------------------------------------- 1 | ## @TODO 2 | 3 | * [ ] 登记表 4 | * [ ] `Contributor` 列表 5 | * [ ] `Reviewer` 列表 6 | * [ ] `Training` 7 | * [x] [工作流程](WORKFLOW.md) [@hanyouqing](https://github.com/hanyouqing) 8 | * [ ] 待翻译资源 [issues](https://github.com/alc-beijing/translation/issues) 9 | * [ ] [翻译指南](GUIDE.md) 10 | * [ ] [术语表](GLOSSARY.md) 11 | * [x] GitHub 模板 ( `Issue`, `PR` ) 12 | * [ ] GitHub 机器人（`/accept`, `/pushed`, `/merged`, `/close`） 13 | * [ ] 构建（GitHub Action/Travis），发布 14 | 15 | 16 | ## Reference 17 | 18 | * [Setting guidelines for repository contributors- GitHub](https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/setting-guidelines-for-repository-contributors) 19 | * [Configuring issue templates for your repository - GitHub](https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/configuring-issue-templates-for-your-repository) 20 | * [Creating a pull request template for your repository - GitHub](https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository) 21 | * [Referencing issues and pull requests - GitHub](https://docs.github.com/en/free-pro-team@latest/github/writing-on-github/basic-writing-and-formatting-syntax#referencing-issues-and-pull-requests) 22 | * [GitHub Action](https://docs.github.com/cn/free-pro-team@latest/actions/quickstart#in-this-article) 23 | * [Building a strong community - GitHub](https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community) 24 | * Robot 25 | * [3ks/issue-man](https://github.com/3ks/issue-man) 26 | * [cloudnativeto/mjolnir-bot](https://github.com/cloudnativeto/mjolnir-bot) 27 | * [Build-a-GitHub-Bot Workshop¶](https://github-bot-tutorial.readthedocs.io/en/latest/) 28 | * [xuexb/github-bot](https://github.com/xuexb/github-bot) 29 | * [draft - k8s new docs contributor - learning path pt 1 - working on a personal fork](https://www.youtube.com/watch?v=MBza4tlp2J0&feature=youtu.be&ab_channel=GeoffreyCline) 30 | -------------------------------------------------------------------------------- /docs/WORKFLOW.drawio: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | -------------------------------------------------------------------------------- /docs/WORKFLOW.md: -------------------------------------------------------------------------------- 1 | ## 准备工作 2 | 3 | 6 | 7 | * Terminal 8 | * [Git](https://git-scm.com/) 9 | * [GitHub](https://github.com/) 10 | 11 | 12 | ## 工作流程 13 | 14 | ![工作流程](images/WORKFLOW.svg) 15 | 16 | ### 1. 认领任务 17 | 18 | 访问 [issue](https://github.com/alc-beijing/translation/issues) 页面，标题以`[翻译]`开头的 issue 为翻译任务，选择未分配的 issue 评论 `/accept` 领取任务，被标记为 `Assignees` 即领取成功。 19 | 20 | @TODO: image 21 | 22 | ### 2. Fork 项目 23 | 24 | 访问 [alc-beijing/translation](https://github.com/alc-beijing/translation) 项目页面，点 `Fork` 克隆项目。 25 | 26 | ![Fork 项目](images/fork.jpg) 27 | 28 | 29 | ### 3. Clone 到本地 30 | 31 | 打开终端，Clone 项目到本地 `~/alc-beijing/translation` (本地路径可自定义)： 32 | 33 | ```sh 34 | $ git clone https://github.com/<你的github名称>/translation ~/alc-beijing/translation 35 | ``` 36 | 37 | ### 4. 创建分支 38 | 39 | ```sh 40 | $ cd ~/alc-beijing/translation 41 | $ git remote add upstream https://github.com/alc-beijing/translation.git # clone 项目后只需执行一次，以后不需要重复执行 42 | $ git fetch upstream master:<自定义分支名> 43 | $ git checkout <自定义分支名> # 分支名建议使用：/ 或 /<文档关键词> 44 | ``` 45 | 46 | ### 5. 本地翻译 47 | 48 | 略 49 | 50 | 工具推荐： 51 | * [Google Translate](https://translate.google.com/) 52 | * [Bing Translator](https://www.bing.com/translator) 53 | * [DeepL](https://www.deepl.com/en/translator) 54 | * [Tatoeba](https://tatoeba.org/eng/sentences/search?query=translate&from=eng&to=cmn) 55 | * [TencentDocs](https://docs.qq.com/) 56 | * [Youdao](http://youdao.com/) 57 | 58 | ### 6. 推送到远程 59 | 60 | ```sh 61 | $ git push origin <自定义分支名> 62 | ``` 63 | 64 | 65 | ### 7. 创建 PR 66 | 67 | 创建 PR 时，可通过 `# issue-id` 引用 issue 链接, 可参考以下文档： 68 | * [Referencing issues and pull requests](https://docs.github.com/en/free-pro-team@latest/github/writing-on-github/basic-writing-and-formatting-syntax#referencing-issues-and-pull-requests) 69 | * [Autolinked references and URLs](https://docs.github.com/en/free-pro-team@latest/github/writing-on-github/autolinked-references-and-urls) 70 | 71 | [Issue 实例](https://github.com/alc-beijing/translation/pull/12) 72 | 73 | ![创建 PR](images/pull-request.jpg) 74 | 75 | 76 | ### 8. Review 77 | 78 | @TODO: Reviewer list 79 | 80 | ### 9. 合并到主干 81 | 82 | @TODO: Merge rules 83 | 84 | 85 | ## Reference 86 | 87 | * [Envoy 中文文档翻译指导手册](https://github.com/cloudnativeto/envoy/blob/zh/docs/root/README.md) 88 | -------------------------------------------------------------------------------- /docs/images/WORKFLOW.svg: -------------------------------------------------------------------------------- 1 |
1. 认领任务
1. 认领任务
Contributor
Contribu...
Reviewer
Reviewer
2. Fork 项目
2. Fork 项目
3. Clone 到本地
3. Clone 到本地
4. 创建分支
4. 创建分支
5. 本地翻译
5. 本地翻译
6. 推送到远程
6. 推送到远程
7. 创建 PR
7. 创建 PR
关闭 Issue
关闭 Issue
9. Merge 到主干
9. Merge 到主干
通过
通过
反馈
反馈
8. Review
8. Review
9. 修改意见
9. 修改意见Viewer does not support full SVG 1.1 -------------------------------------------------------------------------------- /docs/images/clone.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alc-beijing/translation/e12f3bab848b3f4a4164fd601bcf66a904115611/docs/images/clone.jpg -------------------------------------------------------------------------------- /docs/images/fork.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alc-beijing/translation/e12f3bab848b3f4a4164fd601bcf66a904115611/docs/images/fork.jpg -------------------------------------------------------------------------------- /docs/images/pull-request.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alc-beijing/translation/e12f3bab848b3f4a4164fd601bcf66a904115611/docs/images/pull-request.jpg -------------------------------------------------------------------------------- /subtitles/ApacheEverywhere.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:04,000 3 | ALC Beijing 翻译组荣誉出品 4 | 5 | 2 6 | 00:00:04,900 --> 00:00:09,890 7 | Bet somebody that they've used Apache software within the last hour. 8 | 我敢打赌，刚才肯定有人在使用 Apache 软件 9 | 10 | 3 11 | 00:00:10,000 --> 00:00:15,000 12 | And they have, they have. Because not only are particular projects 13 | 结果也确实如此，不仅仅是因为特定的项目 14 | 15 | 4 16 | 00:00:15,270 --> 00:00:22,060 17 | particularly widespread, but the spread of projects is enormous. 18 | 特别受欢迎，还因为 Apache 项目影响深远 19 | 20 | 5 21 | 00:00:22,100 --> 00:00:25,630 22 | And so for instance, if they've used a credit card, 23 | 举例来说，如果使用信用卡， 24 | 25 | 6 26 | 00:00:25,940 --> 00:00:31,090 27 | if they've used television, if they've used a web browser, they've used a laptop. 28 | 看电视，浏览网页，用电脑 29 | 30 | 7 31 | 00:00:31,170 --> 00:00:34,690 32 | It's almost certain that they've used some Apache software, 33 | 这些都会和 Apache 软件有关 34 | 35 | 8 36 | 00:00:35,040 --> 00:00:39,690 37 | not knowing it, not necessarily seeing it. 38 | 只是你没意识到而已。 39 | 40 | 9 41 | 00:00:39,820 --> 00:00:41,380 42 | But it's almost certainly there. 43 | 但它们（Apache软件）一定是在那里的。 44 | 45 | 10 46 | 00:00:41,640 --> 00:00:45,060 47 | And it's unless you've been asleep for the last eight hours, 48 | 除非过去的几个小时，你一直在睡觉 49 | 50 | 11 51 | 00:00:45,210 --> 00:00:48,860 52 | it's really, really hard to go in a modern technological sense, 53 | 只要你和现代科技打交道 54 | 55 | 12 56 | 00:00:49,100 --> 00:00:54,090 57 | more than just a short period of time without using some Apache software. 58 | 哪怕只是很短的时间，你都会用到 Apache 软件。 59 | 60 | 13 61 | 00:00:54,280 --> 00:00:57,260 62 | Why do we give it away? Because it is what we do. 63 | 我们为什么将它们“拱手送人”？因为这就是我们要做的。 64 | 65 | 14 66 | 00:00:57,400 --> 00:01:02,390 67 | because the impact of open source is that openness. 68 | 因为开源本身的影响力就在于开放。 69 | 70 | 15 71 | 00:01:03,360 --> 00:01:07,510 72 | the ability for anyone to come and use and consume and contribute. 73 | Apache 就是要让大家都来使用、消费并贡献 74 | 75 | 16 76 | 00:01:08,720 --> 00:01:14,910 77 | Hundreds and hundreds of years where knowledge was used to generate money. 78 | 过去几千年，知识一直用来赚钱 79 | 80 | 17 81 | 00:01:15,270 --> 00:01:22,760 82 | And the only success factor in society is how much money is my company making. 83 | 社会衡量成功的唯一标准就是你的公司赚了多少钱 84 | 85 | 18 86 | 00:01:23,120 --> 00:01:26,910 87 | I think the ASF has proven that even without making money, 88 | 而 Apache 软件基金会向人们证明，即使不赚钱 89 | 90 | 19 91 | 00:01:27,220 --> 00:01:33,530 92 | we did have a humongous impact in the way which the world runs. 93 | 我们也会给社会带来巨大的影响 94 | 95 | 20 96 | 00:01:33,820 --> 00:01:35,690 97 | What would have defined success? 98 | 什么是成功？ 99 | 100 | 21 101 | 00:01:35,840 --> 00:01:39,440 102 | The project success is based on the people rather than the code. 103 | 项目的成功在于人，而不是代码 104 | 105 | 22 106 | 00:01:39,770 --> 00:01:42,760 107 | And that's pretty much what comes about by the Apache way, 108 | 这就是 Apache 之道 109 | 110 | 23 111 | 00:01:42,980 --> 00:01:46,280 112 | The community is far more important than the code. 113 | 社区远比代码重要。 114 | 115 | 24 116 | 00:01:46,350 --> 00:01:49,030 117 | The code will survive whether or not the community does. 118 | 无论社区能否存活，代码都可以留存下来。 119 | 120 | 25 121 | 00:01:49,040 --> 00:01:51,930 122 | But it won't get any better or be enriched. 123 | 但它一定不会变得更好或更丰富。 124 | 125 | 26 126 | 00:01:52,270 --> 00:01:57,260 127 | They won't go on to succeed unless there's a community that support it. 128 | 除非有一个社区在背后支持它（们），否则它们不会持续发展下去 129 | 130 | 27 131 | 00:01:57,370 --> 00:01:59,440 132 | One of the things we're seeing nowadays 133 | 如今， 134 | 135 | 28 136 | 00:01:59,570 --> 00:02:06,860 137 | is that the lessons learned inside of IT，as far as how to create successful open source projects. 138 | IT 界成功创造了一个又一个的开源项目， 139 | 140 | 29 141 | 00:02:07,170 --> 00:02:11,210 142 | But most important, how to create successful open source communities, 143 | 更重要的是，打造了一个又一个的开源社区，这些大家有目共睹 144 | 145 | 30 146 | 00:02:11,250 --> 00:02:14,060 147 | of which the apache way is most probably the best example of that 148 | 在这点Apache之道或许是最成功的案例 149 | 150 | 31 151 | 00:02:14,120 --> 00:02:18,060 152 | is starting to make inroads in other areas. 153 | 正开始在其他领域取得进展 154 | 155 | 31 156 | 00:02:18,34 --> 00:02:22,14 157 | This excessive open source is gonna expand beyond IT 158 | 这种拓展性的开源将逐渐扩张至IT界之外 159 | 160 | 32 161 | 00:02:22,250 --> 00:02:27,740 162 | is gonna expand beyond other software development in ecosystem. 163 | 将扩张并超越生态中其他软件的发展。 164 | 165 | 33 166 | 00:02:28,070 --> 00:02:36,280 167 | We're seeing open source cities now where the ideas of how to engage the populace, 168 | 我们可以看到开源的城市，在那里关于如何使全体居民参与 169 | 170 | 34 171 | 00:02:36,570 --> 00:02:41,540 172 | how to engage the citizens are using some of the tenets 173 | 如何使全体市民参与的想法正是借鉴了一些（开源的）信条 174 | 175 | 35 176 | 00:02:41,670 --> 00:02:43,710 177 | and some of the ideals of the apache way 178 | 以及一些Apache之道的理念 179 | 180 | 36 181 | 00:02:43,840 --> 00:02:48,560 182 | making sure that there is transparency in all the decision making processes of government. 183 | 确保政府的所有决策过程都可以做到透明。 184 | 185 | 37 186 | 00:02:48,820 --> 00:02:50,360 187 | I mean, this is how you build software, 188 | 这就是软件的开发模式 189 | 190 | 38 191 | 00:02:50,620 --> 00:02:53,680 192 | is by making sure that everyone involve, both the people who are creating the software, 193 | 让大家都参与其中，无论是软件工程师、 194 | 195 | 39 196 | 00:02:53,770 --> 00:02:57,430 197 | who are creating the software, creating the laws, 198 | 软件工程师、立法者 199 | 200 | 40 201 | 00:02:57,520 --> 00:03:02,110 202 | as well as the end users of the software and the citizens who were going to be abiding by the law. 203 | 还是终端的软件用户和那些遵从法律的市民们。 204 | 205 | 41 206 | 00:03:02,120 --> 00:03:07,890 207 | Is everything open? Everything is being done, in an open, public, and transparent manner. 208 | 是所有事情都是公开的吗？所有事情都是在一种公共的、开放的、透明的方式下完成的。 209 | 210 | 42 211 | 00:03:08,090 --> 00:03:11,830 212 | So we're seeing a lot of the tenets of successful open source, 213 | 所以我们看到很多成功开源软件的信条。 214 | 215 | 43 216 | 00:03:12,150 --> 00:03:18,660 217 | A lot of the means of the Apache way transcend the IT community, 218 | Apache 之道的很多方法已经超越了 IT 社区， 219 | 220 | 44 221 | 00:03:18,970 --> 00:03:25,810 222 | and make inroads into government, corporate entities, a heavy industry, manufacturing, machining. 223 | 并运用在政府、公司企业、重工业、工厂、机械领域中。 224 | 225 | 45 226 | 00:03:26,050 --> 00:03:33,010 227 | And I think that's an incredible heritage for the movement we've created. 228 | 这笔遗产价值连城 229 | 230 | 46 231 | 00:03:33,320 --> 00:03:38,240 232 | At the use cases that get me excited are the ones that are about trying to address 233 | 让我感到最激动实际案例，是哪些想要试图解决 234 | 235 | 47 236 | 00:03:38,400 --> 00:03:42,060 237 | any one of those two hundred and sixty different sustainable development goals out there, right? 238 | 二百六十种可持续发展目之中任意一个的软件，对吧？ 239 | 240 | 48 241 | 00:03:42,070 --> 00:03:44,280 242 | if we're going to have a carbon trading market 243 | 如果我们要建立一个碳交易市场的话 244 | 245 | 49 246 | 00:03:44,570 --> 00:03:48,180 247 | we're going to need a distributed ledger system to be able to do that on a global scale 248 | 我们就将需要一个分布式账本系统来在全球范围内实现这一点。 249 | 250 | 50 251 | 00:03:48,520 --> 00:03:54,490 252 | if we're going to eliminate child labor in mines or on fishing boats or in other industries 253 | 如果我们要消除矿上、渔船上或其他行业的童工现象 254 | 255 | 51 256 | 00:03:54,800 --> 00:03:57,010 257 | it's going to be through technologies like this. 258 | 它也将通过向像这样的科技实现。 259 | 260 | 52 261 | 00:03:57,320 --> 00:04:02,530 262 | FIN act is a project that supports Micro finance institutions in giving out loans 263 | FIN act是一个支持小额金融机构为最贫穷的人 264 | 265 | 53 266 | 00:04:02,940 --> 00:04:06,310 267 | and and tracking savings for the poorest of the poor. 268 | 提供贷款和跟踪储蓄的项目。 269 | 270 | 54 271 | 00:04:06,400 --> 00:04:11,410 272 | So it's very rewarding to be able to make these services available to the poor. 273 | 所以，能够让穷人享受到这些服务，是非常有意义的。 274 | 275 | 55 276 | 00:04:11,590 --> 00:04:14,210 277 | Because if you don't have savings, if you don't have loans, 278 | 因为如果你没有储蓄，没有贷款， 279 | 280 | 56 281 | 00:04:14,340 --> 00:04:16,960 282 | if you don't have remittances, that's money transfers, 283 | 没有汇款，也就是转账， 284 | 285 | 57 286 | 00:04:17,140 --> 00:04:20,930 287 | then you don't have contact the global economy and you can't profit 288 | 那你就和全球经济脱节了 289 | 290 | 58 291 | 00:04:21,140 --> 00:04:24,660 292 | when your boat doesn't rise when everybody else's boat rises. 293 | 在大家都向前一步时，你原地踏步，因而你就无法获利 294 | 295 | 59 296 | 00:04:24,850 --> 00:04:27,210 297 | In the case of this project, you're connecting the empowerment 298 | 在这个项目中，你要把最贫困的人的赋能 299 | 300 | 60 301 | 00:04:27,420 --> 00:04:31,860 302 | of the poorest of the poor with the empowerment of the software developers. 303 | 和软件开发者的赋能联系起来。 304 | 305 | 61 306 | 00:04:32,130 --> 00:04:35,040 307 | And you're doing both of them in the context of a community. 308 | 而你是在一个社区的环境下完成这两件事的。 309 | 310 | 62 311 | 00:04:35,550 --> 00:04:42,540 312 | So there are really wonderful parallels between open source software and micro finance. 313 | 所以，开源软件和小微金融之间真的有奇妙的相似之处。 314 | 315 | 63 316 | 00:04:43,070 --> 00:04:47,290 317 | Being part of that, it just gives me a great feeling 318 | 作为其中一员， 319 | 320 | 64 321 | 00:04:47,300 --> 00:04:50,240 322 | that we've been able to change the world for the better 323 | 我们让世界变得更好，这种感觉很棒 324 | 325 | 65 326 | 00:04:50,440 --> 00:04:53,460 327 | A lot of our software helps developing countries. 328 | 我们的很多软件都在帮助发展中国家。 329 | 330 | 66 331 | 00:04:53,740 --> 00:05:00,510 332 | The great strides the world has made today in the last 20 years of globalization, 333 | 在过去20年的全球化进程中，当今世界取得了巨大的进步， 334 | 335 | 67 336 | 00:05:00,870 --> 00:05:07,760 337 | with the developing countries growing and advancing on providing better living conditions 338 | 发展中国家在不断发展、进步，人民生活水平逐步提高 339 | 340 | 68 341 | 00:05:08,000 --> 00:05:12,630 342 | and better economic advancement for its populations 343 | 经济发展欣欣向荣 344 | 345 | 69 346 | 00:05:12,720 --> 00:05:15,430 347 | That's a result of the Free software movements. 348 | 这是自由软件运动的成果之一。 349 | 350 | 70 351 | 00:05:15,750 --> 00:05:19,090 352 | And Apache had a big hand in that. 353 | Apache 在其中发挥了巨大的作用 354 | 355 | 71 356 | 00:05:19,100 --> 00:05:20,010 357 | I feel very strongly. 358 | 我的感觉非常强烈。 359 | 360 | 72 361 | 00:05:20,270 --> 00:05:24,090 362 | The only thing that will save us as a species from our own internal greed 363 | 这是把我们从内心贪婪 364 | 365 | 73 366 | 00:05:24,440 --> 00:05:29,180 367 | and hatred and the distance that we put between human hearts. 368 | 和仇恨中救赎出来，并消除人与人之间冷漠的唯一办法 369 | 370 | 74 371 | 00:05:29,420 --> 00:05:33,960 372 | And I occasionally I'm chided because I am very sensitive person and have thin skin. 373 | 有时大家责备我敏感、脸皮薄 374 | 375 | 75 376 | 00:05:34,100 --> 00:05:37,090 377 | And they say, you need thicker skin. 378 | 他们说，你脸皮应该再厚点。 379 | 380 | 76 381 | 00:05:37,350 --> 00:05:41,090 382 | Now thicker skin puts more distance between human hearts. 383 | 现在 ，厚脸皮让大家更生疏了 384 | 385 | 77 386 | 00:05:41,350 --> 00:05:44,380 387 | It allows more space for “not like me”. 388 | 让大家更讨厌“我” 389 | 390 | 78 391 | 00:05:44,620 --> 00:05:47,840 392 | It allows more space for “us versus them”. 393 | 在“我们“与“他们”之间筑就了一面墙 394 | 395 | 79 396 | 00:05:48,050 --> 00:05:54,010 397 | And that will be our undoing, not just as technologists but as a species. 398 | 而这将是我们的败笔，不仅仅是作为技术专家，更是作为一个物种。 399 | 400 | 80 401 | 00:05:54,360 --> 00:05:59,860 402 | And we are at a crucial point in our evolution, I believe, 403 | 而我相信，我们正处于进化的关键时刻， 404 | 405 | 81 406 | 00:06:00,020 --> 00:06:04,130 407 | where we need to start caring more about each other and less about profit. 408 | 此时我们需要开始更多地关心彼此，而不只是利益。 409 | 410 | 82 411 | 00:06:04,390 --> 00:06:08,230 412 | And the Apache way voices one part of that, 413 | 而Apache之道表达了其中的一部分意思。 414 | 415 | 83 416 | 00:06:08,370 --> 00:06:10,360 417 | I think in a very powerful way. 418 | 我认为以一种非常强大的方式。 419 | 420 | 84 421 | 00:06:10,520 --> 00:06:15,510 422 | When we put community above code, 423 | 当我们更重视社区，而不是代码时， 424 | 425 | 85 426 | 00:06:15,600 --> 00:06:18,610 427 | that gives us the opportunity to have a place 428 | 这就给了我们一个机会， 429 | 430 | 86 431 | 00:06:18,690 --> 00:06:23,410 432 | where people can be passionate about solving other people's problems. 433 | 让人们在这里可以满怀激情地去解决其他人的问题。 434 | 435 | 87 436 | 00:06:23,570 --> 00:06:28,560 437 | That is one element of good empathy. 438 | 而这是好的同理心的要素之一。 439 | 440 | 88 441 | 00:06:29,570 --> 00:06:35,560 442 | 欢迎关注公众号 “ALC Beijing” 443 | 444 | 89 445 | 00:06:35,570 --> 00:06:41,010 446 | 获取更多有关Apache软件基金会信息 447 | -------------------------------------------------------------------------------- /subtitles/Trillions and Trillions Served - Why Apache.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,030 --> 00:00:04,530 3 | what we create runs everywhere 4 | 我们创造的东西遍布全球 5 | 6 | 2 7 | 00:00:04,730 --> 00:00:06,849 8 | it's literally used everywhere in the world 9 | 或者换句话说，全球各地都在使用 10 | 11 | 3 12 | 00:00:07,049 --> 00:00:08,919 13 | today without the Apache，the internet 14 | 如果没有 Apache， 15 | 16 | 4 17 | 00:00:09,119 --> 00:00:10,180 18 | that we know today would not have happened。 19 | 就没有人人在用的互联网 20 | 21 | 5 22 | 00:00:10,380 --> 00:00:12,669 23 | the best database，the best streaming framework. 24 | 没有更好的数据库和流框架。 25 | 26 | 6 27 | 00:00:12,869 --> 00:00:14,349 28 | We're creating industry's. 29 | 我们创建了一个新的产业。 30 | 31 | 7 32 | 00:00:14,548 --> 00:00:17,220 33 | Programming for fun. 34 | 为乐趣而编程。 35 | 36 | 8 37 | 00:00:17,420 --> 00:00:20,409 38 | People. It's a great group of people. 39 | 这是一群很优秀的人。 40 | 41 | 9 42 | 00:00:20,609 --> 00:00:22,419 43 | It's connecting people. It's building bridges 44 | 它把大家紧密联系在一起。它架起一座桥， 45 | 46 | 10 47 | 00:00:22,618 --> 00:00:25,030 48 | people from China people from Europe. 49 | 贯通中国和欧洲。 50 | 51 | 11 52 | 00:00:25,230 --> 00:00:26,940 53 | It doesn't matter what language you speak 54 | 不管讲什么语言 55 | 56 | 12 57 | 00:00:27,140 --> 00:00:28,568 58 | where you come from 59 | 来自何地 60 | 61 | 13 62 | 00:00:28,768 --> 00:00:31,120 63 | Apache is really good at bringing people together 64 | Apache 都能把人们召集在一起 65 | 66 | 14 67 | 00:00:31,320 --> 00:00:33,159 68 | and letting them work together 69 | 协同工作 70 | 71 | 15 72 | 00:00:33,359 --> 00:00:35,709 73 | without companies getting in the way. 74 | 不受公司限制。 75 | 76 | 16 77 | 00:00:35,909 --> 00:00:37,779 78 | Try to learn something from everybody every day. 79 | 我们向他人学习 80 | 81 | 17 82 | 00:00:37,979 --> 00:00:40,750 83 | Inspiring， it makes me want to be better. 84 | 成为更好的自己。 85 | 86 | 18 87 | 00:00:40,950 --> 00:00:43,329 88 | When working with people, 89 | 和这些 90 | 91 | 19 92 | 00:00:43,530 --> 00:00:45,128 93 | there are so much better than yourself 94 | 优秀的人在一起， 95 | 96 | 20 97 | 00:00:45,329 --> 00:00:49,570 98 | you learn a lot. Community，community in more community. 99 | 你会受益匪浅。 一个个小社区组成更大的社区。 100 | 101 | 21 102 | 00:00:49,770 --> 00:00:51,489 103 | People were so open and 104 | 大家都很开放 105 | 106 | 22 107 | 00:00:51,689 --> 00:00:55,059 108 | so engaging and so excited to help. 109 | 很投入，乐于助人。 110 | 111 | 23 112 | 00:00:55,259 --> 00:00:57,669 113 | Don't be afraid to give, to share, you would get more out of it. 114 | 不要害怕给予、分享， 你会收获很多。 115 | 116 | 24 117 | 00:00:57,869 --> 00:00:59,799 118 | I've got more out of Apache 119 | Apache 给予我的，远远超过 120 | 121 | 25 122 | 00:01:00,000 --> 00:01:02,169 123 | than I've ever given. 124 | 我的付出。 125 | 126 | 26 127 | 00:01:02,369 --> 00:01:05,980 128 | Building communities around people who are 129 | 这群人激情澎湃， 130 | 131 | 27 132 | 00:01:06,180 --> 00:01:09,000 133 | passionate about solving problems. 134 | 喜欢解决各种问题， 135 | 136 | 28 137 | 00:01:09,200 --> 00:01:12,969 138 | Create incredibly passionate communities who 139 | 构建一个激情四射的共同体， 140 | 141 | 29 142 | 00:01:13,170 --> 00:01:17,299 143 | are then empowered to create incredibly powerful software. 144 | 然后依托这样的共同体，创建功能强大的软件 145 | 146 | 30 147 | 00:01:17,500 --> 00:01:19,058 148 | The software that we've written 149 | 我们编写的软件 150 | 151 | 31 152 | 00:01:19,259 --> 00:01:21,069 153 | how far it's gone and how 154 | 能走多远 155 | 156 | 32 157 | 00:01:21,269 --> 00:01:24,340 158 | much it's used every day is staggering 159 | 能被多少人使用 160 | 161 | 33 162 | 00:01:24,540 --> 00:01:26,849 163 | I'm proud to be a part of an 164 | 这个组织在改变世界， 165 | 166 | 34 167 | 00:01:27,049 --> 00:01:29,349 168 | organization that has changed the world 169 | 能成为其中一员，我倍感自豪 170 | 171 | 35 172 | 00:01:29,549 --> 00:01:32,649 173 | and I don't think many people understand 174 | 可能很多人还不了解 175 | 176 | 36 177 | 00:01:32,849 --> 00:01:35,659 178 | exactly how Apache has changed the world. 179 | Apache 如何改变了整个世界。 180 | 181 | 37 182 | 00:01:35,859 --> 00:01:37,579 183 | It's impacted everyone when there's 184 | 它影响甚远 185 | 186 | 38 187 | 00:01:37,780 --> 00:01:39,230 188 | something now you know people can touch 189 | 包括你每天接触到的物品 190 | 191 | 39 192 | 00:01:39,430 --> 00:01:41,480 193 | and interact with their phones and 194 | 和手机、汽车的交互 195 | 196 | 40 197 | 00:01:41,680 --> 00:01:43,429 198 | their car. And you know you realize all 199 | 当你会意识到 200 | 201 | 41 202 | 00:01:43,629 --> 00:01:45,739 203 | of them are open-source software and it's like 204 | 这些都是开源软件时， 你会感叹 205 | 206 | 42 207 | 00:01:45,939 --> 00:01:48,049 208 | wow okay this is something that's truly 209 | 开源真的在 210 | 211 | 43 212 | 00:01:48,250 --> 00:01:49,039 213 | changed the world. 214 | 改变世界。 215 | 216 | 44 217 | 00:01:49,239 --> 00:01:52,009 218 | You know it's more than just technology 219 | 这不仅仅是技术， 220 | 221 | 45 222 | 00:01:52,209 --> 00:01:54,679 223 | it's more than just coding. It's bringing 224 | 不仅仅是代码 225 | 226 | 46 227 | 00:01:54,879 --> 00:01:58,730 228 | new ideas new aspects there's so much 229 | 它更是一种新思想， 230 | 231 | 47 232 | 00:01:58,930 --> 00:02:01,399 233 | more we can do with the technology. 234 | 科技创造价值， 235 | 236 | 48 237 | 00:02:01,599 --> 00:02:03,439 238 | We already have that is something that's 239 | 我们已经拥有了 240 | 241 | 49 242 | 00:02:03,640 --> 00:02:04,399 243 | that's amazing 244 | 令人惊叹的 245 | 246 | 50 247 | 00:02:04,599 --> 00:02:06,709 248 | with the foundation. That is something 249 | 基金会, 250 | 251 | 51 252 | 00:02:06,909 --> 00:02:09,259 253 | it's so exciting, and that is the thing 254 | 令人振奋的成就, 255 | 256 | 52 257 | 00:02:09,459 --> 00:02:11,420 258 | that really sort of keeps me interested 259 | 它（基金会)一直吸引着我、 260 | 261 | 53 262 | 00:02:11,620 --> 00:02:13,100 263 | in and I'm passionate about. 264 | 让我充满激情。 265 | 266 | 54 267 | 00:02:13,300 --> 00:02:15,890 268 | There's still so much work to do, so like 269 | 未来的路还很长（路漫漫其修远兮）， 270 | 271 | 55 272 | 00:02:16,090 --> 00:02:19,340 273 | I'm gonna be busy for a while I think 274 | 我会全力以赴为之奋斗（吾将上下而求索）， 275 | 276 | 56 277 | 00:02:19,539 --> 00:02:21,580 278 | doing this kind of work and and I hope 279 | 我希望大家 280 | 281 | 57 282 | 00:02:21,780 --> 00:02:25,500 283 | many other people are too. 284 | 都会为之奋斗不息 285 | 286 | 58 287 | 00:02:26,310 --> 00:02:31,390 288 | The best software in the world I mean 289 | 世界上最好的软件， 290 | 291 | 59 292 | 00:02:31,590 --> 00:02:34,459 293 | that's the ASF 294 | 就是 ASF 295 | --------------------------------------------------------------------------------