Apakah Anda harus memasukkan pemberitahuan lisensi ke setiap file sumber?


111

Saya telah mencari berbagai lisensi yang dapat saya gunakan untuk proyek sumber terbuka milik saya, tetapi semua proyek yang saya lihat, dengan semua jenis lisensi, tampaknya memiliki raksasa, menjengkelkan (menurut saya) perhatikan di setiap file sumber yang menyatakan bahwa file tersebut terdaftar di bawah lisensi tertentu. Saya tidak berpikir bahwa saya telah menemukan proyek sumber tunggal yang bukan domain publik yang tidak memiliki pemberitahuan seperti itu.

Sepertinya ini hanya buang-buang waktu dan ruang file. Saya berencana untuk menempatkan @licensedan memberi @authortag pada proyek-proyek saya, tetapi saya tidak melihat mengapa saya perlu membuat daftar pemberitahuan sebesar itu di setiap file individu jika saya tidak ingin membuat kode saya menjadi domain publik.

Apakah ada alasan mengapa saya ingin memasukkan pemberitahuan seperti itu ke dalam proyek saya, atau hanya akan menyertakan pemberitahuan di READMEdan @licensetag cukup baik? Apakah ini memengaruhi aturan "sebagian besar lisensi" yang dinyatakan dengan jelas, atau hanya berlebihan sehingga orang tidak akan berdebat?


10
Editor Anda harus memungkinkan Anda untuk melipat / menyembunyikan lisensi menjadi 1 baris.
Pubby

1
Secara realistis, jika seseorang menggunakan kode Anda, mengganti nama variabel dan menghapus hak cipta, akankah pengadilan menganggap 2 file ini identik?
NoChance

5
@Emmad: Tidak, pengadilan tidak akan mengatakan mereka identik. (Tapi mereka mungkin "pada dasarnya identik".) Ya, pengadilan akan mengatakan itu adalah pelanggaran hak cipta.
Andrew Dalke


Jawaban:


39

Dalam pemahaman saya, GPLv3 sangat menyarankan (atau bahkan mungkin mengharuskan, setidaknya bagaimana saya memahami teks Cara Mendaftar Persyaratan Ini ke Program Baru Anda , setelah bagian 17) pemberitahuan hak cipta di setiap file sumber. Ia mengatakan

Untuk melakukannya, lampirkan pemberitahuan berikut ke program. Paling aman untuk melampirkannya di awal setiap file sumber untuk menyatakan secara paling efektif pengecualian garansi; dan setiap file harus memiliki setidaknya baris "hak cipta" dan pointer ke tempat pemberitahuan penuh ditemukan.

<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year>  <name of author>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

Dan proyek GNU yang dimiliki FSF, seperti GCC, memiliki pemberitahuan seperti itu di setiap file.

Saya juga tahu sebuah program (sistem CAIA J.Pitrat) yang telah ditolak di situs web komunitas perangkat lunak bebas karena tidak ada pemberitahuan seperti itu di setiap file.

Saya bukan pengacara , tetapi saya percaya bahwa pemberitahuan semacam itu praktis wajib di setiap file sumber program GPLv3 .

(jika Anda menggunakan lisensi lain, terutama yang non-FSF, baca dengan cermat tentang cara menerapkannya; YMMV; namun AFAIK menulis pemberitahuan di setiap file tidak akan membahayakan.)


16
Tidak boleh wajib karena ada sistem, seperti gambar Smalltalk, yang tidak menyatakan kode sumber sebagai file. Mereka mengatakan "paling aman" dan "harus", bukan "harus." Apa yang mereka rekomendasikan adalah pedoman yang mudah dipahami dengan sedikit peluang seseorang melakukan kesalahan, tetapi jelas tidak "praktis wajib".
Andrew Dalke

Saya setuju, dan saya mengatakan "file sumber" dengan sengaja. Sebenarnya, sistem CAIA sedikit mirip dengan Smalltalk: gambar ada dalam file data, dan "file sumber" CAIA yang saya sebutkan adalah file C yang dihasilkan. Namun, GCC MELT saya (cabang GCC, di bawah hak cipta FSF) juga diprogram secara meta, dan saya memang berhati-hati untuk menghasilkan komentar pemberitahuan hak cipta dalam file C yang dihasilkan (dan saya menempatkannya dalam kode C & MELT yang ditulis tangan).
Basile Starynkevitch

Poin yang diambil. Sekarang saya tahu satu paragraf tentang MELT. Secara umum yang terbaik adalah file yang dihasilkan menyertakan pemberitahuan hak cipta karena sangat sulit untuk "melampirkan" lisensi sebaliknya. Misalnya, "yacc" dan "lex" dibatasi dalam apa yang dapat mereka lakukan.
Andrew Dalke

1
Dari pengalaman pribadi: agar sebuah proyek diterima di Savannah Anda harus memiliki lisensi di setiap file.
Mael

1
Hanya untuk memperjelas, menurut FAQ GPL, #LicenseCopyOnly dan #NoticeInSourceFile pada saat penulisan ini, tidak perlu menyertakan teks Cara Mendaftar ... ke setiap file sumber; perhatikan bahasanya menggunakan "harus" dan bukan "harus". Namun, mereka sangat menyarankan Anda untuk mengikuti latihan ini.
ZeroKnight

37

Saya telah melihat banyak proyek yang hanya menyebutkan lisensi dalam README atau dalam file LICENSE atau COPYING.

Perangkat lunak Anda secara otomatis dilindungi oleh hak cipta, sebagaimana disepakati dalam hukum internasional. (Kecuali jika Anda bekerja untuk pemerintah AS atau organisasi lain di mana hak cipta tidak berlaku.)

Jika seseorang menggunakan perangkat lunak Anda maka mereka harus memastikan untuk mengikuti perjanjian lisensi, atau mengikuti pembatasan penggunaan yang adil pada apa yang dapat mereka lakukan.

Misalkan orang tersebut ingin menggunakan salah satu file dalam distribusi kode Anda, yang tentu saja memerlukan salinan dan karenanya hukum hak cipta berlaku. Secara default mereka TIDAK memiliki hak untuk menggunakan perangkat lunak Anda di bawah undang-undang hak cipta. Hanya ketika mereka tahu dan mengikuti batasan lisensi mereka diizinkan menggunakannya.

Jadi jika mereka menggunakan file tanpa lisensi perangkat lunak maka mereka melanggar hukum hak cipta. Karena semua lisensi mengatakan sesuatu seperti "Pemberitahuan hak cipta di atas dan pemberitahuan izin ini akan dimasukkan dalam semua salinan atau bagian substansial Perangkat Lunak", mereka diwajibkan untuk menempatkan lisensi itu di suatu tempat.

Itu bisa di file itu sendiri, atau ketika saya telah menggunakan kode sebagai perpustakaan saya menempatkan bagian yang relevan ke direktori sendiri dan menambahkan "README" atau "LICENSE" ke dalam subdirektori itu.

Singkatnya, Anda tidak perlu meletakkan lisensi di setiap file. Saya pikir itu berlebihan. Tidak ada perlindungan hukum tambahan untuk melakukannya. Memang membantu pengguna hilir agak, tetapi tidak banyak.

Saya pikir tradisi banyak metadata berbasis komentar (lisensi, tanggal pembuatan masing-masing fungsi, changelog, dll) adalah tradisi yang sangat lama yang ada karena mudah dilakukan dan yang lebih merupakan jimat daripada berguna.

Sebagai contoh, Eclipse template default menambahkan apa yang saya anggap sebagai metadata yang tidak berguna sebelum setiap fungsi, yang saya pikir jauh lebih baik ditangkap oleh kontrol versi. Tetapi praktik itu biasa terjadi di banyak toko.


2
Misalnya, saya tidak melihat apa pun yang terkait dengan lisensi di file sumber Rails sama sekali.
Anton Barkovsky

3
Dan dari 200 file di pustaka standar Python tingkat atas, hanya 34 yang berisi kata "hak cipta", dan hanya 4 di antaranya untuk Python Software Foundation, yang mengontrol hak cipta untuk Python.
Andrew Dalke

ya, saya tidak berpikir pemberitahuan hak cipta per file akan bertahan ... itu terlalu banyak .. itu tidak bisa menjadi cara masa depan .. pikirkan KERING ... LISENSI tingkat root, dan mari sebut itu sehari .. saya pikir sebagian besar segalanya di npm sudah melakukannya dengan cara ini
ChaseMoskal

13

Masalahnya adalah sangat mudah untuk memisahkan satu file kode sumber dari proyek yang lebih besar, seperti seseorang yang baru saja memeriksa, mengirim email, mengunduh satu file, tanpa sisanya yang berisi hak cipta penuh. Dan kemudian file itu dapat diteruskan ad-infinitum ke waktu, ke pihak ke-N yang mungkin tidak tahu asal file.

Pemberitahuan hak cipta di bagian atas mengingatkan siapa pun yang menemukan file tunggal yang sebenarnya berhak cipta, bukan domain publik, dan dengan demikian beberapa lisensi mungkin atau mungkin tidak terlibat dalam distribusi atau penggunaannya. Versus membiarkan pencari menemukan asumsi acak mereka sendiri.


21
Bukankah lebih mudah untuk dis-agregat melalui copy-paste berbagai fragmen file sumber juga? Lalu bagaimana? Argumen ini sepertinya tidak konsisten bagi saya.
Travis Griggs

10
Dengan asumsi domain publik untuk sebuah karya tanpa pemberitahuan hak cipta adalah masalahnya. Jika Anda menemukan file tanpa pemberitahuan hak cipta, maka Anda tidak boleh menyalinnya dan mengirimkannya ke orang lain.
Rich Remer

tentu saja kemudian ada masalah yang sah untuk "mengkloning dan memiliki" file, kami telah menempatkan open source ke repo proyek kami secara langsung karena kadang-kadang sulit untuk memperbaiki bug di luar proyek hulu, tetapi Anda tidak bisa menunggu mereka untuk melepaskan keduanya. Bukan mengatakan ini adalah ide yang bagus, tapi kami sudah melakukannya.
xenoterracide

8

Tidak ada pertemuan adikuasa rahasia di dalam bunker bawah tanah yang mengatakan apa yang harus Anda masukkan ke setiap file sumber.

Itu membuat jelas bagi pengguna bahwa file ini berada di bawah lisensi apa pun dan pada kenyataannya sebagian besar perangkat lunak GPL berisi basa-basi pendek yang mengatakan untuk membaca license.txt. Ingat proyek terbelah dan file dapat digunakan kembali sehingga hanya menempatkan pesan dalam satu file mungkin bukan ide yang baik.

Jika dalam hal yang tidak mungkin pernah pergi ke pengadilan Anda mungkin memiliki lebih banyak klaim jika Anda telah dengan jelas menandai setiap file sebagai karya Anda dan lisensi apa yang ada di bawahnya - maka tidak ada yang bisa mengklaim mereka berpikir bahwa file prticular ini tidak tercakup


6

Saya hampir memposting pertanyaan yang sangat mirip. Lebih sedikit tentang gangguan dan lebih banyak tentang masalah teknis. TL; DR: Saya yakin jawabannya adalah masalah prioritas penulis. Mungkin niat akan lebih akurat daripada prioritas ...

Saya yakin tidak apa-apa untuk referensi lisensi di sumber Anda, tergantung pada definisi Anda tentang "oke". Mari kita sepakat bahwa istilah "tanpa pendamping" menunjukkan file sumber yang merupakan bagian dari proyek yang telah dipisahkan dengan kejam dari basis kode yang penuh kasih. File tersebut berisi garis seperti ini:

# This file is covered by the LICENSING file in the root of this project.

Atau garis yang jauh lebih keren seperti ini:

* @license OMGBBQ <http://goodlics.com/bbq>

"Tapi tunggu!" , Anda berseru, "Anda baru saja mengatakan file itu terpisah dari proyeknya! Dan goodlics.com mengalihkan ke penghuni liar domain! Berhentilah menjadi trixy!" Anda benar, saya memang mengatakan itu, tapi itu mungkin baik-baik saja, dan berhenti berteriak kepada saya. Ini alasan saya bukan pengacara:

  • Hampir setiap negara telah menyetujui Konvensi Berne, yang AFAIK berarti bahwa jika Anda membuat sesuatu, Anda memiliki hak cipta atasnya, titik. Anda tidak memerlukan baris (c) atau omong kosong seperti itu, tetapi hal-hal itu (ditambah VCS pihak ketiga seperti GitHub) memang membuatnya lebih mudah untuk membuktikan bahwa Anda membuatnya dan kapan Anda membuatnya.
  • Karenanya, jika Anda memposting beberapa kode 1337 berair online yang Anda buat, Anda memiliki hak cipta di atasnya. Tidak ada yang diizinkan untuk menyalinnya. Ini jarang, dan mengejutkan, saya tahu, tetapi saya pernah mendengar bahwa orang kadang-kadang melanggar hukum. Itu masih mungkin.
  • nyancat-bcminer-algo.qbasicFile luar biasa yang Anda tulis dan diposting di LiveJournal adalah, percaya atau tidak, bukan domain publik. Tidak, kecuali Anda mengatakan itu domain publik. Secara default itu milik Anda dan milik Anda sendiri. Itu ... Berharga . (Setidaknya untuk 25-50 + tahun, kecuali Anda Disney.)
  • Orang-orang secara konvensional mengomunikasikan niat ini (membuat sebagian atau semua hak bukan milik Anda dan Anda sendiri) melalui lisensi, tetapi Anda harus mengumumkan niat itu; itu opt-in opt-out (HAHA DAPATKAN? Memilih untuk memilih keluar dari hak cipta Anda? LUAR BIASA). Dapatkan tiket Anda, kami hampir sampai!
  • Jika tidak apa - apa bahwa file-file pendamping yang disebutkan di atas adalah domain pribadi - yaitu, tidak dapat disalin secara hukum, maka menggunakan referensi yang berpotensi rusak sangat baik. Namun, jika tidak apa-apa , maka saya pikir Anda perlu memasukkan teks lisensi dalam setiap file sumber. Dengan begitu, file yang tidak disertai masih yakin akan dilisensikan seperti yang Anda inginkan sebelumnya . Ya, itu lebih baik.

Alasan ini membuat dua asumsi epik dan mungkin tidak valid:

  • Referensi lisensi "rusak" kembali pada perilaku default (hak cipta), yang mungkin bukan asumsi yang valid.
  • Situs yang Anda posting tidak memiliki semacam kebijakan pengiriman (seperti StackExchange) yang menjadikan semua domain publik.

Terima kasih telah mengendarai saluran udara monyet-otak.

Penafian: Ini logis bagi saya untuk saya 90% yakin bahwa saya 100% salah.


6

Ada perbedaan antara lisensi dan pembukaan .

Dalam beberapa proyek saya, saya menggunakan Lisensi Publik Umum GNU, Versi 3.0 . GNU GPL mengharuskan pembukaan pada setiap file kode sumber:

Pembukaan dan instruksi adalah bagian integral dari GPL GNU dan mungkin tidak dihilangkan.

Sumber: http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble

Jadi inilah yang saya lakukan:

1. Tambahkan License.txt

Untuk mengikuti aturan, saya menaruh LICENSE.txt di root repositori proyek saya. Ini juga disarankan oleh GitHub (lihat " Di mana lisensi tinggal" ).

2. Tambahkan pembukaan menggunakan lipatan otomatis

Selanjutnya saya menyertakan mukadimah GPL di atas setiap file kode sumber TETAPI agar tidak mengganggu saya sembunyikan di IDE. Sebagian besar IDE memiliki fitur untuk secara otomatis melipat blok kode. NetBeans memiliki dukungan untuk Custom Code Folding dan WebStorm juga mendukung komentar lipat .

Jadi begini tampilannya:

//<editor-fold desc="Preamble">
/*
 * Company Name
 * Copyright (C) 2016 Company Name
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * ...
 */
//</editor-fold>

console.log('Here is my licensed JavaScript code.');

Saya pikir ini adalah kompromi yang sangat baik antara kenyamanan dan keamanan hukum.

Jika Anda memiliki banyak proyek di mana Anda perlu menambahkan lisensi, maka http://www.addalicense.com/ mungkin bisa membantu.

Harap dicatat: Saran saya merujuk ke GPLv3. Jenis lisensi lain mungkin tidak memerlukan pembukaan.


7
«GNU GPL mengharuskan pembukaan pada setiap file kode sumber:» Tidak. Bagian yang Anda kutip hanya mencegah Anda menghapus pembukaan dari LICENSEfile, yaitu Anda tidak dapat mengubah teks GPL dengan menjatuhkannya.
Andrea Lazzarotto

6

Ada cara praktis lain yang belum disebutkan di sini.

SPDX-License-Identifiermenandai. https://spdx.org/using-spdx

Dengan menggunakannya, "boilerplate legal" Anda di setiap header file sumber berkurang menjadi hanya dua baris:

/* SPDX-License-Identifier: (GPLv3-or-later AND LGPL-2.0-only) WITH bison-exception */
/* Copyright © 1234 Project Author */

Lebih jauh, orang-orang yang mengotomatisasi analisis rantai pasokan perangkat lunak akan berterima kasih karena Anda berpegang pada standar umum deskripsi lisensi yang dapat dibaca mesin.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.