Saya sedang mengerjakan produk untuk klien yang harus valid dan sesuai untuk tujuan.
Itu dibangun di atas tumpukan LAMP (PHP / Cake), jadi ada lisensi GPL, MIT, PHP, APACHE:
DASAR "SEBAGAIMANA ADANYA", TANPA JAMINAN ATAU KONDISI APA PUN, baik tersurat maupun tersirat, termasuk, tanpa batasan, jaminan atau ketentuan TITLE, PELANGGARAN NON, PELANGGAN, ATAU KESESUAIAN UNTUK TUJUAN TERTENTU . Anda bertanggung jawab sepenuhnya untuk menentukan kelayakan menggunakan atau mendistribusikan kembali Karya dan menanggung segala risiko yang terkait dengan pelaksanaan izin Anda berdasarkan Lisensi ini.
Alasan saya bahwa produk saya valid dan sesuai untuk tujuan:
- Dokumen UAT yang ditandatangani membuktikan validitas dan kesesuaian untuk tujuan tertentu.
- Tumpukan ini sangat banyak digunakan oleh pengembang, industri dan pengguna akhir (netcraft, statistik gartner dll.), Sehingga ada konsensus yang cocok untuk tujuan ini. (yaitu kita dapat mengabaikan kesesuaian untuk pernyataan tujuan dalam penafian garansi sampai batas tertentu)
Apakah ini poin yang valid? Bisakah saya membuat klaim bahwa perangkat lunak saya sesuai untuk tujuan?
sumber
Jawaban:
Pertama-tama, seperti yang dikatakan orang lain, ada perbedaan antara perangkat lunak yang benar-benar berfungsi dengan perangkat lunak yang dijual dengan jaminan hukum bahwa perangkat itu berfungsi.
Teks disclaimer yang Anda kutip berarti bahwa pemberi lisensi asli tempat Anda mendapatkan perangkat lunak tidak memberikan jaminan apa pun. Anda dapat menawarkan perangkat lunak sendiri dengan jaminan terlampir. Penulis asli tidak menawarkan jaminan hukum bahwa perangkat lunak berfungsi, tetapi tidak ada alasan mengapa Anda tidak dapat membuat jaminan seperti itu kepada klien Anda. (Apakah Anda pikir itu ide yang baik untuk melampirkan jaminan hukum pada sesuatu yang tidak Anda tulis adalah masalah lain sepenuhnya.)
Secara khusus, bagian 4 dari GPL menyatakan:
Saya tidak yakin apakah lisensi harus memberi Anda kemampuan untuk menambahkan jaminan secara eksplisit (saya bukan pengacara, tapi saya pikir jawabannya tidak - intuisi saya adalah Anda harus dapat memberikan jaminan pada hampir apa pun yang Anda inginkan. ). Dalam kasus apa pun, GPL secara jelas menawarkan kepada Anda kemampuan untuk menambahkan jaminan Anda sendiri saat menyampaikan perangkat lunak kepada klien.
Saya tidak yakin tentang BSD, karena BSD mengharuskan Anda untuk mempertahankan penafian, tetapi mungkin Anda dapat menawarkan perlindungan garansi terlepas dari penafian dalam lisensi. Akibatnya, Anda mungkin berkata, "Saya menegaskan garansi bahwa pekerjaan ini secara keseluruhan cocok untuk beberapa tujuan (meskipun beberapa karya ini, pekerjaan yang lebih besar ini berasal dari tidak membawa garansi seperti itu)." Tentu saja selalu pastikan bahwa ketentuan garansi Anda tidak melanggar lisensi dari salah satu karya Anda yang disertakan.
Namun, sekali lagi, saya bukan pengacara, dan jika klien Anda telah meminta jaminan kesesuaian tujuan, dia mungkin mencari perlindungan hukum yang diperiksa. Anda harus berkonsultasi dengan pengacara untuk membuat konsep teks jaminan semacam itu.
sumber
Ini adalah penafian standar, yang sering diberikan untuk perangkat lunak, terutama perangkat lunak bebas.
Ini hanya berarti bahwa penyedia perangkat lunak tidak membuat jaminan tentang kesesuaian perangkat lunak. Dia mungkin sangat meyakinkan dirinya sendiri bahwa perangkat lunak itu baik untuk apa yang dilakukannya, tetapi dia tidak ingin memasuki ladang ranjau legal yang menjaminnya.
Hal yang sama berlaku untuk "konsensus": "Komunitas" (namun Anda ingin mendefinisikannya) mungkin setuju bahwa perangkat lunak tertentu sesuai untuk tujuan yang dinyatakan, tetapi mereka tidak akan memberi Anda jaminan.
Singkatnya: kecuali Anda membayar untuk itu, Anda tidak akan pernah membuat orang menjamin kebugaran apa pun. Dan bahkan jika Anda membayar seseorang, mereka mungkin tidak menjaminnya.
sumber
Saya pikir jawaban lain mencakup berbagai aspek dari pertanyaan Anda, tetapi saya tidak percaya mereka langsung menjawab pertanyaan Anda.
Ya , Anda dapat mengeluarkan jaminan untuk perangkat lunak yang Anda buat termasuk perangkat lunak dengan berbagai lisensi OSS yang Anda sebutkan.
Anda (dan perusahaan Anda) akan menjadi satu-satunya pemegang tanggung jawab yang dihasilkan oleh garansi itu. Dan itu semua garansi - itu adalah kewajiban. Anda menjamin bahwa Anda bertanggung jawab jika produk gagal berfungsi.
Anda tidak meminta untuk melakukan ini, tetapi Anda tidak boleh mendorong tanggung jawab itu kembali "up-stream" ke komponen / penerbit perangkat lunak lain yang Anda sebutkan karena mereka telah secara tegas menolak menerima pertanggungan tanggung jawab itu.
Apakah Anda mengeluarkan lisensi bersama dengan perangkat lunak adalah pertanyaan terkait tetapi ortogonal. Lisensi memberikan ketentuan penggunaan. Garansi menjamin tingkat fungsionalitas atau operasi. Saya akan merekomendasikan Anda melisensikan produk kepada klien Anda selain memberikan garansi yang mereka butuhkan. Memiliki lisensi membantu membatasi penerapan jaminan yang Anda berikan. Ini juga memungkinkan Anda untuk mengecualikan non-klien dari mencoba mengklaim dukungan garansi dari Anda.
Apa yang Anda gunakan untuk menentukan kebugaran adalah semata - mata kebijaksanaan Anda . Tergantung pada jumlah risiko yang bersedia diterima oleh organisasi Anda. Ini juga tergantung pada kerusakan yang mungkin Anda alami jika produk gagal dan klien Anda membuat klaim garansi terhadap Anda. UAT adalah pendekatan standar dan bisa menjadi cara yang bagus untuk mengidentifikasi kebugaran. Ini verifikasi positif untuk fungsionalitas yang diharapkan. Konsensus sedikit lebih rapuh karena Anda tidak tahu pasti bagaimana orang lain menggunakan komponen-komponen itu. Konsensus bagus untuk menghasilkan tingkat kepercayaan, tetapi tidak ada yang seketat yang ditentukan dan tes khusus yang memvalidasi fungsi yang diperlukan.
sumber
Saya telah mengerjakan proyek perangkat lunak medis, di mana kami berada di bawah peraturan yang sama, kami harus memverifikasi dan memvalidasi produk.
Dan kita bisa melakukan itu dan memenuhi persyaratan FDA.
Saya tidak mengambil bagian dalam validasi alat pihak ke-3 yang sebenarnya, tetapi sejauh yang saya bisa mengerti, apa yang harus kami lakukan adalah menentukan tujuan mana yang akan diberikan oleh perangkat lunak pihak ke-3 kepada kami. Kemudian kami harus memvalidasi produk-produk itu sendiri, artinya kami memvalidasi bahwa paket perangkat lunak pihak ke-3 yang dipilih memang sesuai dengan tujuan tersebut.
Sejauh yang saya mengerti, jenis validasi ini tidak harus proses yang panjang. Hanya semacam dokumen setengah halaman yang menjelaskan persyaratan dan bagaimana perangkat lunak itu memenuhi persyaratan itu.
Validasi ini akan untuk kedua komponen membangun ke dalam perangkat lunak yang sebenarnya, tetapi juga untuk lingkungan pengembangan, sistem kontrol sumber, dll.
Catatan: Ini didasarkan pada bagaimana saya memahami apa yang harus kita lakukan. Saya mungkin memiliki masalah salah paham. Dan perusahaan mungkin juga lebih berlebihan dalam proses validasi daripada yang sebenarnya diperlukan (saya merasa ini adalah kasus tertentu).
Tetapi perangkat lunak itu divalidasi.
Tetapi mengapa Anda membutuhkan produk yang divalidasi? Apakah Anda mengirim ke segmen yang diatur, misalnya medis atau keuangan. Atau apakah klien ISO 9001 (atau serupa) tersertifikasi? Jika demikian, Anda harus mempelajari persyaratan untuk jenis peraturan ini sendiri untuk mengetahui dengan tepat apa yang dibutuhkan.
sumber
Penafian lisensi GNU ada di sana sehingga, secara default, pengembang dilepaskan dari segala kewajiban yang timbul dari menjalankan perangkat lunak.
Bahkan jika Anda merasa bahwa programmer harus bertanggung jawab atas perangkat lunak yang buruk, kenyataannya adalah perangkat lunak itu gratis.
Penafian hanya mengatakan bahwa apa yang didistribusikan adalah perangkat lunak saja, bukan perlindungan garansi.
Model GNU untuk menghasilkan uang dari perangkat lunak adalah dengan menjual layanan, atau perlindungan garansi.
Garansi lebih dari sekadar pernyataan keyakinan bahwa produk tersebut sesuai untuk suatu tujuan. Pasti ada uang menungganginya. Paling tidak "uang kembali", atau lebih: kewajiban untuk melakukan pekerjaan untuk membawa produk ke kondisi sedemikian rupa sehingga sesuai untuk tujuan tertutup, atau bahkan untuk menutupi beberapa kerugian dan kerusakan.
Ada atau tidak adanya jaminan tidak mengubah apa produk itu ; itu hanya bentuk asuransi yang mengubah cara risiko didistribusikan antara vendor dan pelanggan.
Bisnis pemberian kewajiban atas perangkat lunak bebas ini sebenarnya cukup umum. Siapa pun yang bekerja secara komersial dengan perangkat lunak bebas biasanya akan menambalnya jika pelanggan memiliki masalah. Jika Anda membuat beberapa kotak perangkat keras yang menjalankan distro Linux tertanam di dalamnya, dan memiliki masalah karena bug di kernel, pustaka C atau di mana pun, Anda memperbaikinya untuk pelanggan. Situasinya adalah bahwa kotak Anda memiliki masalah, dan Anda berjanji kepada pelanggan sebuah kotak yang dapat diandalkan, 24/7.
sumber
Alasan Anda salah karena beberapa alasan:
Tidak ada dalam lisensi yang memberi Anda kemampuan untuk mengubah ketentuannya. Jika Anda menerima persyaratan lisensi dengan menggunakan karya tersebut, Anda terikat oleh segala sesuatu di dalamnya. Jika Anda tidak lagi menyukai persyaratan, Anda bebas untuk berhenti menggunakan perangkat lunak.
Tidak ada ketentuan dalam lisensi untuk adopsi luas dari pekerjaan yang mengubah persyaratan.
Tes penerimaan pengguna Anda tidak ada hubungannya dengan perjanjian yang Anda buat dengan pemberi lisensi. Jika Anda menjamin bahwa pilihan pekerjaan Anda untuk dimasukkan ke dalam produk Anda membuatnya cocok untuk tujuan pelanggan Anda, itu antara Anda dan pelanggan Anda. Pemberi lisensi adalah pihak ketiga yang tidak terlibat.
Kalimat setelah kalimat yang Anda tonjolkan ("Anda bertanggung jawab untuk menentukan ...") menempatkan konsekuensi karena menggunakannya tepat di pangkuan Anda.
sumber