From e1f54de9ac4f813f5d4a4217970f9b4013ab1108 Mon Sep 17 00:00:00 2001 From: Sebastiaan van Stijn Date: Wed, 22 May 2019 15:43:25 +0200 Subject: [PATCH 1/3] Add maintainers and authors Signed-off-by: Sebastiaan van Stijn --- .mailmap | 6 ++ AUTHORS | 7 ++ MAINTAINERS | 192 ++++++++++++++++++++++++++++++++++++++++++ Makefile | 5 +- hack/generate-authors | 21 +++++ 5 files changed, 230 insertions(+), 1 deletion(-) create mode 100644 .mailmap create mode 100644 AUTHORS create mode 100644 MAINTAINERS create mode 100755 hack/generate-authors diff --git a/.mailmap b/.mailmap new file mode 100644 index 00000000..e09bf4d7 --- /dev/null +++ b/.mailmap @@ -0,0 +1,6 @@ +# This file lists all individuals having contributed content to the repository. +# For how it is generated, see `hack/generate-authors`. + +Tibor Vass +Tibor Vass +Tõnis Tiigi diff --git a/AUTHORS b/AUTHORS new file mode 100644 index 00000000..224634d3 --- /dev/null +++ b/AUTHORS @@ -0,0 +1,7 @@ +# This file lists all individuals having contributed content to the repository. +# For how it is generated, see `scripts/generate-authors.sh`. + +Bin Du +Brian Goff +Tibor Vass +Tõnis Tiigi diff --git a/MAINTAINERS b/MAINTAINERS new file mode 100644 index 00000000..f0bc0154 --- /dev/null +++ b/MAINTAINERS @@ -0,0 +1,192 @@ +# Buildx maintainers file +# +# This file describes the maintainer groups within the project. +# More detail on Moby project governance is available in the +# https://github.com/moby/moby/blob/master/project/GOVERNANCE.md file. +# +# It is structured to be consumable by both humans and programs. +# To extract its contents programmatically, use any TOML-compliant +# parser. +# + +[Rules] + + [Rules.maintainers] + + title = "What is a maintainer?" + + text = """ +There are different types of maintainers, with different +responsibilities, but all maintainers have 3 things in common: + +1) They share responsibility in the project's success. +2) They have made a long-term, recurring time investment to improve + the project. +3) They spend that time doing whatever needs to be done, not + necessarily what is the most interesting or fun. + +Maintainers are often under-appreciated, because their work is harder +to appreciate. It's easy to appreciate a really cool and technically +advanced feature. It's harder to appreciate the absence of bugs, the +slow but steady improvement in stability, or the reliability of a +release process. But those things distinguish a good project from a +great one. +""" + + [Rules.adding-maintainers] + + title = "How are maintainers added?" + + text = """ +Maintainers are first and foremost contributors that have shown they +are committed to the long term success of a project. Contributors +wanting to become maintainers are expected to be deeply involved in +contributing code, pull request review, and triage of issues in the +project for more than three months. + +Just contributing does not make you a maintainer, it is about building +trust with the current maintainers of the project and being a person +that they can depend on and trust to make decisions in the best +interest of the project. + +Periodically, the existing maintainers curate a list of contributors +that have shown regular activity on the project over the prior +months. From this list, maintainer candidates are selected. + +After a candidate has been announced, the existing maintainers are +given five business days to discuss the candidate, raise objections +and cast their vote. Candidates must be approved by at least 66% of +the current maintainers by adding their vote on the slack +channel. Only maintainers of the repository that the candidate is +proposed for are allowed to vote. + +If a candidate is approved, a maintainer will contact the candidate to +invite the candidate to open a pull request that adds the contributor +to the MAINTAINERS file. The candidate becomes a maintainer once the +pull request is merged. +""" + + [Rules.stepping-down-policy] + + title = "Stepping down policy" + + text = """ +Life priorities, interests, and passions can change. If you're a +maintainer but feel you must remove yourself from the list, inform +other maintainers that you intend to step down, and if possible, help +find someone to pick up your work. At the very least, ensure your +work can be continued where you left off. + +After you've informed other maintainers, create a pull request to +remove yourself from the MAINTAINERS file. +""" + + [Rules.inactive-maintainers] + + title = "Removal of inactive maintainers" + + text = """ +Similar to the procedure for adding new maintainers, existing +maintainers can be removed from the list if they do not show +significant activity on the project. Periodically, the maintainers +review the list of maintainers and their activity over the last three +months. + +If a maintainer has shown insufficient activity over this period, a +neutral person will contact the maintainer to ask if they want to +continue being a maintainer. If the maintainer decides to step down as +a maintainer, they open a pull request to be removed from the +MAINTAINERS file. + +If the maintainer wants to remain a maintainer, but is unable to +perform the required duties they can be removed with a vote of at +least 66% of the current maintainers. The voting period is five +business days. Issues related to a maintainer's performance should be +discussed with them among the other maintainers so that they are not +surprised by a pull request removing them. +""" + + [Rules.DCO] + + title = "Helping contributors with the DCO" + + text = """ +The [DCO or `Sign your work`]( +https://github.com/moby/buildkit/blob/master/CONTRIBUTING.md#sign-your-work) +requirement is not intended as a roadblock or speed bump. + +Some BuildKit contributors are not as familiar with `git`, or have +used a web based editor, and thus asking them to `git commit --amend +-s` is not the best way forward. + +In this case, maintainers can update the commits based on clause (c) +of the DCO. The most trivial way for a contributor to allow the +maintainer to do this, is to add a DCO signature in a pull requests's +comment, or a maintainer can simply note that the change is +sufficiently trivial that it does not substantially change the +existing contribution - i.e., a spelling change. + +When you add someone's DCO, please also add your own to keep a log. +""" + + [Rules."no direct push"] + + title = "I'm a maintainer. Should I make pull requests too?" + + text = """ +Yes. Nobody should ever push to master directly. All changes should be +made through a pull request. +""" + + [Rules.meta] + + title = "How is this process changed?" + + text = "Just like everything else: by making a pull request :)" + + +[Org] + + [Org.Maintainers] + + people = [ + "tiborvass", + "tonistiigi", + ] + + [Org.Curators] + + # The curators help ensure that incoming issues and pull requests are properly triaged and + # that our various contribution and reviewing processes are respected. With their knowledge of + # the repository activity, they can also guide contributors to relevant material or + # discussions. + # + # They are neither code nor docs reviewers, so they are never expected to merge. They can + # however: + # - close an issue or pull request when it's an exact duplicate + # - close an issue or pull request when it's inappropriate or off-topic + + people = [ + "thajeztah", + ] + +[people] + +# A reference list of all people associated with the project. +# All other sections should refer to people by their canonical key +# in the people section. + + [people.thajeztah] + Name = "Sebastiaan van Stijn" + Email = "github@gone.nl" + GitHub = "thaJeztah" + + [people.tiborvass] + Name = "Tibor Vass" + Email = "tibor@docker.com" + GitHub = "tiborvass" + + [people.tonistiigi] + Name = "Tõnis Tiigi" + Email = "tonis@docker.com" + GitHub = "tonistiigi" diff --git a/Makefile b/Makefile index 464ba82a..2954179a 100644 --- a/Makefile +++ b/Makefile @@ -25,4 +25,7 @@ validate-all: lint test validate-vendor vendor: ./hack/update-vendor -.PHONY: vendor lint shell binaries install binaries-cross validate-all \ No newline at end of file +generate-authors: + ./hack/generate-authors + +.PHONY: vendor lint shell binaries install binaries-cross validate-all generate-authors diff --git a/hack/generate-authors b/hack/generate-authors new file mode 100755 index 00000000..c154d263 --- /dev/null +++ b/hack/generate-authors @@ -0,0 +1,21 @@ +#!/usr/bin/env bash + +set -eu -o pipefail -x + +if [ -x "$(command -v greadlink)" ]; then + # on macOS, GNU readlink is ava (greadlink) can be installed through brew install coreutils + cd "$(dirname "$(greadlink -f "$BASH_SOURCE")")/.." +else + cd "$(dirname "$(readlink -f "$BASH_SOURCE")")/.." +fi + +# see also ".mailmap" for how email addresses and names are deduplicated + +{ + cat <<-'EOH' + # This file lists all individuals having contributed content to the repository. + # For how it is generated, see `scripts/generate-authors.sh`. + EOH + echo + git log --format='%aN <%aE>' | LC_ALL=C.UTF-8 sort -uf +} > AUTHORS From 138b2e74159af69c28803003a406e71e2c77d1f7 Mon Sep 17 00:00:00 2001 From: Sebastiaan van Stijn Date: Wed, 22 May 2019 16:24:28 +0200 Subject: [PATCH 2/3] Add contributing, code of conduct Signed-off-by: Sebastiaan van Stijn --- .github/CODE_OF_CONDUCT.md | 4 + .github/CONTRIBUTING.md | 292 +++++++++++++++++++++++++++++++++++++ README.md | 19 +-- 3 files changed, 298 insertions(+), 17 deletions(-) create mode 100644 .github/CODE_OF_CONDUCT.md create mode 100644 .github/CONTRIBUTING.md diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md new file mode 100644 index 00000000..cab302dd --- /dev/null +++ b/.github/CODE_OF_CONDUCT.md @@ -0,0 +1,4 @@ +# Code of conduct + +- [Moby community guidelines](https://github.com/moby/moby/blob/master/CONTRIBUTING.md#moby-community-guidelines) +- [Docker Code of Conduct](https://github.com/docker/code-of-conduct) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md new file mode 100644 index 00000000..24461870 --- /dev/null +++ b/.github/CONTRIBUTING.md @@ -0,0 +1,292 @@ +# Contribute to the Buildx project + +This page contains information about reporting issues as well as some tips and +guidelines useful to experienced open source contributors. + +## Reporting security issues + +The project maintainers take security seriously. If you discover a security +issue, please bring it to their attention right away! + +**Please _DO NOT_ file a public issue**, instead send your report privately to +[security@docker.com](mailto:security@docker.com). + +Security reports are greatly appreciated and we will publicly thank you for it. +We also like to send gifts—if you're into schwag, make sure to let +us know. We currently do not offer a paid security bounty program, but are not +ruling it out in the future. + + +## Reporting other issues + +A great way to contribute to the project is to send a detailed report when you +encounter an issue. We always appreciate a well-written, thorough bug report, +and will thank you for it! + +Check that [our issue database](https://github.com/docker/buildx/issues) +doesn't already include that problem or suggestion before submitting an issue. +If you find a match, you can use the "subscribe" button to get notified on +updates. Do *not* leave random "+1" or "I have this too" comments, as they +only clutter the discussion, and don't help resolving it. However, if you +have ways to reproduce the issue or have additional information that may help +resolving the issue, please leave a comment. + +Include the steps required to reproduce the problem if possible and applicable. +This information will help us review and fix your issue faster. When sending +lengthy log-files, consider posting them as an attachment, instead of posting +inline. + +**Do not forget to remove sensitive data from your logfiles before submitting** + (you can replace those parts with "REDACTED"). + +### Pull requests are always welcome + +Not sure if that typo is worth a pull request? Found a bug and know how to fix +it? Do it! We will appreciate it. + +If your pull request is not accepted on the first try, don't be discouraged! If +there's a problem with the implementation, hopefully you received feedback on +what to improve. + +We're trying very hard to keep Buildx lean and focused. We don't want it to +do everything for everybody. This means that we might decide against +incorporating a new feature. However, there might be a way to implement that +feature *on top of* Buildx. + +### Design and cleanup proposals + +You can propose new designs for existing features. You can also design +entirely new features. We really appreciate contributors who want to refactor or +otherwise cleanup our project. + +### Sign your work + +The sign-off is a simple line at the end of the explanation for the patch. Your +signature certifies that you wrote the patch or otherwise have the right to pass +it on as an open-source patch. The rules are pretty simple: if you can certify +the below (from [developercertificate.org](http://developercertificate.org/)): + +``` +Developer Certificate of Origin +Version 1.1 + +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. +1 Letterman Drive +Suite D4700 +San Francisco, CA, 94129 + +Everyone is permitted to copy and distribute verbatim copies of this +license document, but changing it is not allowed. + +Developer's Certificate of Origin 1.1 + +By making a contribution to this project, I certify that: + +(a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + +(b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + +(c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + +(d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. +``` + +Then you just add a line to every git commit message: + + Signed-off-by: Joe Smith + +**Use your real name** (sorry, no pseudonyms or anonymous contributions.) + +If you set your `user.name` and `user.email` git configs, you can sign your +commit automatically with `git commit -s`. + +### Run the unit- and integration-tests + +To enter a demo container environment and experiment, you may run: + +``` +$ make shell +``` + +To validate PRs before submitting them you should run: + +``` +$ make validate-all +``` + +To generate new vendored files with go modules run: + +``` +$ make vendor +``` + + +### Conventions + +- Fork the repository and make changes on your fork in a feature branch +- Submit tests for your changes. See [run the unit- and integration-tests](#run-the-unit--and-integration-tests) + for details. +- [Sign your work](#sign-your-work) + +Write clean code. Universally formatted code promotes ease of writing, reading, +and maintenance. Always run `gofmt -s -w file.go` on each changed file before +committing your changes. Most editors have plug-ins that do this automatically. + +Pull request descriptions should be as clear as possible and include a +reference to all the issues that they address. Be sure that the [commit +messages](#commit-messages) also contain the relevant information. + +### Successful Changes + +Before contributing large or high impact changes, make the effort to coordinate +with the maintainers of the project before submitting a pull request. This +prevents you from doing extra work that may or may not be merged. + +Large PRs that are just submitted without any prior communication are unlikely +to be successful. + +While pull requests are the methodology for submitting changes to code, changes +are much more likely to be accepted if they are accompanied by additional +engineering work. While we don't define this explicitly, most of these goals +are accomplished through communication of the design goals and subsequent +solutions. Often times, it helps to first state the problem before presenting +solutions. + +Typically, the best methods of accomplishing this are to submit an issue, +stating the problem. This issue can include a problem statement and a +checklist with requirements. If solutions are proposed, alternatives should be +listed and eliminated. Even if the criteria for elimination of a solution is +frivolous, say so. + +Larger changes typically work best with design documents. These are focused on +providing context to the design at the time the feature was conceived and can +inform future documentation contributions. + +### Commit Messages + +Commit messages must start with a capitalized and short summary (max. 50 chars) +written in the imperative, followed by an optional, more detailed explanatory +text which is separated from the summary by an empty line. + +Commit messages should follow best practices, including explaining the context +of the problem and how it was solved, including in caveats or follow up changes +required. They should tell the story of the change and provide readers +understanding of what led to it. + +If you're lost about what this even means, please see [How to Write a Git +Commit Message](http://chris.beams.io/posts/git-commit/) for a start. + +In practice, the best approach to maintaining a nice commit message is to +leverage a `git add -p` and `git commit --amend` to formulate a solid +changeset. This allows one to piece together a change, as information becomes +available. + +If you squash a series of commits, don't just submit that. Re-write the commit +message, as if the series of commits was a single stroke of brilliance. + +That said, there is no requirement to have a single commit for a PR, as long as +each commit tells the story. For example, if there is a feature that requires a +package, it might make sense to have the package in a separate commit then have +a subsequent commit that uses it. + +Remember, you're telling part of the story with the commit message. Don't make +your chapter weird. + +### Review + +Code review comments may be added to your pull request. Discuss, then make the +suggested modifications and push additional commits to your feature branch. Post +a comment after pushing. New commits show up in the pull request automatically, +but the reviewers are notified only when you comment. + +Pull requests must be cleanly rebased on top of master without multiple branches +mixed into the PR. + +> **Git tip**: If your PR no longer merges cleanly, use `rebase master` in your +> feature branch to update your pull request rather than `merge master`. + +Before you make a pull request, squash your commits into logical units of work +using `git rebase -i` and `git push -f`. A logical unit of work is a consistent +set of patches that should be reviewed together: for example, upgrading the +version of a vendored dependency and taking advantage of its now available new +feature constitute two separate units of work. Implementing a new function and +calling it in another file constitute a single logical unit of work. The very +high majority of submissions should have a single commit, so if in doubt: squash +down to one. + +- After every commit, [make sure the test suite passes](#run-the-unit--and-integration-tests). + Include documentation changes in the same pull request so that a revert would + remove all traces of the feature or fix. +- Include an issue reference like `closes #XXXX` or `fixes #XXXX` in the PR + description that close an issue. Including references automatically closes + the issue on a merge. +- Do not add yourself to the `AUTHORS` file, as it is regenerated regularly + from the Git history. +- See the [Coding Style](#coding-style) for further guidelines. + + +### Merge approval + +Project maintainers use LGTM (Looks Good To Me) in comments on the code review to +indicate acceptance, or use the Github review approval feature. + + +## Coding Style + +Unless explicitly stated, we follow all coding guidelines from the Go +community. While some of these standards may seem arbitrary, they somehow seem +to result in a solid, consistent codebase. + +It is possible that the code base does not currently comply with these +guidelines. We are not looking for a massive PR that fixes this, since that +goes against the spirit of the guidelines. All new contributions should make a +best effort to clean up and make the code base better than they left it. +Obviously, apply your best judgement. Remember, the goal here is to make the +code base easier for humans to navigate and understand. Always keep that in +mind when nudging others to comply. + +The rules: + +1. All code should be formatted with `gofmt -s`. +2. All code should pass the default levels of + [`golint`](https://github.com/golang/lint). +3. All code should follow the guidelines covered in [Effective + Go](http://golang.org/doc/effective_go.html) and [Go Code Review + Comments](https://github.com/golang/go/wiki/CodeReviewComments). +4. Comment the code. Tell us the why, the history and the context. +5. Document _all_ declarations and methods, even private ones. Declare + expectations, caveats and anything else that may be important. If a type + gets exported, having the comments already there will ensure it's ready. +6. Variable name length should be proportional to its context and no longer. + `noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo`. + In practice, short methods will have short variable names and globals will + have longer names. +7. No underscores in package names. If you need a compound name, step back, + and re-examine why you need a compound name. If you still think you need a + compound name, lose the underscore. +8. No utils or helpers packages. If a function is not general enough to + warrant its own package, it has not been written generally enough to be a + part of a util package. Just leave it unexported and well-documented. +9. All tests should run with `go test` and outside tooling should not be + required. No, we don't need another unit testing framework. Assertion + packages are acceptable if they provide _real_ incremental value. +10. Even though we call these "rules" above, they are actually just + guidelines. Since you've read all the rules, you now know that. + +If you are having trouble getting into the mood of idiomatic Go, we recommend +reading through [Effective Go](https://golang.org/doc/effective_go.html). The +[Go Blog](https://blog.golang.org) is also a great resource. \ No newline at end of file diff --git a/README.md b/README.md index 5449973d..57e31498 100644 --- a/README.md +++ b/README.md @@ -639,20 +639,5 @@ To remove this alias, you can run `docker buildx uninstall`. # Contributing -To enter a demo container environment and experiment, you may run: - -``` -$ make shell -``` - -To validate PRs before submitting them you should run: - -``` -$ make validate-all -``` - -To generate new vendored files with go modules run: - -``` -$ make vendor -``` +Want to contribute to Buildx? Awesome! You can find information about +contributing to this project in the [CONTRIBUTING.md](/.github/CONTRIBUTING.md) From 854f704a2fefbbd240779084575c6267f16c3600 Mon Sep 17 00:00:00 2001 From: Sebastiaan van Stijn Date: Wed, 22 May 2019 16:25:02 +0200 Subject: [PATCH 3/3] Add LICENSE file Signed-off-by: Sebastiaan van Stijn Signed-off-by: Tibor Vass --- LICENSE | 202 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 202 insertions(+) create mode 100644 LICENSE diff --git a/LICENSE b/LICENSE new file mode 100644 index 00000000..d6456956 --- /dev/null +++ b/LICENSE @@ -0,0 +1,202 @@ + + Apache License + Version 2.0, January 2004 + http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the Work, but + excluding communication that is conspicuously marked or otherwise + designated in writing by the copyright owner as "Not a Contribution." + + "Contributor" shall mean Licensor and any individual or Legal Entity + on behalf of whom a Contribution has been received by Licensor and + subsequently incorporated within the Work. + + 2. Grant of Copyright License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + copyright license to reproduce, prepare Derivative Works of, + publicly display, publicly perform, sublicense, and distribute the + Work and such Derivative Works in Source or Object form. + + 3. Grant of Patent License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + (except as stated in this section) patent license to make, have made, + use, offer to sell, sell, import, and otherwise transfer the Work, + where such license applies only to those patent claims licensable + by such Contributor that are necessarily infringed by their + Contribution(s) alone or by combination of their Contribution(s) + with the Work to which such Contribution(s) was submitted. If You + institute patent litigation against any entity (including a + cross-claim or counterclaim in a lawsuit) alleging that the Work + or a Contribution incorporated within the Work constitutes direct + or contributory patent infringement, then any patent licenses + granted to You under this License for that Work shall terminate + as of the date such litigation is filed. + + 4. Redistribution. You may reproduce and distribute copies of the + Work or Derivative Works thereof in any medium, with or without + modifications, and in Source or Object form, provided that You + meet the following conditions: + + (a) You must give any other recipients of the Work or + Derivative Works a copy of this License; and + + (b) You must cause any modified files to carry prominent notices + stating that You changed the files; and + + (c) You must retain, in the Source form of any Derivative Works + that You distribute, all copyright, patent, trademark, and + attribution notices from the Source form of the Work, + excluding those notices that do not pertain to any part of + the Derivative Works; and + + (d) If the Work includes a "NOTICE" text file as part of its + distribution, then any Derivative Works that You distribute must + include a readable copy of the attribution notices contained + within such NOTICE file, excluding those notices that do not + pertain to any part of the Derivative Works, in at least one + of the following places: within a NOTICE text file distributed + as part of the Derivative Works; within the Source form or + documentation, if provided along with the Derivative Works; or, + within a display generated by the Derivative Works, if and + wherever such third-party notices normally appear. The contents + of the NOTICE file are for informational purposes only and + do not modify the License. You may add Your own attribution + notices within Derivative Works that You distribute, alongside + or as an addendum to the NOTICE text from the Work, provided + that such additional attribution notices cannot be construed + as modifying the License. + + You may add Your own copyright statement to Your modifications and + may provide additional or different license terms and conditions + for use, reproduction, or distribution of Your modifications, or + for any such Derivative Works as a whole, provided Your use, + reproduction, and distribution of the Work otherwise complies with + the conditions stated in this License. + + 5. Submission of Contributions. Unless You explicitly state otherwise, + any Contribution intentionally submitted for inclusion in the Work + by You to the Licensor shall be under the terms and conditions of + this License, without any additional terms or conditions. + Notwithstanding the above, nothing herein shall supersede or modify + the terms of any separate license agreement you may have executed + with Licensor regarding such Contributions. + + 6. Trademarks. This License does not grant permission to use the trade + names, trademarks, service marks, or product names of the Licensor, + except as required for reasonable and customary use in describing the + origin of the Work and reproducing the content of the NOTICE file. + + 7. Disclaimer of Warranty. Unless required by applicable law or + agreed to in writing, Licensor provides the Work (and each + Contributor provides its Contributions) on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + implied, including, without limitation, any warranties or conditions + of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A + PARTICULAR PURPOSE. You are solely responsible for determining the + appropriateness of using or redistributing the Work and assume any + risks associated with Your exercise of permissions under this License. + + 8. Limitation of Liability. In no event and under no legal theory, + whether in tort (including negligence), contract, or otherwise, + unless required by applicable law (such as deliberate and grossly + negligent acts) or agreed to in writing, shall any Contributor be + liable to You for damages, including any direct, indirect, special, + incidental, or consequential damages of any character arising as a + result of this License or out of the use or inability to use the + Work (including but not limited to damages for loss of goodwill, + work stoppage, computer failure or malfunction, or any and all + other commercial damages or losses), even if such Contributor + has been advised of the possibility of such damages. + + 9. Accepting Warranty or Additional Liability. While redistributing + the Work or Derivative Works thereof, You may choose to offer, + and charge a fee for, acceptance of support, warranty, indemnity, + or other liability obligations and/or rights consistent with this + License. However, in accepting such obligations, You may act only + on Your own behalf and on Your sole responsibility, not on behalf + of any other Contributor, and only if You agree to indemnify, + defend, and hold each Contributor harmless for any liability + incurred by, or claims asserted against, such Contributor by reason + of your accepting any such warranty or additional liability. + + END OF TERMS AND CONDITIONS + + APPENDIX: How to apply the Apache License to your work. + + To apply the Apache License to your work, attach the following + boilerplate notice, with the fields enclosed by brackets "[]" + replaced with your own identifying information. (Don't include + the brackets!) The text should be enclosed in the appropriate + comment syntax for the file format. We also recommend that a + file or class name and description of purpose be included on the + same "printed page" as the copyright notice for easier + identification within third-party archives. + + Copyright [yyyy] [name of copyright owner] + + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License.