Generator licencji

Dalej

Wysłanie projektu bez pliku LICENSE technicznie oznacza „wszelkie prawa zastrzeżone”, nikt nie może ponownie użyć kodu. Ten generator tworzy pełny, niezmodyfikowany tekst najpopularniejszych licencji open source, z Twoim nazwiskiem i bieżącym rokiem podstawionymi w nagłówku praw autorskich. Wklej go do pliku LICENSE w korzeniu swojego repozytorium i wypchnij.

Jak wybrać i wygenerować licencję

  1. 1

    Wybierz licencję

    MIT dla pozwalającej, Apache-2.0 dla pozwalającej + grant patentowy, GPLv3 dla copyleft.

  2. 2

    Wpisz swoje nazwisko i rok

    Posiadacz praw autorskich: Twoje imię i nazwisko prawne lub Twoja firma. Rok to pierwszy rok wydania.

  3. 3

    Przejrzyj pełny tekst

    Tekst licencji pozostaje dokładnie taki, jak publikują go OSI / FSF; zmienia się tylko wiersz praw autorskich.

  4. 4

    Wrzuć go do LICENSE

    Zapisz w korzeniu swojego repozytorium. GitHub wykrywa i wyświetla go na pasku bocznym.

Wybór między popularnymi opcjami

Nie ma uniwersalnie „najlepszej“ licencji open source. Wybór zależy od tego, co chcesz, by użytkownicy w dalszym ciągu mogli, i nie mogli, robić.

Licencja Typ Grant patentowy Copyleft? Znani użytkownicy
MIT Pozwalająca Domniemany Nie Rails, pakiety Node, jQuery
Apache-2.0 Pozwalająca Wyraźny Nie Kubernetes, Android AOSP
BSD-3-Clause Pozwalająca Brak Nie Biblioteka standardowa Go, Nginx
GPL-3.0 Silny copyleft Tak Tak GCC, Bash, GIMP
LGPL-3.0 Słaby copyleft Tak Częściowo glibc, Qt (historycznie)
MPL-2.0 Słaby copyleft Tak Częściowo Firefox, Thunderbird
AGPL-3.0 Copyleft sieciowy Tak Tak MongoDB (przed 2018), Grafana
Unlicense / CC0 Przekazanie do domeny publicznej - Nie Małe biblioteki narzędziowe

Trzy praktyczne pytania

  1. Czy chcesz, by istniały zamknięte forki? Pozwalająca (MIT, Apache, BSD) → tak. Copyleft (GPL, AGPL) → nie.

  2. Czy zależy Ci na odwecie patentowym? Apache-2.0, GPLv3 i MPL-2.0 mają wyraźne granty patentowe, które wygasają przy wszczęciu sporu. MIT i BSD-2/3 nie mają.

  3. Czy Twój kod działa jako usługa sieciowa? AGPL-3.0 zamyka „lukę SaaS“, użytkownicy usługi liczą się jako dystrybucja. Jeśli to ma znaczenie, wybierz ją; w przeciwnym razie GPLv3 jest prostsze.

Częste błędy do uniknięcia

  • Nie edytuj tekstu licencji. Licencja „MIT z moimi poprawkami“ to nowa, niezgodna licencja. Sądy odrzucają doraźne modyfikacje.
  • Nie używaj dwóch licencji bez zrozumienia zgodności. Apache-2.0 i GPLv2 nie są zgodne; Apache-2.0 i GPLv3 są.
  • Nie zapomnij o identyfikatorze SPDX w nagłówkach źródeł: SPDX-License-Identifier: MIT w wierszu 1 pomaga narzędziom wykryć Twój wybór.
  • Nie używaj „Creative Commons“ do oprogramowania. Licencje CC są do dzieł twórczych; stosuj je w dokumentacji i obrazach, a nie w kodzie.

Podwójne licencjonowanie

Niektóre projekty wydają się na dwóch licencjach, zwykle jednej copyleft, jednej komercyjnej, by firmy mogły wykupić się z warunków copyleft. Qt i MySQL słynnie tak robią. Jest to prawnie złożone; jeśli nie monetyzujesz projektu, trzymaj się jednej licencji zatwierdzonej przez OSI.

Najczęściej zadawane pytania

MIT to najpopularniejsza domyślna opcja dla małych projektów open source: krótka, pozwalająca, szeroko zrozumiała i zgodna z praktycznie każdą inną licencją. Apache-2.0 to nieco bezpieczniejszy wybór, jeśli Twój projekt ma jakąkolwiek nowość nadającą się do opatentowania.

Tak. Bez niego Twój kod jest w pełni objęty prawami autorskimi i nikt nie może go legalnie ponownie użyć, publiczny dostęp na GitHubie to nie licencja. Dodaj plik LICENSE tego samego dnia, w którym upubliczniasz repozytorium.

Pierwszy rok wydania (pojedynczy rok) albo zakres kończący się bieżącym rokiem (np. „2019-2026“). Aktualizowanie roku każdego stycznia to uprzejmość, a nie wymóg prawny w większości jurysdykcji.

Nie, podstawienie odbywa się w Twojej przeglądarce, a Twoje nazwisko, rok i wybór licencji nigdy nie są do nas wysyłane.

Powiązane narzędzia

Narzędzie jest dostępne w innych językach