From 20de1188ee6dea4401b444ede11cf2eed97c8301 Mon Sep 17 00:00:00 2001 From: Wesley de Groot Date: Thu, 27 Aug 2020 17:05:38 +0200 Subject: [PATCH] Article 'Legal' --- _articles/nl/legal.md | 135 +++++++++++++++++++++++------------------- 1 file changed, 73 insertions(+), 62 deletions(-) diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md index 8e4c84d961d..68c73cf9194 100644 --- a/_articles/nl/legal.md +++ b/_articles/nl/legal.md @@ -20,147 +20,158 @@ related: ## Understanding the legal implications of open source -Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).) +Het delen van uw creatieve werk met de wereld kan een opwindende en lonende ervaring zijn. Het kan ook een heleboel juridische dingen betekenen waarvan je niet wist dat u zich er zorgen over moest maken. Gelukkig hoef je niet helemaal opnieuw te beginnen. We hebben uw juridische behoeften gedekt. (Lees voordat u verder gaat onze [disclaimer](/notices/).) ## Waarom geven mensen zoveel om de juridische kant van open source? -Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it. +Blij dat je het vraagt! Wanneer u een creatief werk maakt (zoals schrijven, afbeeldingen of code), valt dat werk standaard onder exclusief auteursrecht. Dat wil zeggen, de wet gaat ervan uit dat u als auteur van uw werk inspraak hebt in wat anderen ermee kunnen doen. -In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. +Over het algemeen betekent dit dat niemand anders uw werk kan gebruiken, kopiëren, distribueren of wijzigen zonder het risico te lopen op uitval, opschudding of rechtszaak. -Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions. +Open source is echter een ongebruikelijke omstandigheid, omdat de auteur verwacht dat anderen het werk zullen gebruiken, aanpassen en delen. Maar omdat de wettelijke standaard nog steeds exclusief copyright is, hebt u een licentie nodig waarin deze machtigingen expliciet worden vermeld. -If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you. +Als u geen open source-licentie toepast, wordt iedereen die aan uw project bijdraagt ​​ook de exclusieve copyrighthouder van zijn werk. Dat betekent dat niemand zijn bijdragen kan gebruiken, kopiëren, verspreiden of wijzigen - en dat "niemand" jou ook omvat. -Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below. +Ten slotte kan uw project afhankelijkheden hebben met licentievereisten waarvan u zich niet bewust was. De gemeenschap van uw project of het beleid van uw werkgever kan ook vereisen dat uw project specifieke open source-licenties gebruikt. We behandelen deze situaties hieronder. ## Zijn openbare GitHub-projecten open source? -When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**. +Wanneer je [een nieuw project maakt](https://help.github.com/articles/creating-a-new-repository/) op GitHub, heb je de optie om de repository **privé** of **openbaar te maken**. ![Create repository](/assets/images/legal/repo-create-name.png) -**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions. +**Het openbaar maken van uw GitHub-project is niet hetzelfde als het licentiëren van uw project.** Openbare projecten vallen onder de [Servicevoorwaarden van GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), waarmee anderen uw project kunnen bekijken en splitsen (_een fork_), maar uw werk heeft verder geen rechten. -If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. +Als u wilt dat anderen uw project gebruiken, distribueren, wijzigen of eraan bijdragen, moet u een open source-licentie opnemen. Iemand kan bijvoorbeeld geen enkel deel van je GitHub-project legaal in zijn code gebruiken, zelfs niet als het openbaar is, tenzij je hem expliciet het recht geeft om dit te doen. ## Geef me gewoon de TL;DR over wat ik nodig heb om mijn project te beschermen -You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project. +Je hebt geluk, want tegenwoordig zijn open source-licenties gestandaardiseerd en gebruiksvriendelijk. U kunt een bestaande licentie rechtstreeks in uw project kopiëren en plakken. -[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) en [GPLv3](https://choicealicense.com/licenses/gpl-3.0/) zijn de meest populaire open source-licenties, maar er zijn andere opties om uit te kiezen. U kunt de volledige tekst van deze licenties en instructies voor het gebruik ervan vinden op [choosealicense.com](https://choosealicense.com/). -When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/). +Wanneer u een nieuw project op GitHub maakt, wordt u [gevraagd om een licentie toe te voegen](https://help.github.com/articles/open-source-licensing/). ## Welke open source-licentie is geschikt voor mijn project? -If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. +Als je begint met een blanco project, is het moeilijk om fout te gaan met de [MIT License](https://choosealicense.com/licenses/mit/). Het is kort, heel gemakkelijk te begrijpen en staat iedereen toe om alles te doen, zolang ze een kopie van de licentie bewaren, inclusief uw copyrightmelding. U kunt het project onder een andere licentie vrijgeven als dat ooit nodig is. -Otherwise, picking the right open source license for your project depends on your objectives. +Anders hangt het kiezen van de juiste open source-licentie voor uw project af van uw doelstellingen. -Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. +Uw project heeft (of zal) zeer waarschijnlijk **afhankelijkheden**. Als u bijvoorbeeld een Node.js-project open source maakt, gebruikt u waarschijnlijk bibliotheken van de Node Package Manager (npm). Elk van die bibliotheken waarvan u afhankelijk bent, heeft zijn eigen open source-licentie. Als elk van hun licenties "permissief" is (geeft het publiek toestemming om te gebruiken, wijzigen en delen, zonder enige voorwaarde voor downstreamlicenties), kunt u elke gewenste licentie gebruiken. Veelgebruikte licenties zijn onder meer MIT, Apache 2.0, ISC en BSD. -On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. +Aan de andere kant, als een van de licenties van je afhankelijkheden "sterk copyleft" is (geeft ook publiek dezelfde permissies, op voorwaarde dat je dezelfde licentie downstream gebruikt), dan zal je project dezelfde licentie moeten gebruiken. Veelgebruikte licenties voor sterke auteursplicht zijn GPLv2, GPLv3 en AGPLv3. -You may also want to consider the **communities** you hope will use and contribute to your project: +U kunt ook de **gemeenschappen** overwegen waarvan u hoopt dat ze zullen gebruiken en bijdragen aan uw project: -* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM). -* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. -* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. +* **Wilt u dat uw project wordt gebruikt als afhankelijkheid door andere projecten?** Waarschijnlijk het beste om de meest populaire licentie in uw relevante gemeenschap te gebruiken. [MIT](https://choosealicense.com/licenses/mit/) is bijvoorbeeld de meest populaire licentie voor [npm libraries](https://libraries.io/search?platforms=NPM). +* **Wilt u dat uw project grote bedrijven aanspreekt?** Een groot bedrijf wil waarschijnlijk een uitdrukkelijke patentlicentie van alle bijdragers. In dit geval heeft [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) jou (en hen) gedekt. +* **Wilt u dat uw project een beroep doet op bijdragers die niet willen dat hun bijdragen worden gebruikt in closed source-software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) of (indien ze willen ook niet bijdragen aan closed source-diensten) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) zal goed overkomen. -Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#wat-moet-het-juridische-team-van-mijn-bedrijf-weten). +Uw **bedrijf** heeft mogelijk specifieke licentievereisten voor zijn open source-projecten. Het kan bijvoorbeeld een vergunning vereisen, zodat het bedrijf uw project kan gebruiken in het closed source-product van het bedrijf. Of uw bedrijf heeft mogelijk een sterke auteursplichtlicentie en een aanvullende bijdragersovereenkomst nodig (zie hieronder) zodat alleen uw bedrijf, en niemand anders, uw project kan gebruiken in closed source-software. Of uw bedrijf kan bepaalde behoeften hebben met betrekking tot normen, sociale verantwoordelijkheid of transparantie, die elk een bepaalde licentiestrategie vereisen. Neem contact op met de juridische afdeling van uw [bedrijf](#wat-moet-het-juridische-team-van-mijn-bedrijf-weten). -When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/). +Wanneer u een nieuw project op GitHub maakt, krijgt u de mogelijkheid om een ​​licentie te selecteren. Als u een van de bovengenoemde licenties opneemt, wordt uw GitHub-project open source. Als je andere opties wilt zien, ga dan naar [choosealicense.com](https://choosealicense.com) om de juiste licentie voor je project te vinden, zelfs als het [geen software is](https://choosealicense.com/non-software/). ## Wat moet ik doen als ik de licentie van mijn project wil wijzigen? -Most projects never need to change licenses. But occasionally circumstances change. +De meeste projecten hoeven nooit van licentie te wisselen. Maar af en toe veranderen de omstandigheden. -For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license: +Naarmate uw project groeit, voegt het bijvoorbeeld afhankelijkheden of gebruikers toe, of verandert uw bedrijf van strategie, die voor elk een andere licentie kunnen vereisen of willen. Als u vanaf het begin geen licentie voor uw project hebt verleend, is het toevoegen van een licentie in feite hetzelfde als het wijzigen van licenties. Er zijn drie fundamentele zaken waarmee u rekening moet houden bij het toevoegen of wijzigen van de licentie van uw project: -**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! +**Het is ingewikkeld.** Het bepalen van de compatibiliteit en naleving van licenties en wie het auteursrecht bezit, kan zeer snel ingewikkeld en verwarrend worden. Overschakelen naar een nieuwe maar compatibele licentie voor nieuwe releases en bijdragen is iets anders dan alle bestaande bijdragen opnieuw licentiëren. Betrek uw juridische team bij de eerste aanwijzing dat u licenties wilt wijzigen. Zelfs als u toestemming hebt of kunt krijgen van de auteursrechthouders van uw project voor een licentiewijziging, moet u rekening houden met de impact van de wijziging op de andere gebruikers en bijdragers van uw project. Beschouw een licentiewijziging als een "bestuursgebeurtenis" voor uw project dat waarschijnlijk vlotter zal verlopen met duidelijke communicatie en overleg met de belanghebbenden van uw project. Reden te meer om vanaf het begin een geschikte licentie voor uw project te kiezen en te gebruiken! -**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses. +**De bestaande licentie van uw project.** Als de bestaande licentie van uw project compatibel is met de licentie waarnaar u wilt overschakelen, kunt u de nieuwe licentie gewoon gaan gebruiken. Dat komt omdat als licentie A compatibel is met licentie B, u voldoet aan de voorwaarden van A terwijl u voldoet aan de voorwaarden van B (maar niet noodzakelijkerwijs andersom). Dus als u momenteel een toegestane licentie gebruikt (bijv. MIT), kunt u overschakelen naar een licentie met meer voorwaarden, zolang u een kopie van de MIT-licentie en eventuele bijbehorende copyrightkennisgevingen bewaart (dat wil zeggen, blijf voldoen aan de Minimale voorwaarden van de MIT-licentie). Maar als je huidige licentie niet toelaatbaar is (bijv. Copyleft, of je hebt geen licentie) en je bent niet de enige copyrighthouder, dan zou je niet zomaar de licentie van je project kunnen veranderen in MIT. In wezen hebben de auteursrechthouders van het project met een toegestane licentie van tevoren toestemming gegeven om licenties te wijzigen. -**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. +**De bestaande auteursrechthouders van uw project.** Als u de enige bijdrager aan uw project bent, bent u of uw bedrijf de enige houder van het auteursrecht van het project. U kunt elke licentie die u of uw bedrijf wenst, toevoegen of wijzigen. Anders zijn er mogelijk andere auteursrechthouders met wie u toestemming nodig heeft om licenties te wijzigen. Wie zijn zij? Mensen die commits hebben in uw project, zijn een goede plek om te beginnen. Maar in sommige gevallen berust het auteursrecht bij de werkgevers van die mensen. In sommige gevallen hebben mensen slechts minimale bijdragen geleverd, maar er is geen vaste regel dat bijdragen onder een aantal coderegels niet onderhevig zijn aan auteursrechten. Wat te doen? Het hangt er van af. Voor een relatief klein en jong project kan het haalbaar zijn om alle bestaande bijdragers zover te krijgen dat ze instemmen met een licentiewijziging in een issue of pull-aanvraag. Voor grote en langlopende projecten moet u mogelijk veel bijdragers en zelfs hun erfgenamen zoeken. Mozilla heeft jaren (2001-2006) nodig gehad om Firefox, Thunderbird en gerelateerde software opnieuw te licentiëren. -Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. +Als alternatief kunt u bijdragers van tevoren laten instemmen (via een aanvullende overeenkomst voor bijdragers - zie hieronder) met bepaalde licentiewijzigingen onder bepaalde voorwaarden, naast die welke zijn toegestaan ​​door uw bestaande open source-licentie. Dit verschuift de complexiteit van het wijzigen van licenties een beetje. U heeft vooraf meer hulp van uw advocaten nodig en u wilt toch duidelijk communiceren met de belanghebbenden van uw project wanneer u een licentiewijziging doorvoert. ## Heeft mijn project een aanvullende contribuantenovereenkomst nodig? -Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). +Waarschijnlijk niet. Voor de overgrote meerderheid van open source-projecten dient een open source-licentie impliciet als zowel de inkomende (van bijdragers) als uitgaande (naar andere bijdragers en gebruikers) licentie. Als uw project zich op GitHub bevindt, maken de Servicevoorwaarden van GitHub "inbound = outbound" tot de [expliciete standaard](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). -An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers. +Een aanvullende bijdragersovereenkomst -- vaak een bijdragerslicentieovereenkomst (CLA) genoemd -- kan administratief werk creëren voor projectbeheerders. Hoeveel werk een overeenkomst toevoegt, hangt af van het project en de uitvoering. Een eenvoudige overeenkomst kan vereisen dat bijdragers met een klik bevestigen dat ze de benodigde rechten hebben om bij te dragen onder de open source-licentie van het project. Een meer gecompliceerde overeenkomst vereist mogelijk juridische beoordeling en goedkeuring door de werkgevers van contribuanten. -Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community. +Door ook 'papierwerk' toe te voegen waarvan sommigen denken dat het onnodig, moeilijk te begrijpen of oneerlijk is (wanneer de ontvanger van de overeenkomst meer rechten krijgt dan bijdragers of het publiek via de open source-licentie van het project), kan een aanvullende overeenkomst voor bijdragers als onvriendelijk worden ervaren aan de gemeenschap van het project. +Enkele situaties waarin u wellicht een aanvullende bijdrageovereenkomst voor uw project wilt overwegen, zijn onder meer: -Some situations where you may want to consider an additional contributor agreement for your project include: +* Uw advocaten willen dat alle bijdragers uitdrukkelijk (_tekenen_, online of offline) contributievoorwaarden accepteren, misschien omdat ze vinden dat de open source-licentie zelf niet voldoende is (ook al is het dat wel!). Als dit de enige zorg is, zou een bijdragersovereenkomst moeten volstaan ​​die de open source-licentie van het project bevestigt. De [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is een goed voorbeeld van een lichtgewicht aanvullende overeenkomst voor bijdragers. +* U of uw advocaten willen dat ontwikkelaars verklaren dat elke toezegging die ze doen, geautoriseerd is. Een [Developer Certificate of Origin](https://developercertificate.org/) vereiste is hoeveel projecten dit bereiken. De Node.js-community [gebruikt](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) bijvoorbeeld de DCO [in plaats daarvan](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) van hun eerdere cao. Een eenvoudige optie om de handhaving van de DCO op uw repository te automatiseren, is de [DCO Probot] (https://github.com/probot/dco). +* Uw project maakt gebruik van een open source-licentie die geen uitdrukkelijke octrooiverlening omvat (zoals MIT), en u hebt een octrooiverlening nodig van alle bijdragers, van wie sommigen mogelijk werken voor bedrijven met grote octrooiportefeuilles die kunnen worden gebruikt om u te targeten of de andere bijdragers en gebruikers van het project. De [Apache-licentieovereenkomst voor individuele bijdragers](https://www.apache.org/licenses/icla.pdf) is een veelgebruikte aanvullende overeenkomst voor bijdragers met een octrooiverlening die overeenkomt met die in de Apache-licentie 2.0. +* Uw project valt onder een auteursplichtlicentie, maar u moet ook een eigen versie van het project distribueren. Je hebt elke bijdrager nodig om het auteursrecht aan jou toe te wijzen of jou (maar niet het publiek) een permissieve licentie te verlenen. De [MongoDB-bijdragersovereenkomst](https://www.mongodb.com/legal/contributor-agreement) is een voorbeeld van dit type overeenkomst. +* U denkt dat uw project mogelijk licenties moet wijzigen gedurende de levensduur en u wilt dat bijdragers van tevoren akkoord gaan met dergelijke wijzigingen. -* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. -* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). -* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. -* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. -* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes. - -If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. +Als je toch een aanvullende bijdragersovereenkomst nodig hebt voor je project, overweeg dan om een ​​integratie zoals [CLA-assistent](https://github.com/cla-assistant/cla-assistant) te gebruiken om afleiding van bijdragers te minimaliseren. ## Wat moet het juridische team van mijn bedrijf weten? -If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project. +Als u als bedrijfsmedewerker een open source-project vrijgeeft, moet uw juridische team eerst weten dat u een project open source maakt. -For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company. +Overweeg om ze te laten weten, of het nu een persoonlijk project is, of het nu beter of slechter is. U hebt waarschijnlijk een "IP-overeenkomst voor werknemers" met uw bedrijf die hen enige controle geeft over uw projecten, vooral als ze überhaupt verband houden met de zaken van het bedrijf of als u bedrijfsmiddelen gebruikt om het project te ontwikkelen. Uw bedrijf _moet_ u gemakkelijk toestemming geven, en heeft dat misschien al gedaan via een werknemersvriendelijke IE-overeenkomst of een bedrijfsbeleid. Zo niet, dan kunt u onderhandelen (leg bijvoorbeeld uit dat uw project de professionele leer- en ontwikkelingsdoelstellingen van het bedrijf voor u dient), of werk niet aan uw project totdat u een beter bedrijf heeft gevonden. -**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: +**Als u een open source project voor uw bedrijf zoekt,** laat het hen dan zeker weten. Uw juridische team heeft waarschijnlijk al beleid voor welke open source-licentie (en misschien een aanvullende bijdragersovereenkomst) moet worden gebruikt op basis van de zakelijke vereisten en expertise van het bedrijf om ervoor te zorgen dat uw project voldoet aan de licenties van zijn afhankelijkheden. Zo niet, dan hebben jij en zij geluk! Uw juridische team zou graag met u willen samenwerken om dit uit te zoeken. Enkele dingen om over na te denken: -* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. +* **Materiaal van derden:** Heeft uw project afhankelijkheden die door anderen zijn gecreëerd of bevat of gebruikt u anderszins code van anderen? Als deze open source zijn, moet u voldoen aan de open source-licenties van het materiaal. Dat begint met het kiezen van een licentie die werkt met de open source-licenties van derden (zie hierboven). Als uw project open source-materiaal van derden wijzigt of verspreidt, zal uw juridische team ook willen weten dat u voldoet aan andere voorwaarden van de open source-licenties van derden, zoals het behouden van copyrightkennisgevingen. Als uw project code van anderen gebruikt die geen open source-licentie heeft, moet u waarschijnlijk de externe beheerders vragen om [een open source-licentie toe te voegen](https://choosealicense.com/no-license/#for-users), en als u er geen kunt krijgen, stop dan met het gebruik van hun code in uw project. -* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private. +* **Handelsgeheimen:** Bedenk of er iets in het project staat dat het bedrijf niet beschikbaar wil stellen aan het grote publiek. Als dat het geval is, kunt u de rest van uw project open source maken, nadat u het materiaal hebt geëxtraheerd dat u privé wilt houden. -* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). +* **Octrooien:** Vraagt ​​uw bedrijf een octrooi aan waarvan open sourcing uw project [openbaar](https://en.wikipedia.org/wiki/Public_disclosure) zou maken? Helaas wordt u mogelijk gevraagd om te wachten (of misschien heroverweegt het bedrijf de wijsheid van de toepassing). Als u bijdragen aan uw project verwacht van werknemers van bedrijven met grote octrooiportefeuilles, kan uw juridische team willen dat u een licentie gebruikt met een uitdrukkelijke octrooiverlening van bijdragers (zoals Apache 2.0 of GPLv3), of een aanvullende bijdragersovereenkomst (zie hierboven). -* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#naamconflicten-vermijden). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects. +* **Handelsmerken:** Controleer nogmaals of de naam van uw project [niet in strijd is met bestaande handelsmerken](../starting-a-project/#naamconflicten-vermijden). Als u in het project uw eigen bedrijfsmerken gebruikt, controleer dan of dit geen conflicten veroorzaakt. [FOSSmarks](http://fossmarks.org/) is een praktische gids om handelsmerken te begrijpen in de context van gratis en open source projecten. -* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. +* **Privacy:** Verzamelt uw project gegevens over gebruikers? 'Naar huis bellen' naar bedrijfsservers? Uw juridische team kan u helpen bij het naleven van het bedrijfsbeleid en externe regelgeving. -If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns). +Als u het eerste open source-project van uw bedrijf uitbrengt, is het bovenstaande meer dan voldoende om erdoorheen te komen (maar maakt u zich geen zorgen, de meeste projecten zouden geen grote zorgen moeten baren). -Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe: +Op de langere termijn kan uw juridische team meer doen om het bedrijf te helpen meer uit zijn betrokkenheid bij open source te halen en veilig te blijven: -* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/). +* **Beleid inzake werknemersbijdragen:** Overweeg om een ​​bedrijfsbeleid te ontwikkelen dat aangeeft hoe uw werknemers bijdragen aan open source-projecten. Een duidelijk beleid zal de verwarring onder uw medewerkers verminderen en hen helpen bij te dragen aan open source-projecten in het belang van het bedrijf, zowel als onderdeel van hun baan als in hun vrije tijd. Een goed voorbeeld is Rackspace's [Model IP and Open Source Contribution Policy] (https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/). -* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts. -* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. +* **Wat vrij te geven:** [(Bijna) alles?] (Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Als uw juridische team het begrijpt en geïnvesteerd in de open source-strategie van uw bedrijf, zullen ze u het beste kunnen helpen in plaats van hinderen. +* **Naleving:** Zelfs als uw bedrijf geen open source-projecten vrijgeeft, gebruikt het open source-software van anderen. [Bewustwording en proces](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) kan hoofdpijn, productvertragingen, en rechtszaken voorkomen. -* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). -* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#heb-ik-een-juridische-entiteit-nodig-om-mijn-project-te-ondersteunen). +* **Patenten:** Uw bedrijf wil wellicht lid worden van het [Open Invention Network](https://www.openinventionnetwork.com/), een gedeelde defensieve patentpool om het gebruik van grote open source-projecten door leden te beschermen, of andere [alternatieve patentlicenties](https://www.eff.org/document/hacking-patent-system-2016). +* **Governance:** Zeker als en wanneer het zinvol is om een project te verhuizen naar een [juridische entiteit buiten het bedrijf](../leadership-and-governance/#heb-ik-een-juridische-entiteit-nodig-om-mijn-project-te-ondersteunen).