Lines Matching full:the
13 This document contains the LLVM Developer Policy which defines the project's
14 policy towards developers and their contributions. The intent of this policy is
15 to eliminate miscommunication, rework, and confusion that might arise from the
16 distributed nature of LLVM's development. By stating the policy in clear terms,
21 This policy is also designed to accomplish the following objectives:
23 #. Attract both users and developers to the LLVM project.
27 #. Keep the top of tree as stable as possible.
29 #. Establish awareness of the project's :ref:`copyright, license, and patent
30 policies <copyright-license-patents>` with contributors to the project.
33 contributing one-off patches can do so in an informal way by sending them to the
36 developer to see it through the process.
43 LLVM, but we expect more from frequent contributors to keep the system as
45 meet the following requirements in order for LLVM to maintain a high standard of
51 Developers should stay informed by reading the `LLVM Discourse forums`_ and subscribing
52 to the categories of interest for notifications.
55 are interested in and watching the flow of the project as a whole.
57 Contibutions to the project are made through :ref:`GitHub Pull Requests <github-reviews>`.
58 You can subscribe to notification for areas of the codebase by joining
59 one of the `pr-subscribers-* <https://github.com/orgs/llvm/teams?query=pr-subscribers>`_
61 indicates which team is associated with a particular paths in the repository.
63 You can also subscribe to the "commits" mailing list for a subproject you're interested in,
72 one of the `issue-subscribers-* <https://github.com/orgs/llvm/teams?query=issue-subscribers>`_
74 You may also subscribe to the `llvm-bugs
76 of bugs and enhancements occurring in the entire project. We really appreciate people
89 When making a patch for review, the goal is to make it as easy for the reviewer
93 of LLVM. This makes it easy to apply the patch. For information on how to
94 clone from git, please see the :ref:`Getting Started Guide <sources>`.
97 patches may not apply correctly if the underlying code changes between the
98 time the patch was created and the time it is applied.
105 notices to the patches themselves. These notices conflict with the LLVM
113 The LLVM project uses email to communicate to contributors outside of the
118 Therefore, the LLVM community requires contributors to have a public
128 LLVM has a code-review policy. Code review is one way to increase the quality of
139 to be removed in the future, removing an already-deprecated feature, upgrading a
142 awareness of. For such changes, the following should be done:
150 * When performing the code review for the change, please add any applicable
151 "vendors" group to the review for their awareness. The purpose of these
154 testing feedback on the changes to alert us to unacceptable breakages. The
160 People interested in joining the vendors group can do so by clicking the
161 "Join Project" link on the vendor's "Members" page in Phabricator.
163 * When committing the change to the repository, add appropriate information
164 about the potentially breaking changes to the ``Potentially Breaking Changes``
165 section of the project's release notes. The release note should have
166 information about what the change is, what is potentially disruptive about
171 * After the change has been committed to the repository, the potentially
172 disruptive changes described in the release notes should be posted to the
174 Discourse. The post should be tagged with the ``potentially-breaking`` label
175 and a label specific to the project (such as ``clang``, ``llvm``, etc). This
177 potentially disruptive changes. It is a lower-traffic alternative to the
179 with the ``potentially-breaking`` label, go to your user preferences page in
180 Discourse, and add the label to one of the watch categories under
188 The LLVM Project aims to evolve features quickly while continually being in a
189 release-ready state. In order to accomplish this, the project needs volunteers
190 willing to do the less glamorous work to ensure we produce robust, high-quality
195 Community members can find active and inactive maintainers for a project in the
196 ``Maintainers.rst`` file at the root directory of the individual project.
198 Maintainers are volunteering to take on the following shared responsibilities
201 * ensure that commits receive high-quality review, either by the maintainer
213 Each top-level project in the monorepo will specify one or more
216 except the responsibilities span the project rather than a limited area
217 within the project. If you cannot reach a maintainer or don't know which
220 reasonable candidate for removal from the monorepo. A discussion should be
221 started on Discourse to find a new, active lead maintainer or whether the
224 All contributors with commit access to the LLVM Project are eligible to be a
227 * engaging in their responsibilities the majority of the days in a month,
228 * ensuring that they, and the community members they interact with, abide by
229 the LLVM Community Code of Conduct, and
238 adds yourself to the area(s) you are volunteering for. Alternatively, an
239 existing maintainer can nominate you by posting a PR, but the nominee must
240 explicitly accept the PR so that it's clear they agree to volunteer within the
241 proposed area(s). The PR will be accepted so long as at least one maintainer in
242 the same project vouches for their ability to perform the responsibilities and
243 there are no explicit objections raised by the community.
245 *To step down as a maintainer*, you can move your name to the "inactive
246 maintainers" section of the ``Maintainers.rst`` file for the project, or remove
249 of time can be moved to the "inactive maintainers" section by another active
252 please post on Discourse to solicit wider community feedback about the removal
253 and future direction for the project. However, please discuss the situation
254 with the inactive maintainer before such removal to avoid accidental
255 miscommunications. If the inactive maintainer is unreachable, no discussion
258 the future.
261 the "inactive maintainers" section of the ``Maintainers.rst`` file to the
262 active maintainers list. Because the volunteer was already previously accepted,
263 they will be re-accepted so long as at least one maintainer in the same project
264 approves the PR and there are no explicit objections raised by the community.
274 * All feature and regression test cases are added to the ``llvm/test``
275 directory. The appropriate sub-directory should be selected (see the
285 * Avoid adding links to resources that are not available to the entire
287 documentation, etc. Instead, add sufficient comments to the test to provide
288 the context behind such links.
292 etc) should be added to the ``llvm-test`` test suite. The llvm-test suite is
300 notes, typically found in ``docs/ReleaseNotes.rst`` for the project. Changes to
302 added to the project's release notes at the author's or code reviewer's
303 discretion, preferably as part of the commit landing the changes. Examples of
310 to the issue fixed in the bug database).
315 a future release, such as removal of a deprecated feature. In this case, the
317 the notes with sufficient information and examples to demonstrate the
319 announced in the `Announcements <https://discourse.llvm.org/c/announce/>`_
328 The minimum quality standards that any change must satisfy before being
329 committed to the main development branch are:
331 #. Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
335 #. Bug fixes and new features should `include a testcase`_ so we know if the
336 fix/feature ever regresses in the future.
338 #. Code must pass the ``llvm/test`` test suite.
340 #. The code must not cause regressions on a reasonable subset of llvm-test,
341 where "reasonable" depends on the contributor's judgement and the scope of
342 the change (more invasive changes require more testing). A reasonable subset
347 to supply critical context. The surrounding comments should be sufficient
348 to provide the context behind such links.
350 Additionally, the committer is responsible for addressing any problems found in
351 the future that the change is responsible for. For example:
353 * The code should compile cleanly on all supported platforms.
355 * The changes should not cause any correctness regressions in the ``llvm-test``
358 * The change set should not cause performance or correctness regressions for the
361 * The changes should not cause performance or correctness regressions in code
370 to check the nightly testers for regressions the day after your change. Build
372 failure. You are expected to check the build bot messages to see if they are
373 your fault and, if so, fix the breakage.
376 reverted. This is necessary when the change blocks other developers from making
377 progress. The developer is welcome to re-commit the change after the problem has
385 Although we don't enforce the format of commit messages, we prefer that
390 Most importantly, the contents of the message should be carefully written to
391 convey the rationale of the change (without delving too much in detail). It
393 set right" will leave the reviewer wondering about which bits, and why they
395 all there is to the change.
397 Below are some guidelines about the format of the message itself:
399 * Separate the commit message into title and body separated by a blank line.
401 * If you're not the original author, ensure the 'Author' property of the commit is
402 set to the original author and the 'Committer' property is set to yourself.
404 ``git commit --amend --author="John Doe <jdoe@llvm.org>"`` to correct the
406 information including the method we used for attribution before the project
409 In the rare situation where there are multiple authors, please use the `git
410 tag 'Co-authored-by:' to list the additional authors
413 * The title should be concise. Because all commits are emailed to the list with
414 the first line as the subject, long titles are frowned upon. Short titles
417 * When the changes are restricted to a specific part of the code (e.g. a
418 back-end or optimization pass), it is customary to add a tag to the
419 beginning of the line in square brackets. For example, "[SCEV] ..."
423 * The body, if it exists, should be separated from the title by an empty line.
425 * The body should be concise, but explanatory, including a complete
426 reasoning. Unless it is required to understand the change, examples,
428 review or the mailing list.
430 * Text formatting and spelling should follow the same rules as documentation
433 * If the commit is a bug fix on top of another recently committed patch, or a
434 revert or reapply of a patch, include the git commit hash of the prior
438 * If the patch has been reviewed, add a link to its review page, as shown
440 If the patch fixes a bug in GitHub Issues, we encourage adding a reference to
441 the issue being closed, as described
444 * It is also acceptable to add other metadata to the commit message to automate
446 links to resources that are not available to the entire community. However,
447 such links and/or metadata should not be used in place of making the commit
449 included in the submitted code.
451 For minor violations of these recommendations, the community normally favors
452 reminding the contributor of this policy over reverting. Minor corrections and
453 omissions can be handled by sending a reply to the commits mailing list.
460 As a community, we strongly value having the tip of tree in a good state while
462 use of reverts to keep the tree healthy than some other open source projects,
469 * We encourage explicitly thanking the person who reverted the patch for doing
470 the task on your behalf.
471 * If you need more information to address the problem, please follow up in the
472 original commit thread with the reverting patch author.
478 encourage reverting first, investigating offline, and then reapplying the
481 * If a test case that demonstrates a problem is reported in the commit thread,
487 the merits of the request offline (unless doing so would further destabilize
492 * In general, if the author themselves would revert the change per these
493 guidelines, we encourage other contributors to do so as a courtesy to the
494 author. This is one of the major cases where our norms differ from others;
496 expect contributors to be always available, and the assurance that a
500 What are the expectations around a revert?
503 the commit thread asking for assistance. We aren't trying to enumerate
505 * You should be sure that reverting the change improves the stability of tip
508 the proper patch or set of patches is being reverted.
509 * The commit message for the reverting commit should explain why patch
511 * It is customary to respond to the original commit email mentioning the
512 revert. This serves as both a notice to the original author that their
516 in PRs. We encourage the reverter to minimize the test case and to prune
518 patch; documenting the reasons for others who might be following along
520 * It is not considered reasonable to revert without at least the promise to
521 provide a means for the patch author to debug the root issue. If a situation
524 compile time of internal workload, etc.), the reverter is expected to be
525 proactive about working with the patch author to debug and test candidate
529 should not be. Where exactly the transition point is is hard to say, but
530 it's probably in the handful of days in tree territory. If you are unsure,
531 we encourage you to reply to the commit thread, give the author a bit to
532 respond, and then proceed with the revert if the author doesn't seem to be
534 * When re-applying a reverted patch, the commit message should be updated to
535 indicate the problem that was addressed and how it was addressed.
544 an issue and request commit access. Replace the <user> string in the title
546 the issue description. If approved, a GitHub invitation will be sent to your
549 you accept the invitation, you'll get commit access.
553 provide the name and email address you would like to use in the Author
554 property of the commit.
557 on a commits mailing list soon after the commit lands (e.g. llvm-commits_).
559 commit to require a moderator to approve the email, so do not be concerned if a
560 commit does not immediately appear in the archives.
575 correcting the format first (ideally) or afterward. Such changes should be
576 highly localized and the commit message should clearly state that the commit
582 responsibility for), with the proviso that such commits must not break the
590 after they are committed, depending on the nature of the change). You are
594 .. _discuss the change/gather consensus:
599 When a developer begins a major new project with the aim of contributing it back
600 to LLVM, they should inform the community with a post to the `LLVM Discourse forums`_, to the extent
601 possible. The reason for this is to:
603 #. keep the community informed about future changes to LLVM,
605 #. avoid duplication of effort by preventing multiple parties working on the
608 #. ensure that any technical issues around the proposed work are discussed and
611 The design of LLVM is carefully controlled to ensure that all the pieces fit
613 change to the way LLVM works or want to add a major new extension, it is a good
614 idea to get consensus with the development community before you start working on
617 Once the design of the new feature is finalized, the work itself should be done
625 In the LLVM project, we do all significant changes as a series of incremental
629 #. Branches must have mainline merged into them periodically. If the branch
630 development and mainline development occur in the same pieces of code,
633 #. Other people in the community tend to ignore work on branches.
640 #. Changes developed as monolithic large changes often don't work until the
642 changes increases the odds that any of the work will be committed to the main
650 required before the big change can be made (e.g. API cleanup, etc). These
651 sorts of changes can often be done before the major change is done,
654 * The remaining inter-related work should be decomposed into unrelated sets of
655 changes if possible. Once this is done, define the first increment and get
656 consensus on what the end goal of the change is.
658 * Each change in the set can be stand alone (e.g. to fix a bug), or part of a
659 planned series of changes that works towards the development goal.
662 (into a logical progression), simplifies code review and reduces the chance
663 that you will get negative feedback on the change. Small increments also
664 facilitate the maintenance of a high quality code base.
667 migrate clients to use the new API. Each change to use the new API is often
668 "obvious" and can be committed without review. Once the new API is in place
669 and used, it is much easier to replace the underlying implementation of the
670 API. This implementation change is logically separate from the API
674 sure to first `discuss the change/gather consensus`_ then ask about the best way
675 to go about making the change.
681 commit access may commit it for the author once appropriate (based on the
684 want the source code to be littered with random attributions "this code written
685 by J. Random Hacker" (this is noisy and distracting). In practice, the revision
686 control system keeps a perfect history of who changed what, and the CREDITS.txt
688 else, please follow the attribution of changes in the simple manner as outlined
689 by the `commit messages`_ section. Overall, please do not add contributor names
690 to the source code.
692 Also, don't commit patches authored by others unless they have submitted the
693 patch to the project or you have been authorized to submit them on their behalf
694 (you work together and your company authorized you to contribute the patches,
695 etc.). The author should first submit them to the relevant project's commit
697 a patch privately, encourage them to submit it to the appropriate list first.
699 Our previous version control system (subversion) did not distinguish between the
700 author and the committer like git does. As such, older commits used a different
701 attribution mechanism. The previous method was to include "Patch by John Doe."
702 in a separate line of the commit message and there are automated processes that
708 The goal of a ban is to protect people in the community from having to interact
709 with people who are consistently not respecting the
712 interacting with the community. Therefore, we do not accept any form of direct
717 the community regarding that contribution.
728 When the IR format has to be changed, keep in mind that we try to maintain some
729 backwards compatibility. The rules are intended as a balance between convenience
732 * The textual format is not backwards compatible. We don't change it too often,
735 * Additions and changes to the IR should be reflected in
738 * The current LLVM version supports loading any bitcode since version 3.0.
741 ``compatibility-X.Y.ll``. The corresponding bitcode file should be assembled
742 using the X.Y build and committed as ``compatibility-X.Y.ll.bc``.
746 dropping it would be a valid way to upgrade the IR.
757 * Stability Guarantees: The C API is, in general, a "best effort" for stability.
758 This means that we make every attempt to keep the C API stable, but that
759 stability will be limited by the abstractness of the interface and the
760 stability of the C++ API that it wraps. In practice, this means that things
764 * Release stability: We won't break the C API on the release branch with patches
765 that go on that branch, with the exception that we will fix an unintentional
766 C API break that will keep the release consistent with both the previous and
769 * Testing: Patches to the C API are expected to come with tests just like any
772 * Including new things into the API: If an LLVM subcomponent has a C API already
774 subcomponents that don't currently have one needs to be discussed on the
777 * Documentation: Any changes to the C API are required to be documented in the
778 release notes so that it's clear to external users who do not follow the
779 project how the C API is changing and evolving.
789 will only be done through the following process:
791 * It is a general goal to support LLVM and GCC versions from the last 3 years
795 * An RFC is sent to the `LLVM Discourse forums`_
797 - Detail upsides of the version increase (e.g. which newer C++ language or
802 * Once the RFC reaches consensus, update the CMake toolchain version checks as
803 well as the :doc:`getting started<GettingStarted>` guide. This provides a
804 softer transition path for developers compiling LLVM, because the
806 step: LLVM still doesn't have code which requires the new toolchains, but it
807 soon will. If you compile LLVM but don't read the forums, we should
814 * Turn the soft-error into a hard-error after said LLVM release has branched.
816 * Update the :doc:`coding standards<CodingStandards>` to allow the new
817 features we've explicitly approved in the RFC.
819 * Start using the new features in LLVM's codebase.
822 <https://discourse.llvm.org/t/rfc-migrating-past-c-11/50943>`_ and the
827 Working with the CI system
830 The main continuous integration (CI) tool for the LLVM project is the
832 to cover a wide variety of sub-projects and configurations. The builds are
836 The Buildbot tracks the commits on the main branch and the release branches.
837 This means that patches are built and tested after they are merged to the these
838 branches (aka post-merge testing). This also means it's okay to break the build
842 *If your commit broke the build:*
844 * Fix the build as soon as possible as this might block other contributors or
846 * If you need more time to analyze and fix the bug, please revert your change to
849 *If someone else broke the build and this blocks your work*
851 * Comment on the code review in `GitHub <https://github.com/llvm/llvm-project/pulls>`_
852 (if available) or email the author, explain the problem and how this impacts
853 you. Add a link to the broken build and the error message so folks can
854 understand the problem.
855 * Revert the commit if this blocks your work, see revert_policy_ .
859 * 1st step: contact the owner of the worker. You can find the name and contact
860 information for the *Admin* of worker on the page of the build in the
865 * 2nd step: If the owner does not respond or fix the worker, please escalate
866 to Galina Kostanova, the maintainer of the BuildBot master.
867 * 3rd step: If Galina could not help you, please escalate to the
875 The LLVM community is a vibrant and exciting place to be, and we look to be
880 people and the cost of ongoing maintenance that new code requires. As such, we
882 components into the LLVM world, depending on the degree of detail and
884 than *peripheral* projects, and the latter may have additional differences.
888 to discussing unusual cases as well - just start an RFC thread on the
896 normally added in bulk. New targets need the same level of support as other
897 *core* parts of the compiler, so they are covered in the *core tier* of our
905 The differences between both classes are:
910 * Test failures, bugs, and build breakages that only appear when the
911 experimental target is enabled, caused by changes unrelated to the target, are
912 the responsibility of the community behind the target to fix.
914 The basic rules for a back-end to be upstreamed in **experimental** mode are:
916 * Every target must have at least one :ref:`maintainer<maintainers>`. The
917 `Maintainers.rst` file has to be updated as part of the first merge. These
918 maintainers make sure that changes to the target get reviewed and steers the
921 * There must be an active community behind the target. This community
922 will help maintain the target by providing buildbots, fixing
923 bugs, answering the LLVM community's questions and making sure the new
924 target doesn't break any of the other targets, or generic code. This
925 behavior is expected to continue throughout the lifetime of the
928 * The code must be free of contentious issues, for example, large
929 changes in how the IR behaves or should be formed by the front-ends,
930 unless agreed by the majority of the community via refactoring of the
931 (:doc:`IR standard<LangRef>`) **before** the merge of the new target changes,
932 following the :ref:`IR backwards compatibility`.
934 * The code conforms to all of the policies laid out in this developer policy
937 * The target should have either reasonable documentation on how it
941 that can affect the target.
943 In addition, the rules for a back-end to be promoted to **official** are:
945 * The target must have addressed every other minimum requirement and
947 period is to make sure that the back-end and the target community can
948 endure continuous upstream development for the foreseeable future.
950 * The target's code must have been completely adapted to this policy
951 as well as the :doc:`coding standards<CodingStandards>`. Any exceptions that
955 * The test coverage needs to be broad and well written (small tests,
956 well documented). The build target ``check-all`` must pass with the
957 new target built, and where applicable, the ``test-suite`` must also
962 the target requires no additional buildbots (ex. ``check-all`` covers
963 all tests). The more relevant and public the new target's CI infrastructure
964 is, the more the LLVM community will embrace it.
968 * The maintainer(s) must continue following these rules throughout the lifetime
969 of the target. Continuous violations of aforementioned rules and policies
970 could lead to complete removal of the target from the code base.
972 * Degradation in support, documentation or test coverage will make the target as
977 status, but also markers to define bit-rot, and will be used to clean up the
980 Those wishing to add a new target to LLVM must follow the procedure below:
984 adjustments soon after the initial merge.
985 2. Send a request for comment (RFC) to the `LLVM Discourse forums`_ describing
986 your target and how it follows all the requirements and what work has been
987 done and will need to be done to accommodate the official target requirements.
988 Make sure to expose any and all controversial issues, changes needed in the
990 3. Once the response is positive, the LLVM community can start reviewing the
991 actual patches (but they can be prepared before, to support the RFC). Create
993 number, not the letter 'N'), that completes the basic structure of the target.
994 4. The initial patch should add documentation, maintainers, and triple support in
995 clang and LLVM. The following patches add TableGen infrastructure to describe
996 the target and lower instructions to assembly. The final patch must show that
997 the target can lower correctly with extensive LIT tests (IR to MIR, MIR to
1000 approved that the whole set can be merged in one go. This is to guarantee
1002 6. After the initial merge, the target community can stop numbering patches and
1003 start working asynchronously on the target to complete support. They should
1004 still seek review from those who helped them in the initial phase, to make
1005 sure the progress is still consistent.
1006 7. Once all official requirements have been fulfilled (as above), the maintainers
1007 should request the target to be enabled by default by sending another RFC to
1008 the `LLVM Discourse forums`_.
1010 Adding an Established Project To the LLVM Monorepo
1013 The `LLVM monorepo <https://github.com/llvm/llvm-project>`_ is the centerpoint
1014 of development in the LLVM world, and has all of the primary LLVM components,
1015 including the LLVM optimizer and code generators, Clang, LLDB, etc. `Monorepos
1017 allow atomic commits to the project, simplify CI, and make it easier for
1020 Like new targets, most projects already in the monorepo are considered to be in
1021 the *core tier* of our :doc:`support policy<SupportPolicy>`. The burden to add
1022 things to the LLVM monorepo needs to be very high - code that is added to this
1023 repository is checked out by everyone in the community. As such, we hold
1026 * Must be generally aligned with the mission of the LLVM project to advance
1028 * Must conform to all of the policies laid out in this developer policy
1030 * Must have an active community that maintains the code, including established
1034 * Should have CI to catch breakage within the project itself or due to
1036 * Should have code free of issues the community finds contentious, or be on a
1038 * Must be proposed through the LLVM RFC process, and have its addition approved
1039 by the LLVM community - this ultimately mediates the resolution of the
1042 If you have a project that you think would make sense to add to the LLVM
1043 monorepo, please start an RFC topic on the `LLVM Discourse forums`_ to kick off
1044 the discussion. This process can take some time and iteration - please don’t
1048 see the "Incubating New Projects" section.
1053 The burden to add a new project to the LLVM monorepo is intentionally very high,
1060 to projects under the LLVM umbrella.
1062 Projects which can be considered for the LLVM incubator meet the following
1065 * Must be generally aligned with the mission of the LLVM project to advance
1067 * Must conform to the license, patent, and code of conduct policies laid out
1069 * Must have a documented charter and development plan, e.g. in the form of a
1073 * Should have a sense of the community that it hopes to eventually foster, and
1077 or sub-project within the `LLVM monorepo
1079 * Should include a notice (e.g. in the project README or web page) that the
1082 * Must be proposed through the LLVM RFC process, and have its addition
1083 approved by the LLVM community - this ultimately mediates the resolution of
1084 the "should" concerns above.
1086 That said, the project need not have any code to get started, and need not have
1088 through transient states that violate the "Should" guidelines above, or would
1089 otherwise make them unsuitable for direct inclusion in the monorepo (e.g.
1093 When approved, the llvm-admin group can grant the new project:
1094 * A new repository in the LLVM Github Organization - but not the LLVM monorepo.
1099 Graduation to the mono-repo would follow existing processes and standards for
1100 becoming a first-class part of the monorepo. Similarly, an incubating project
1102 and when this comes up, please start an RFC discussion on the `LLVM Discourse forums`_.
1104 This process is very new - please expect the details to change, it is always
1105 safe to ask on the `LLVM Discourse forums`_ about this.
1107 Suggested disclaimer for the project README and the main project web page:
1111 This project is participating in the LLVM Incubator process: as such, it is
1113 necessarily a reflection of the completeness or stability of the code, it
1114 does indicate that the project is not yet endorsed as a component of LLVM.
1126 This section addresses the issues of copyright, license and patents for the LLVM
1127 project. The copyright for the code is held by the contributors of
1128 the code. The code is licensed under permissive `open source licensing terms`_,
1129 namely the Apache-2.0 with LLVM-exception license, which includes a copyright
1130 and `patent license`_. When you contribute code to the LLVM project, you
1134 to the codebase. However, this may only be done with approval of the LLVM
1135 Foundation Board of Directors, and contributors should plan for the approval
1137 under a different license, please create a pull request with the code
1140 If you have questions or comments about these topics, please ask on the
1150 The LLVM project does not collect copyright assignments, which means that the
1151 copyright for the code in the project is held by the respective contributors.
1153 retain ownership of the code you contribute, you know it may only be used under
1154 the terms of the open source license you contributed it under: the license for
1155 your contributions cannot be changed in the future without your approval.
1157 Because the LLVM project does not require copyright assignments, changing the
1158 LLVM license requires tracking down the
1161 is good for the project, because contributors do not have to fear that their
1167 The LLVM project does not accept contributions that include in-source copyright
1171 LLVM source code lives for a long time and is edited by many people, the best
1173 See the `Attribution of Changes`_ section for more information about attributing
1174 changes to authors other than the committer.
1179 The last paragraph notwithstanding, the LLVM Project is in the middle of a large
1182 * The old licenses made it difficult to move code from (e.g.) the compiler to
1183 runtime libraries, because runtime libraries used a different license from the
1184 rest of the compiler.
1186 the patent grant required by the project was overly broad.
1187 * The patent grant was unique to the LLVM Project, not written by a lawyer, and
1190 The scope of relicensing is all code that is considered part of the LLVM
1191 project, including the main LLVM repository, runtime libraries (compiler_rt,
1195 remain as it is. This code isn't developed as part of the LLVM project, it
1198 and dragonegg). These will be split off from the LLVM project (e.g. to
1202 To relicense LLVM, we will be seeking approval from all of the copyright holders
1203 of code in the repository, or potentially remove/rewrite code if we cannot.
1209 be covered by the new LLVM license, i.e. Apache-2.0 WITH LLVM-exception.
1210 Before this date, the project required all contributions to be made under
1211 both the new license and the legacy license.
1214 and have not done so already, please do follow the instructions at
1216 Relicensing Agreement" to relicense your contributions under the new license.
1224 Contributions to LLVM are licensed under the `Apache License, Version 2.0
1227 Collectively, the name of this license is "Apache 2.0 License with LLVM
1228 exceptions". The exceptions read:
1232 ---- LLVM Exceptions to the Apache 2.0 License ----
1237 with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
1240 software that is licensed under the GPLv2 ("Combined Software") and if a
1241 court of competent jurisdiction determines that the patent provision (Section
1242 3), the indemnity provision (Section 9) or other Section of the License
1243 conflicts with the conditions of the GPLv2, you may retroactively and
1245 the License, but only in their entirety and only with respect to the Combined
1250 license - this fosters the widest adoption of LLVM by
1253 particular, LLVM's license is not a "copyleft" license like the GPL.
1255 The "Apache 2.0 License with LLVM exceptions" allows you to:
1263 to the project - contributions are appreciated though!
1267 * You must retain the copyright notice if you redistribute LLVM: You cannot
1268 strip the copyright headers off or replace them with your own.
1269 * Binaries that include LLVM must reproduce the copyright notice (e.g. in an
1270 included README file or in an "About" box), unless the LLVM code was added as
1272 compiler_rt or libc++ was automatically included into your application by the
1275 though you can make truthful statements about your use of the LLVM code,
1280 is great for contributors and users of the project. For more information about
1281 the Apache 2.0 License, please see the `Apache License FAQ
1282 <http://www.apache.org/foundation/license-faq.html>`_, maintained by the
1290 Section 3 of the Apache 2.0 license is a patent grant under which
1291 contributors of code to the project contribute the rights to use any of
1293 (protecting uses of that code). Further, the patent grant is revoked
1294 from anyone who files a patent lawsuit about code in LLVM - this protects the
1295 community by providing a "patent commons" for the code base and reducing the
1298 The license specifically scopes which patents are included with code
1299 contributions. To help explain this, the `Apache License FAQ
1302 reference, the "ASF" is the Apache Software Foundation, the guidance still
1305 Q1: If I own a patent and contribute to a Work, and, at the time my
1308 later become subject to the Grant of Patent License solely due to subsequent
1315 they were licensable by me at the time of my contribution, do those other
1316 claims become subject to the Grant of Patent License?
1324 A3: The only patent claims that are licensed to the ASF are those you own or
1325 have the right to license that read on your contribution or on the
1326 combination of your contribution with the specific Apache product to which
1327 you contributed as it existed at the time of your contribution. No additional
1330 claims include those that you acquire in the future, as long as they read on
1331 your original contribution as made at the original time. Once a patent claim
1332 is subject to Apache's Grant of Patent License, it is licensed under the
1333 terms of that Grant to the ASF and to recipients of any software distributed
1334 by the ASF for any Apache software product whatsoever.
1342 The code base was previously licensed under the Terms described here.
1343 We are in the middle of relicensing to a new approach (described above).
1344 More than 99% of all contributions made to LLVM are covered by the Apache-2.0
1346 covered by the legacy license. Contributions after 2024-06-01 are covered
1347 exclusively by the new license._
1350 source license. The code in
1351 LLVM is available under the `University of Illinois/NCSA Open Source License
1356 * You must retain the copyright notice if you redistribute LLVM.
1357 * Binaries derived from LLVM must reproduce the copyright notice (e.g. in an
1362 We believe this fosters the widest adoption of LLVM because it **allows
1365 license is not a "copyleft" license like the GPL). We suggest that you read the
1369 In addition to the UIUC license, the runtime library components of LLVM
1370 (**compiler_rt, libc++, and libclc**) are also licensed under the `MIT License
1372 the binary redistribution clause. As a user of these runtime libraries, it
1373 means that you can choose to use the code under either license (and thus don't
1374 need the binary redistribution clause), and as a contributor to the code that
1378 applications to the binary redistribution clause. This also means that it is ok
1379 to move code from (e.g.) libc++ to the LLVM core without concern, but that code
1380 cannot be moved from the LLVM core to libc++ without the copyright owner's
1390 Contributors are responsible for ensuring that they have the right to contribute
1391 code under the terms of our license, typically meaning that either they, their
1392 employer, or their collaborators hold the copyright. Using AI tools to
1393 regenerate copyrighted material does not remove the copyright, and contributors
1397 As such, the LLVM policy is that contributors are permitted to use artificial
1398 intelligence tools to produce contributions, provided that they have the right
1399 to license that code under the project license. Contributions found to violate
1402 While the LLVM project has a liberal policy on AI tool use, contributors are
1406 review. Reviewing and maintaining generated code that the original contributor