The translation is temporarily closed for contributions due to maintenance, please come back later.
Context English Turkish (tr_TR) State
Unix author Ken Thompson returned to his alma mater, University of California Berkeley (UCB), in 1975 and taught the kernel line-by-line. This ultimately resulted in an evolving system known as BSD (Berkeley Standard Distribution). UCB converted Unix to 32-bits, added virtual memory, and implemented the version of the TCP/IP stack upon which the Internet was essentially built. UCB made BSD available for the cost of media, under what became known as <quote>the BSD license</quote>. A customer purchased Unix from AT&amp;T and then ordered a BSD tape from UCB. Unix yazarı Ken Thompson 1975 yılında California Berkeley Üniversitesi'ne (UCB) geri döndü ve çekirdeği satır satır öğretti. Sonuç olarak BSD (Berkeley Standart Dağıtım) olarak bilinen gelişmekte olan bir sistem ortaya çıktı. UCB, Unix’i 32 bit’e dönüştürdü, sanal bellek ekledi ve internet temelini oluşturan TCP/IP ek bellek sürümünü uyguladı. UCB, BSD’i BSD lisansı </quote> adı altında <quote> medya maliyeti için kullanılabilir hale getirdi. Bir müşteri AT&amp;T’ den Unix satın aldı ve sonra UCB’ den BSD bandı şipariş etti.
A lengthy series of articles published slightly later in Dr. Dobbs magazine described a BSD-derived 386 PC version of Unix, with BSD-licensed replacement files for the 6 missing 4.4 lite files. This system, named 386BSD, was due to ex-UCB programmer William Jolitz. It became the original basis of all the PC BSDs in use today. Dr. Dobbs dergisinde biraz sonra yayınlanan uzun bir makale serisi, Unix'in BSD'den üretilen 386 PC versiyonunu ve 6 eksik 4.4 lite dosyası için BSD lisanslı yedek dosyaların tanımını yaptı. 386BSD adlı bu sistem, eski UCB programcısı William Jolitz tarafından yapıldı. 386BSD, bugün kullanılan tüm PC BSD'lerinin temeli haline geldi.
The GPL was designed to be the antithesis of the standard proprietary license. To this end, any modifications that were made to a GPL program were required to be given back to the GPL community (by requiring that the source of the program be available to the user) and any program that used or linked to GPL code was required to be under the GPL. The GPL was intended to keep software from becoming proprietary. As the last paragraph of the GPL states: GPL, standart tescilli lisansın karşısavı olacak şekilde tasarlanmıştır. Bu düşünce ile, GPL’de yapılacak olan değişikler , GPL Topluluğuna ( Programın kullanıcılar tarafından kullanılabilir olması gerektirdiği için) verilir ve bağlanan veya kullanılan herhangi bir program GPL kodu adı altında kullanılmalıdır.GPL, yazılımın kişiye özel olmaması için tasarlanmıştır. GPL’ nin son paragrafında bu durum belirtilmiştir:
The <link xlink:href="http://www.opensource.org/licenses/gpl-license.php">GPL</link> is a complex license so here are some rules of thumb when using the GPL: <link xlink:href="http://www.opensource.org/licenses/gpl-license.php">GPL</link> linki karmaşık bir link olduğundan GKL (Genel Kamu Lisansı) kullanımı için işte birkaç pratik kural:
you can charge as much as you want for distributing, supporting, or documenting the software, but you cannot sell the software itself. <link xlink:href="http://www.opensource.org/licenses/gpl-license.php">GPL</link> linki karmaşık bir link olduğundan GKL (Genel Kamu Lisansı) kullanımı için işte birkaç pratik kural:
One of the serious problems associated with proprietary software is known as <quote>orphaning</quote>. This occurs when a single business failure or change in a product strategy causes a huge pyramid of dependent systems and companies to fail for reasons beyond their control. Decades of experience have shown that the momentary size or success of a software supplier is no guarantee that their software will remain available, as current market conditions and strategies can change rapidly. Tescilli yazılımla ilgili ciddi sorunlardan biri de "orphaning" olarak bilinir. Bu durum, bir ticari başarısızlığın veya ürün stratejisindeki bir değişikliğin, birbirine bağlı sistem ve şirketlerden oluşan büyük bir piramidin kontrolleri dışındaki nedenlerden dolayı başarısız olmasına sebep olduğunda ortaya çıkar. Onlarca yıllık deneyim, bir yazılım tedarikçisinin anlık büyüklüğünün veya başarısının, mevcut piyasa koşulları ve stratejileri hızla değişebileceğinden ötürü, yazılımlarının mevcut halde kalacağının garantisi olmadığını göstermiştir.