Linus´dan SCO´ya cevap!

0
sundance
SCO´nun iddiaları üzerine son yapılan röportajında Linus Tornvalds, iddiaları yanıtlarken, durumun çok güzel bir resmini çiziyor. Her zamanki sade akılcı üslubu ile duruma açıklık getiriyor.

Fakat bence daha bile önemlisi, email ya da ICQ başına geçtiğinde canavar dönüşen birçok Internet kullanıcısına problemlerin bu şekilde çözülmediğini anlatan bilgece bir yol göstermesi.
Linus Tornvalds: SCO "Sadece fazlasıyla hatalı"
Linux hareketini başlatan, Linus Tornvalds, SCO'nun "köşeye sıkıştırılmış fare" misali yaptığı fikri mülk (intellectual property*) ithamlarını değerlendirdi.
(*cevirenin notu: şahsi fikrime göre intellectual property kavramı, koskocaman bir dangalaklık olup, sadece ve sadece şirketlerin insanları biraz daha sömürmesine yönelik bir kavram olduğundan, bunu aynı derecede uydurmasyon fikri mülk kavramına çevirmekte bir sakınca görmedim.)

S: SCO, şu anda kendisine ait olan eski Unix dosyalarının Linux'un içinde bulunduğunu iddia ediyor. Lütfen siz bunun nesinin yanlış olduğunu bize izah edebilir misiniz ?

C: [SCO'nun kendisine ait olduğunu iddia ettiği dosyalar] Linux için sıfırdan yazılmışlardır. Bunun yanında SCO, BSD kodu üzerinde [Berkeley Üniversitesi'nde geliştirilen ve SCO'a ait telif hakları içeren yazılımların Linux'a aktarıldığı iddiası var] SCO'nun bir hakkı olmadığı gibi, bu dosyalar [SCO'nun Unix versionunda] bulunmamaktadırlar. Bu sebeplerle SCO hatalıdır.

SCO'nun birçok defalar tekrarladığı iddiasına göre, telif haklarından bahseden ifadeler koddan çıkartılmıştır. Kayıtlara geçmesi için belirtiyorum: Orjinal Unix kodlarında, bu şekilde çıkartılabilecek bir telif hakları ibaresi yoktur. Bunlar bir dava sonucunda [Berkeley geliştiricileri ve AT&T arasında gerçekleştirilen ve uzlaşmaya varılmış bir dava] konulmuşlardır. Bu sebeple SCO tekrar hatalıdır.

Temel olarak SCO'nun argümanları mantıklı olarak tartışılamayacak derecede hatalıdırlar. SCO bahsettiği dosyalar üzerinde telif haklarına sahip değildir -bu haklar Berkeley'deki California Üniversitesi'ne aittir. Fakat eğer bu haklara sahip olsaydı bile Linux kodları bu dosyalardan kopyalanmadığı için yine hatalı olacaklardı. Ve eğer kopyalanmış olsalardı, bu sefer de herhangibir telif ibaresi olmadığından -ve olmayan bu ifadeler koddan çıkartılamayacağından- yine hatalı olacaklardı. Yani, SCO argümanlarının hemen her katmanında hatalıdır. Ve eğer SCO'nun haklı olacağı alternatif bir evrende yaşıyor bile olsaydık, SCO haksız olacaktı.

S: Aslında, geçenlerde okuduğum bir röportajda sözkonusu dosyaların oluşturulması konusunda kendinizi eleştirdiğinizi gördüm. Bunun sebebi nedir ?

C: Telif haklarına sahip olduklarını iddia ettikleri bazı dosyaları kontrol etmek için arşivleri taradım ve oniki yıl geriye gittim, bu dosyaların orjinal hallerini buldum ve işin doğrusu, 91'de üniversitede genç bir öğrenciydim ve şu anda kesinlikle yapmayacağım bazı hataları yapmıştım ki bunlar yeni başlayan bir programcının tipik hatalarıydı.

Ve bu hatalar sözkonusu kodun kopyalanmadığının belki de en güçlü delilleri --eski zamanlarda harita yapanların, eserlerinin kopyalanmamasını sağlamak için bilerek küçük hatalar yapması gibi bir şey bu. Eğer bir başkası bu haritayı kopyalayıp kendi yaptığını iddia ederse, hatayı gösterip "madem öyle nasıl oluyorda aynı hata senin haritanda da var" diyorlardı.

Öte yandan kesinlikle söyleyebilirim ki bu hataları ben isteyerek yapmadım. Helsinki Üniversitesi'nde okuyan genç bir öğrenci olarak kesinlikle oniki yıl sonra bir şirketin çıkıp yazdığım kodun kendilerine ait olduğunu iddia edeceğini düşünerek böyle bir şey yapacak öngörüye sahip değildim. Zaten bu tür güçlerim olsa programcılığa girmez borsa oynardım.

S: Peki, herhangi bir telif hakkı ya da patent kapsamındaki Unix kodunun Linux'un koduna karıştığını düşünüyor musunuz ?

C: Açıkcası böyle bir şey olduğunu çok sanmıyorum. Şu anda bir miktar kişi hem Unix hem de Linux kodlarına erişebilmekte ve bunlar benzerlikleri bulmak üzere çeşitli programlar yazmış durumdalar. Şu ana kadar bulunan tek şey [Silicon Graphics, SGI]'a ait olduğu şüpheli 30 satır kadar bir kod parçası ki bu da çoktan kodddan çıkartılmış durumda. SGI bu konuda hata yaptıklarını belirten bir açık mektubu da bu olayın akabinde yayınladı, Internet'te ararsanız bulabilirsiniz.

Patentli algoritmalara gelirsek, evet bunun birkaç örneği var açıkcası. IBM mesela bunların bir kısmını Linux'a lisansladı. Zaten bu olmasa bu kodu kabul de edemezdik. SCO ise bu patentlerin hiçbirine sahip değil, dolayısıyla bu konuda bir mülkiyet iddia edemezler.

S: Eğer Linux içinde böyle bir kod varsa, bu problemin çözümü var mıdır ?

C: Bu tür bir problemin çözümü basitçe sözkonusu materyali lisanslamak ya da kullanmamaktır. Bu kadar basit.

Böyle bir şey gerçekleşirse tabi ki bizim yapacağımız bu kodu çıkartmak olacaktır. Fakat SCO bu konuda da (söz konusu kodun akıbeti) çok saldırgan yaklaşmıştır. Herkese tekrar tekrar söylediğimiz gibi, SCO basitçe birilerinin SCO'ya ait kodu Linux'a eklediğini gösterdiği takdirde biz bu kodu çıkartırız. SCO'nun tek yapması gereken bunu talep etmekti.

Tabi ki bu senaryolar SCO'nun iddialarının geçerli olduğu varsayımına dayalıdır. SCO için çok daha temel bir mevzu vardır. İddialarının geçerliliği her zaman tartışma konusu olmuştur, hatta bu Novell SCO'nun Unix telif haklarına sahip olmadığını iddia etmesinden önce bile böyleydi.

Bu iddialar tartışmaya açıktır, çünkü daha kopyalandığı iddia edilen koda dair bir kanıt ortaya sunmamışlardır. Bu, benim sizin Business Week için yazdığınız bir makale üzerinde hak iddia etmem, fakat hangi makalenin hangi kısmını kastettiğimi söyleyeyemem gibi bir şey. Novell'in SCO'nun Unix'in telif haklarına sahip olmadığını (sadece Unix'in kaynak koduna sahip olduğunu) belirtmesi ise durumu daha da tartışmaya açmakta.

S: SCO'nun IBM'e karşı açtığı dava ve IBM müşterilerine karşı tehditleri konusunda ne diyorsunuz ?

C: Açıkcası bu konuda çok da düşünmüyorum. Ama kesin olan bir şey dikkatli olmamız gerektiğidir. Birleşik Devletler'deki herhangibir şirket yasal iddialar karşısında dikkatli olmak zorundadır, bu iddialar geçerli olsun olmasın.

Bu yüzden bunları gözardı ettiğimi söyleyemem. Fakat bu meseleyi toptan olarak SCO tarafından yürütülen bir çeşit "troll ağı ile balık avlama" yöntemine benzetiyorum. Ve şu anda geri de çekilemiyorlar, çünkü bu ilk aşamada ellerinde hiçbir şey olmadığını ispatlamış olacak.

Kaybedecek bir şeyi olmama durumu oldukça kötü bir durumdur. Şu anda köşeye sıkışmış bir fare gibiler ve şahsen tehlikeli olduklarını da düşünüyorum, çok yakınların gitmek istemezdim.

S: Motivasyonlarının kaynağının ne olduğunu düşünüyorsunuz ?

C: IBM'le birlikte yürüttükleri Monterey projesinin durdurulması hakkında kötü düşünceleri olduğunu sanıyorum. Bu SCO için çok önemli bir projeydi ve bu durumu hazmetmekte zorlandılar. Aslında projenin bir yere gidemeyeceği uzun süreden belliydi, IBM'in bunu devam ettirmeye çalışması delilik olacaktı.

Dolayısıyla IBM'e bu konuyla ilgili kızgınlığı olan, gün geçtikçe pazar payını kaybetmekte olan bir firma düşünün ve bunu daha önce benzer yasal mücadelelere girmiş açgözlü bir yeni genel müdür ile birleştirin, nedir sonuç ?

S: Bunu yıllardır geliştirdiğiniz bir şeye karşı kişisel bir saldırı olarak görüyor musunuz ?

C: Açıkcası evet görüyorum ve hayır görmüyorum. Arada sırada çok rahatsız olduğum oluyor; SCO orjinal olarak benim yazdığım ve on yılı aşkın süredir geliştirdiğim bir kod hakkında yeni ve tamamen saçmasapan bir iddiada daha bulundukça. Ve bu işin yaklaşık sekiz aydır devam ediyor olmasından da rahatsızlık duyuyorum.

Öte yandan oniki yılı aşkın bir süredir bu konudaki bütün çalışmalarımı Internet üzerinden yapmaktayım ve işin aslı bu süre içinde kendi kendime gülebilecek kadar kalın bir koruma geliştirmemiş olsaydım zaten çoktan bırakmıştım bunları.

Söylemek istediğim, yeri geldiğinde bir adım geriye çekilip kendi tepkilerimi tarafsızca değerlendirmek konusunda bayağı iyi bir hale geldim -ya da öyle sanıyorum. Bu sadece beni sakinleştirmekle kalmıyor, aynı zamanda durumu anlamamı da sağlıyor: Bu dava mesela bu mevzuların nasıl da kişisel bir hal alabileceğini ve bunlara çok ters tepkiler verebileceğinizi öğretti bana.

Yani, mailları gözden geçirirken hala sinirlenebiliyorum, fakat aynı zamanda ilginç bir tecrübe de oluyor. Başka insanlara çok tavsiye edebileceğim türden bir şey değil ama samimi söylemek gerekirse bunun Linux hakkında açılacak son dava olmadığını düşünüyorum. Bu dişçide olup o rahatsız edici matkap sesini düşünmek yerine, matkabı elinde tutan adamın hislerini anlamaya benziyor.

Durumu daha iyi hale getirmiyor belki ama bundan alınabilecek dersler var. İşlerin nasıl yürüdüğünü anlayabilir ve kendinizi stresli durumlar karşısında hazır tutabilirsiniz ki bence bunlar çok önemli şeyler, diye düşünüyorum.

S: Sonuç olarak SCO'ya elinizdeki dökümanları teslim ettiniz mi ?

C: Hayır, onlar ayı ve güneşi istiyorlar -tonlarca email aldım- ve istedikleri bilgi konusunda da otomatik bir tarama yapmamı sağlayacak bilgileri iletmediler. Bu yüzden avukatlar iki tarafın da üstünde anlaşabileceği otomatik bazı arama kriterleri üzerinde mütabakata varmak istiyorlar. Sonuçta elimdekileri dökümanları isteyecekler büyük ihtimalle ve bu da basitçe birsürü email demek.

E-maillarımı topluma açmak konusunda bir çekincem yok -zaten çoğu Internet'te açık. Fakat bunun hepsini de vermek istemem, kişisel dökümanlar olabilir, ya da SCO ile alakası olmayan diğer şeyler. Bunlardan çok fazla bulunduğu için bunları teker teker okumam da mümkün değil. Bu iş için bazı araçlar yazdım ama bana arayabileceğim kriterleri vermeleri lazım.

Çeviren: KIVILCIM Hindistan
www.fazlamesai.net/sundance

Görüşler

0
yalcink01
Torvalds, SCO konusunda kesinlikle haklı. Bu heriflerden bi halt olmaz, iddialarından da hiç bir şey çıkması mümkün değil. Arkalarına, muhtemelen Microsoft desteğini almış kendi çaplarında eğleniyorlar. Bence de bu son saldırı olmayacak. Ucunda para görününce, insanlar düne kadar saygı duydukları şeylere karşı, yırtıcı bir hayvana dönüşebiliyorlar. Bu dün de böyle idi, yarın da böyle böyle olacak. Bizler kendi işimize baktığımız sürece, SCO gibi binlercesi gelse de, hiçbir şeyi değiştiremezler.

Ayrıca şu fikir sahipliği saçmalığına oldukça uygun bir karşılık bulmuşsun. Yarın gidip, fikrime tapu alayımda, araya kaynamasın :)
fikri mülk: 12 şiddetindeki depremde bile yıkılmayan mülk
0
bahadirkandemir
"şu anda geri de çekilemiyorlar, çünkü bu ilk aşamada ellerinde hiçbir şey olmadığını ispatlamış olacak."


En sevdiğim bölüm burası :)
0
malkocoglu
Linus Torvalds dogru bildigini cok direk soylemesi ile bilinir. Asagidaki e-posta mesaji da buna ornek.
-----------------------------

Asağıdaki konuşma, bir İnternet tartışma forum'undan alınmıştır.


TIGRAN


....Bütün bu bilgiler icin teşekkürler. Acaba Linus (Torvalds) bu konu hakkında ne düşünüyor? Bir süre önceki fikrini hatırlıyorum, ama belki değişmiştir. Yani, fikir değistirmek normal, ve kdb programı artık bayağı iyi durumda, acaba Linus bunlara bakınca, kdb programını Linux ana dağıtımına dahil edemez mi?


LINUS


Hatâbul yazılımlarını sevmem. Hiç bir zaman hoşuma gitmedi, herhalde böyle devam edecek. GDB programını kullanırım, hatâbul olarak değil ama, disassembler olarak.


Çekirdek (kernel) hatâbul'larını savunmak icin söylenenler beni az bile olsun etkilemedi. Emin olun, savunmaların çoğunu da duydum. Sonuçta söylenenleri şu kelimeye indirgeyebiliriz.


Hatâbul varsa, geliştirme yapmak rahatlar, ve yeni özellikler eklemek kolaylaşır.


Açık olayım, umrumda değil. Çekirdek kod yazmak "kolay" bir şey olmamalı. Satırları teker teker takip edip, program çalışmasını anında izlemeyerek hata bulma işlemini desteklemiyorum. Çekirdek içini en ince detayda görebilmemiz (hatâbul sayesinde) bence o kadar da iyi bir şey değil.


Güya, karşı destekçilere göre, eğer hatâbul yazılımı yoksa başımıza şunlar gelecekmiş.


* Bir hata olunca her sey çöküyor, fsck programını kullanıyorsunuz ve cok uzun zaman alıyor, bu da programcının moralini bozuyor.



* Hatâbul olmayınca, programcılar Linux çekirdek projesinden vageçiyorlar, çünkü işleri zorlaşıyor ve zaman alıyor.


* Yeni özellikler eklemek zaman alıyor.


Fakat bütün bunların nesi kötü?


Bana göre, durum hata değil, istenen özellik. Hem belgelenmiş, hem de boyle olması iyi, o zaman duruma hata diyemeyiz.


Özellikle, "yeni özellik eklemek zaman alıyor" düşüncesi, hatâbul kullanmak için hiç geçerli değil. Sanki özellik azalsa, bu Linux icin (ya da bütün yazılım sektörü için) bir problem olacak. Tam tersi. Benim en büyük işlerimden biri Linux icin yazılan yeni özelliklere 'hayır' demek, arayıpda bulmak değil.


Oh tabii, "ama her şey çöktü ve fsck komutunu kullandım, ve sonuç olarak hic yardım edecek bir ipucu vermedi, moralim bozuldu". Ne yapayım? Bu olana iki turlu karşılık verirsin. Ya daha dikkatli olmaya başlarsın, ya da çekirdek hatâbul programı istiyorum diye ağlarsın.


Açıkcası, dikkatli olmayanları bu şekilde önceden elemek bence iyi. Bu kulağa hissiz gelebilir, ne yazık ki öyle. Ve hani, 'Eğer sıcağa gelemiyorsan mutfaktan çıkarsın' seviyesinde bile değil. Daha da derin. Yazılım dünyasinda Darwin Kanunu'ndan bahsediyorum.
"Dünyada iki türlü programcı var" demek cok soğuk ve hissiz. Ama öyle ve ben ikinci tür ile çalışmayı tercih ederim. Alışın.


Ben kötü bir adamım. Linux dünyasi niye bazen tersini düşünüyor anlamıyorum. İnsanlar beni iyi zannediyor, fakat ben, sinsi ve plancı bir adamım; Eğer bana göre daha güzel bir Linux ortaya çıkacaksa, kaybedilen ve kırılmış kalpler beni zerre kadar ilgilendirmiyor.


Bunu öylesine de soylemiyorum. Hakikaten iyi bir adam değilim. İçimden gelerek ve yüzümü bozmadan "umrumda degil" diyebilirim.


Benim düşünceme göre, çekirdek hatâbul olmaması, programcıları otomatik olarak sorunlar hakkında değişik "seviyede" görmeye sevkedecek. Hatâbul yoksa, "nasıl çalıştığını anlayım, sonra tamir etmeye baslarım" düşüncesine girmezsiniz. Daha değisik şekilde düşünmelisiniz. Herşeyi daha başka seviyede görmek isteyeceksiniz.


Bir bakıma "kaynak kod, işler kod" ayırımı bu, daha bile fazlası... Kaynak koda bakmak değil, (tabii ki arada bakacaksınız, bütün en basit hatâbul bunu sağlardı zaten), ama kaynak kodun üst seviyesine bakacaksınız. Kavramların "anlamına" geleceksiniz. Yani, hatâbul olmazsa, üst seviyeye atlayıp programin genel olarak ne yapmaya uğraştığını anlamak isteyeceksiniz, tek bir satırın ne yaptığını değil.


Zaten 'önemli' hataların coğunda hatâbul programlarının faydası olması çok zor. Önemsiz aptalca hatalar da var tabii, geçende olan truncate() hatası gibi mesela... Beni ilgilendiren 'önemli' hatalar. Gerisi detay. Eninde sonunda tamir olurlar nasıl olsa.
Başkalarının aynı fikirde olmadığının farkındayım. Ben kimsenin annesi değilim, eğer hatâbul kullanmak isterseniz kullanırsınız, "lekelendiniz" diye düşünüp size arkamı dönecek falan değilim. Sadece, bu programları kullanmak konusunda benden yardım beklemeyin. Tercihim, programcıların hatâbul kullanmayı azaltması. O yüzden, bu yazılımlar Linux ana dağıtımın parcası olmayacak. Ayrıca revaçta olan programlar ismen bilinmiyorsa, ya da yokolurlar ise arkasından ağlayacağımı zannetmiyorum.


Linus Torvalds
0
FZ
Şahsen ``debugger´´ kullanmayı, kullanmamaya bin kat tercih ederim :) Allahıma çok şükür çekirdek programlama gibi saç ağartıcı, uykusuz bırakıcı bir işle uğraşmıyorum, normal, sıradan bir faniyim, web programlama, veritabanı programlama falan yapıyorum :)
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Slackware 11.0 duyuruldu!

anonim

Bir yıldan daha uzun süredir beklenen ve yaşayan Linux dağıtımları arasında en eskisi -bir grup Linux kullanıcısına göre de en iyisi- olan Slackware Linux'un 11.0 sürümü duyuruldu. Ayrıntılar www.slackware.com adresinden öğrenilebilir.

Vector Linux-3.2 Çıktı

ersan

Vector Linux 3.2 bir kaç gün önce duyuruldu: 2.4.20 kernel, Glibc-2.2.5, Opera-6.11, Dillo-0.6.6 ve daha bir çok program ile eskisi gibi yine çok hızlı.

Gentoo Türkiye

pinhanarch

Gentoo Türkiye sitesi, Gentoo'nun haftalık bülteninde duyuruldu. Umarız katılımı ve devamlılığı sürekli olur.

Gentoo Türkiye : http://www.gentoo-tr.org/

Haber kaynağı: http://www.gentoo.org/news/en/gwn/20041129-newsletter.xml

Hata Toleranslı Shell

lifesdkver0_1

ftsh (Fault Tolerant Shell), kabuk programlamaya hata merkezli bir bakış açısı getiren; basit bir scripting dili. Temelde yaptığı işi, bir scripting diline try - catch bloğu koyulmuş gibi oluşabilecek muhtemel hatayı kontrol altında tutup işleyişi ona göre devam ettirmek.

HP: GNU/Linux olduğundan düşük gösteriliyor

cihatix

Açık kaynağı destekleyen şirketlerden HP’nin üst düzey bir yöneticisi, istatistik şirketlerinin geri kalmış ölçüm yöntemleri nedeniyle GNU/Linux’un yaygınlığını olduğundan aşağıda gösterdiklerini öne sürdü.