|
150
|
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 tree as stable as possible.
|
|
|
26
|
|
|
27 #. Establish awareness of the project's :ref:`copyright, license, and patent
|
|
|
28 policies <copyright-license-patents>` with contributors to the project.
|
|
|
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.llvm.org/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 `llvm-dev
|
|
|
51 <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ for LLVM, `cfe-dev
|
|
|
52 <http://lists.llvm.org/mailman/listinfo/cfe-dev>`_ for Clang, or `lldb-dev
|
|
|
53 <http://lists.llvm.org/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.llvm.org/mailman/listinfo/llvm-commits>`_, `cfe-commits
|
|
|
58 <http://lists.llvm.org/mailman/listinfo/cfe-commits>`_, or `lldb-commits
|
|
|
59 <http://lists.llvm.org/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 <https://bugs.llvm.org/>`_ and preferably subscribe to the `llvm-bugs
|
|
|
66 <http://lists.llvm.org/mailman/listinfo/llvm-bugs>`_ 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
|
|
|
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
|
|
|
74 .. _patch:
|
|
|
75 .. _one-off patches:
|
|
|
76
|
|
|
77 Making and Submitting a Patch
|
|
|
78 -----------------------------
|
|
|
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 git master, not a branch, and not an old version
|
|
|
84 of LLVM. This makes it easy to apply the patch. For information on how to
|
|
|
85 clone from git, please see the :ref:`Getting Started Guide
|
|
|
86 <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 ``git format-patch``, 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 Once your patch is ready, submit it by emailing it to the appropriate project's
|
|
|
97 commit mailing list (or commit it directly if applicable). Alternatively, some
|
|
|
98 patches get sent to the project's development list or component of the LLVM bug
|
|
|
99 tracker, but the commit list is the primary place for reviews and should
|
|
|
100 generally be preferred.
|
|
|
101
|
|
|
102 When sending a patch to a mailing list, it is a good idea to send it as an
|
|
|
103 *attachment* to the message, not embedded into the text of the message. This
|
|
|
104 ensures that your mailer will not mangle the patch when it sends it (e.g. by
|
|
|
105 making whitespace changes or by wrapping lines).
|
|
|
106
|
|
|
107 *For Thunderbird users:* Before submitting a patch, please open *Preferences >
|
|
|
108 Advanced > General > Config Editor*, find the key
|
|
|
109 ``mail.content_disposition_type``, and set its value to ``1``. Without this
|
|
|
110 setting, Thunderbird sends your attachment using ``Content-Disposition: inline``
|
|
|
111 rather than ``Content-Disposition: attachment``. Apple Mail gamely displays such
|
|
|
112 a file inline, making it difficult to work with for reviewers using that
|
|
|
113 program.
|
|
|
114
|
|
|
115 When submitting patches, please do not add confidentiality or non-disclosure
|
|
|
116 notices to the patches themselves. These notices conflict with the LLVM
|
|
|
117 licensing terms and may result in your contribution being excluded.
|
|
|
118
|
|
|
119 .. _code review:
|
|
|
120
|
|
|
121 Code Reviews
|
|
|
122 ------------
|
|
|
123
|
|
|
124 LLVM has a code review policy. Code review is one way to increase the quality of
|
|
|
125 software. We generally follow these policies:
|
|
|
126
|
|
|
127 #. All developers are required to have significant changes reviewed before they
|
|
|
128 are committed to the repository.
|
|
|
129
|
|
|
130 #. Code reviews are conducted by email on the relevant project's commit mailing
|
|
|
131 list, or alternatively on the project's development list or bug tracker.
|
|
|
132
|
|
|
133 #. Code can be reviewed either before it is committed or after. We expect major
|
|
|
134 changes to be reviewed before being committed, but smaller changes (or
|
|
|
135 changes where the developer owns the component) can be reviewed after commit.
|
|
|
136
|
|
|
137 #. The developer responsible for a code change is also responsible for making
|
|
|
138 all necessary review-related changes.
|
|
|
139
|
|
|
140 #. Code review can be an iterative process, which continues until the patch is
|
|
|
141 ready to be committed. Specifically, once a patch is sent out for review, it
|
|
|
142 needs an explicit "looks good" before it is submitted. Do not assume silent
|
|
|
143 approval, or request active objections to the patch with a deadline.
|
|
|
144
|
|
|
145 Sometimes code reviews will take longer than you would hope for, especially for
|
|
|
146 larger features. Accepted ways to speed up review times for your patches are:
|
|
|
147
|
|
|
148 * Review other people's patches. If you help out, everybody will be more
|
|
|
149 willing to do the same for you; goodwill is our currency.
|
|
|
150 * Ping the patch. If it is urgent, provide reasons why it is important to you to
|
|
|
151 get this patch landed and ping it every couple of days. If it is
|
|
|
152 not urgent, the common courtesy ping rate is one week. Remember that you're
|
|
|
153 asking for valuable time from other professional developers.
|
|
|
154 * Ask for help on IRC. Developers on IRC will be able to either help you
|
|
|
155 directly, or tell you who might be a good reviewer.
|
|
|
156 * Split your patch into multiple smaller patches that build on each other. The
|
|
|
157 smaller your patch, the higher the probability that somebody will take a quick
|
|
|
158 look at it.
|
|
|
159
|
|
|
160 Developers should participate in code reviews as both reviewers and
|
|
|
161 reviewees. If someone is kind enough to review your code, you should return the
|
|
|
162 favor for someone else. Note that anyone is welcome to review and give feedback
|
|
|
163 on a patch, but only people with GitHub commit access can approve it.
|
|
|
164
|
|
|
165 There is a web based code review tool that can optionally be used
|
|
|
166 for code reviews. See :doc:`Phabricator`.
|
|
|
167
|
|
|
168 .. _code owners:
|
|
|
169
|
|
|
170 Code Owners
|
|
|
171 -----------
|
|
|
172
|
|
|
173 The LLVM Project relies on two features of its process to maintain rapid
|
|
|
174 development in addition to the high quality of its source base: the combination
|
|
|
175 of code review plus post-commit review for trusted maintainers. Having both is
|
|
|
176 a great way for the project to take advantage of the fact that most people do
|
|
|
177 the right thing most of the time, and only commit patches without pre-commit
|
|
|
178 review when they are confident they are right.
|
|
|
179
|
|
|
180 The trick to this is that the project has to guarantee that all patches that are
|
|
|
181 committed are reviewed after they go in: you don't want everyone to assume
|
|
|
182 someone else will review it, allowing the patch to go unreviewed. To solve this
|
|
|
183 problem, we have a notion of an 'owner' for a piece of the code. The sole
|
|
|
184 responsibility of a code owner is to ensure that a commit to their area of the
|
|
|
185 code is appropriately reviewed, either by themself or by someone else. The list
|
|
|
186 of current code owners can be found in the file `CODE_OWNERS.TXT
|
|
|
187 <https://github.com/llvm/llvm-project/blob/master/llvm/CODE_OWNERS.TXT>`_ in the
|
|
|
188 root of the LLVM source tree.
|
|
|
189
|
|
|
190 Note that code ownership is completely different than reviewers: anyone can
|
|
|
191 review a piece of code, and we welcome code review from anyone who is
|
|
|
192 interested. Code owners are the "last line of defense" to guarantee that all
|
|
|
193 patches that are committed are actually reviewed.
|
|
|
194
|
|
|
195 Being a code owner is a somewhat unglamorous position, but it is incredibly
|
|
|
196 important for the ongoing success of the project. Because people get busy,
|
|
|
197 interests change, and unexpected things happen, code ownership is purely opt-in,
|
|
|
198 and anyone can choose to resign their "title" at any time. For now, we do not
|
|
|
199 have an official policy on how one gets elected to be a code owner.
|
|
|
200
|
|
|
201 .. _include a testcase:
|
|
|
202
|
|
|
203 Test Cases
|
|
|
204 ----------
|
|
|
205
|
|
|
206 Developers are required to create test cases for any bugs fixed and any new
|
|
|
207 features added. Some tips for getting your testcase approved:
|
|
|
208
|
|
|
209 * All feature and regression test cases are added to the ``llvm/test``
|
|
|
210 directory. The appropriate sub-directory should be selected (see the
|
|
|
211 :doc:`Testing Guide <TestingGuide>` for details).
|
|
|
212
|
|
|
213 * Test cases should be written in :doc:`LLVM assembly language <LangRef>`.
|
|
|
214
|
|
|
215 * Test cases, especially for regressions, should be reduced as much as possible,
|
|
|
216 by :doc:`bugpoint <Bugpoint>` or manually. It is unacceptable to place an
|
|
|
217 entire failing program into ``llvm/test`` as this creates a *time-to-test*
|
|
|
218 burden on all developers. Please keep them short.
|
|
|
219
|
|
|
220 Note that llvm/test and clang/test are designed for regression and small feature
|
|
|
221 tests only. More extensive test cases (e.g., entire applications, benchmarks,
|
|
|
222 etc) should be added to the ``llvm-test`` test suite. The llvm-test suite is
|
|
|
223 for coverage (correctness, performance, etc) testing, not feature or regression
|
|
|
224 testing.
|
|
|
225
|
|
|
226 Quality
|
|
|
227 -------
|
|
|
228
|
|
|
229 The minimum quality standards that any change must satisfy before being
|
|
|
230 committed to the main development branch are:
|
|
|
231
|
|
|
232 #. Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
|
|
|
233
|
|
|
234 #. Code must compile cleanly (no errors, no warnings) on at least one platform.
|
|
|
235
|
|
|
236 #. Bug fixes and new features should `include a testcase`_ so we know if the
|
|
|
237 fix/feature ever regresses in the future.
|
|
|
238
|
|
|
239 #. Code must pass the ``llvm/test`` test suite.
|
|
|
240
|
|
|
241 #. The code must not cause regressions on a reasonable subset of llvm-test,
|
|
|
242 where "reasonable" depends on the contributor's judgement and the scope of
|
|
|
243 the change (more invasive changes require more testing). A reasonable subset
|
|
|
244 might be something like "``llvm-test/MultiSource/Benchmarks``".
|
|
|
245
|
|
|
246 Additionally, the committer is responsible for addressing any problems found in
|
|
|
247 the future that the change is responsible for. For example:
|
|
|
248
|
|
|
249 * The code should compile cleanly on all supported platforms.
|
|
|
250
|
|
|
251 * The changes should not cause any correctness regressions in the ``llvm-test``
|
|
|
252 suite and must not cause any major performance regressions.
|
|
|
253
|
|
|
254 * The change set should not cause performance or correctness regressions for the
|
|
|
255 LLVM tools.
|
|
|
256
|
|
|
257 * The changes should not cause performance or correctness regressions in code
|
|
|
258 compiled by LLVM on all applicable targets.
|
|
|
259
|
|
|
260 * You are expected to address any `Bugzilla bugs <https://bugs.llvm.org/>`_ that
|
|
|
261 result from your change.
|
|
|
262
|
|
|
263 We prefer for this to be handled before submission but understand that it isn't
|
|
|
264 possible to test all of this for every submission. Our build bots and nightly
|
|
|
265 testing infrastructure normally finds these problems. A good rule of thumb is
|
|
|
266 to check the nightly testers for regressions the day after your change. Build
|
|
|
267 bots will directly email you if a group of commits that included yours caused a
|
|
|
268 failure. You are expected to check the build bot messages to see if they are
|
|
|
269 your fault and, if so, fix the breakage.
|
|
|
270
|
|
|
271 Commits that violate these quality standards (e.g. are very broken) may be
|
|
|
272 reverted. This is necessary when the change blocks other developers from making
|
|
|
273 progress. The developer is welcome to re-commit the change after the problem has
|
|
|
274 been fixed.
|
|
|
275
|
|
|
276 .. _commit messages:
|
|
|
277
|
|
|
278 Commit messages
|
|
|
279 ---------------
|
|
|
280
|
|
|
281 Although we don't enforce the format of commit messages, we prefer that
|
|
|
282 you follow these guidelines to help review, search in logs, email formatting
|
|
|
283 and so on. These guidelines are very similar to rules used by other open source
|
|
|
284 projects.
|
|
|
285
|
|
|
286 Most importantly, the contents of the message should be carefully written to
|
|
|
287 convey the rationale of the change (without delving too much in detail). It
|
|
|
288 also should avoid being vague or overly specific. For example, "bits were not
|
|
|
289 set right" will leave the reviewer wondering about which bits, and why they
|
|
|
290 weren't right, while "Correctly set overflow bits in TargetInfo" conveys almost
|
|
|
291 all there is to the change.
|
|
|
292
|
|
|
293 Below are some guidelines about the format of the message itself:
|
|
|
294
|
|
|
295 * Separate the commit message into title and body separated by a blank line.
|
|
|
296
|
|
|
297 * If you're not the original author, ensure the 'Author' property of the commit is
|
|
|
298 set to the original author and the 'Committer' property is set to yourself.
|
|
|
299 You can use a command similar to
|
|
|
300 ``git commit --amend --author="John Doe <jdoe@llvm.org>`` to correct the
|
|
|
301 author property if it is incorrect. See `Attribution of Changes`_ for more
|
|
|
302 information including the method we used for attribution before the project
|
|
|
303 migrated to git.
|
|
|
304
|
|
|
305 * The title should be concise. Because all commits are emailed to the list with
|
|
|
306 the first line as the subject, long titles are frowned upon. Short titles
|
|
|
307 also look better in `git log`.
|
|
|
308
|
|
|
309 * When the changes are restricted to a specific part of the code (e.g. a
|
|
|
310 back-end or optimization pass), it is customary to add a tag to the
|
|
|
311 beginning of the line in square brackets. For example, "[SCEV] ..."
|
|
|
312 or "[OpenMP] ...". This helps email filters and searches for post-commit
|
|
|
313 reviews.
|
|
|
314
|
|
|
315 * The body, if it exists, should be separated from the title by an empty line.
|
|
|
316
|
|
|
317 * The body should be concise, but explanatory, including a complete
|
|
|
318 reasoning. Unless it is required to understand the change, examples,
|
|
|
319 code snippets and gory details should be left to bug comments, web
|
|
|
320 review or the mailing list.
|
|
|
321
|
|
|
322 * If the patch fixes a bug in bugzilla, please include the PR# in the message.
|
|
|
323
|
|
|
324 * Text formatting and spelling should follow the same rules as documentation
|
|
|
325 and in-code comments, ex. capitalization, full stop, etc.
|
|
|
326
|
|
|
327 * If the commit is a bug fix on top of another recently committed patch, or a
|
|
|
328 revert or reapply of a patch, include the git commit hash of the prior
|
|
|
329 related commit. This could be as simple as "Revert commit NNNN because it
|
|
|
330 caused PR#".
|
|
|
331
|
|
|
332 For minor violations of these recommendations, the community normally favors
|
|
|
333 reminding the contributor of this policy over reverting. Minor corrections and
|
|
|
334 omissions can be handled by sending a reply to the commits mailing list.
|
|
|
335
|
|
|
336 Obtaining Commit Access
|
|
|
337 -----------------------
|
|
|
338
|
|
|
339 New Contributors
|
|
|
340 ^^^^^^^^^^^^^^^^
|
|
|
341 We grant commit access to contributors with a track record of submitting high
|
|
|
342 quality patches. If you would like commit access, please send an email to
|
|
|
343 `Chris <mailto:clattner@llvm.org>`_ with your GitHub username.
|
|
|
344
|
|
|
345 Prior to obtaining commit access, it is common practice to request that
|
|
|
346 someone with commit access commits on your behalf. When doing so, please
|
|
|
347 provide the name and email address you would like to use in the Author
|
|
|
348 property of the commit.
|
|
|
349
|
|
|
350 Your first commit to a repository may require the autogenerated email to be
|
|
|
351 approved by a moderator of the mailing list.
|
|
|
352 This is normal and will be done when the mailing list owner has time.
|
|
|
353
|
|
|
354 If you have recently been granted commit access, these policies apply:
|
|
|
355
|
|
|
356 #. You are granted *commit-after-approval* to all parts of LLVM. To get
|
|
|
357 approval, submit a `patch`_ to `llvm-commits
|
|
|
358 <http://lists.llvm.org/mailman/listinfo/llvm-commits>`_. When approved,
|
|
|
359 you may commit it yourself.
|
|
|
360
|
|
|
361 #. You are allowed to commit patches without approval which you think are
|
|
|
362 obvious. This is clearly a subjective decision --- we simply expect you to
|
|
|
363 use good judgement. Examples include: fixing build breakage, reverting
|
|
|
364 obviously broken patches, documentation/comment changes, any other minor
|
|
|
365 changes. Avoid committing formatting- or whitespace-only changes outside of
|
|
|
366 code you plan to make subsequent changes to. Also, try to separate
|
|
|
367 formatting or whitespace changes from functional changes, either by
|
|
|
368 correcting the format first (ideally) or afterward. Such changes should be
|
|
|
369 highly localized and the commit message should clearly state that the commit
|
|
|
370 is not intended to change functionality, usually by stating it is
|
|
|
371 :ref:`NFC <nfc>`.
|
|
|
372
|
|
|
373 #. You are allowed to commit patches without approval to those portions of LLVM
|
|
|
374 that you have contributed or maintain (i.e., have been assigned
|
|
|
375 responsibility for), with the proviso that such commits must not break the
|
|
|
376 build. This is a "trust but verify" policy, and commits of this nature are
|
|
|
377 reviewed after they are committed.
|
|
|
378
|
|
|
379 #. Multiple violations of these policies or a single egregious violation may
|
|
|
380 cause commit access to be revoked.
|
|
|
381
|
|
|
382 In any case, your changes are still subject to `code review`_ (either before or
|
|
|
383 after they are committed, depending on the nature of the change). You are
|
|
|
384 encouraged to review other peoples' patches as well, but you aren't required
|
|
|
385 to do so.
|
|
|
386
|
|
|
387 Current Contributors - Transferring from SVN
|
|
|
388 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
389 If you had commit access to SVN and would like to request commit access to
|
|
|
390 GitHub, please email `llvm-admin <mailto:llvm-admin@lists.llvm.org>`_ with your
|
|
|
391 SVN username and GitHub username.
|
|
|
392
|
|
|
393 .. _discuss the change/gather consensus:
|
|
|
394
|
|
|
395 Making a Major Change
|
|
|
396 ---------------------
|
|
|
397
|
|
|
398 When a developer begins a major new project with the aim of contributing it back
|
|
|
399 to LLVM, they should inform the community with an email to the `llvm-dev
|
|
|
400 <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ email list, to the extent
|
|
|
401 possible. The reason for this is to:
|
|
|
402
|
|
|
403 #. keep the community informed about future changes to LLVM,
|
|
|
404
|
|
|
405 #. avoid duplication of effort by preventing multiple parties working on the
|
|
|
406 same thing and not knowing about it, and
|
|
|
407
|
|
|
408 #. ensure that any technical issues around the proposed work are discussed and
|
|
|
409 resolved before any significant work is done.
|
|
|
410
|
|
|
411 The design of LLVM is carefully controlled to ensure that all the pieces fit
|
|
|
412 together well and are as consistent as possible. If you plan to make a major
|
|
|
413 change to the way LLVM works or want to add a major new extension, it is a good
|
|
|
414 idea to get consensus with the development community before you start working on
|
|
|
415 it.
|
|
|
416
|
|
|
417 Once the design of the new feature is finalized, the work itself should be done
|
|
|
418 as a series of `incremental changes`_, not as a long-term development branch.
|
|
|
419
|
|
|
420 .. _incremental changes:
|
|
|
421
|
|
|
422 Incremental Development
|
|
|
423 -----------------------
|
|
|
424
|
|
|
425 In the LLVM project, we do all significant changes as a series of incremental
|
|
|
426 patches. We have a strong dislike for huge changes or long-term development
|
|
|
427 branches. Long-term development branches have a number of drawbacks:
|
|
|
428
|
|
|
429 #. Branches must have mainline merged into them periodically. If the branch
|
|
|
430 development and mainline development occur in the same pieces of code,
|
|
|
431 resolving merge conflicts can take a lot of time.
|
|
|
432
|
|
|
433 #. Other people in the community tend to ignore work on branches.
|
|
|
434
|
|
|
435 #. Huge changes (produced when a branch is merged back onto mainline) are
|
|
|
436 extremely difficult to `code review`_.
|
|
|
437
|
|
|
438 #. Branches are not routinely tested by our nightly tester infrastructure.
|
|
|
439
|
|
|
440 #. Changes developed as monolithic large changes often don't work until the
|
|
|
441 entire set of changes is done. Breaking it down into a set of smaller
|
|
|
442 changes increases the odds that any of the work will be committed to the main
|
|
|
443 repository.
|
|
|
444
|
|
|
445 To address these problems, LLVM uses an incremental development style and we
|
|
|
446 require contributors to follow this practice when making a large/invasive
|
|
|
447 change. Some tips:
|
|
|
448
|
|
|
449 * Large/invasive changes usually have a number of secondary changes that are
|
|
|
450 required before the big change can be made (e.g. API cleanup, etc). These
|
|
|
451 sorts of changes can often be done before the major change is done,
|
|
|
452 independently of that work.
|
|
|
453
|
|
|
454 * The remaining inter-related work should be decomposed into unrelated sets of
|
|
|
455 changes if possible. Once this is done, define the first increment and get
|
|
|
456 consensus on what the end goal of the change is.
|
|
|
457
|
|
|
458 * Each change in the set can be stand alone (e.g. to fix a bug), or part of a
|
|
|
459 planned series of changes that works towards the development goal.
|
|
|
460
|
|
|
461 * Each change should be kept as small as possible. This simplifies your work
|
|
|
462 (into a logical progression), simplifies code review and reduces the chance
|
|
|
463 that you will get negative feedback on the change. Small increments also
|
|
|
464 facilitate the maintenance of a high quality code base.
|
|
|
465
|
|
|
466 * Often, an independent precursor to a big change is to add a new API and slowly
|
|
|
467 migrate clients to use the new API. Each change to use the new API is often
|
|
|
468 "obvious" and can be committed without review. Once the new API is in place
|
|
|
469 and used, it is much easier to replace the underlying implementation of the
|
|
|
470 API. This implementation change is logically separate from the API
|
|
|
471 change.
|
|
|
472
|
|
|
473 If you are interested in making a large change, and this scares you, please make
|
|
|
474 sure to first `discuss the change/gather consensus`_ then ask about the best way
|
|
|
475 to go about making the change.
|
|
|
476
|
|
|
477 Attribution of Changes
|
|
|
478 ----------------------
|
|
|
479
|
|
|
480 When contributors submit a patch to an LLVM project, other developers with
|
|
|
481 commit access may commit it for the author once appropriate (based on the
|
|
|
482 progression of code review, etc.). When doing so, it is important to retain
|
|
|
483 correct attribution of contributions to their contributors. However, we do not
|
|
|
484 want the source code to be littered with random attributions "this code written
|
|
|
485 by J. Random Hacker" (this is noisy and distracting). In practice, the revision
|
|
|
486 control system keeps a perfect history of who changed what, and the CREDITS.txt
|
|
|
487 file describes higher-level contributions. If you commit a patch for someone
|
|
|
488 else, please follow the attribution of changes in the simple manner as outlined
|
|
|
489 by the `commit messages`_ section. Overall, please do not add contributor names
|
|
|
490 to the source code.
|
|
|
491
|
|
|
492 Also, don't commit patches authored by others unless they have submitted the
|
|
|
493 patch to the project or you have been authorized to submit them on their behalf
|
|
|
494 (you work together and your company authorized you to contribute the patches,
|
|
|
495 etc.). The author should first submit them to the relevant project's commit
|
|
|
496 list, development list, or LLVM bug tracker component. If someone sends you
|
|
|
497 a patch privately, encourage them to submit it to the appropriate list first.
|
|
|
498
|
|
|
499 Our previous version control system (subversion) did not distinguish between the
|
|
|
500 author and the committer like git does. As such, older commits used a different
|
|
|
501 attribution mechanism. The previous method was to include "Patch by John Doe."
|
|
|
502 in a separate line of the commit message and there are automated processes that
|
|
|
503 rely on this format.
|
|
|
504
|
|
|
505 .. _IR backwards compatibility:
|
|
|
506
|
|
|
507 IR Backwards Compatibility
|
|
|
508 --------------------------
|
|
|
509
|
|
|
510 When the IR format has to be changed, keep in mind that we try to maintain some
|
|
|
511 backwards compatibility. The rules are intended as a balance between convenience
|
|
|
512 for llvm users and not imposing a big burden on llvm developers:
|
|
|
513
|
|
|
514 * The textual format is not backwards compatible. We don't change it too often,
|
|
|
515 but there are no specific promises.
|
|
|
516
|
|
|
517 * Additions and changes to the IR should be reflected in
|
|
|
518 ``test/Bitcode/compatibility.ll``.
|
|
|
519
|
|
|
520 * The current LLVM version supports loading any bitcode since version 3.0.
|
|
|
521
|
|
|
522 * After each X.Y release, ``compatibility.ll`` must be copied to
|
|
|
523 ``compatibility-X.Y.ll``. The corresponding bitcode file should be assembled
|
|
|
524 using the X.Y build and committed as ``compatibility-X.Y.ll.bc``.
|
|
|
525
|
|
|
526 * Newer releases can ignore features from older releases, but they cannot
|
|
|
527 miscompile them. For example, if nsw is ever replaced with something else,
|
|
|
528 dropping it would be a valid way to upgrade the IR.
|
|
|
529
|
|
|
530 * Debug metadata is special in that it is currently dropped during upgrades.
|
|
|
531
|
|
|
532 * Non-debug metadata is defined to be safe to drop, so a valid way to upgrade
|
|
|
533 it is to drop it. That is not very user friendly and a bit more effort is
|
|
|
534 expected, but no promises are made.
|
|
|
535
|
|
|
536 C API Changes
|
|
|
537 ----------------
|
|
|
538
|
|
|
539 * Stability Guarantees: The C API is, in general, a "best effort" for stability.
|
|
|
540 This means that we make every attempt to keep the C API stable, but that
|
|
|
541 stability will be limited by the abstractness of the interface and the
|
|
|
542 stability of the C++ API that it wraps. In practice, this means that things
|
|
|
543 like "create debug info" or "create this type of instruction" are likely to be
|
|
|
544 less stable than "take this IR file and JIT it for my current machine".
|
|
|
545
|
|
|
546 * Release stability: We won't break the C API on the release branch with patches
|
|
|
547 that go on that branch, with the exception that we will fix an unintentional
|
|
|
548 C API break that will keep the release consistent with both the previous and
|
|
|
549 next release.
|
|
|
550
|
|
|
551 * Testing: Patches to the C API are expected to come with tests just like any
|
|
|
552 other patch.
|
|
|
553
|
|
|
554 * Including new things into the API: If an LLVM subcomponent has a C API already
|
|
|
555 included, then expanding that C API is acceptable. Adding C API for
|
|
|
556 subcomponents that don't currently have one needs to be discussed on the
|
|
|
557 mailing list for design and maintainability feedback prior to implementation.
|
|
|
558
|
|
|
559 * Documentation: Any changes to the C API are required to be documented in the
|
|
|
560 release notes so that it's clear to external users who do not follow the
|
|
|
561 project how the C API is changing and evolving.
|
|
|
562
|
|
|
563 New Targets
|
|
|
564 -----------
|
|
|
565
|
|
|
566 LLVM is very receptive to new targets, even experimental ones, but a number of
|
|
|
567 problems can appear when adding new large portions of code, and back-ends are
|
|
|
568 normally added in bulk. We have found that landing large pieces of new code
|
|
|
569 and then trying to fix emergent problems in-tree is problematic for a variety
|
|
|
570 of reasons.
|
|
|
571
|
|
|
572 For these reasons, new targets are *always* added as *experimental* until
|
|
|
573 they can be proven stable, and later moved to non-experimental. The difference
|
|
|
574 between both classes is that experimental targets are not built by default
|
|
|
575 (need to be added to -DLLVM_TARGETS_TO_BUILD at CMake time).
|
|
|
576
|
|
|
577 The basic rules for a back-end to be upstreamed in **experimental** mode are:
|
|
|
578
|
|
|
579 * Every target must have a :ref:`code owner<code owners>`. The `CODE_OWNERS.TXT`
|
|
|
580 file has to be updated as part of the first merge. The code owner makes sure
|
|
|
581 that changes to the target get reviewed and steers the overall effort.
|
|
|
582
|
|
|
583 * There must be an active community behind the target. This community
|
|
|
584 will help maintain the target by providing buildbots, fixing
|
|
|
585 bugs, answering the LLVM community's questions and making sure the new
|
|
|
586 target doesn't break any of the other targets, or generic code. This
|
|
|
587 behavior is expected to continue throughout the lifetime of the
|
|
|
588 target's code.
|
|
|
589
|
|
|
590 * The code must be free of contentious issues, for example, large
|
|
|
591 changes in how the IR behaves or should be formed by the front-ends,
|
|
|
592 unless agreed by the majority of the community via refactoring of the
|
|
|
593 (:doc:`IR standard<LangRef>`) **before** the merge of the new target changes,
|
|
|
594 following the :ref:`IR backwards compatibility`.
|
|
|
595
|
|
|
596 * The code conforms to all of the policies laid out in this developer policy
|
|
|
597 document, including license, patent, and coding standards.
|
|
|
598
|
|
|
599 * The target should have either reasonable documentation on how it
|
|
|
600 works (ISA, ABI, etc.) or a publicly available simulator/hardware
|
|
|
601 (either free or cheap enough) - preferably both. This allows
|
|
|
602 developers to validate assumptions, understand constraints and review code
|
|
|
603 that can affect the target.
|
|
|
604
|
|
|
605 In addition, the rules for a back-end to be promoted to **official** are:
|
|
|
606
|
|
|
607 * The target must have addressed every other minimum requirement and
|
|
|
608 have been stable in tree for at least 3 months. This cool down
|
|
|
609 period is to make sure that the back-end and the target community can
|
|
|
610 endure continuous upstream development for the foreseeable future.
|
|
|
611
|
|
|
612 * The target's code must have been completely adapted to this policy
|
|
|
613 as well as the :doc:`coding standards<CodingStandards>`. Any exceptions that
|
|
|
614 were made to move into experimental mode must have been fixed **before**
|
|
|
615 becoming official.
|
|
|
616
|
|
|
617 * The test coverage needs to be broad and well written (small tests,
|
|
|
618 well documented). The build target ``check-all`` must pass with the
|
|
|
619 new target built, and where applicable, the ``test-suite`` must also
|
|
|
620 pass without errors, in at least one configuration (publicly
|
|
|
621 demonstrated, for example, via buildbots).
|
|
|
622
|
|
|
623 * Public buildbots need to be created and actively maintained, unless
|
|
|
624 the target requires no additional buildbots (ex. ``check-all`` covers
|
|
|
625 all tests). The more relevant and public the new target's CI infrastructure
|
|
|
626 is, the more the LLVM community will embrace it.
|
|
|
627
|
|
|
628 To **continue** as a supported and official target:
|
|
|
629
|
|
|
630 * The maintainer(s) must continue following these rules throughout the lifetime
|
|
|
631 of the target. Continuous violations of aforementioned rules and policies
|
|
|
632 could lead to complete removal of the target from the code base.
|
|
|
633
|
|
|
634 * Degradation in support, documentation or test coverage will make the target as
|
|
|
635 nuisance to other targets and be considered a candidate for deprecation and
|
|
|
636 ultimately removed.
|
|
|
637
|
|
|
638 In essences, these rules are necessary for targets to gain and retain their
|
|
|
639 status, but also markers to define bit-rot, and will be used to clean up the
|
|
|
640 tree from unmaintained targets.
|
|
|
641
|
|
|
642 .. _toolchain:
|
|
|
643
|
|
|
644 Updating Toolchain Requirements
|
|
|
645 -------------------------------
|
|
|
646
|
|
|
647 We intend to require newer toolchains as time goes by. This means LLVM's
|
|
|
648 codebase can use newer versions of C++ as they get standardized. Requiring newer
|
|
|
649 toolchains to build LLVM can be painful for those building LLVM; therefore, it
|
|
|
650 will only be done through the following process:
|
|
|
651
|
|
|
652 * Generally, try to support LLVM and GCC versions from the last 3 years at a
|
|
|
653 minimum. This time-based guideline is not strict: we may support much older
|
|
|
654 compilers, or decide to support fewer versions.
|
|
|
655
|
|
|
656 * An RFC is sent to the `llvm-dev mailing list <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_
|
|
|
657
|
|
|
658 - Detail upsides of the version increase (e.g. which newer C++ language or
|
|
|
659 library features LLVM should use; avoid miscompiles in particular compiler
|
|
|
660 versions, etc).
|
|
|
661 - Detail downsides on important platforms (e.g. Ubuntu LTS status).
|
|
|
662
|
|
|
663 * Once the RFC reaches consensus, update the CMake toolchain version checks as
|
|
|
664 well as the :doc:`getting started<GettingStarted>` guide. We want to
|
|
|
665 soft-error when developers compile LLVM. We say "soft-error" because the
|
|
|
666 error can be turned into a warning using a CMake flag. This is an important
|
|
|
667 step: LLVM still doesn't have code which requires the new toolchains, but it
|
|
|
668 soon will. If you compile LLVM but don't read the mailing list, we should
|
|
|
669 tell you!
|
|
|
670
|
|
|
671 * Ensure that at least one LLVM release has had this soft-error. Not all
|
|
|
672 developers compile LLVM top-of-tree. These release-bound developers should
|
|
|
673 also be told about upcoming changes.
|
|
|
674
|
|
|
675 * Turn the soft-error into a hard-error after said LLVM release has branched.
|
|
|
676
|
|
|
677 * Update the :doc:`coding standards<CodingStandards>` to allow the new
|
|
|
678 features we've explicitly approved in the RFC.
|
|
|
679
|
|
|
680 * Start using the new features in LLVM's codebase.
|
|
|
681
|
|
|
682 Here's a `sample RFC
|
|
|
683 <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html>`_ and the
|
|
|
684 `corresponding change <https://reviews.llvm.org/D57264>`_.
|
|
|
685
|
|
|
686 .. _copyright-license-patents:
|
|
|
687
|
|
|
688 Copyright, License, and Patents
|
|
|
689 ===============================
|
|
|
690
|
|
|
691 .. note::
|
|
|
692
|
|
|
693 This section deals with legal matters but does not provide legal advice. We
|
|
|
694 are not lawyers --- please seek legal counsel from a licensed attorney.
|
|
|
695
|
|
|
696 This section addresses the issues of copyright, license and patents for the LLVM
|
|
|
697 project. The copyright for the code is held by the contributors of
|
|
|
698 the code. The code is licensed under permissive `open source licensing terms`_,
|
|
|
699 namely the Apache 2 license, which includes a copyright and `patent license`_.
|
|
|
700 When you contribute code to the LLVM project, you license it under these terms.
|
|
|
701
|
|
|
702 If you have questions or comments about these topics, please contact the
|
|
|
703 `LLVM Developer's Mailing List <mailto:llvm-dev@lists.llvm.org>`_. However,
|
|
|
704 please realize that most compiler developers are not lawyers, and therefore you
|
|
|
705 will not be getting official legal advice.
|
|
|
706
|
|
|
707 Copyright
|
|
|
708 ---------
|
|
|
709
|
|
|
710 The LLVM project does not collect copyright assignments, which means that the
|
|
|
711 copyright for the code in the project is held by the respective contributors.
|
|
|
712 Because you (or your company)
|
|
|
713 retain ownership of the code you contribute, you know it may only be used under
|
|
|
714 the terms of the open source license you contributed it under: the license for
|
|
|
715 your contributions cannot be changed in the future without your approval.
|
|
|
716
|
|
|
717 Because the LLVM project does not require copyright assignments, changing the
|
|
|
718 LLVM license requires tracking down the
|
|
|
719 contributors to LLVM and getting them to agree that a license change is
|
|
|
720 acceptable for their contributions. We feel that a high burden for relicensing
|
|
|
721 is good for the project, because contributors do not have to fear that their
|
|
|
722 code will be used in a way with which they disagree.
|
|
|
723
|
|
|
724 Relicensing
|
|
|
725 -----------
|
|
|
726
|
|
|
727 The last paragraph notwithstanding, the LLVM Project is in the middle of a large
|
|
|
728 effort to change licenses, which aims to solve several problems:
|
|
|
729
|
|
|
730 * The old licenses made it difficult to move code from (e.g.) the compiler to
|
|
|
731 runtime libraries, because runtime libraries used a different license from the
|
|
|
732 rest of the compiler.
|
|
|
733 * Some contributions were not submitted to LLVM due to concerns that
|
|
|
734 the patent grant required by the project was overly broad.
|
|
|
735 * The patent grant was unique to the LLVM Project, not written by a lawyer, and
|
|
|
736 was difficult to determine what protection was provided (if any).
|
|
|
737
|
|
|
738 The scope of relicensing is all code that is considered part of the LLVM
|
|
|
739 project, including the main LLVM repository, runtime libraries (compiler_rt,
|
|
|
740 OpenMP, etc), Polly, and all other subprojects. There are a few exceptions:
|
|
|
741
|
|
|
742 * Code imported from other projects (e.g. Google Test, Autoconf, etc) will
|
|
|
743 remain as it is. This code isn't developed as part of the LLVM project, it
|
|
|
744 is used by LLVM.
|
|
|
745 * Some subprojects are impractical or uninteresting to relicense (e.g. llvm-gcc
|
|
|
746 and dragonegg). These will be split off from the LLVM project (e.g. to
|
|
|
747 separate GitHub projects), allowing interested people to continue their
|
|
|
748 development elsewhere.
|
|
|
749
|
|
|
750 To relicense LLVM, we will be seeking approval from all of the copyright holders
|
|
|
751 of code in the repository, or potentially remove/rewrite code if we cannot.
|
|
|
752 This is a large
|
|
|
753 and challenging project which will take a significant amount of time to
|
|
|
754 complete. In the interim, **all contributions to the project will be made under
|
|
|
755 the terms of both the new license and the legacy license scheme** (each of which
|
|
|
756 is described below). The exception to this is the legacy patent grant, which
|
|
|
757 will not be required for new contributions.
|
|
|
758
|
|
|
759 When all of the code in the project has been converted to the new license or
|
|
|
760 removed, we will drop the requirement to contribute under the legacy license.
|
|
|
761 This will achieve the goal of having
|
|
|
762 a single standardized license for the entire codebase.
|
|
|
763
|
|
|
764 If you are a prior contributor to LLVM and have not done so already, please do
|
|
|
765 *TODO* to allow us to use your code. *Add a link to a separate page here, which
|
|
|
766 is probably a click through web form or something like that. Details to be
|
|
|
767 determined later*.
|
|
|
768
|
|
|
769
|
|
|
770 .. _open source licensing terms:
|
|
|
771
|
|
|
772 New LLVM Project License Framework
|
|
|
773 ----------------------------------
|
|
|
774
|
|
|
775 Contributions to LLVM are licensed under the `Apache License, Version 2.0
|
|
|
776 <https://www.apache.org/licenses/LICENSE-2.0>`_, with two limited
|
|
|
777 exceptions intended to ensure that LLVM is very permissively licensed.
|
|
|
778 Collectively, the name of this license is "Apache 2.0 License with LLVM
|
|
|
779 exceptions". The exceptions read:
|
|
|
780
|
|
|
781 ::
|
|
|
782
|
|
|
783 ---- LLVM Exceptions to the Apache 2.0 License ----
|
|
|
784
|
|
|
785 As an exception, if, as a result of your compiling your source code, portions
|
|
|
786 of this Software are embedded into an Object form of such source code, you
|
|
|
787 may redistribute such embedded portions in such Object form without complying
|
|
|
788 with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
|
|
|
789
|
|
|
790 In addition, if you combine or link compiled forms of this Software with
|
|
|
791 software that is licensed under the GPLv2 ("Combined Software") and if a
|
|
|
792 court of competent jurisdiction determines that the patent provision (Section
|
|
|
793 3), the indemnity provision (Section 9) or other Section of the License
|
|
|
794 conflicts with the conditions of the GPLv2, you may retroactively and
|
|
|
795 prospectively choose to deem waived or otherwise exclude such Section(s) of
|
|
|
796 the License, but only in their entirety and only with respect to the Combined
|
|
|
797 Software.
|
|
|
798
|
|
|
799
|
|
|
800 We intend to keep LLVM perpetually open source and available under a permissive
|
|
|
801 license - this fosters the widest adoption of LLVM by
|
|
|
802 **allowing commercial products to be derived from LLVM** with few restrictions
|
|
|
803 and without a requirement for making any derived works also open source. In
|
|
|
804 particular, LLVM's license is not a "copyleft" license like the GPL.
|
|
|
805
|
|
|
806 The "Apache 2.0 License with LLVM exceptions" allows you to:
|
|
|
807
|
|
|
808 * freely download and use LLVM (in whole or in part) for personal, internal, or
|
|
|
809 commercial purposes.
|
|
|
810 * include LLVM in packages or distributions you create.
|
|
|
811 * combine LLVM with code licensed under every other major open source
|
|
|
812 license (including BSD, MIT, GPLv2, GPLv3...).
|
|
|
813 * make changes to LLVM code without being required to contribute it back
|
|
|
814 to the project - contributions are appreciated though!
|
|
|
815
|
|
|
816 However, it imposes these limitations on you:
|
|
|
817
|
|
|
818 * You must retain the copyright notice if you redistribute LLVM: You cannot
|
|
|
819 strip the copyright headers off or replace them with your own.
|
|
|
820 * Binaries that include LLVM must reproduce the copyright notice (e.g. in an
|
|
|
821 included README file or in an "About" box), unless the LLVM code was added as
|
|
|
822 a by-product of compilation. For example, if an LLVM runtime library like
|
|
|
823 compiler_rt or libc++ was automatically included into your application by the
|
|
|
824 compiler, you do not need to attribute it.
|
|
|
825 * You can't use our names to promote your products (LLVM derived or not) -
|
|
|
826 though you can make truthful statements about your use of the LLVM code,
|
|
|
827 without implying our sponsorship.
|
|
|
828 * There's no warranty on LLVM at all.
|
|
|
829
|
|
|
830 We want LLVM code to be widely used, and believe that this provides a model that
|
|
|
831 is great for contributors and users of the project. For more information about
|
|
|
832 the Apache 2.0 License, please see the `Apache License FAQ
|
|
|
833 <http://www.apache.org/foundation/license-faq.html>`_, maintained by the
|
|
|
834 Apache Project.
|
|
|
835
|
|
|
836
|
|
|
837 .. note::
|
|
|
838
|
|
|
839 The LLVM Project includes some really old subprojects (dragonegg,
|
|
|
840 llvm-gcc-4.0, and llvm-gcc-4.2), which are licensed under **GPL
|
|
|
841 licenses**. This code is not actively maintained - it does not even
|
|
|
842 build successfully. This code is cleanly separated into distinct SVN
|
|
|
843 repositories from the rest of LLVM, and the LICENSE.txt files specifically
|
|
|
844 indicate that they contain GPL code. When LLVM transitions from SVN to Git,
|
|
|
845 we plan to drop these code bases from the new repository structure.
|
|
|
846
|
|
|
847
|
|
|
848 .. _patent license:
|
|
|
849
|
|
|
850 Patents
|
|
|
851 -------
|
|
|
852
|
|
|
853 Section 3 of the Apache 2.0 license is a patent grant under which
|
|
|
854 contributors of code to the project contribute the rights to use any of
|
|
|
855 their patents that would otherwise be infringed by that code contribution
|
|
|
856 (protecting uses of that code). Further, the patent grant is revoked
|
|
|
857 from anyone who files a patent lawsuit about code in LLVM - this protects the
|
|
|
858 community by providing a "patent commons" for the code base and reducing the
|
|
|
859 odds of patent lawsuits in general.
|
|
|
860
|
|
|
861 The license specifically scopes which patents are included with code
|
|
|
862 contributions. To help explain this, the `Apache License FAQ
|
|
|
863 <http://www.apache.org/foundation/license-faq.html>`_ explains this scope using
|
|
|
864 some questions and answers, which we reproduce here for your convenience (for
|
|
|
865 reference, the "ASF" is the Apache Software Foundation, the guidance still
|
|
|
866 holds though)::
|
|
|
867
|
|
|
868 Q1: If I own a patent and contribute to a Work, and, at the time my
|
|
|
869 contribution is included in that Work, none of my patent's claims are subject
|
|
|
870 to Apache's Grant of Patent License, is there a way any of those claims would
|
|
|
871 later become subject to the Grant of Patent License solely due to subsequent
|
|
|
872 contributions by other parties who are not licensees of that patent.
|
|
|
873
|
|
|
874 A1: No.
|
|
|
875
|
|
|
876 Q2: If at any time after my contribution, I am able to license other patent
|
|
|
877 claims that would have been subject to Apache's Grant of Patent License if
|
|
|
878 they were licensable by me at the time of my contribution, do those other
|
|
|
879 claims become subject to the Grant of Patent License?
|
|
|
880
|
|
|
881 A2: Yes.
|
|
|
882
|
|
|
883 Q3: If I own or control a licensable patent and contribute code to a specific
|
|
|
884 Apache product, which of my patent claims are subject to Apache's Grant of
|
|
|
885 Patent License?
|
|
|
886
|
|
|
887 A3: The only patent claims that are licensed to the ASF are those you own or
|
|
|
888 have the right to license that read on your contribution or on the
|
|
|
889 combination of your contribution with the specific Apache product to which
|
|
|
890 you contributed as it existed at the time of your contribution. No additional
|
|
|
891 patent claims become licensed as a result of subsequent combinations of your
|
|
|
892 contribution with any other software. Note, however, that licensable patent
|
|
|
893 claims include those that you acquire in the future, as long as they read on
|
|
|
894 your original contribution as made at the original time. Once a patent claim
|
|
|
895 is subject to Apache's Grant of Patent License, it is licensed under the
|
|
|
896 terms of that Grant to the ASF and to recipients of any software distributed
|
|
|
897 by the ASF for any Apache software product whatsoever.
|
|
|
898
|
|
|
899 .. _legacy:
|
|
|
900
|
|
|
901 Legacy License Structure
|
|
|
902 ------------------------
|
|
|
903
|
|
|
904 .. note::
|
|
|
905 The code base was previously licensed under the Terms described here.
|
|
|
906 We are in the middle of relicensing to a new approach (described above), but
|
|
|
907 until this effort is complete, the code is also still available under these
|
|
|
908 terms. Once we finish the relicensing project, new versions of the code will
|
|
|
909 not be available under these terms. However, nothing takes away your right
|
|
|
910 to use old versions under the licensing terms under which they were
|
|
|
911 originally released.
|
|
|
912
|
|
|
913 We intend to keep LLVM perpetually open source and to use a permissive open
|
|
|
914 source license. The code in
|
|
|
915 LLVM is available under the `University of Illinois/NCSA Open Source License
|
|
|
916 <http://www.opensource.org/licenses/UoI-NCSA.php>`_, which boils down to
|
|
|
917 this:
|
|
|
918
|
|
|
919 * You can freely distribute LLVM.
|
|
|
920 * You must retain the copyright notice if you redistribute LLVM.
|
|
|
921 * Binaries derived from LLVM must reproduce the copyright notice (e.g. in an
|
|
|
922 included README file).
|
|
|
923 * You can't use our names to promote your LLVM derived products.
|
|
|
924 * There's no warranty on LLVM at all.
|
|
|
925
|
|
|
926 We believe this fosters the widest adoption of LLVM because it **allows
|
|
|
927 commercial products to be derived from LLVM** with few restrictions and without
|
|
|
928 a requirement for making any derived works also open source (i.e. LLVM's
|
|
|
929 license is not a "copyleft" license like the GPL). We suggest that you read the
|
|
|
930 `License <http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further
|
|
|
931 clarification is needed.
|
|
|
932
|
|
|
933 In addition to the UIUC license, the runtime library components of LLVM
|
|
|
934 (**compiler_rt, libc++, and libclc**) are also licensed under the `MIT License
|
|
|
935 <http://www.opensource.org/licenses/mit-license.php>`_, which does not contain
|
|
|
936 the binary redistribution clause. As a user of these runtime libraries, it
|
|
|
937 means that you can choose to use the code under either license (and thus don't
|
|
|
938 need the binary redistribution clause), and as a contributor to the code that
|
|
|
939 you agree that any contributions to these libraries be licensed under both
|
|
|
940 licenses. We feel that this is important for runtime libraries, because they
|
|
|
941 are implicitly linked into applications and therefore should not subject those
|
|
|
942 applications to the binary redistribution clause. This also means that it is ok
|
|
|
943 to move code from (e.g.) libc++ to the LLVM core without concern, but that code
|
|
|
944 cannot be moved from the LLVM core to libc++ without the copyright owner's
|
|
|
945 permission.
|
