Free jQuery Plugins, HTML5 and CSS3 Scripts - Providing tons of Jquery Plugins,Html5 and CSS3 Scripts for web developers to preview and download. By using these resources, you can create amazing effects with fancy animations of content elements like text, images and so on.
Easily generate links from elements on your page. For example, generate links to all the articles on a page by linking to the article’s h1’s, and put them in a nav element on the page with an id of article-nav. (By default, the links will use the same text as the h1).
$.MagicNav($('#article-nav'),$('article h1'));
The first argument to $.MagicNav is a selector for the element to which the links will be appended. The second is a selector for the elements from which the plugin should build the links. The third is a settings object (optional).
There are a few options available when initializing the plugin:
Here’s an example applying some custom options:
$.MagicNav($('#article-nav'),$('article h1'),{
titles: 'data-title',
ease: function (x, t, b, c, d) {
// easeOutQuad
return -c *(t/=d)*(t-2) + b;
},
duration: 500,
offset: -60
});
Run MagicNav.js
Click the button to see MagicNav to generate links for the FAQ below.
Sample FAQ from Open Source Initiative
Absolutely. All Open Source software can be used for commercial purpose; the Open Source Definition guarantees this. You can even sell Open Source software.
However, note that commercial is not the same as proprietary. If you receive software under an Open Source license, you can always use that software for commercial purposes, but that doesn't always mean you can place further restrictions on people who receive the software from you. In particular, so-called copyleft-style Open Source licenses require that when you distribute the software, you do so under the same license you received it under.
"Copyleft" refers to licenses that allow derivative works but require them to use the same license as the original work. 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.
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. For example, the BSD license is a non-copyleft Open Source license. 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.
For most practical purposes, it is — sort of. This is a complicated question, so please read on.
"Public domain" is a technical term in copyright law that refers to works not under copyright — either because they were never in copyright to begin with (for example, works authored by U.S. government employees, on government time and as part of their job, are automatically in the public domain), or because their copyright term has finally lapsed and they have "fallen into" the public domain.
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. But even if we could succeed at this (which would be difficult, because it would mean evaluating not just the statutes but various bodies of case law), it 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.S. government works as described above, where it is not easy to apply a license, and the software must be released into the public domain. 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 2012, February 2012, and March 2012 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.
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 2012, 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. An unexpectedly intense and detailed discussion followed — search for "CC0" and "Creative Commons Zero" in the subject headers of the February 2012 and March 2012 archives of the OSI License Review mailing list.
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 trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document.". 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.
See also the public domain question.
You can choose any license from the open source licenses shown at opensource.org/licenses/category. Most people select one from the "popular" category, but you are free to choose any license on that list.
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.2 of the eBook Introduction to Free Software by Hernandez, Jimenez, Barahona, Pascual, and Robles.
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.)
Note that copyleft Open Source licenses require redistributors to make source code available under certain circumstances; for example, see the GNU General Public License and GNU Affero General Public License.
The Open Source Initiative is not a legal services organization and generally cannot help you when someone is violating a copyleft license. However, as of late 2011, one of the organizations below may be able to help (note that most of the enforcement they do is about the GNU GPL and AGPL licenses, though in theory they can help enforce other copyleft licenses too):
If you know of other organizations that provide similar legal assistance, please let us know at osi {_AT_} opensource.org.
No, at least not any more than they could otherwise. Open Source is about software source code, not about identity. That is, letting people use your code under an Open Source license is not the same as letting them use your trademarks or other identifying attributes, except insofar as they would be permitted to anyway (for example, in nominative use doctrine). There are many companies and other organizations that release open source code while exercising tight control over their trademarks.
Trademarks and other marks of attribution are primarily about preventing public confusion over identity and provenance, and therefore trademark regulation is useful in Open Source software in the same way it is useful generally.
We are not a legal services organization and we can't give you legal advice. If you want legal advice, you need to have an attorney-client relationship with a lawyer. Even if the lawyer is pro bono, there still needs to be a formal client arrangement.
Without giving you legal advice, we can still give you advice about community norms and expectations. It won't be legal advice, but you may find it useful when talking with your lawyer or, if necessary, coming to a decision without the help of a lawyer.