Open-source software is a boon to computer programmers: by sharing the source code for freely released software, anyone with the skill can modify it for their own needs. Under the GNU General Public License that governs a large number of open-source products, open-source code can only be tightly integrated into other open-source products, and a condition of using the code is that the user also publish its modified version of the code.
Take Cisco Systems Inc. The term "free software" is older, and is reflected in the name of the Free Software Foundation FSF , an organization founded in to protect and promote free software. The term "open source" was coined by Christine Peterson and adopted in by the founders of the Open Source Initiative.
In the s, the term "open" applied to software source code was sometimes used to imply source code being merely inspectable or visible or available. Going back further, in the s there were uses of "open" in the computing industry that primarily connoted something like "absence of hardware vendor lockin". OSI's term "open source", as defined in the Open Source Definition, makes clear that open source specifically entails not mere inspection access but also conveying to recipients the perpetual right to fork covered code and use it without additional fees.
The FSF uses a shorter, four-point definition of software freedom when evaluating licenses, while the OSI uses a longer, ten-point definition. The two definitions lead to the same result in practice, but use superficially different language to get there.
This history has led to occasional confusion about the relationship between the two terms. Sometimes people mistakenly assume that users of the term "open source" do not intend to communicate a philosophical point of view via that term, even though many actually do use it that way.
Another mistake, which has occasionally been seen since about , is to assume that "free software" refers only to software licensed under copyleft licenses, since that is how the FSF typically releases software, while "open source" refers to software released under so-called permissive i. In fact, both terms refer to software released under both kinds of license. Neither term binds exclusively to one set of associations or another, however; it is always question of context and intended audience.
When you sense a potential misunderstanding, you may wish to reassure your audience that the terms are essentially interchangeable, except when being used specifically to discuss the history or connotations of the terminological difference itself. See also our history page for more information about the history and usage of the term "open source".
For example, if you write some software and release it under the GNU General Public License a widely-used copyleft license , and then someone else modifies that software and distributes their modified version, the modified version must be licensed under the GNU GPL too — including any new code written specifically to go into the modified version. Both the original and the new work are Open Source; the copyleft license simply ensures that property is perpetuated to all downstream derivatives.
There is at least one copyleft license, the Affero GPL , that even requires you to offer the source code, under the AGPL, to anyone to whom you make the software's functionality available as a network service — however, most copyleft licenses activate their share-and-share-alike requirement on distribution of a copy of the software itself.
You should read the license to understand its requirements for source code distribution. Most copyleft licenses are Open Source, but not all Open Source licenses are copyleft. When an Open Source license is not copyleft, that means software released under that license can be used as part of programs distributed under other licenses, including proprietary non-open-source licenses. Such licenses are usually called either "non-copyleft" or "permissive" open source licenses.
Copyleft provisions apply only to actual derivatives, that is, cases where an existing copylefted work was modified. Merely distributing a copyleft work alongside a non-copyleft work does not cause the latter to fall under the copyleft terms. For more information, look at the text of the specific copyleft license you're thinking of using, or see the Wikipedia entry on copyleft.
A "permissive" license is simply a non-copyleft open source license — one that guarantees the freedoms to use, modify, and redistribute, but that permits proprietary derivative works. See the copyleft entry for more information. Only if it uses one of the approved licenses , and releases appropriate software. Please don't do that. If you call it "Open Source" without using an approved license, you will confuse people.
This is not merely a theoretical concern — we have seen this confusion happen in the past, and it's part of the reason we have a formal license approval process. See also our page on license proliferation for why this is a problem.
In general, no. We run all licenses through an approval process to provide an accepted standard on which licenses are Open Source, and we list the approved ones. Be dubious of claimed Open Source-ness for licenses that haven't gone through the process.
See also the license proliferation page for why this matters so much. Many older licenses, such as the BSD license, have several variations that differ only by a few words or sentences. Unfortunately, it is not possible for OSI to approve every variation, so we cannot say if a specific variation is approved. Where possible, please avoid using these variants, and instead use the same version used on the OSI website.
Not all jurisdictions have a public domain, and it doesn't always mean exactly the same thing in the jurisdictions that do have it. Furthermore, even where it is clear what it means, it's still not a license. To be subject to a license, a work must still be in copyright. That means there is no way for the "public domain", as a concept, to go through the OSI evaluation and approval process.
We wouldn't be evaluating a license text. Instead, we would have to somehow evaluate the laws themselves, in different jurisdictions, and say which jurisdictions have a public domain that meets the Open Source Definition and does not create problems for software authors and users. This would be very difficult, because it would mean evaluating not just the statutes but various bodies of case law for example, open source licenses usually have a strong disclaimer of liability for the copyright holder — but we don't know how or whether the author would be protected from liability for software released into the public domain in various jurisdictions.
This approach would not be useful to the OSI's mission, because open source is an international phenomenon and we only want to approve licenses that meet the Open Source Definition everywhere. Thus we recommend that you always apply an approved Open Source license to software you are releasing, rather than try to waive copyright altogether. Using a clear, recognized Open Source license actually makes it easier for others to know that your software meets the Open Source Definition.
It also enables the protection of attribution, and various other non-restrictive rights, that cannot be reliably enforced when there is no license. There are certain circumstances, such as with U. In these cases, while it would be inaccurate to display the OSI logo or say that the license is OSI-approved since there is no license , nevertheless we think it is accurate to say that such software is effectively open source, or open source for most practical purposes, even though it is not officially released under an open source license.
This is assuming, of course, that in the laws of releasing jurisdiction the meaning of "public domain" is compatible with the Open Source Definition. After all, the freedoms guaranteed by open source licenses are still present, and it is possible for the familiar dynamics of open source collaboration to arise around the software. For a detailed discussion of the complexities of the public domain and open source, search for the words "public domain" and "PD" in the subject headers of the January , February , and March archives of the OSI License Review mailing list.
And if the thought of reading all those conversations is daunting, please take that as more evidence that it's just better to use an approved Open Source License if you can! See also the CC0 question. For a different viewpoint than the one presented above, see unlicense. At this time, we do not recommend releasing software using the the CC0 public domain dedication. Creative Commons Zero is a legal device known as a "public domain dedication". It is essentially a statement of intent by the copyright holder to waive copyright ownership in the work — that is, the copyright holder wishes to place the work into the public domain.
Because such a waiver is perhaps surprisingly not possible in all jurisdictions, CC0 also contains a "Public License Fallback" clause that goes into effect "should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law". The fallback is essentially a copyright license that is very similar to an Open Source license, in that it gives up most of the restrictive powers associated with copyright, and allows redistribution and modification of the work.
In February , Creative Commons submitted CC0 to the OSI for approval as an open source license, requesting that the OSI evaluate the public license fallback section, since the rest of the text is a waiver of rights rather than a license.
CC0 was not explicitly rejected, but the License Review Committee was unable to reach consensus that it should be approved, and Creative Commons eventually withdrew the application.
The most serious of the concerns raised had to do with the effects of clause 4 a , which reads: "No While many open source licenses simply do not mention patents, it is exceedingly rare for open source licenses to explicitly disclaim any conveyance of patent rights, and the Committee felt that approving such a license would set a dangerous precedent, and possibly even weaken patent infringement defenses available to users of software released under CC0.
If you don't distribute source code, then what you are distributing cannot meaningfully be called "Open Source". And if you don't distribute at all, then by definition you're not distributing source code, so you're not distributing anything Open Source. Think of it this way: Open Source licenses are always applied to the source code — so if you're not distributing the source, then you're not distributing the thing to which an Open Source license applies.
You might or might not distribute binaries; that's a separate question. But while some Open Source licenses allow you to distribute binary code without distributing the corresponding source, it is only the source code that can be "open source". The binaries alone cannot be Open Source, because you're not making any source code available to be open.
If someone else distributes the source code under an Open Source license, then that's still Open Source, of course. You can choose any license from the open source licenses listed starting here: opensource. Most people select one from the "popular" category, but you are free to choose any listed license.
If this is your first time choosing an open source license, we recommend that you find someone who has experience with open source licensing and talk to them about your project — that will help you choose the most appropriate license.
The person doesn't have to be a lawyer; it could be a developer who has experience releasing open source code. The section Choosing a License at the Civic Commons wiki may be useful, and you can learn more about open source licenses from, Section 3. Unlike bilateral copyright licenses, which are negotiated between two parties and embody a truce between them for business purposes, multilateral copyright licenses — of which open source licenses are a kind — are community agreements.
They express the consensus of how a community chooses to collaborate. They also embody its ethical assumptions, even if they are not explicitly enumerated. When that consensus includes giving permission to all to use, study improve and share the code without prejudice, the license is an open source license. The Open Source Definition provides an objective test of evaluating that such a license is indeed an open source license and delivers the software freedom we all expect.
Since licenses are the consensus of communities, it is natural that different communities will have different licenses, that communities with different norms will find fault with the licenses used by others, and that all will regard their way as optimum. Any Open Source Software provided hereunder is provided pursuant to such Open Source Software license terms and conditions.
Upon reasonable notice to You , Pervasive has the right to replace software provided to You as part of Open Source Software with software that has similar functionality. The license terms associated with Open Source Software require that Pervasive provide copyright and license information to You. A list of the Open Source Software included in the Software and available to You from Pervasive, the applicable license terms, and how to obtain the Open Source Software if not already provided to You as part of the Software are provided in the Software notice.
Any provisions in this Agreement which differ from any Open Source Software license are offered by Pervasive alone and not by any other party. The Software provided with Storage Services may contain programming , scripts , tools , modules , libraries , components , or other items that were developed using "open source" code the "Open Source Software". Open Source Software is provided to you under one or more open source license agreements that contain important information concerning ownership , terms of use , and rights , and restrictions for the applicable element of the Open Source Software.
If Customer uses open source software or any other third party software not supplied by TIBCO in conjunction with the Software , Customer must ensure that its use does not: i create, or purport to create , obligations of use with respect to the Software; or.
0コメント