├── MAINTAINERS ├── .catwatch.yaml ├── pull_request_template.md ├── READMEtemplate.md ├── producttemplate.md ├── innersource.md ├── README.md └── LICENSE /MAINTAINERS: -------------------------------------------------------------------------------- 1 | Lauri Apple 2 | -------------------------------------------------------------------------------- /.catwatch.yaml: -------------------------------------------------------------------------------- 1 | # this file will be read by Catwatch 2 | # see https://github.com/zalando/catwatch/issues/32 3 | title: How to Open Source at Zalando 4 | -------------------------------------------------------------------------------- /pull_request_template.md: -------------------------------------------------------------------------------- 1 | ## Pull Request Template 2 | 3 | Please use this to create a roadmap for your project or to track bugs. A pull request template improves development quality and provides a common guideline for contributors to follow. It also enables to you to reference issues and shows others your development progress. 4 | 5 | 6 | 7 | ### Description 8 | 9 | 10 | ### Related Issue 11 | 12 | 13 | 14 | 15 | 16 | 17 | ### Motivation and Context 18 | 19 | 20 | ### How Has This Been Tested? 21 | 22 | 23 | 24 | 25 | 26 | ### Screenshots (if appropriate): 27 | 28 | ### Types of changes 29 | 30 | - [ ] Bug fix (non-breaking change which fixes an issue) 31 | - [ ] New feature (non-breaking change which adds functionality) 32 | - [ ] Breaking change (fix or feature that would cause existing functionality to change) 33 | 34 | ### Checklist: 35 | 36 | 37 | - [ ] My code follows the code style of this project. 38 | - [ ] My change requires a change to the documentation. 39 | - [ ] I have updated the documentation accordingly. 40 | - [ ] I have read the **CONTRIBUTING** document. 41 | - [ ] I have added tests to cover my changes. 42 | - [ ] All new and existing tests passed. 43 | 44 | -------------------------------------------------------------------------------- /READMEtemplate.md: -------------------------------------------------------------------------------- 1 | ## Zalando's README Template 2 | 3 | Clear documentation is critical to the success of your project. This checklist is meant to help you cover all your bases. Not every section/subsection will be relevant to your project; pick and choose what is. Inspired by READMEs of very successful projects like etcd. 4 | 5 | Please copy-paste this into a new document and save as you build your READMEs. For alternative formats, you might create a [Structured README](https://github.com/shaloo/structuredreadme), which offers a thorough breakdown of optional README ingredients for you to consider. You might also take a look at [this similar checklist](https://github.com/cfpb/open-source-project-template); or check out [art-of-readme](https://github.com/noffle/art-of-readme). 6 | 7 | ### Project Name/Intro 8 | 9 | - Describe very briefly but clearly what the project does. 10 | - State if it is out-of-the-box user-friendly, so it’s clear to the user. 11 | - List its most useful/innovative/noteworthy features. 12 | - State its goals/what problem(s) it solves. 13 | - Note and briefly describe any key concepts (technical, philosophical, or both) important to the user’s understanding. 14 | - Link to any supplementary blog posts or project main pages. 15 | - Note its development status. 16 | - Include badges. 17 | - If possible, include screenshots and demo videos. 18 | 19 | ### Core Technical Concepts/Inspiration 20 | 21 | - Why does it exist? 22 | - Frame your project for the potential user. 23 | - Compare/contrast your project with other, similar projects so the user knows how it is different from those projects. 24 | - Highlight the technical concepts that your project demonstrates or supports. Keep it very brief. 25 | - Keep it useful. 26 | 27 | ### Getting Started/Requirements/Prerequisites/Dependencies 28 | Include any essential instructions for: 29 | - Getting it 30 | - Installing It 31 | - Configuring It 32 | - Running it 33 | 34 | ### More Specific Topics (+ sample sub-categories) 35 | - Versioning: Services, APIs, Systems 36 | - Common Error Messages/related details 37 | - Tests 38 | - Is it a Swift project? Please take a look at Mattt Thompson & Nate Cook's [Swift documentation](http://nshipster.com/swift-documentation/) guide 39 | 40 | ### Contributing 41 | - Contributor Guidelines 42 | - Code Style/Requirements 43 | - Format for commit messages 44 | - Thank you (name contributors) 45 | 46 | ### TODO 47 | - Next steps 48 | - Features planned 49 | - Known bugs (shortlist) 50 | 51 | ### Contact 52 | - Email address 53 | - Google Group/mailing list (if applicable) 54 | - IRC or Slack (if applicable) 55 | 56 | ### License 57 | -------------------------------------------------------------------------------- /producttemplate.md: -------------------------------------------------------------------------------- 1 | ## Building a Useful, User-Friendly Project 2 | 3 | So, you want to build a new open-source project. Great! Use this template (derived from [this](http://www.uxapprentice.com/resources/stakeholder-interview-template/)) to ensure that the project you build is as great as possible from a purpose, innovation, maintenance, and usability perspective. 4 | 5 | Also recommended: check out [Mozilla's Open Canvas](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/develop-an-open-project-strategy-with-open-canvas/), which presents a very similar approach in a nifty canvas format; and [this Design Doc Template](https://docs.google.com/document/d/1uMHzRsEDZb_p9xfFGerCVhr-0mAi-d-OFY4jJi0dYk4/edit) from Google. 6 | 7 | #### 1. PROJECT VISION 8 | - What is your vision for this project? 9 | - What defines “success” for this project? 10 | - What are the potential pitfalls (i.e. what keeps you up at night about this project)? 11 | - Do you actually need the open-source community to help you with this project? 12 | - Do you need more: 13 | - devs helping you to build features/functionality? 14 | - code review? 15 | - doc help? 16 | - product users? 17 | - What does your project MVP (minimum viable product) look like? 18 | 19 | #### 2. VALUE PROPOSITION 20 | 21 | - What problems are you solving for potential users? 22 | - What are the main “why you should use this” message points? 23 | - What are the most innovative features? 24 | 25 | #### 3. USERS: OVERVIEW 26 | Use your own experience on this one to get started, then find more internally. Then go externally as you build the product vision. 27 | - Who are the different types of users? Could be: 28 | - Zalando users (examples): other teams, other departments within tech, other departments outside of tech, etc. 29 | - non-Zalando users (examples): startups, small companies, big companies, OAuth2 users, devs using a specific language/library/framework/etc., “site reliability engineers,” “front-end engineers working in a microservices environment,” etc. 30 | - Who are the primary target users? 31 | - Background? 32 | - Defining Attributes? 33 | - Use cases/recipes? 34 | 35 | #### 3a. USER RESEARCH 36 | We strongly recommend that you conduct preliminary interviews with potential stakeholders and users to ensure that your project vision aligns with their needs. 37 | 38 | User research helps you to avoid duplication/building something in a silo; technical debt, and poor craftsmanship; and to gain efficiency, maximum usability/adoption/maintenance, and excellent craftsmanship. We have these resources available internally and are working with product to make them available ASAP. 39 | 40 | #### 3b. USABILITY PROCESS & WORKFLOW 41 | - What is the current relationship between you/your project team and your potential users of your project? 42 | - How will you engage with your project’s potential users to tell them about the project and keep them informed of updates/new features/etc? 43 | - Examples: LinkedIn groups, direct contact with likely users (in personal networks), social media, meetups, conferences 44 | - What steps will you/your team take to increase engagement and build community? 45 | - Do you have a six-month maintenance plan for the project? Such a plan would address: 46 | - Your/your team's definition of what "maintainer" means, and what a maintainer is accountable for (role definition). 47 | - Total number of project maintainers, and assurance that they can/will fulfill the role. 48 | - The expected response time for PRs and issues. Within 48-72 hours is advisable; any longer, and we request that you note in your README that longer response times should be expected. 49 | - Reviewing PRs from outside your own team, and related processes. 50 | - Asking for PRs from outside your own team. 51 | - Labelling issues "Help Wanted" to drive contributions, and how you will achieve this. 52 | - How you will handle rejecting PRs you don’t want to use. 53 | 54 | #### 4. COMPETITOR ANALYSIS 55 | - What similar tools are in use today internally? 56 | - What similar tools are already developed and open-source? 57 | - What are their relative strengths/weaknesses? 58 | - How is this offering different? 59 | 60 | Provide some evidence, such as online research results you conducted prior to developing the project, or survey feedback generated about your idea. Show that your work is unique and does not imitate an existing, actively maintained project. (Remaking someone else’s deprecated project is acceptable, as you are demonstrating that your project fulfills a once-served need.) Usually a one-paragraph summary/list of 3-4 bullet points defining your project’s innovative features and distinct advantages is sufficient. 61 | 62 | #### 5. KPI ANALYSIS AND SUCCESS INDICATORS 63 | How will you be define and measure success in terms of gaining and keeping users? 64 | 65 | #### 6. FUTURE FEATURES 66 | - What are bad results for the user? (If an experience doesn’t go well, what happens?) 67 | - How will you communicate with and involve your users long-term to ensure you’re still serving their needs with this project? 68 | - What else do you think your users would want this project to do? 69 | -------------------------------------------------------------------------------- /innersource.md: -------------------------------------------------------------------------------- 1 | ## How to InnerSource 2 | 3 | ### Preparing Your Repos for InnerSource 4 | Many teams at Zalando have applied the InnerSource collaboration model to deliver more effectively and get work done. To try InnerSource with your own team's repos, here's what you need: 5 | 6 | - **A good README**. What does your project do? What need does it address? Who inside Zalando would use it? How do you install it? Here’s [our README template](https://github.com/zalando/zalando-howto-open-source/blob/master/READMEtemplate.md) to help you. 7 | - **Contribution Guidelines**. How do you want potential contributors to approach developing a change or enhancement for your project? An initial email? An empty pull request with a detailed proposal? [Here's a good set](https://github.com/zalando/skipper/blob/master/CONTRIBUTING.md) to help you get started. 8 | - **A “Help Wanted” list**. Is it easy for other teams to spot the features, bugs, etc. you want help with? Issues Trackers are good, and tagging them with “help wanted” is even better. We have a Grafana dashboard collecting all our "help wanted" issues in one place [internal link, please ask us for it]. 9 | - Compiling all your needs across all your InnerSourced repos in one email and blasting it out to our innersource Google group from time to time (or posting to zLive) is really great, too. 10 | - **Github Enterprise**. Have you migrated from Stash yet? It helps if our code is all in the same system. 11 | - **[Zappr](https://github.com/integrations/zappr)** up and running. 12 | - **Adequate Test Coverage**. If you’re letting people contribute to your code base, you want to be reasonably confident that they (or you) don’t break the world when everything is integrated. Ping us here for help. 13 | - **Continuous Integration**. Sure, you can run your test suite manually, but contributors will feel more confident in their changes if there’s a constant feedback loop. 14 | 15 | ### FAQ on InnerSourcing Your Team's Repos 16 | 17 | ##### What if our team doesn't have time to review all the incoming PRs? 18 | That's up to your team to resolve. But keep this in mind: What's faster, coding everything yourselves, or reviewing someone else's code? Approaching these efforts collaboratively — communicating your goals, wishes, risks, etc. to the team that's looking to contribute — can also save you lots of time. Talking things out over 30-60 minutes only takes 30-60 minutes. 19 | 20 | ##### But writing code is more fun than reviewing someone else's code. 21 | Maybe so. So write some code! Contribute a PR back to the team that contributed to your repo, or to a different team. Take a look at [our open-source offerings](https://zalando.github.io/) and code something for one of those projects. 22 | 23 | ##### Hey, it takes time to get people up to speed with the codebase and go through a couple of PR iterations to get something done. What if we don't have time right now to handle that? 24 | Check again and make sure that it will truly take longer to teach someone about your codebase than to do the work yourself. Also, don't project or make assumptions about your potential, still-imaginary contributor: For all you know, they might be able to dive right in and get the job done quickly. They might even be able to teach you some things. This dynamic plays out in the open source world all the time. 25 | 26 | ##### What if we allow a team to go forward with a PR, and the end result is not to our liking? 27 | Try to work with the contributing team to achieve something you can all accept. Remember, part of this is on you communicating with the contributing team what you're hoping they'll produce. Check in with them to get progress updates. Give them guidance, if needed. This will save you time, and save everyone involved disappointment. 28 | 29 | ##### What if someone surprises us with a PR we didn't ask for and don't want? 30 | Then don't accept it. We want people to reach out to an owning team before making any bug fix or (especially) more significant change to a repo. If, for example, a team doesn't do that, and tries to fix one of your bugs/build one of your requested features without talking to you, then you have the right to reject their work. That team will most likely learn from the experience and be sure to talk about their proposed changes before setting to work. 31 | 32 | #### Changing Another Team's Repos 33 | If your team needs something from another team's repo, InnerSource could help. A FAQ based on questions many a Zalando engineer has raised about how this works. 34 | 35 | ##### How do I know if a team will accept my proposed PR? 36 | Simple: Ask that team. We recommend reaching out to their producer or pinging them over HipChat as a first step. Don't do anything until you hear back from them. If they don't answer the first time, try them again. 37 | 38 | ##### If my team/I change another team's repo, who ends up owning the repo? 39 | The original team. 40 | 41 | ### More info 42 | There's a growing number of useful resources on InnerSource. Here are a few: 43 | - O'Reilly/PayPal's [Getting Started With InnerSource](https://www.oreilly.com/ideas/getting-started-with-innersource) booklet 44 | - [Adopting Open Source Development Practices in Organizations: A Tutorial](http://ieeexplore.ieee.org/document/6809709/) by the IEEE (requires sign-in) 45 | - [InnerSource Commons](https://paypal.github.io/InnerSourceCommons/) website 46 | - [Inner Source in Platform-Based Product 47 | Engineering](http://www.develop-group.de/fileadmin/dg_Internet/downloads/Fachveroeffentlichungen/Fachveroeffentlichungen_Projekt/devgroup_InnerSource_in_Platform-BasedProductEngineering.pdf) by Drs. Dirk Riehle, Maximilian Capraro, Detlef Kips, Lars Horn 48 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # OPEN SOURCE RULES AND STRATEGY 2 | 3 | **Deprecated document:** this document has been replaced by the documentation on [opensource.zalando.com](https://opensource.zalando.com/docs/releasing/index/) and will not receive further updates - source files for the docs are available in the public [openssource.zalando.com github repository](https://github.com/zalando/zalando.github.io/tree/master/_docs) 4 | 5 | ---- 6 | 7 | If you are an Zalando employee please use the [internal version](https://confluence.zalando.net/display/TG/OPEN+SOURCE) because in this public version internal links and contact persons are excluded. 8 | 9 | 1. [Purpose](#purpose) 10 | 2. [Contact](#contact) 11 | 3. [Project Publication Process](#Process) 12 | 4. [Rules](#rules) 13 | 5. [Appendix 1: Philosophy/principles](#A1) 14 | 6. [Appendix 2: Potential risks to Zalando’s competitive advantage](#A2) 15 | 7. [Appendix 3: How Zalando organizes open source](#A3) 16 | 8. [Appendix 4: Zalando’s public GitHub organizations](#A4) 17 | 10. [Appendix 5: How to deprecate a project](#A5) 18 | 1. [Appendix 6: MIT license](#A6) 19 | 1. [Appendix 7: How to honor non-Zalando third-party OSS components](#A7) 20 | 1. [Appendix 8: Why you must create a new repo](#A8) 21 | 22 | 23 | ### Purpose 24 | These open source rules aim to make your OSS efforts more sustainable and successful by reinforcing development habits that improve our software, coding literacy, and craftsmanship. The rules offer guidance and clarify expectations regarding project quality, security, compliance, and usefulness beyond Zalando (see also our OS philosophy/principles in [Appendix 1](#A1)). They also aim to protect Zalando’s competitive advantage (see [Appendix 2](#A2)). 25 | 26 | ### Contact 27 | Please contact Zalando’s Open Source Review Group for open source-related questions and suggestions. For more details on how Zalando organizes open source, see [Appendix 3](#A3). 28 | 29 | ### Project Publication Process 30 | To publish your project on GitHub.com, please follow these steps: 31 | 1. Read all of these rules and make sure your project complies with them. 32 | 2. Email the Review Group about your project with the following information: 33 | + Project name and link: 34 | + Do you plan to promote your project internally and externally, to build a community of users and contributors? 35 | + Does this project have any internal Zalando dependencies? (If "Yes," stop here.) 36 | + Who is your target audience? 37 | + How many hours per week will you devote to maintaining and growing the project? 38 | + What does this project solve for potential users, and how is it different (better, faster, simpler) than existing solutions? 39 | + Did you requested internal feedback? 40 | 3. The Review Group will review your project and offer feedback and guidance to support your publication bid. 41 | 4. The Review Group might ask you to present your project, but in most cases will request information over email/HipChat. 42 | 5. For your project to go live, you must receive the following approvals from the Review Group: security, code quality, documentation, and agreement that the project does not risk our competitive advantage. 43 | 6. Upon receiving the Review Group’s approval, you can push your project to the [incubator](https://github.com/zalando-incubator) where it can remain for up to six months. During this time, we expect you to take actions to grow your project. Find more information about Zalando’s public github organizations in [Appendix 4](#A4). 44 | 7. If your project grows and evolves, you may ask the Review Group to push your project to [Zalando’s main Open Source organization](https://github.com/zalando). To initiate this process, please contact the Review Group. 45 | 46 | 47 | ### Rules 48 | All open source projects published since 2015 MUST comply to rules 1-9. Non-compliant projects must be deleted from github.com; see [Appendix 5](#A5) for how to deprecate a project. To publish a new project, you MUST also follow rules 10. (If you are an Zalando employee please use the [internal version](https://confluence.zalando.net/display/TG/OPEN+SOURCE) because in this public version internal links and contact persons are excluded. ) 49 | 1. All projects MUST include an Maintainers.md/rst file listing at least two active maintainers by name and contact email. 50 | 2. You MUST create a meaningful README that includes the items requested in Question #11 our application form. 51 | 3. You MUST include a [CONTRIBUTING.md/rst guidelines file](https://github.com/nayafia/contributing-template). 52 | 4. You MUST create a license file and state that the MIT license applies to all code owned by Zalando. (Please use the license text in [Appendix 6](#A6)). If you use third-party OSS, you MUST only use license-compatible projects/software. You MUST honor the original licenses used in those third-party projects in the license file (see [example](https://github.com/zalando-incubator/zally/blob/master/LICENSE)). For more information and guidance, see [Appendix 7](#A7). Projects published before June 1, 2017 may keep their original license (e.g. Apache 2.0). Contact Legal for personal support on licensing. 53 | 5. You SHOULD semantically version project artifacts. You MUST tag all versions in GitHub with the exact version name: e.g., 0.1.0. 54 | 6. You SHOULD sign every commit. 55 | 7. You MUST create a SECURITY. md file in the main root folder of your repository. This text is sufficient for the file: “If you have discovered a security vulnerability, please email tech-security@zalando.de.” 56 | 8. Your repositories MUST NOT, at any time, include Zalando specifics such as credentials and private identifiers. 57 | 9. You SHOULD review all merge requests for implanted security backdoors and vulnerable code fragments regardless of who is making the pull request. [User impersonation](http://www.jayhuang.org/blog/pushing-code-to-github-as-linus-torvalds/) is easy. 58 | 59 | In addition to the above rules, the following also govern new open source projects you wish to publish on a Zalando-owned GitHub organization. 60 | 61 | 10. You MUST create an entirely new Git repository before pushing the project to GitHub. More info in [Appendix 8](#A8). 62 | 63 | 64 | ### Appendix 1: Philosophy / Principles 65 | OSS development is integral to our engineering practices and culture for these reasons: 66 | + Facilitates skills acquisition (coding, communication, project management, product mindset) that benefits internal and personal development 67 | + Engages highly skilled external contributors who improve our software quality and relevance 68 | + Brings about knowledge exchange and innovation through collaborative partnerships with other companies 69 | + Sends a positive “giving back” massage to a community upon which we rely 70 | + Implicitly shows developers why working for Zalando will be an enriching and challenging experience, and therefore serves as a highly authentic “employer branding” asset 71 | 72 | ### Appendix 2: Potential Risks to Zalando’s Competitive Advantage 73 | Anything that risks Zalando’s competitive advantage is not permissible for publication on GitHub.com. This typically means technologies we build that are intrinsic to generating or reinforcing the uniqueness of our customer experience. This could include (but is not limited to): 74 | + confidential source code 75 | + recommendation algorithms 76 | + search functionalities that give us an edge over competitors 77 | We advise you to take a conservative approach and reach out to our Legal team for any ambiguous cases. 78 | 79 | ### Appendix 3: How Zalando organizes open source 80 | There are two relevant organizations at Zalando: the OSS Review Group and the Open Source Guild. An OS Team is planned but does not exist yet. 81 | 82 | OSS Review Group 83 | + Purpose 84 | + Guide Zalando technologists to create high-quality projects that meet our standards. 85 | + Offer peer review and feedback. 86 | + Develop policies and processes that reinforce open source development based on quality, end-to-end ownership, broad usefulness to non-Zalandos, and innovation as key values. 87 | + Responsibility: 88 | + Meet every two week to approve/reject projects awaiting public release 89 | + Update and manage the OSS Priority Project List (quarterly) 90 | + Help Incubator projects graduate to /zalando, the main Zalando organization 91 | + Manage all Zalando GitHub organizations. The group has the right to remove non-compliant projects from GitHub. (To deprecate a project, see [Appendix 5](#A5).) 92 | + Membership: 93 | + VP(s) Engineering 94 | + Open Source Evangelist (RG leader) 95 | + 3-5 engineers, delivery leads, and (at least one) dedicated owners 96 | + Tech Security 97 | + IT-Compliance 98 | + Legal 99 | + Membership Process: Please mail the OSS Review Group if you would like to become a member. 100 | 101 | Open Source Guild 102 | Founded in spring 2015, the Guild exists for Zalando technologists to discuss OSS topics and development. Members maintain a lively Google Group that all Zalandos are encouraged to use for these purposes: 103 | + Announcing new projects and asking for feedback 104 | + Requesting/offering project demos 105 | + Knowledge exchange: sharing articles, talks, videos, etc. 106 | + Generating discussions 107 | 108 | Once formed, the OSS Team will offer guidance to structure the Guild into working groups on mentoring, quality, external community building, and documentation. 109 | 110 | ### Appendix 4: Zalando’s Public GitHub organizations 111 | + [zalando](https://github.com/zalando): Where we showcase our strongest projects 112 | + [zalando-incubator](github.com/zalando-incubator): Where we incubate new projects, giving them six months to grow audiences and develop. 113 | + [zalando-stups](https://github.com/zalando-stups): Setup/purpose in review. 114 | + [zalando-nakadi](https://github.com/zalando-nakadi): For all repos related to the Nakadi project. Setup/purpose in review. 115 | + [zalando-zmon](https://github.com/zalando-zmon): For all repos related to the ZMON project. Setup/purpose in review. 116 | + [zalandoresearch](https://github.com/zalandoresearch): For all repos and code samples generated by Zalando Research. Setup/purpose in review. 117 | 118 | 119 | ### Appendix 5: How to deprecate a project 120 | Please follow this process to remove a project from GitHub.com: 121 | 1. File a JIRA ticket for your repository deletion process. 122 | 2. Archive a version of your repository in your GHE org of choice and follow these steps: 123 | + You MUST ensure that commit ID’s in the new GHE repo are exactly the same as in the old GitHub repo 124 | + You MUST register the application in YourTurn/Kio, unless the repo is a library, document, or locally used tool 125 | + You MUst ensure the SCM URL in YourTurn/Kio is entered correctly (for GHE) 126 | 3. Wait for IT-Compliance to approve the request. 127 | 4. If your OS project is public on maven, pip, or npm or similar public repositories, please contact Review Group for further instructions. 128 | 129 | 130 | ### Appendix 6: MIT License 131 | Replace the [yyyy] field with the year that you created the project, and do not update it. Do not provide multiple years. 132 | 133 | The MIT License (MIT) Copyright © [yyyy] Zalando SE, https://tech.zalando.com 134 | 135 | Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: 136 | 137 | The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. 138 | 139 | THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 140 | 141 | 142 | ### Appendix 7: How to honor non-Zalando/third-party OSS components 143 | Copyleft: Copyleft is a legal obligation that Zalando must fulfill when you modify and/or distribute and/or make third party material publicly available (so-called “copyleft trigger”). 144 | 145 | Examples: changing the program code, uploading to public GitHub, sending it to someone else from another company. Copyleft may oblige Zalando to license its modifications also under the license whose copyleft was triggered. In legal terms, “modification” can be interpreted very broadly—e.g. whole libraries or code that you added (so-called “scope of copyleft”). 146 | 147 | For Modification + Internal and/or Publishing, do not use reciprocal licenses that trigger the copyleft already during internal modification—e.g. RPL or APSL 2.1, AGPLv3. 148 | 149 | For Modification + Publishing: 150 | + See above (RPL, ASPL 2.1, AGPLv3, etc.). 151 | + Do not use licenses with strict copyleft, e.g. GPLv2, GLPLv3, unless you have clearance from Legal. 152 | + If you use licenses with limited copyleft (e.g. LGPLv2.1, LGPLv3, MPLv2, CPL), please make sure you can fulfill their specific requirements to restrict the copyleft from taking over Zalando’s or other third-party’s code. → reach out to Legal. 153 | 154 | License Template for Multi-Licensed Projects without Copyleft 155 | 156 | “This {name} Project is in general licensed under the following MIT license except the files named underneath (see corresponding notice files below) 157 | 158 | (Insert Zalando MIT from Appendix 6 above) 159 | 160 | Notice file for (path)/(other file) 161 | 162 | (Insert license text & copyright notice from the original file here) 163 | 164 | Notice file for (path)/(other file) 165 | 166 | (Insert license text & copyright notice from the original file here) 167 | 168 | (...) 169 | 170 | 171 | ### Appendix 8: Why you must create a new repo 172 | “You MUST create an entirely new Git repository before pushing the project to GitHub.” 173 | 174 | This rule is a trade-off. On the one hand, we lose information when creating a new git repository. On the other hand, keeping a long history in an existing repository is too-high risk; specifics like credentials could be published by mistake. Security comes first. 175 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution 4.0 International Public License 58 | 59 | By exercising the Licensed Rights (defined below), You accept and agree 60 | to be bound by the terms and conditions of this Creative Commons 61 | Attribution 4.0 International Public License ("Public License"). To the 62 | extent this Public License may be interpreted as a contract, You are 63 | granted the Licensed Rights in consideration of Your acceptance of 64 | these terms and conditions, and the Licensor grants You such rights in 65 | consideration of benefits the Licensor receives from making the 66 | Licensed Material available under these terms and conditions. 67 | 68 | 69 | Section 1 -- Definitions. 70 | 71 | a. Adapted Material means material subject to Copyright and Similar 72 | Rights that is derived from or based upon the Licensed Material 73 | and in which the Licensed Material is translated, altered, 74 | arranged, transformed, or otherwise modified in a manner requiring 75 | permission under the Copyright and Similar Rights held by the 76 | Licensor. For purposes of this Public License, where the Licensed 77 | Material is a musical work, performance, or sound recording, 78 | Adapted Material is always produced where the Licensed Material is 79 | synched in timed relation with a moving image. 80 | 81 | b. Adapter's License means the license You apply to Your Copyright 82 | and Similar Rights in Your contributions to Adapted Material in 83 | accordance with the terms and conditions of this Public License. 84 | 85 | c. Copyright and Similar Rights means copyright and/or similar rights 86 | closely related to copyright including, without limitation, 87 | performance, broadcast, sound recording, and Sui Generis Database 88 | Rights, without regard to how the rights are labeled or 89 | categorized. For purposes of this Public License, the rights 90 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 91 | Rights. 92 | 93 | d. Effective Technological Measures means those measures that, in the 94 | absence of proper authority, may not be circumvented under laws 95 | fulfilling obligations under Article 11 of the WIPO Copyright 96 | Treaty adopted on December 20, 1996, and/or similar international 97 | agreements. 98 | 99 | e. Exceptions and Limitations means fair use, fair dealing, and/or 100 | any other exception or limitation to Copyright and Similar Rights 101 | that applies to Your use of the Licensed Material. 102 | 103 | f. Licensed Material means the artistic or literary work, database, 104 | or other material to which the Licensor applied this Public 105 | License. 106 | 107 | g. Licensed Rights means the rights granted to You subject to the 108 | terms and conditions of this Public License, which are limited to 109 | all Copyright and Similar Rights that apply to Your use of the 110 | Licensed Material and that the Licensor has authority to license. 111 | 112 | h. Licensor means the individual(s) or entity(ies) granting rights 113 | under this Public License. 114 | 115 | i. Share means to provide material to the public by any means or 116 | process that requires permission under the Licensed Rights, such 117 | as reproduction, public display, public performance, distribution, 118 | dissemination, communication, or importation, and to make material 119 | available to the public including in ways that members of the 120 | public may access the material from a place and at a time 121 | individually chosen by them. 122 | 123 | j. Sui Generis Database Rights means rights other than copyright 124 | resulting from Directive 96/9/EC of the European Parliament and of 125 | the Council of 11 March 1996 on the legal protection of databases, 126 | as amended and/or succeeded, as well as other essentially 127 | equivalent rights anywhere in the world. 128 | 129 | k. You means the individual or entity exercising the Licensed Rights 130 | under this Public License. Your has a corresponding meaning. 131 | 132 | 133 | Section 2 -- Scope. 134 | 135 | a. License grant. 136 | 137 | 1. Subject to the terms and conditions of this Public License, 138 | the Licensor hereby grants You a worldwide, royalty-free, 139 | non-sublicensable, non-exclusive, irrevocable license to 140 | exercise the Licensed Rights in the Licensed Material to: 141 | 142 | a. reproduce and Share the Licensed Material, in whole or 143 | in part; and 144 | 145 | b. produce, reproduce, and Share Adapted Material. 146 | 147 | 2. Exceptions and Limitations. For the avoidance of doubt, where 148 | Exceptions and Limitations apply to Your use, this Public 149 | License does not apply, and You do not need to comply with 150 | its terms and conditions. 151 | 152 | 3. Term. The term of this Public License is specified in Section 153 | 6(a). 154 | 155 | 4. Media and formats; technical modifications allowed. The 156 | Licensor authorizes You to exercise the Licensed Rights in 157 | all media and formats whether now known or hereafter created, 158 | and to make technical modifications necessary to do so. The 159 | Licensor waives and/or agrees not to assert any right or 160 | authority to forbid You from making technical modifications 161 | necessary to exercise the Licensed Rights, including 162 | technical modifications necessary to circumvent Effective 163 | Technological Measures. For purposes of this Public License, 164 | simply making modifications authorized by this Section 2(a) 165 | (4) never produces Adapted Material. 166 | 167 | 5. Downstream recipients. 168 | 169 | a. Offer from the Licensor -- Licensed Material. Every 170 | recipient of the Licensed Material automatically 171 | receives an offer from the Licensor to exercise the 172 | Licensed Rights under the terms and conditions of this 173 | Public License. 174 | 175 | b. No downstream restrictions. You may not offer or impose 176 | any additional or different terms or conditions on, or 177 | apply any Effective Technological Measures to, the 178 | Licensed Material if doing so restricts exercise of the 179 | Licensed Rights by any recipient of the Licensed 180 | Material. 181 | 182 | 6. No endorsement. Nothing in this Public License constitutes or 183 | may be construed as permission to assert or imply that You 184 | are, or that Your use of the Licensed Material is, connected 185 | with, or sponsored, endorsed, or granted official status by, 186 | the Licensor or others designated to receive attribution as 187 | provided in Section 3(a)(1)(A)(i). 188 | 189 | b. Other rights. 190 | 191 | 1. Moral rights, such as the right of integrity, are not 192 | licensed under this Public License, nor are publicity, 193 | privacy, and/or other similar personality rights; however, to 194 | the extent possible, the Licensor waives and/or agrees not to 195 | assert any such rights held by the Licensor to the limited 196 | extent necessary to allow You to exercise the Licensed 197 | Rights, but not otherwise. 198 | 199 | 2. Patent and trademark rights are not licensed under this 200 | Public License. 201 | 202 | 3. To the extent possible, the Licensor waives any right to 203 | collect royalties from You for the exercise of the Licensed 204 | Rights, whether directly or through a collecting society 205 | under any voluntary or waivable statutory or compulsory 206 | licensing scheme. In all other cases the Licensor expressly 207 | reserves any right to collect such royalties. 208 | 209 | 210 | Section 3 -- License Conditions. 211 | 212 | Your exercise of the Licensed Rights is expressly made subject to the 213 | following conditions. 214 | 215 | a. Attribution. 216 | 217 | 1. If You Share the Licensed Material (including in modified 218 | form), You must: 219 | 220 | a. retain the following if it is supplied by the Licensor 221 | with the Licensed Material: 222 | 223 | i. identification of the creator(s) of the Licensed 224 | Material and any others designated to receive 225 | attribution, in any reasonable manner requested by 226 | the Licensor (including by pseudonym if 227 | designated); 228 | 229 | ii. a copyright notice; 230 | 231 | iii. a notice that refers to this Public License; 232 | 233 | iv. a notice that refers to the disclaimer of 234 | warranties; 235 | 236 | v. a URI or hyperlink to the Licensed Material to the 237 | extent reasonably practicable; 238 | 239 | b. indicate if You modified the Licensed Material and 240 | retain an indication of any previous modifications; and 241 | 242 | c. indicate the Licensed Material is licensed under this 243 | Public License, and include the text of, or the URI or 244 | hyperlink to, this Public License. 245 | 246 | 2. You may satisfy the conditions in Section 3(a)(1) in any 247 | reasonable manner based on the medium, means, and context in 248 | which You Share the Licensed Material. For example, it may be 249 | reasonable to satisfy the conditions by providing a URI or 250 | hyperlink to a resource that includes the required 251 | information. 252 | 253 | 3. If requested by the Licensor, You must remove any of the 254 | information required by Section 3(a)(1)(A) to the extent 255 | reasonably practicable. 256 | 257 | 4. If You Share Adapted Material You produce, the Adapter's 258 | License You apply must not prevent recipients of the Adapted 259 | Material from complying with this Public License. 260 | 261 | 262 | Section 4 -- Sui Generis Database Rights. 263 | 264 | Where the Licensed Rights include Sui Generis Database Rights that 265 | apply to Your use of the Licensed Material: 266 | 267 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 268 | to extract, reuse, reproduce, and Share all or a substantial 269 | portion of the contents of the database; 270 | 271 | b. if You include all or a substantial portion of the database 272 | contents in a database in which You have Sui Generis Database 273 | Rights, then the database in which You have Sui Generis Database 274 | Rights (but not its individual contents) is Adapted Material; and 275 | 276 | c. You must comply with the conditions in Section 3(a) if You Share 277 | all or a substantial portion of the contents of the database. 278 | 279 | For the avoidance of doubt, this Section 4 supplements and does not 280 | replace Your obligations under this Public License where the Licensed 281 | Rights include other Copyright and Similar Rights. 282 | 283 | 284 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 285 | 286 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 287 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 288 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 289 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 290 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 291 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 292 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 293 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 294 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 295 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 296 | 297 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 298 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 299 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 300 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 301 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 302 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 303 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 304 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 305 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 306 | 307 | c. The disclaimer of warranties and limitation of liability provided 308 | above shall be interpreted in a manner that, to the extent 309 | possible, most closely approximates an absolute disclaimer and 310 | waiver of all liability. 311 | 312 | 313 | Section 6 -- Term and Termination. 314 | 315 | a. This Public License applies for the term of the Copyright and 316 | Similar Rights licensed here. However, if You fail to comply with 317 | this Public License, then Your rights under this Public License 318 | terminate automatically. 319 | 320 | b. Where Your right to use the Licensed Material has terminated under 321 | Section 6(a), it reinstates: 322 | 323 | 1. automatically as of the date the violation is cured, provided 324 | it is cured within 30 days of Your discovery of the 325 | violation; or 326 | 327 | 2. upon express reinstatement by the Licensor. 328 | 329 | For the avoidance of doubt, this Section 6(b) does not affect any 330 | right the Licensor may have to seek remedies for Your violations 331 | of this Public License. 332 | 333 | c. For the avoidance of doubt, the Licensor may also offer the 334 | Licensed Material under separate terms or conditions or stop 335 | distributing the Licensed Material at any time; however, doing so 336 | will not terminate this Public License. 337 | 338 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 339 | License. 340 | 341 | 342 | Section 7 -- Other Terms and Conditions. 343 | 344 | a. The Licensor shall not be bound by any additional or different 345 | terms or conditions communicated by You unless expressly agreed. 346 | 347 | b. Any arrangements, understandings, or agreements regarding the 348 | Licensed Material not stated herein are separate from and 349 | independent of the terms and conditions of this Public License. 350 | 351 | 352 | Section 8 -- Interpretation. 353 | 354 | a. For the avoidance of doubt, this Public License does not, and 355 | shall not be interpreted to, reduce, limit, restrict, or impose 356 | conditions on any use of the Licensed Material that could lawfully 357 | be made without permission under this Public License. 358 | 359 | b. To the extent possible, if any provision of this Public License is 360 | deemed unenforceable, it shall be automatically reformed to the 361 | minimum extent necessary to make it enforceable. If the provision 362 | cannot be reformed, it shall be severed from this Public License 363 | without affecting the enforceability of the remaining terms and 364 | conditions. 365 | 366 | c. No term or condition of this Public License will be waived and no 367 | failure to comply consented to unless expressly agreed to by the 368 | Licensor. 369 | 370 | d. Nothing in this Public License constitutes or may be interpreted 371 | as a limitation upon, or waiver of, any privileges and immunities 372 | that apply to the Licensor or You, including from the legal 373 | processes of any jurisdiction or authority. 374 | 375 | 376 | ======================================================================= 377 | 378 | Creative Commons is not a party to its public licenses. 379 | Notwithstanding, Creative Commons may elect to apply one of its public 380 | licenses to material it publishes and in those instances will be 381 | considered the "Licensor." Except for the limited purpose of indicating 382 | that material is shared under a Creative Commons public license or as 383 | otherwise permitted by the Creative Commons policies published at 384 | creativecommons.org/policies, Creative Commons does not authorize the 385 | use of the trademark "Creative Commons" or any other trademark or logo 386 | of Creative Commons without its prior written consent including, 387 | without limitation, in connection with any unauthorized modifications 388 | to any of its public licenses or any other arrangements, 389 | understandings, or agreements concerning use of licensed material. For 390 | the avoidance of doubt, this paragraph does not form part of the public 391 | licenses. 392 | 393 | Creative Commons may be contacted at creativecommons.org. 394 | --------------------------------------------------------------------------------