Translation

(itstool) path: listitem/para
English
will evolve over a long period of time
0/380
Context English Turkish (tr_TR) State
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.
A BSD license is not simply a gift. The question <quote>why should we help our competitors or let them steal our work?</quote> comes up often in relation to a BSD license. Under a BSD license, if one company came to dominate a product niche that others considered strategic, the other companies can, with minimal effort, form a mini-consortium aimed at reestablishing parity by contributing to a competitive BSD variant that increases market competition and fairness. This permits each company to believe that it will be able to profit from some advantage it can provide, while also contributing to economic flexibility and efficiency. The more rapidly and easily the cooperating members can do this, the more successful they will be. A BSD license is essentially a minimally complicated license that enables such behavior. BSD lisansı ile ilgili olarak <quote>Neden rakiplerimize yardım edelim veya çalışmamızı çalmalarına izin verelim ki?</quote> sorusu çok sık sorulsa da BSD lisansının buna olanak tanıdığı düşünülmemelidir. Bir şirketin, başkalarınca stratejik olduğu düşünülen, BSD lisansı altındaki ihtiyaç odaklı bir ürün (niş ürün) üzerinde hakimiyet kurması durumunda, diğer şirketler, asgari düzeyde bir çabayla, dengenin yeniden sağlanabilmesi için söz konusu BSD lisansı ile rekabet edebilecek farklı bir BSD lisansını destekleyip adil ve rekabetçi piyasa koşullarını oluşturabilecek küçük çaplı bir konsorsiyum oluşturabilir. Bu durum, bir yandan her bir şirketin bu durumun sağlayabileceği avantajlardan faydalanıp kar elde edebileceğine inanmasına olanak tanırken diğer yandan ekonomik esnekliğe ve verimliliğe katkıda bulunur. Ayrıca, işbirliği içerisinde olan üyeler bunu ne kadar hızlı ve kolay yaparsa o kadar başarılı olacaklardır. Bu açıdan bakıldığında BSD lisansı, karmaşıklığın asgari düzeyde tutulduğu ve yukarıda bahsedilenlere olanak sağlayan bir lisanstır.
A key effect of the GPL, making a complete and competitive Open Source system widely available at cost of media, is a reasonable goal. A BSD style license, in conjunction with ad-hoc-consortiums of individuals, can achieve this goal without destroying the economic assumptions built around the deployment-end of the technology transfer pipeline. Eksiksiz ve rekabetçi bir Açık Kaynak sistemin yalnızca dağıtım ortamı (CD/DVD vb.) maliyeti karşılığında yaygın kullanıma sunulması, Genel Kamu Lisansının da önemli çıktılarından biri olup oldukça makul bir hedeftir ve bu hedef, BSD lisansı kullanılarak, gereklilik halinde oluşturulan şahıs konsorsiyumlarının da işbirliğiyle, son kullanıcı tarafında oluşmuş ekonomik varsayımlar alt üst edilmeden gerçekleştirilebilir.
Specific Recommendations for using a BSD license BSD lisansının kullanılabileceği özel durumlara ilişkin tavsiyeler
The BSD license is preferable for transferring research results in a way that will widely be deployed and most benefit an economy. As such, research funding agencies, such as the NSF, ONR and DARPA, should encourage in the earliest phases of funded research projects, the adoption of BSD style licenses for software, data, results, and open hardware. They should also encourage formation of standards based around implemented Open Source systems and ongoing Open Source projects. BSD Lisansı, araştırma sonuçlarının yaygın şekilde kullanıma sunulabilecek ve ekonomiye en çok faydayı sağlayabilecek şekilde aktarımı için tercih edilebilir. Bu bakımdan, araştırmalara fon sağlayan NSF (Ulusal Bilim Vakfı), ONR (Birleşik Devletler Deniz Kuvvetleri Denizcilik Araştırmaları Ofisi) and DARPA (ABD Savunma Bakanlığı Savunma Araştırmaları Müsteşarlığı) gibi kuruluşlar fon sağladıkları araştırma projelerinin başlangıç safhaslarında, yazılım, veri ve sonuçlar için BSD lisansının ve açık kaynak donanımınların benimsenmesini ve bunların yanı sıra uyarlanmış Açık Kaynak sistemlere ve sürmekte olan Açık Kaynak projelere dayalı standartların oluşturulmasını teşvik etmelidir.
Government policy should minimize the costs and difficulties in moving from research to deployment. When possible, grants should require results to be available under a commercialization friendly BSD style license. Hükümet politikaları, araştırma aşamasından araştırma bulgularının kullanılabilir hale gelmesi aşamasına geçişteki masraf ve zorlukları asgari düzeyde tutmalı ve mümkün olduğu durumlarda, verilen hibelerde, araştırma sonuçlarının ticarileştirmeye imkan tanıyan bir BSD lisansı altında sunulması şartı yer almalıdır.
In many cases, the long-term results of a BSD style license more accurately reflect the goals proclaimed in the research charter of universities than what occurs when results are copyrighted or patented and subject to proprietary university licensing. Anecdotal evidence exists that universities are financially better rewarded in the long run by releasing research results and then appealing to donations from commercially successful alumni.
Companies have long recognized that the creation of de facto standards is a key marketing technique. The BSD license serves this role well, if a company really has a unique advantage in evolving the system. The license is legally attractive to the widest audience while the company's expertise ensures their control. There are times when the GPL may be the appropriate vehicle for an attempt to create such a standard, especially when attempting to undermine or co-opt others. The GPL, however, penalizes the evolution of that standard, because it promotes a suite rather than a commercially applicable standard. Use of such a suite constantly raises commercialization and legal issues. It may not be possible to mix standards when some are under the GPL and others are not. A true technical standard should not mandate exclusion of other standards for non-technical reasons.
Companies interested in promoting an evolving standard, which can become the core of other companies' commercial products, should be wary of the GPL. Regardless of the license used, the resulting software will usually devolve to whoever actually makes the majority of the engineering changes and most understands the state of the system. The GPL simply adds more legal friction to the result.
Large companies, in which Open Source code is developed, should be aware that programmers appreciate Open Source because it leaves the software available to the employee when they change employers. Some companies encourage this behavior as an employment perk, especially when the software involved is not directly strategic. It is, in effect, a front-loaded retirement benefit with potential lost opportunity costs but no direct costs. Encouraging employees to work for peer acclaim outside the company is a cheap portable benefit a company can sometimes provide with near zero downside.
Small companies with software projects vulnerable to orphaning should attempt to use the BSD license when possible. Companies of all sizes should consider forming such Open Source projects when it is to their mutual advantage to maintain the minimal legal and organization overheads associated with a true BSD-style Open Source project.
Non-profits should participate in Open Source projects when possible. To minimize software engineering problems, such as mixing code under different licenses, BSD-style licenses should be encouraged. Being leery of the GPL should particularly be the case with non-profits that interact with the developing world. In some locales where application of law becomes a costly exercise, the simplicity of the new BSD license, as compared to the GPL, may be of considerable advantage.

Loading…

No matching activity found.

Browse all component changes

Glossary

English Turkish (tr_TR)
boot time önyükleme zamanı FreeBSD Doc
compilation time derleme zamanı FreeBSD Doc
timeout, time out zaman aşımı FreeBSD Doc

Source information

Source string comment
(itstool) path: listitem/para
Source string location
article.translate.xml:392
String age
10 months ago
Source string age
a year ago
Translation file
articles/tr-TR/bsdl-gpl.po, string 64