]>
Commit | Line | Data |
---|---|---|
223e47cc LB |
1 | ===================== |
2 | LLVM Developer Policy | |
3 | ===================== | |
4 | ||
5 | .. contents:: | |
6 | :local: | |
7 | ||
8 | Introduction | |
9 | ============ | |
10 | ||
11 | This document contains the LLVM Developer Policy which defines the project's | |
12 | policy towards developers and their contributions. The intent of this policy is | |
13 | to eliminate miscommunication, rework, and confusion that might arise from the | |
14 | distributed nature of LLVM's development. By stating the policy in clear terms, | |
15 | we hope each developer can know ahead of time what to expect when making LLVM | |
16 | contributions. This policy covers all llvm.org subprojects, including Clang, | |
17 | LLDB, libc++, etc. | |
18 | ||
19 | This policy is also designed to accomplish the following objectives: | |
20 | ||
21 | #. Attract both users and developers to the LLVM project. | |
22 | ||
23 | #. Make life as simple and easy for contributors as possible. | |
24 | ||
25 | #. Keep the top of Subversion trees as stable as possible. | |
26 | ||
970d7e83 LB |
27 | #. Establish awareness of the project's :ref:`copyright, license, and patent |
28 | policies <copyright-license-patents>` with contributors to the project. | |
223e47cc LB |
29 | |
30 | This policy is aimed at frequent contributors to LLVM. People interested in | |
31 | contributing one-off patches can do so in an informal way by sending them to the | |
32 | `llvm-commits mailing list | |
33 | <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_ and engaging another | |
34 | developer to see it through the process. | |
35 | ||
36 | Developer Policies | |
37 | ================== | |
38 | ||
39 | This section contains policies that pertain to frequent LLVM developers. We | |
40 | always welcome `one-off patches`_ from people who do not routinely contribute to | |
41 | LLVM, but we expect more from frequent contributors to keep the system as | |
42 | efficient as possible for everyone. Frequent LLVM contributors are expected to | |
43 | meet the following requirements in order for LLVM to maintain a high standard of | |
44 | quality. | |
45 | ||
46 | Stay Informed | |
47 | ------------- | |
48 | ||
49 | Developers should stay informed by reading at least the "dev" mailing list for | |
50 | the projects you are interested in, such as `llvmdev | |
51 | <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_ for LLVM, `cfe-dev | |
52 | <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>`_ for Clang, or `lldb-dev | |
53 | <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev>`_ for LLDB. If you are | |
54 | doing anything more than just casual work on LLVM, it is suggested that you also | |
55 | subscribe to the "commits" mailing list for the subproject you're interested in, | |
56 | such as `llvm-commits | |
57 | <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_, `cfe-commits | |
58 | <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>`_, or `lldb-commits | |
59 | <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits>`_. Reading the | |
60 | "commits" list and paying attention to changes being made by others is a good | |
61 | way to see what other people are interested in and watching the flow of the | |
62 | project as a whole. | |
63 | ||
64 | We recommend that active developers register an email account with `LLVM | |
65 | Bugzilla <http://llvm.org/bugs/>`_ and preferably subscribe to the `llvm-bugs | |
66 | <http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs>`_ email list to keep track | |
67 | of bugs and enhancements occurring in LLVM. We really appreciate people who are | |
68 | proactive at catching incoming bugs in their components and dealing with them | |
69 | promptly. | |
70 | ||
1a4d82fc JJ |
71 | Please be aware that all public LLVM mailing lists are public and archived, and |
72 | that notices of confidentiality or non-disclosure cannot be respected. | |
73 | ||
223e47cc LB |
74 | .. _patch: |
75 | .. _one-off patches: | |
76 | ||
1a4d82fc JJ |
77 | Making and Submitting a Patch |
78 | ----------------------------- | |
223e47cc LB |
79 | |
80 | When making a patch for review, the goal is to make it as easy for the reviewer | |
81 | to read it as possible. As such, we recommend that you: | |
82 | ||
83 | #. Make your patch against the Subversion trunk, not a branch, and not an old | |
84 | version of LLVM. This makes it easy to apply the patch. For information on | |
85 | how to check out SVN trunk, please see the `Getting Started | |
86 | Guide <GettingStarted.html#checkout>`_. | |
87 | ||
88 | #. Similarly, patches should be submitted soon after they are generated. Old | |
89 | patches may not apply correctly if the underlying code changes between the | |
90 | time the patch was created and the time it is applied. | |
91 | ||
92 | #. Patches should be made with ``svn diff``, or similar. If you use a | |
93 | different tool, make sure it uses the ``diff -u`` format and that it | |
94 | doesn't contain clutter which makes it hard to read. | |
95 | ||
96 | #. If you are modifying generated files, such as the top-level ``configure`` | |
97 | script, please separate out those changes into a separate patch from the rest | |
98 | of your changes. | |
99 | ||
1a4d82fc JJ |
100 | Once your patch is ready, submit it by emailing it to the appropriate project's |
101 | commit mailing list (or commit it directly if applicable). Alternatively, some | |
102 | patches get sent to the project's development list or component of the LLVM bug | |
103 | tracker, but the commit list is the primary place for reviews and should | |
104 | generally be preferred. | |
105 | ||
223e47cc LB |
106 | When sending a patch to a mailing list, it is a good idea to send it as an |
107 | *attachment* to the message, not embedded into the text of the message. This | |
108 | ensures that your mailer will not mangle the patch when it sends it (e.g. by | |
109 | making whitespace changes or by wrapping lines). | |
110 | ||
111 | *For Thunderbird users:* Before submitting a patch, please open *Preferences > | |
112 | Advanced > General > Config Editor*, find the key | |
113 | ``mail.content_disposition_type``, and set its value to ``1``. Without this | |
114 | setting, Thunderbird sends your attachment using ``Content-Disposition: inline`` | |
115 | rather than ``Content-Disposition: attachment``. Apple Mail gamely displays such | |
116 | a file inline, making it difficult to work with for reviewers using that | |
117 | program. | |
118 | ||
1a4d82fc JJ |
119 | When submitting patches, please do not add confidentiality or non-disclosure |
120 | notices to the patches themselves. These notices conflict with the `LLVM | |
121 | License`_ and may result in your contribution being excluded. | |
122 | ||
223e47cc LB |
123 | .. _code review: |
124 | ||
125 | Code Reviews | |
126 | ------------ | |
127 | ||
128 | LLVM has a code review policy. Code review is one way to increase the quality of | |
129 | software. We generally follow these policies: | |
130 | ||
131 | #. All developers are required to have significant changes reviewed before they | |
132 | are committed to the repository. | |
133 | ||
1a4d82fc JJ |
134 | #. Code reviews are conducted by email on the relevant project's commit mailing |
135 | list, or alternatively on the project's development list or bug tracker. | |
223e47cc LB |
136 | |
137 | #. Code can be reviewed either before it is committed or after. We expect major | |
138 | changes to be reviewed before being committed, but smaller changes (or | |
139 | changes where the developer owns the component) can be reviewed after commit. | |
140 | ||
141 | #. The developer responsible for a code change is also responsible for making | |
142 | all necessary review-related changes. | |
143 | ||
144 | #. Code review can be an iterative process, which continues until the patch is | |
1a4d82fc JJ |
145 | ready to be committed. Specifically, once a patch is sent out for review, it |
146 | needs an explicit "looks good" before it is submitted. Do not assume silent | |
147 | approval, or request active objections to the patch with a deadline. | |
148 | ||
149 | Sometimes code reviews will take longer than you would hope for, especially for | |
150 | larger features. Accepted ways to speed up review times for your patches are: | |
151 | ||
152 | * Review other people's patches. If you help out, everybody will be more | |
153 | willing to do the same for you; goodwill is our currency. | |
154 | * Ping the patch. If it is urgent, provide reasons why it is important to you to | |
155 | get this patch landed and ping it every couple of days. If it is | |
156 | not urgent, the common courtesy ping rate is one week. Remember that you're | |
157 | asking for valuable time from other professional developers. | |
158 | * Ask for help on IRC. Developers on IRC will be able to either help you | |
159 | directly, or tell you who might be a good reviewer. | |
160 | * Split your patch into multiple smaller patches that build on each other. The | |
161 | smaller your patch, the higher the probability that somebody will take a quick | |
162 | look at it. | |
223e47cc LB |
163 | |
164 | Developers should participate in code reviews as both reviewers and | |
165 | reviewees. If someone is kind enough to review your code, you should return the | |
166 | favor for someone else. Note that anyone is welcome to review and give feedback | |
167 | on a patch, but only people with Subversion write access can approve it. | |
168 | ||
970d7e83 LB |
169 | There is a web based code review tool that can optionally be used |
170 | for code reviews. See :doc:`Phabricator`. | |
171 | ||
223e47cc LB |
172 | Code Owners |
173 | ----------- | |
174 | ||
175 | The LLVM Project relies on two features of its process to maintain rapid | |
176 | development in addition to the high quality of its source base: the combination | |
177 | of code review plus post-commit review for trusted maintainers. Having both is | |
178 | a great way for the project to take advantage of the fact that most people do | |
179 | the right thing most of the time, and only commit patches without pre-commit | |
180 | review when they are confident they are right. | |
181 | ||
182 | The trick to this is that the project has to guarantee that all patches that are | |
183 | committed are reviewed after they go in: you don't want everyone to assume | |
184 | someone else will review it, allowing the patch to go unreviewed. To solve this | |
185 | problem, we have a notion of an 'owner' for a piece of the code. The sole | |
186 | responsibility of a code owner is to ensure that a commit to their area of the | |
187 | code is appropriately reviewed, either by themself or by someone else. The list | |
188 | of current code owners can be found in the file | |
189 | `CODE_OWNERS.TXT <http://llvm.org/viewvc/llvm-project/llvm/trunk/CODE_OWNERS.TXT?view=markup>`_ | |
190 | in the root of the LLVM source tree. | |
191 | ||
192 | Note that code ownership is completely different than reviewers: anyone can | |
193 | review a piece of code, and we welcome code review from anyone who is | |
194 | interested. Code owners are the "last line of defense" to guarantee that all | |
195 | patches that are committed are actually reviewed. | |
196 | ||
197 | Being a code owner is a somewhat unglamorous position, but it is incredibly | |
198 | important for the ongoing success of the project. Because people get busy, | |
199 | interests change, and unexpected things happen, code ownership is purely opt-in, | |
200 | and anyone can choose to resign their "title" at any time. For now, we do not | |
201 | have an official policy on how one gets elected to be a code owner. | |
202 | ||
203 | .. _include a testcase: | |
204 | ||
205 | Test Cases | |
206 | ---------- | |
207 | ||
208 | Developers are required to create test cases for any bugs fixed and any new | |
209 | features added. Some tips for getting your testcase approved: | |
210 | ||
211 | * All feature and regression test cases are added to the ``llvm/test`` | |
970d7e83 LB |
212 | directory. The appropriate sub-directory should be selected (see the |
213 | :doc:`Testing Guide <TestingGuide>` for details). | |
223e47cc | 214 | |
1a4d82fc | 215 | * Test cases should be written in :doc:`LLVM assembly language <LangRef>`. |
223e47cc LB |
216 | |
217 | * Test cases, especially for regressions, should be reduced as much as possible, | |
1a4d82fc | 218 | by :doc:`bugpoint <Bugpoint>` or manually. It is unacceptable to place an |
223e47cc LB |
219 | entire failing program into ``llvm/test`` as this creates a *time-to-test* |
220 | burden on all developers. Please keep them short. | |
221 | ||
222 | Note that llvm/test and clang/test are designed for regression and small feature | |
223 | tests only. More extensive test cases (e.g., entire applications, benchmarks, | |
224 | etc) should be added to the ``llvm-test`` test suite. The llvm-test suite is | |
225 | for coverage (correctness, performance, etc) testing, not feature or regression | |
226 | testing. | |
227 | ||
228 | Quality | |
229 | ------- | |
230 | ||
231 | The minimum quality standards that any change must satisfy before being | |
232 | committed to the main development branch are: | |
233 | ||
234 | #. Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_. | |
235 | ||
236 | #. Code must compile cleanly (no errors, no warnings) on at least one platform. | |
237 | ||
238 | #. Bug fixes and new features should `include a testcase`_ so we know if the | |
239 | fix/feature ever regresses in the future. | |
240 | ||
241 | #. Code must pass the ``llvm/test`` test suite. | |
242 | ||
243 | #. The code must not cause regressions on a reasonable subset of llvm-test, | |
244 | where "reasonable" depends on the contributor's judgement and the scope of | |
245 | the change (more invasive changes require more testing). A reasonable subset | |
246 | might be something like "``llvm-test/MultiSource/Benchmarks``". | |
247 | ||
248 | Additionally, the committer is responsible for addressing any problems found in | |
249 | the future that the change is responsible for. For example: | |
250 | ||
251 | * The code should compile cleanly on all supported platforms. | |
252 | ||
253 | * The changes should not cause any correctness regressions in the ``llvm-test`` | |
254 | suite and must not cause any major performance regressions. | |
255 | ||
256 | * The change set should not cause performance or correctness regressions for the | |
257 | LLVM tools. | |
258 | ||
259 | * The changes should not cause performance or correctness regressions in code | |
260 | compiled by LLVM on all applicable targets. | |
261 | ||
262 | * You are expected to address any `Bugzilla bugs <http://llvm.org/bugs/>`_ that | |
263 | result from your change. | |
264 | ||
265 | We prefer for this to be handled before submission but understand that it isn't | |
266 | possible to test all of this for every submission. Our build bots and nightly | |
267 | testing infrastructure normally finds these problems. A good rule of thumb is | |
268 | to check the nightly testers for regressions the day after your change. Build | |
269 | bots will directly email you if a group of commits that included yours caused a | |
270 | failure. You are expected to check the build bot messages to see if they are | |
271 | your fault and, if so, fix the breakage. | |
272 | ||
273 | Commits that violate these quality standards (e.g. are very broken) may be | |
274 | reverted. This is necessary when the change blocks other developers from making | |
275 | progress. The developer is welcome to re-commit the change after the problem has | |
276 | been fixed. | |
277 | ||
278 | Obtaining Commit Access | |
279 | ----------------------- | |
280 | ||
281 | We grant commit access to contributors with a track record of submitting high | |
282 | quality patches. If you would like commit access, please send an email to | |
283 | `Chris <mailto:sabre@nondot.org>`_ with the following information: | |
284 | ||
285 | #. The user name you want to commit with, e.g. "hacker". | |
286 | ||
287 | #. The full name and email address you want message to llvm-commits to come | |
288 | from, e.g. "J. Random Hacker <hacker@yoyodyne.com>". | |
289 | ||
290 | #. A "password hash" of the password you want to use, e.g. "``2ACR96qjUqsyM``". | |
1a4d82fc | 291 | Note that you don't ever tell us what your password is; you just give it to |
223e47cc LB |
292 | us in an encrypted form. To get this, run "``htpasswd``" (a utility that |
293 | comes with apache) in crypt mode (often enabled with "``-d``"), or find a web | |
294 | page that will do it for you. | |
295 | ||
296 | Once you've been granted commit access, you should be able to check out an LLVM | |
297 | tree with an SVN URL of "https://username@llvm.org/..." instead of the normal | |
298 | anonymous URL of "http://llvm.org/...". The first time you commit you'll have | |
299 | to type in your password. Note that you may get a warning from SVN about an | |
1a4d82fc | 300 | untrusted key; you can ignore this. To verify that your commit access works, |
223e47cc LB |
301 | please do a test commit (e.g. change a comment or add a blank line). Your first |
302 | commit to a repository may require the autogenerated email to be approved by a | |
1a4d82fc | 303 | mailing list. This is normal and will be done when the mailing list owner has |
223e47cc LB |
304 | time. |
305 | ||
306 | If you have recently been granted commit access, these policies apply: | |
307 | ||
308 | #. You are granted *commit-after-approval* to all parts of LLVM. To get | |
309 | approval, submit a `patch`_ to `llvm-commits | |
1a4d82fc | 310 | <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_. When approved, |
223e47cc LB |
311 | you may commit it yourself. |
312 | ||
313 | #. You are allowed to commit patches without approval which you think are | |
314 | obvious. This is clearly a subjective decision --- we simply expect you to | |
315 | use good judgement. Examples include: fixing build breakage, reverting | |
316 | obviously broken patches, documentation/comment changes, any other minor | |
317 | changes. | |
318 | ||
319 | #. You are allowed to commit patches without approval to those portions of LLVM | |
320 | that you have contributed or maintain (i.e., have been assigned | |
321 | responsibility for), with the proviso that such commits must not break the | |
1a4d82fc | 322 | build. This is a "trust but verify" policy, and commits of this nature are |
223e47cc LB |
323 | reviewed after they are committed. |
324 | ||
325 | #. Multiple violations of these policies or a single egregious violation may | |
326 | cause commit access to be revoked. | |
327 | ||
328 | In any case, your changes are still subject to `code review`_ (either before or | |
329 | after they are committed, depending on the nature of the change). You are | |
330 | encouraged to review other peoples' patches as well, but you aren't required | |
1a4d82fc | 331 | to do so. |
223e47cc LB |
332 | |
333 | .. _discuss the change/gather consensus: | |
334 | ||
335 | Making a Major Change | |
336 | --------------------- | |
337 | ||
338 | When a developer begins a major new project with the aim of contributing it back | |
1a4d82fc | 339 | to LLVM, they should inform the community with an email to the `llvmdev |
223e47cc LB |
340 | <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_ email list, to the extent |
341 | possible. The reason for this is to: | |
342 | ||
343 | #. keep the community informed about future changes to LLVM, | |
344 | ||
345 | #. avoid duplication of effort by preventing multiple parties working on the | |
346 | same thing and not knowing about it, and | |
347 | ||
348 | #. ensure that any technical issues around the proposed work are discussed and | |
349 | resolved before any significant work is done. | |
350 | ||
351 | The design of LLVM is carefully controlled to ensure that all the pieces fit | |
352 | together well and are as consistent as possible. If you plan to make a major | |
353 | change to the way LLVM works or want to add a major new extension, it is a good | |
354 | idea to get consensus with the development community before you start working on | |
355 | it. | |
356 | ||
357 | Once the design of the new feature is finalized, the work itself should be done | |
358 | as a series of `incremental changes`_, not as a long-term development branch. | |
359 | ||
360 | .. _incremental changes: | |
361 | ||
362 | Incremental Development | |
363 | ----------------------- | |
364 | ||
365 | In the LLVM project, we do all significant changes as a series of incremental | |
366 | patches. We have a strong dislike for huge changes or long-term development | |
367 | branches. Long-term development branches have a number of drawbacks: | |
368 | ||
369 | #. Branches must have mainline merged into them periodically. If the branch | |
370 | development and mainline development occur in the same pieces of code, | |
371 | resolving merge conflicts can take a lot of time. | |
372 | ||
373 | #. Other people in the community tend to ignore work on branches. | |
374 | ||
375 | #. Huge changes (produced when a branch is merged back onto mainline) are | |
376 | extremely difficult to `code review`_. | |
377 | ||
378 | #. Branches are not routinely tested by our nightly tester infrastructure. | |
379 | ||
380 | #. Changes developed as monolithic large changes often don't work until the | |
381 | entire set of changes is done. Breaking it down into a set of smaller | |
382 | changes increases the odds that any of the work will be committed to the main | |
383 | repository. | |
384 | ||
385 | To address these problems, LLVM uses an incremental development style and we | |
386 | require contributors to follow this practice when making a large/invasive | |
387 | change. Some tips: | |
388 | ||
389 | * Large/invasive changes usually have a number of secondary changes that are | |
390 | required before the big change can be made (e.g. API cleanup, etc). These | |
391 | sorts of changes can often be done before the major change is done, | |
392 | independently of that work. | |
393 | ||
394 | * The remaining inter-related work should be decomposed into unrelated sets of | |
395 | changes if possible. Once this is done, define the first increment and get | |
396 | consensus on what the end goal of the change is. | |
397 | ||
398 | * Each change in the set can be stand alone (e.g. to fix a bug), or part of a | |
399 | planned series of changes that works towards the development goal. | |
400 | ||
401 | * Each change should be kept as small as possible. This simplifies your work | |
402 | (into a logical progression), simplifies code review and reduces the chance | |
403 | that you will get negative feedback on the change. Small increments also | |
404 | facilitate the maintenance of a high quality code base. | |
405 | ||
406 | * Often, an independent precursor to a big change is to add a new API and slowly | |
407 | migrate clients to use the new API. Each change to use the new API is often | |
408 | "obvious" and can be committed without review. Once the new API is in place | |
409 | and used, it is much easier to replace the underlying implementation of the | |
410 | API. This implementation change is logically separate from the API | |
411 | change. | |
412 | ||
413 | If you are interested in making a large change, and this scares you, please make | |
414 | sure to first `discuss the change/gather consensus`_ then ask about the best way | |
415 | to go about making the change. | |
416 | ||
417 | Attribution of Changes | |
418 | ---------------------- | |
419 | ||
1a4d82fc JJ |
420 | When contributors submit a patch to an LLVM project, other developers with |
421 | commit access may commit it for the author once appropriate (based on the | |
422 | progression of code review, etc.). When doing so, it is important to retain | |
423 | correct attribution of contributions to their contributors. However, we do not | |
424 | want the source code to be littered with random attributions "this code written | |
425 | by J. Random Hacker" (this is noisy and distracting). In practice, the revision | |
426 | control system keeps a perfect history of who changed what, and the CREDITS.txt | |
427 | file describes higher-level contributions. If you commit a patch for someone | |
428 | else, please say "patch contributed by J. Random Hacker!" in the commit | |
429 | message. Overall, please do not add contributor names to the source code. | |
430 | ||
431 | Also, don't commit patches authored by others unless they have submitted the | |
432 | patch to the project or you have been authorized to submit them on their behalf | |
433 | (you work together and your company authorized you to contribute the patches, | |
434 | etc.). The author should first submit them to the relevant project's commit | |
435 | list, development list, or LLVM bug tracker component. If someone sends you | |
436 | a patch privately, encourage them to submit it to the appropriate list first. | |
437 | ||
438 | ||
439 | IR Backwards Compatibility | |
440 | -------------------------- | |
441 | ||
442 | When the IR format has to be changed, keep in mind that we try to maintain some | |
443 | backwards compatibility. The rules are intended as a balance between convenience | |
444 | for llvm users and not imposing a big burden on llvm developers: | |
445 | ||
446 | * The textual format is not backwards compatible. We don't change it too often, | |
447 | but there are no specific promises. | |
448 | ||
449 | * The bitcode format produced by a X.Y release will be readable by all following | |
450 | X.Z releases and the (X+1).0 release. | |
451 | ||
452 | * Newer releases can ignore features from older releases, but they cannot | |
453 | miscompile them. For example, if nsw is ever replaced with something else, | |
454 | dropping it would be a valid way to upgrade the IR. | |
455 | ||
456 | * Debug metadata is special in that it is currently dropped during upgrades. | |
223e47cc | 457 | |
1a4d82fc JJ |
458 | * Non-debug metadata is defined to be safe to drop, so a valid way to upgrade |
459 | it is to drop it. That is not very user friendly and a bit more effort is | |
460 | expected, but no promises are made. | |
223e47cc | 461 | |
970d7e83 | 462 | .. _copyright-license-patents: |
223e47cc LB |
463 | |
464 | Copyright, License, and Patents | |
465 | =============================== | |
466 | ||
467 | .. note:: | |
468 | ||
469 | This section deals with legal matters but does not provide legal advice. We | |
470 | are not lawyers --- please seek legal counsel from an attorney. | |
471 | ||
472 | This section addresses the issues of copyright, license and patents for the LLVM | |
473 | project. The copyright for the code is held by the individual contributors of | |
474 | the code and the terms of its license to LLVM users and developers is the | |
475 | `University of Illinois/NCSA Open Source License | |
476 | <http://www.opensource.org/licenses/UoI-NCSA.php>`_ (with portions dual licensed | |
477 | under the `MIT License <http://www.opensource.org/licenses/mit-license.php>`_, | |
478 | see below). As contributor to the LLVM project, you agree to allow any | |
479 | contributions to the project to licensed under these terms. | |
480 | ||
481 | Copyright | |
482 | --------- | |
483 | ||
484 | The LLVM project does not require copyright assignments, which means that the | |
485 | copyright for the code in the project is held by its respective contributors who | |
486 | have each agreed to release their contributed code under the terms of the `LLVM | |
487 | License`_. | |
488 | ||
489 | An implication of this is that the LLVM license is unlikely to ever change: | |
490 | changing it would require tracking down all the contributors to LLVM and getting | |
491 | them to agree that a license change is acceptable for their contribution. Since | |
492 | there are no plans to change the license, this is not a cause for concern. | |
493 | ||
494 | As a contributor to the project, this means that you (or your company) retain | |
495 | ownership of the code you contribute, that it cannot be used in a way that | |
496 | contradicts the license (which is a liberal BSD-style license), and that the | |
497 | license for your contributions won't change without your approval in the | |
498 | future. | |
499 | ||
500 | .. _LLVM License: | |
501 | ||
502 | License | |
503 | ------- | |
504 | ||
505 | We intend to keep LLVM perpetually open source and to use a liberal open source | |
506 | license. **As a contributor to the project, you agree that any contributions be | |
507 | licensed under the terms of the corresponding subproject.** All of the code in | |
508 | LLVM is available under the `University of Illinois/NCSA Open Source License | |
509 | <http://www.opensource.org/licenses/UoI-NCSA.php>`_, which boils down to | |
510 | this: | |
511 | ||
512 | * You can freely distribute LLVM. | |
513 | * You must retain the copyright notice if you redistribute LLVM. | |
514 | * Binaries derived from LLVM must reproduce the copyright notice (e.g. in an | |
515 | included readme file). | |
516 | * You can't use our names to promote your LLVM derived products. | |
517 | * There's no warranty on LLVM at all. | |
518 | ||
519 | We believe this fosters the widest adoption of LLVM because it **allows | |
520 | commercial products to be derived from LLVM** with few restrictions and without | |
521 | a requirement for making any derived works also open source (i.e. LLVM's | |
522 | license is not a "copyleft" license like the GPL). We suggest that you read the | |
523 | `License <http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further | |
524 | clarification is needed. | |
525 | ||
526 | In addition to the UIUC license, the runtime library components of LLVM | |
527 | (**compiler_rt, libc++, and libclc**) are also licensed under the `MIT License | |
528 | <http://www.opensource.org/licenses/mit-license.php>`_, which does not contain | |
529 | the binary redistribution clause. As a user of these runtime libraries, it | |
530 | means that you can choose to use the code under either license (and thus don't | |
531 | need the binary redistribution clause), and as a contributor to the code that | |
532 | you agree that any contributions to these libraries be licensed under both | |
533 | licenses. We feel that this is important for runtime libraries, because they | |
534 | are implicitly linked into applications and therefore should not subject those | |
535 | applications to the binary redistribution clause. This also means that it is ok | |
536 | to move code from (e.g.) libc++ to the LLVM core without concern, but that code | |
537 | cannot be moved from the LLVM core to libc++ without the copyright owner's | |
538 | permission. | |
539 | ||
1a4d82fc JJ |
540 | Note that the LLVM Project does distribute dragonegg, **which is |
541 | GPL.** This means that anything "linked" into dragonegg must itself be compatible | |
223e47cc | 542 | with the GPL, and must be releasable under the terms of the GPL. This implies |
1a4d82fc | 543 | that **any code linked into dragonegg and distributed to others may be subject to |
223e47cc | 544 | the viral aspects of the GPL** (for example, a proprietary code generator linked |
1a4d82fc | 545 | into dragonegg must be made available under the GPL). This is not a problem for |
223e47cc LB |
546 | code already distributed under a more liberal license (like the UIUC license), |
547 | and GPL-containing subprojects are kept in separate SVN repositories whose | |
548 | LICENSE.txt files specifically indicate that they contain GPL code. | |
549 | ||
550 | We have no plans to change the license of LLVM. If you have questions or | |
551 | comments about the license, please contact the `LLVM Developer's Mailing | |
552 | List <mailto:llvmdev@cs.uiuc.edu>`_. | |
553 | ||
554 | Patents | |
555 | ------- | |
556 | ||
557 | To the best of our knowledge, LLVM does not infringe on any patents (we have | |
558 | actually removed code from LLVM in the past that was found to infringe). Having | |
559 | code in LLVM that infringes on patents would violate an important goal of the | |
560 | project by making it hard or impossible to reuse the code for arbitrary purposes | |
561 | (including commercial use). | |
562 | ||
563 | When contributing code, we expect contributors to notify us of any potential for | |
564 | patent-related trouble with their changes (including from third parties). If | |
565 | you or your employer own the rights to a patent and would like to contribute | |
566 | code to LLVM that relies on it, we require that the copyright owner sign an | |
567 | agreement that allows any other user of LLVM to freely use your patent. Please | |
568 | contact the `oversight group <mailto:llvm-oversight@cs.uiuc.edu>`_ for more | |
569 | details. |