Merge pull request #1234 from katrinleinweber/de

Update German translation

Author: MikeMcQuaid

_articles/de/how-to-contribute.md

@@ -244,6 +244,8 @@ Weiterhin, können Sie auf folgenden Seiten neue Projekte zum Beitragen entdecke
 * [24 Pull Requests](https://24pullrequests.com/)
 * [Up For Grabs](http://up-for-grabs.net/)
 * [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://www.sourcesort.com/)
 
 ### Eine Checkliste, bevor Sie einen Beitrag leisten
 

_articles/de/legal.md

@@ -113,6 +113,7 @@ Durch das Hinzufügen von "Papierkram", den einige für unnötig, schwer verstä
 Einige Situationen, in denen Sie eine zusätzliche Kontributionsvereinbarung für Ihr Projekt in Betracht ziehen sollten, sind z.B:
 
 * Ihre Anwälte wollen, dass alle Mitwirkenden ausdrücklich die Kontributionsbedingungen akzeptieren (_unterschreiben_, on- oder off-line), vielleicht weil sie der Meinung sind, dass die Open-Source-Lizenz selbst nicht ausreicht (obwohl sie ausreicht!). Wenn dies die einzige Sorge ist, sollte eine Kontributionsvereinbarung, welche die Open-Source-Lizenz des Projekts bestätigt, ausreichen. Das [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) ist ein gutes Beispiel für eine leichtgewichtige, zusätzliche Kontributionsvereinbarung. Für manche Projekte kann ein [Developer Certificate of Origin](https://github.com/probot/dco) eine Alternative sein.
+* Sie oder Ihre Anwälte wollen Entwickler\*innen bestätigen lassen, dass Ihre Commits autorisiert sind. Viele Projekte nutzen dafür das [Developer Certificate of Origin](https://developercertificate.org/). Beispielsweise nutzt die Node.js-Community [ein DCO](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md) anstatt ihres [vorherigen CLAs](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution). [DCO Probot](https://github.com/probot/dco) bietet eine einfache Möglichkeit, in Ihrem Projekt ein solches DCO automatisch einzufordern.
 * Ihr Projekt verwendet eine Open-Source-Lizenz, die keine ausdrückliche Patenterteilung enthält (z.B. MIT), die Sie aber von allen Mitwirkenden benötigen. Von denen können Einige für Unternehmen mit großen Patentportfolios arbeiten, die gegen Sie oder die anderen Mitwirkenden und Benutzer\*innen des Projekts verwendet werden könnten. Die [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) ist eine häufig verwendete zusätzliche Kontributionsvereinbarung mit einer der Apache License 2.0 entsprechenden Patenterteilung.
 * Ihr Projekt steht unter einer Copyleft-Lizenz, aber Sie müssen auch eine proprietäre Version des Projekts verbreiten. Sie werden von allen Kontributor\*innen eine Rechteverwertungsvereinbarung einholen müssen, die Ihnen (aber nicht der Öffentlichkeit) eine permissive Lizenz gewährt. Das [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) ist ein Beispiel für eine solche Vereinbarungen.
 * Sie sind der Meinung, dass Ihr Projekt im Laufe seiner Laufzeit seine Lizenz wechseln muss und möchten, dass die Mitwirkenden dieser Änderungen im Voraus zustimmen.

_articles/de/starting-a-project.md

@@ -18,16 +18,9 @@ Sie denken also über einen Sprung in die Open-Source-Welt nach? Herzlichen Glü
 
 Ein Open-Source-Projekt kann von **jedem Menschen für jeden Zweck verwendet, inspiziert, modifiziert und weiterverbreitet werden.** Diese Rechte werden [mittels einer Open-Source-Lizenz durchgesetzt](https://opensource.org/licenses).
 
-Open Source ist leistungsstark, weil es Akzeptanzbarrieren senkt und Ideen schneller verbreiten lässt.
+Open Source ist so mächtig, weil es Barrieren für Nutzung und Zusammenarbeit senkt und Leuten somit ermöglicht, Ideen schneller zu verbreiten und Dinge schneller zu verbessern. Zudem ermöglicht es den Benutzer\*inn\*n, ihr eigenes Computing besser unter Kontrolle zu behalten, als mit proprietären Lösungen. Ein Unternehmen, das Open-Source-Software verwendet, kann beispielsweise jemanden einstellen, um maßgeschneiderte Verbesserungen an der Software vorzunehmen, anstatt von den Produktentscheidungen des Anbieters abhängig zu sein.
 
-Um zu verstehen, wie es funktioniert, stellen Sie sich vor, eine Freundin von Ihnen lädt zur Grillparty ein und Sie bringen einen Kartoffelsalat mit.
-
-* Alle probiere den Salat (_verwenden_)
-* Er ist der Hit! Andere Gäste fragen Sie nach dem Rezept, das Sie auch gerne nennen (_inspizieren_)
-* Ihr süddeutscher Freund Alex schlägt vor, weniger Majo zu nehmen (_modifizieren_)
-* Eine andere Freundin, Lisa, möchte den Salat für ein Abendessen nächste Woche selbst ausprobieren (_weiterverbreiten_)
-
-Zum Vergleich: Closed-Source entspricht einem Restaurantbesuch mit der Bestellung einer Portion Kartoffelsalat. Sie müssen eine Gebühr zahlen, um ihn zu essen, und das Restaurant wird Ihnen das Rezept wahrscheinlich nicht geben. Wenn Sie den Salat genau kopieren und unter Ihrem eigenen Namen verkaufen würden, könnte das Restaurant gegen Sie vorgehen.
+_Freie Software_ meint dieselbe Art von Projekten wie _Open Source_. Der [Begriff](https://de.wikipedia.org/wiki/Free/Libre_Open_Source_Software) wird manchmal auch kombiniert mit "Freie/Libre und Open-Source-Software" (FOSS bzw. FLOSS). _Frei_ und _Libre_ meinen hierbei die Freiheit, nicht den [Preis](#bedeutet-open-source-auch-gratis).
 
 ### Warum öffnen Menschen den Quellcode ihrer Software?