Haruskah saya memasukkan diri saya sebagai penulis setelah memodifikasi kode pihak ketiga?


17

Ini adalah praktik umum untuk membuat beberapa tweak atau perbaikan dalam kode pihak ke-3 (baik itu intisari sederhana atau seluruh perpustakaan). Tapi itu juga umum bahwa banyak dari kode ini memiliki aturan lisensi mereka sendiri dan akhirnya header pada setiap file dengan informasi hak cipta.

Setelah melakukan modifikasi itu apa yang harus dilakukan selanjutnya? Biarkan informasi lisensi tidak tersentuh atau coba perbarui termasuk Anda dengan sesuatu seperti @authoratau @revisiontag?

Masalah umum lainnya adalah mengubah namespace / paket pihak ke-3 agar sesuai dengan konvensi proyek Anda. Beberapa jenis lisensi memasukkan jenis informasi ini dalam blok lisensi mereka, dapatkah saya mengubahnya secara bebas?

Saya tahu jawaban untuk pertanyaan ini tergantung pada masing-masing jenis lisensi, jadi untuk membuat pertanyaan saya lebih spesifik ...

Mempertimbangkan aturan lisensi umum (biasanya berbeda dalam aspek minor, kan?), Etis (atau setidaknya diizinkan) bahwa saya bebas menambahkan informasi ke blok lisensi tentang modifikasi saya dan mungkin juga memodifikasi bagaimana saya merujuknya dalam kode saya (mis. gunakan YACorp.YALibsebagai Utils.YALib)?


2
Tergantung pada lisensi dan praktik yang ditetapkan proyek. Beberapa proyek menghargai semua penulis dalam teks lisensi; yang lain menempatkan penulis di Github, dan merujuk proyek dengan nama dalam lisensi. Beberapa lisensi memerlukan atribusi, beberapa tidak.
Robert Harvey

@RobertHarvey Anda benar, tetapi saya mencoba mendefinisikan beberapa pedoman umum untuk situasi ini. Saya telah memperbarui pertanyaan.
kbtz

Hasil edit Anda terdengar seperti garpu. Jika Anda forking proyek, Anda dapat melakukan apa pun yang Anda inginkan (Anda memiliki garpu). Tapi saya tidak akan bermain-main dengan nama perpustakaan kecuali Anda memiliki proyek.
Robert Harvey


1
Pertanyaan ini tampaknya di luar topik karena menyangkut penegasan dan penetapan hak cipta. Pertanyaan hak cipta adalah pertanyaan hukum di luar keahlian komunitas dan tidak sesuai untuk situs. Pertanyaan ini sulit dijawab dengan benar karena ada terlalu banyak faktor yang terlibat seperti yurisdiksi lokal serta lisensi dan kepemilikan hak cipta dari program asli.

Jawaban:


9

Setelah melakukan modifikasi itu apa yang harus dilakukan selanjutnya? Biarkan informasi lisensi tidak tersentuh atau coba perbarui termasuk Anda dengan sesuatu seperti tag @author atau @revision?

Saya pikir Anda mengacaukan lisensi perangkat lunak dan prolog apa pun yang mungkin menjadi bagian dari perangkat lunak.

Lisensi adalah tempat pemilik hak cipta untuk program menentukan persyaratan penggunaan (lisensi) untuk orang lain. Beberapa lisensi sangat permisif, yang lain jauh lebih ketat.

Prolog adalah tempat penulis menyisipkan @authordan memberi @revisiontag untuk memberikan cara melacak perubahan pada kode sumber. Dalam beberapa kasus, menjadi penulis dari penambahan kode yang tidak sepele dapat memberikan Anda hak cipta atas bagian kode tersebut. Mengurai masalah hak cipta bisa sangat sulit dan paling baik ditangani oleh pengacara. Namun, Anda secara khusus menyatakan bahwa Anda tidak peduli dengan aspek itu jadi saya akan melanjutkan.

Masalah umum lainnya adalah mengubah namespace / paket pihak ke-3 agar sesuai dengan konvensi proyek Anda. Beberapa jenis lisensi memasukkan jenis informasi ini dalam blok lisensi mereka, dapatkah saya mengubahnya secara bebas?

Ini sangat tergantung pada konvensi proyek.

Jika Anda melakukan proyek, Anda dapat melakukan apa pun yang Anda inginkan.

Jika Anda berencana untuk menyumbangkan perubahan Anda kembali ke proyek, Anda harus tetap dengan konvensi yang didirikan. Jika ada alasan kuat untuk mengubah namespace maka Anda harus mempresentasikannya ke komunitas aplikasi.

Mempertimbangkan aturan lisensi umum (biasanya berbeda dalam aspek minor, bukan?)

etis (atau setidaknya diizinkan) bahwa saya bebas menambahkan informasi ke blok lisensi tentang modifikasi saya dan mungkin juga memodifikasi bagaimana saya merujuknya dalam kode saya (mis. gunakan YACorp.YALib sebagai Utils.YALib)?

Jangan mengubah lisensi!

Pertama, Anda mungkin tidak memiliki hak hukum untuk mengubah lisensi. Kedua, setiap perubahan yang Anda buat kemungkinan akan mengacaukan lisensi. Tinggalkan perubahan lisensi kepada pengacara.

Sejauh memperbarui prolog, itu tergantung pada norma-norma proyek. Beberapa proyek tidak menginginkan prolog karena mereka menggunakan kontrol sumber untuk melacaknya. Proyek lain melakukannya. Ikuti konvensi proyek.

Sebenarnya kekhawatiran saya lebih pada "rasa hormat kepada masyarakat" daripada aspek hukum, saya bertanya lebih banyak tentang seberapa banyak kita bisa "menjadi liar" tetap etis jika proyek kita dapat dianggap pribadi atau pribadi.

Jika Anda menyimpan perubahan untuk diri sendiri, mengapa Anda peduli dengan apa yang dipikirkan orang lain? Sesuatu yang Anda gunakan hanya untuk diri sendiri dan tidak pernah didistribusikan kepada orang lain tidak berdampak balik pada proyek asli. Jadi mereka tidak peduli apa yang Anda lakukan.

Jika Anda berencana mendistribusikan perubahan Anda atau berkontribusi kembali ke proyek, Anda perlu mengevaluasi konvensi proyek itu. Beberapa proyek tidak ingin bercabang dan akan memiliki lisensi untuk mencegahnya. Yang lain mengatakan "melakukan apa yang Anda inginkan" dan Anda diberi carte blanche untuk melakukan apa yang Anda inginkan. Pada akhirnya, jawabannya di sini tergantung pada proyek tertentu yang Anda lihat.


Seperti yang saya harapkan, jawabannya hampir jelas, tetapi itu melegakan melihat semua orang berbicara dalam pikiran mereka. Terima kasih atas semua jawabannya!
kbtz

Apakah proyek yang menerima kontribusi tetapi tidak mengizinkan forking benar-benar ada? Atau maksud Anda hal-hal seperti perpustakaan komersial yang juga datang dengan kode sumbernya?
svick

@svick - Keduanya akan berlaku dalam hal ini. Ada beberapa proyek open-source dekat yang (mencoba) mencegah garpu. Pikirkan proyek-proyek di mana mereka mencoba untuk memiliki kemampuan untuk komersial di beberapa titik di masa depan. Perpustakaan komersial yang ada akan mencegah percabangan dengan persyaratan lisensi.

@ GlenH7 Saya pikir proyek seperti itu (misalnya MySQL) biasanya mensyaratkan bahwa hak cipta dari kontribusi yang masuk ke versi resmi ditugaskan ke organisasi pemerintahan. Kemudian versi open source dirilis di bawah lisensi open-source yang umum (seperti GPL), tetapi mereka juga dapat memiliki versi open-source komersial. Tetapi itu tidak mencegah percabangan versi open-source (lihat MariaDB).
svick

5

Saya akan menambahkan komentar, sebagian untuk memberi sinyal kepada pembaca bahwa file tersebut bukan "vanilla", dengan tautan ke dokumentasi yang relevan atau sistem pelacakan masalah.

Sunting: Jadi situasi ini mengingatkan saya ketika sebuah paket distribusi Linux misalnya perpustakaan. Debian memiliki pedoman dan standar tentang bagaimana paket harus dibangun dan dinamai, yang bisa sangat bervariasi dari bagaimana perpustakaan biasanya didistribusikan sebelum dibangun.

Saya tidak berpikir Anda harus malu menamai / membangun / memodifikasi perpustakaan, karena saya kira Anda tidak akan membagikan hasilnya ke dunia yang lebih luas? Dalam hal ini saya akan menyertakan README bersama dengan sumber yang menjelaskan perubahan apa yang telah Anda buat dan mengapa. Misalnya README. $ {CompanyName} .changes


Saya akan melakukan sesuatu seperti ini juga, tetapi pertanyaan saya lebih pada apa yang dianggap benar dari sudut pandang bagian 3 dan / atau aturan lisensi umum.
kbtz

2

Anda harus berkonsultasi dengan aturan lisensi kode.

Secara umum, banyak aplikasi frontend open source (misalnya Firefox, OpenOffice) menganggap nama aplikasi dan logo mereka sebagai merek dagang; jadi jika Anda akan merilis versi modifikasi dari aplikasi Anda tidak akan dapat menggunakan merek dagang asli / pakaian perdagangan (dengan demikian IceWeasel, Torbrowser, LibreOffice).

Namun, sebagian besar perpustakaan pemrograman sering kurang peduli tentang merek dagang selama cukup jelas siapa yang melakukan apa (biasanya ini dapat ditemukan dari metadata kontrol versi).

Informasi penulis melayani dua tujuan:

  1. Memberi kredit pada saat jatuh tempo
  2. Memberi kesalahan di tempat yang pantas

Yang terakhir menjadi lebih penting karena perubahan Anda menjadi lebih besar. Informasi kepenulisan yang sebenarnya umumnya dapat ditemukan dalam kontrol versi, tetapi beberapa proyek secara resmi menghargai satu set penulis dalam file terpisah. Titik potong di mana orang akan dikreditkan secara formal bervariasi untuk setiap proyek, hubungi penulis asli jika ragu.

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.