The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

(itstool) path: sect1/para
English
A common reason to use the GPL is when modifying or extending the gcc compiler. This is particularly apt when working with one-off specialty CPUs in environments where all software costs are likely to be considered overhead, with minimal expectations that others will use the resulting compiler.
0/2950 · 295
Context English Turkish (tr_TR) State
since the Linux kernel is under the GPL, any code statically linked with the Linux kernel must be GPLed. This requirement can be circumvented by dynamically linking loadable kernel modules. This permits companies to distribute binary drivers, but often has the disadvantage that they will only work for particular versions of the Linux kernel. Linux çekirdeği GPL (Genel Kamu Lisansı) kontrolünde olduğundan beri, Linux çekirdeği ile statik olarak bağlı olan kodlar GPL'ye dönüştürülmelidir. Bu gereksinim yüklenebilir çekirdek modüllerini dinamik olarak bağlayarak önlenebilir. Bu, şirketlerin ikili sürücülerini dağıtmasına izin verir ama sadece Linux çekirdeğinin belirli sürümlerinde çalıştığından çoğu kez dezavantaj sağlar.
Due in part to its complexity, in many parts of the world today the legalities of the GPL are being ignored in regard to Linux and related software. The long-term ramifications of this are unclear. Kısmen karmaşıklığından ötürü, bugün dünyanın birçok yerinde, GPL'nin yasallığı Linux ve ilgili yazılımlar açısından göz ardı edilmektedir. Bunun uzun vadeli sonuçları belirsizdir.
The origins of Linux and the LGPL Linux ve LGPL'nin Kökenleri
While the commercial Unix wars raged, the Linux kernel was developed as a PC Unix clone. Linus Torvalds credits the existence of the GNU C compiler and the associated GNU tools for the existence of Linux. He put the Linux kernel under the GPL. Ticari Unix savaşları hızlanırken, Linux çekirdeği bir PC Unix klonu olarak geliştirilmişti. Linus Torvalds, Linux’un varlığını GNU C derleyicisinin ve ilgili GNU araçlarının varlığıyla ortaya çıktığını savunur. Linux çekirdeğini Linus Torvalds GPL altına aldı.
Remember that the GPL requires anything that statically links to any code under the GPL also be placed under the GPL. The source for this code must thus be made available to the user of the program. Dynamic linking, however, is not considered a violation of the GPL. Pressure to put proprietary applications on Linux became overwhelming. Such applications often must link with system libraries. This resulted in a modified version of the GPL called the <link xlink:href="http://www.opensource.org/licenses/lgpl-license.php">LGPL</link> ("Library", since renamed to "Lesser", GPL). The LGPL allows proprietary code to be linked to the GNU C library, glibc. You do not have to release the source code which has been dynamically linked to an LGPLed library. Hatırlamanız gerekir ki GPL, GPL’in altındaki herhangi bir koda statistik olarak bağlanmakta olan ve hatta GPL’in altında yer alan herhangi koddan birine ihtiyaç duyulmaktadır. Bu kodun kaynağı dolayısıyla kullanıcıya programı kullanabilir hale getirilmelidir. Dinamik bağlantı ancak GPL’in uyumsuzluğu olarak dikkate alınmamalıdır. Linux’a özel uygulamalar koyma girişimleri karşı konulamaz halde baskıya yapmıştır. Bu tip uygulamalar çoğunlukla sistemin kitaplıkları ile bağlantı kurmalıdır. GPL’in değiştirilmiş sürümü adı altında olarak bu <link xlink:href="http://www.opensource.org/licenses/lgpl-license.php">LGPL</link> ("Kitaplık", yeniden adlandırıldığından itibaren "Kiralayan", GPL) ile sonuçlanmaktadır. LGPL, tescilli kod olan GNU C kitaplık ve glibc’e bağlantı kurulmasına imkân sağlar. Dinamik olarak bağlanılan LGPLed kitaplığının kaynak kodunu serbest bırakmak zorunda değilsiniz.
If you statically link an application with glibc, such as is often required in embedded systems, you cannot keep your application proprietary, that is, the source must be released. Both the GPL and LGPL require any modifications to the code directly under the license to be released. Gömülü sistemlerde genellikle olduğu gibi bir uygulamayı glibc ile de statik olarak bağlarsanız, uygulamanız kişiye özel olmaz, yani kaynak serbest bırakılmalıdır. GPL ve PGPL'de de kaynağın serbest bırakılması için doğrudan lisansın altındaki kodda herhangi bir değişiklik yapılmalıdır.
Open Source licenses and the Orphaning Problem Açık Kaynak lisansları ve Artık Satır Problemi
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.
The GPL attempts to prevent orphaning by severing the link to proprietary intellectual property. GPL, tescilli fikri mülkiyet bağlantısını keserek orphaning oluşmasını önlemeye çalışır.
A BSD license gives a small company the equivalent of software-in-escrow without any legal complications or costs. If a BSD-licensed program becomes orphaned, a company can simply take over, in a proprietary manner, the program on which they are dependent. An even better situation occurs when a BSD code-base is maintained by a small informal consortium, since the development process is not dependent on the survival of a single company or product line. The survivability of the development team when they are mentally in the zone is much more important than simple physical availability of the source code.
What a license cannot do Bir lisansın yapamayacağı şeyler
No license can guarantee future software availability. Although a copyright holder can traditionally change the terms of a copyright at anytime, the presumption in the BSD community is that such an attempt simply causes the source to fork. Hiçbir lisans gelecek yazılımların kullanılabilirliğini garanti edemez. Telif hakkı sahibi bilindiği üzere istediği zaman telif hakkı şartlarını değiştirebilmesine rağmen, BSD topluluğundaki yaklaşım , böyle bir girişimde kaynağın bozulmasına neden olur.
The GPL explicitly disallows revoking the license. It has occurred, however, that a company (Mattel) purchased a GPL copyright (cphack), revoked the entire copyright, went to court, and prevailed [2]. That is, they legally revoked the entire distribution and all derivative works based on the copyright. Whether this could happen with a larger and more dispersed distribution is an open question; there is also some confusion regarding whether the software was really under the GPL. GNU açıkça lisansı iptal etmeye izin vermemektedir. Fakat bir şirket (Mattel) mahkemeye başvurdu ve kazanarak, GNU telif hakkını satın aldı ve tüm telif hakkını iptal etti. Kısacası, telif hakkına dayalı olan tüm dağılım ve türev çalışmaları yasal olarak iptal etmiş oldular. Bunun daha geniş ve karışık dağılımda olup olmayacağı halen sonuca bağlanmamış bir sorundur ve yazılımın gerçekten GNU altında olup olmadığına ilişkin kafalarda halen soru işareti bulunmaktadır.
In another example, Red Hat purchased Cygnus, an engineering company that had taken over development of the FSF compiler tools. Cygnus was able to do so because they had developed a business model in which they sold support for GNU software. This enabled them to employ some 50 engineers and drive the direction of the programs by contributing the preponderance of modifications. As Donald Rosenberg states "projects using licenses like the GPL...live under constant threat of having someone take over the project by producing a better version of the code and doing it faster than the original owners." [3] Farklı bir örnekte, Red Hat, FSF derleyici araçların geliştirilmesini devrelan mühendislik şirketi Cygnus’u satın aldı. Cygnus, GNU yazılımına destek olarak sattıkları bir iş modeli geliştirerek bunu başardılar. Bu, yaklaşık 50 mühendis istihdam etmelerini ve değişikliklere ağırlık vererek programları yönlendirmelerini sağladı. Donald Rosenberg'in belirttiği gibi "GPL gibi lisansları kullanan projeler ... Devamlı birinin daha iyi bir kod üretip asıl sahiplerinden daha hızlı yaparak projeyi ele geçirme tehditi altındadır." [3]
GPL Advantages and Disadvantages
A common reason to use the GPL is when modifying or extending the gcc compiler. This is particularly apt when working with one-off specialty CPUs in environments where all software costs are likely to be considered overhead, with minimal expectations that others will use the resulting compiler.
The GPL is also attractive to small companies selling CDs in an environment where "buy-low, sell-high" may still give the end-user a very inexpensive product. It is also attractive to companies that expect to survive by providing various forms of technical support, including documentation, for the GPLed intellectual property world.
A less publicized and unintended use of the GPL is that it is very favorable to large companies that want to undercut software companies. In other words, the GPL is well suited for use as a marketing weapon, potentially reducing overall economic benefit and contributing to monopolistic behavior. GPL'nin (Genel Kamu Lisansı) kamuya yarı açık ve istenmeyen bir kullanımı, yazılım şirketlerini alt etmek isteyen büyük şirketler için çok elverişlidir. Başka bir deyişle, GPL bir pazarlama silahı olarak kullanılmaya çok uygundur, bu da potansiyel olarak genel ekonomik faydayı azaltır ve tekelci davranışlara katkıda bulunur.
The GPL can present a real problem for those wishing to commercialize and profit from software. For example, the GPL adds to the difficulty a graduate student will have in directly forming a company to commercialize his research results, or the difficulty a student will have in joining a company on the assumption that a promising research project will be commercialized. GPL, ticarileştirmek ve yazılımdan faydalanmak isteyenler için gerçek bir sorun yaratabilir. Örneğin GPL, bir yüksek lisans öğrencisinin araştırma sonuçlarını ticarileştirmek için doğrudan bir şirket kurmasını veya bir öğrencinin gelecek vaat eden bir araştırma projesinin ticarileştirileceği varsayımı üzerine bir şirkete katılmasını zorlaştırır.
For those who must work with statically-linked implementations of multiple software standards, the GPL is often a poor license, because it precludes using proprietary implementations of the standards. The GPL thus minimizes the number of programs that can be built using a GPLed standard. The GPL was intended to not provide a mechanism to develop a standard on which one engineers proprietary products. (This does not apply to Linux applications because they do not statically link, rather they use a trap-based API.) Çoklu yazılım standartlarının statik olarak bağlanan uygulamalarıyla çalışması gereken kişiler için GPL, genellikle yetersiz bir lisanstır; bunun sebebi standartlar dahilindeki tescilli uygulamaların kullanılmasını olanaksız hale getirmesidir. Dolayısıyla GPL, bir GPL standardı kullanılarak oluşturulabilecek programların sayısını minimuma indirir. GPL'in, kişilerin tescilli ürünlerin mühendisliğini yaptığı bir standart geliştirilmesi için bir mekanizma sağlaması amaçlanmamıştı. (Bu Linux uygulamaları için geçerli değildir çünkü bu uygulamalar statik olarak bağlanmış değillerdir, bunun yerine tuzak tabanlı API kullanırlar.)
The GPL attempts to make programmers contribute to an evolving suite of programs, then to compete in the distribution and support of this suite. This situation is unrealistic for many required core system standards, which may be applied in widely varying environments which require commercial customization or integration with legacy standards under existing (non-GPL) licenses. Real-time systems are often statically linked, so the GPL and LGPL are definitely considered potential problems by many embedded systems companies.
The GPL is an attempt to keep efforts, regardless of demand, at the research and development stages. This maximizes the benefits to researchers and developers, at an unknown cost to those who would benefit from wider distribution.
The GPL was designed to keep research results from transitioning to proprietary products. This step is often assumed to be the last step in the traditional technology transfer pipeline and it is usually difficult enough under the best of circumstances; the GPL was intended to make it impossible.
BSD Advantages
A BSD style license is a good choice for long duration research or other projects that need a development environment that:
has near zero cost
will evolve over a long period of time
permits anyone to retain the option of commercializing final results with minimal legal issues.
This final consideration may often be the dominant one, as it was when the Apache project decided upon its license:
<quote>This type of license is ideal for promoting the use of a reference body of code that implements a protocol for common service. This is another reason why we choose it for the Apache group - many of us wanted to see HTTP survive and become a true multiparty standard, and would not have minded in the slightest if Microsoft or Netscape choose to incorporate our HTTP engine or any other component of our code into their products, if it helped further the goal of keeping HTTP common... All this means that, strategically speaking, the project needs to maintain sufficient momentum, and that participants realize greater value by contributing their code to the project, even code that would have had value if kept proprietary.</quote>
Developers tend to find the BSD license attractive as it keeps legal issues out of the way and lets them do whatever they want with the code. In contrast, those who expect primarily to use a system rather than program it, or expect others to evolve the code, or who do not expect to make a living from their work associated with the system (such as government employees), find the GPL attractive, because it forces code developed by others to be given to them and keeps their employer from retaining copyright and thus potentially "burying" or orphaning the software. If you want to force your competitors to help you, the GPL is attractive. Hukuki sorunlar ortadan kalktığı ve kodla istedikleri her şeyi yapabildikleri için geliştiriciler, BSD lisansını cazip bulmaya meyillidirler. Diğer tarafta da öncelikle bir sistemi programlamak yerine kullanmayı bekleyenler, diğerlerinin kodu geliştirmesini bekleyenler ya da sistemle ilgili olan işleriyle geçinme gibi bir beklentisi olmayanlar (örneğin memurlar) GPL'yi cazip bulurlar, çünkü diğerlerinin geliştirdiği kodun onlara verilmesini zorunlu kılar ve işverenlerinin telif hakkına sahip olmasını, bu sebeple yazılımın "gömülmesini" veya terk edilmesini önler. Rakiplerinizi size yardım etmeye zorlamak istiyorsanız GPL caziptir.

Loading…

No matching activity found.

Browse all component changes

Glossary

English Turkish (tr_TR)
overhead ek yük FreeBSD Doc
software program,yazılım FreeBSD Doc
Software Yazılım FreeBSD Doc

Source information

Source string comment
(itstool) path: sect1/para
Source string location
article.translate.xml:323
String age
11 months ago
Source string age
a year ago
Translation file
articles/tr-TR/bsdl-gpl.po, string 53