Üçüncü taraf kodunu değiştirdikten sonra kendimi yazar olarak eklemeli miyim?


17

3. taraf kodunda bazı basit düzeltmeler veya düzeltmeler yapmak yaygın bir uygulamadır (basit bir öz veya tüm bir kütüphane olsun). Ancak, bu kodların çoğunun kendi lisanslama kurallarına ve sonunda her dosyada telif hakkı bilgileri içeren bir başlığa sahip olması da yaygındır.

Bu değişiklikleri yaptıktan sonra, bundan sonra yapılacak doğru şey nedir? Lisans bilgilerini dokunulmaz halde tutun veya kendiniz @authorveya @revisionetiketlerinizle birlikte dahil olmak üzere güncellemeye çalışın mı?

Başka bir yaygın sorun, üçüncü taraf ad alanını / paketini proje kurallarınıza uyacak şekilde değiştirmektir. Bazı lisans türleri bu tür bilgileri lisans bloklarına ekler, özgürce değiştirebilir miyim?

Bu soruların cevabının her lisans türüne bağlı olduğunu biliyorum, bu yüzden sorumu daha spesifik hale getirmek için ...

Genel lisans kurallarını (genellikle sağ, minör yönleriyle farklı?), Göz önünde özgürce etik (veya en azından izin) 'dir bilgi eklemek benim değişiklikler hakkında lisans bloğuna ve belki de ben bakın nasıl değiştirmek benim kodunda kendisine (örn kullanmak YACorp.YALibolarak Utils.YALib)?


2
Lisansa ve projenin yerleşik uygulamalarına bağlıdır. Bazı projeler lisans metnindeki tüm yazarlara kredi verir; diğerleri yazarları Github'a koyarlar ve lisansta projeye adlarıyla başvururlar. Bazı lisanslar ilişkilendirme gerektirir, bazıları gerektirmez.
Robert Harvey

@RobertHarvey Haklısınız, ancak bu durumlar için bazı genel yönergeler tanımlamaya çalışıyorum. Soruyu güncelledim.
kbtz

Düzenlemeniz çatal gibi geliyor . Projeyi çatallıyorsanız, istediğinizi yapabilirsiniz (çatalın sahibi sizsiniz). Ama projeye sahip olmadığınız sürece kütüphane isimleriyle dolaşmayacağım.
Robert Harvey


1
Bu soru konu dışı gibi görünüyor çünkü telif hakkı iddiası ve tahsisi ile ilgili. Telif hakkı soruları, topluluğun uzmanlığı dışındaki yasal sorulardır ve siteye yetersizdir. Bu sorunun doğru bir şekilde cevaplanması zordur çünkü yerel yargı yetkisinin yanı sıra orijinal programın lisanslama ve telif hakkı sahipliği gibi çok fazla faktör söz konusudur.

Yanıtlar:


9

Bu değişiklikleri yaptıktan sonra, bundan sonra yapılacak doğru şey nedir? Lisans bilgilerini dokunulmaz halde tutun veya kendiniz de dahil olmak üzere @hauthor veya @revision tags gibi bir şeyi güncellemeye çalışın.

Bence yazılım lisansını ve yazılımın bir parçası olabilecek herhangi bir önermeyi karıştırıyorsunuz.

Lisans, programın telif hakkı sahiplerinin diğer kişiler için kullanım koşullarını (lisans) belirttiği yerdir. Bazı lisanslar çok izin vericidir, diğerleri çok daha kısıtlayıcıdır.

Giriş, yazarların kaynak kodundaki değişiklikleri izlemek için bir yol sağlamak üzere etiket ekledikleri @authorve @revisionetiketledikleri yerdir . Bazı durumlarda, kod için önemsiz olmayan bir ekin yazarı olmak, kodun bu bölümü üzerinde telif hakkı talebinde bulunmanıza neden olabilir. Telif hakkı endişelerinin çözülmesi dikenli olabilir ve en iyi avukatlar tarafından ele alınır. Ancak, özellikle bu yönle ilgilenmediğinizi söylediniz, bu yüzden devam edeceğim.

Başka bir yaygın sorun, üçüncü taraf ad alanını / paketini proje kurallarınıza uyacak şekilde değiştirmektir. Bazı lisans türleri bu tür bilgileri lisans bloklarına ekler, özgürce değiştirebilir miyim?

Bu gerçekten projenin kurallarına bağlıdır.

Projeyi çatal yaparsanız, istediğinizi yapabilirsiniz.

Değişikliklerinizi projeye geri eklemeyi planlıyorsanız, belirlenen sözleşmeye bağlı kalmalısınız. Ad alanını değiştirmek için zorlayıcı bir neden varsa, bunu uygulamanın topluluğuna sunmanız gerekir.

Genel lisans kurallarını göz önünde bulundurursak (genellikle küçük yönlerden farklıdırlar, değil mi?),

değişikliklerim hakkında lisans bloğuna özgürce bilgi eklediğim ve belki de kodumda buna nasıl atıfta bulunacağımı değiştirdiğim etik (veya en azından izin verilir)?

Lisansı değiştirmeyin!

Öncelikle, lisansı değiştirmek için yasal haklarınız yoktur. İkinci olarak, yaptığınız değişiklikler büyük olasılıkla lisansı bozacaktır. Avukatlara lisans değişiklikleri bırakın.

Prologun güncellenmesi ile ilgili olarak proje normlarına bağlıdır. Bazı projeler prolog istemezler çünkü bunu izlemek için kaynak kontrolü kullanırlar. Diğer projeler. Projenin kurallarına uyun.

Aslında endişelerim, “topluma saygı” ile ilgili olarak hukuki yönlerden daha fazla, projemizin özel veya kişisel olarak kabul edilebildiği takdirde etik olarak ne kadar "vahşileşebileceğimizi" soruyorum.

Değişikliklerinizi kendinize saklıyorsanız, neden başkalarının ne düşündüğüne önem veriyorsunuz? Sadece kendiniz için kullandığınız ve başkalarına asla dağıtmadığınız bir şeyin orijinal proje üzerinde bir etkisi yoktur. Yani ne yaptığını umursamıyorlar.

Değişikliklerinizi dağıtmayı veya projeye geri eklemeyi planlıyorsanız, söz konusu projenin sözleşmelerini değerlendirmeniz gerekir. Bazı projeler çatallanmak istemez ve bunu önleyen bir lisansa sahiptir. Diğerleri "ne istersen yap" diyecek kadar ileri giderler ve size uygun gördüğünüz gibi carte blanche verilir. Sonuçta, buradaki cevap baktığınız projeye bağlıdır.


Beklediğim gibi, cevaplar neredeyse açık, ama herkesin akıllarını konuşan bir rahatlama oldu. Tüm cevaplar için teşekkürler!
kbtz

Katkı kabul eden ancak çatallamaya izin vermeyen projeler gerçekten var mı? Yoksa ticari kitaplıklar gibi kaynak kodları ile gelen şeyleri mi kastediyorsunuz?
svick

@svick - Bu durumda her ikisi de uygulanabilir. Çatalı önleyen (denemeye) bazı açık kaynak projeleri var. Gelecekte bir noktada ticari faaliyette bulunma yeteneğini korumaya çalıştıkları projeleri düşünün. Mevcut ticari kütüphaneler çatalları lisans koşullarına göre önleyecektir.

@ GlenH7 Bu tür projelerin (örn. MySQL) genellikle resmi sürüme giren katkıların telif hakkının yönetim kuruluşuna atanmasını gerektirdiğini düşündüm. Daha sonra açık kaynak sürümü, ortak bir açık kaynak lisansı (GPL gibi) altında yayınlanır, ancak ticari bir kapalı kaynak sürümüne de sahip olabilirler. Ancak bu, açık kaynaklı sürümün çatallarını engellemez (bkz. MariaDB).
svick

5

Kısmen bir okuyucuya dosyanın "vanilya" olmadığını, ilgili belgelere veya sorun izleme sistemine bağlantılar içeren bir sinyal vermek için bir yorum ekleyeceğim.

Düzenleme: Yani bu durum bana ne zaman bir Linux dağıtım paketleri örneğin bir kütüphane hatırlatıyor. Debian, paketlerin nasıl oluşturulacağı ve adlandırılacağı konusunda, kütüphanenin genellikle önceden oluşturulmuş dağıtım biçiminden çok farklı olabilecek kurallara ve standartlara sahiptir.

Bir kütüphaneyi adlandırmak / inşa etmek / değiştirmek konusunda utangaç olmanız gerektiğini düşünmüyorum, çünkü sonucu daha geniş dünyaya dağıtmayacağınızı tahmin ediyorum. Bu durumda, yaptığınız değişiklikleri ve nedenini açıklayan bir kaynak ile birlikte bir README ekleyeceğim. Örneğin, README. $ {CompanyName} .changes


Ben de böyle bir şey yapardım ama sorum 3. bölüm bakış açısından ve / veya genel lisanslama kuralları açısından neyin doğru olduğu hakkında daha fazla endişe duyuyorum.
kbtz

2

Kodun lisanslama kuralına başvurmanız gerekir.

Genel olarak, birçok açık kaynaklı ön uç uygulaması (örn. Firefox, OpenOffice) uygulama adını ve logosunu ticari marka olarak görür; böylece uygulamanın değiştirilmiş bir sürümünü yayınlayacak olsaydınız, orijinal ticari markaları / ticari elbiseyi (dolayısıyla IceWeasel, Torbrowser, LibreOffice) kullanamazsınız.

Bununla birlikte, çoğu programlama kütüphanesi, kimin ne yaptığını oldukça açık olduğu sürece genellikle ticari markalar hakkında daha az endişe duyar (genellikle bu, sürüm kontrolü meta verilerinden bulunabilir).

Yazar bilgileri iki amaca hizmet eder:

  1. Vadesi geldiğinde kredi vermek
  2. Hak ettiği yere suçlama

İkincisi, değişiklikleriniz büyüdükçe daha önemli hale gelir. Gerçek yazarlık bilgileri genellikle sürüm kontrolünde bulunabilir, ancak bazı projeler resmi olarak bir dizi yazarın ayrı bir dosyada kredilendirilmesini sağlar. İnsanların resmi olarak kredilendirileceği kesinti noktası her proje için değişir, şüpheniz varsa orijinal yazarlarla iletişime geçin.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.