If my site uses jquery and jquery plugins, am I supposed to refer to the MIT license and give credit to the creators? Ordoes this only apply to software redistribution?
The MIT license linked to by the jQuery Web site:
Copyright (c) 2010 John Resig,
http://jquery.com/
Permission is hereby granted, free of
charge, to any person obtaining a copy
of this software and associated
documentation files (the "Software"),
to deal in the Software without
restriction, including without
limitation the rights to use, copy,
modify, merge, publish, distribute,
sublicense, and/or sell copies of the
Software, and to permit persons to
whom the Software is furnished to do
so, subject to the following
conditions:
The above copyright notice and this
permission notice shall be included in
all copies or substantial portions of
the Software.
THE SOFTWARE IS PROVIDED "AS IS",
WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED
TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE
FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.
I'd say this is pretty self-explanatory. If you distribute substantial portions of the software, the copyright notice must be included.
EDIT:
Upon reading your question again, maybe you're wondering if you have to display the notice on your Web pages somewhere. In that case I would say no, the notice in the scripts themselves is enough. Just don't delete them.
If you modify the others script, then you will have to state this somewhere explicitly otherwise each of those scripts have the implicit liscnce info for everyone to see.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
So I found an open source project that uses the reciprocal public license 1.5 (RPL). It seems that the RPL means that you must post all of your code back out to the community.
RPL 1.5 - Paragraph 5
Further, under the RPL all components you author including schemas, scripts,
source code, etc. -- regardless of whether they're compiled into a single
binary or used as two halves of client/server application -- must be shared.
You have to share the whole pie, not an isolated slice of it.
I work for a health care company that is not going to be ok with me posting our proprietary code out on the internet.
So I am wondering, is that really what the RPL does? Is there limitations on what needs to be published? Or is it really just any thing that touches the RPLed project must also go open source under the RPL?
For a commercial software RPL is even worse than GPL.
It is true that you have to publish your source code on any derivative work.
Also in GNU web site it says:
The Reciprocal Public License is a
non-free license because of three
problems. 1. It puts limits on prices
charged for an initial copy. 2. It
requires notification of the original
developer for publication of a
modified version. 3. It requires
publication of any modified version
that an organization uses, even
privately.
source
Edit
Quatation from RPL 1.5:
6.0 Your Obligations And Grants. In consideration of, and as an express
condition to, the licenses granted to
You under this License You hereby
agree that any Modifications,
Derivative Works, or Required
Components (collectively Extensions)
that You create or to which You
contribute are governed by the terms
of this License including, without
limitation, Section 4. Any Extensions
that You create or to which You
contribute must be Deployed under the
terms of this License or a future
version of this License released under
Section 7. You hereby grant to
Licensor and all third parties a
world-wide, non-exclusive,
royalty-free license under those
intellectual property rights You own
or control to use, reproduce, display,
perform, modify, create derivatives,
sublicense, and distribute Licensed
Software, in any form. Any Extensions
You make and Deploy must have a
distinct title so as to readily tell
any subsequent user or Contributor
that the Extensions are by You. You
must include a copy of this License or
directions on how to obtain a copy
with every copy of the Extensions You
distribute. You agree not to offer or
impose any terms on any Source Code or
executable version of the Licensed
Software, or its Extensions that alter
or restrict the applicable version of
this License or the recipients' rights
hereunder.
Reciprocal Public License is more stricter than of GPLv2. It requires the distribution of all the source code (Whether the proprietary or Open Source), which linked, based out of RPL. Be careful in terms of protecting own IP.
Can the owner of an open source Github repository later decide to close it? What about other people's contribution to that project?
Edit - several people focused only on the legal aspects. Besides them there exists the technical question: Is it technically possible to take a public repository I own on Github, and turn it private at a later date? Assuming nobody created a public forked from it, will this in effect hide the source code for this project?
(Note that I am not a lawyer.) From the GitHub Terms of Service, paragraph F.1:
We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
In other words, GitHub itself has nothing to do with how you license your code. So you can decide to stop publishing your source via GitHub, but everything that has been forked and cloned from it up to that point is of course still "out there" under the open source license you originally used.
The same holds for other people's contribution to the project: whatever was permitted by the original license remains, so it is between you and the other contributors. GitHub has little to do with it.
As to the updated question:
It is safest to assume that anything you put on the web is out there forever. GitHub allows you to browse the source code through the web. It seems that GitHub's robots.txt asks crawlers to stay away from the source code, but there's no guarantee that they will do this. I can easily imagine Google Code Search starting to index GitHub, for example (if they're not doing that already.)
Bottom line: once the source is public, you can never make it private anymore.
Is it technically possible to take a public repository I own on github, and turn it private at a later date?
You cannot have private repositories unless you pay for them. Github's Plans and Pricing state that you can sign up for the free public repositories, and upgrade/downgrade your account at any time, so they almost certainly have a way to make your free public repositories private by upgrading to a paid account, or they would have a tremendously broken business model.
After reading their help files, you can indeed mark a public repository as private if you have a paid account.
You could also just delete the repository from your free account, and start hosting the repository yourself if you want to stop sharing it.
It depends on the license. If it's BSD or similar, then yes, it can be close-sourced from a future point in time, incorporating third-party contributions (because the license allows it). (Any code released before the source is closed remains open under whatever license was chosen.)
If it's GPL, then any third-party GPL'd code can no longer remain in the closed-source repository, unless a separate license to use it in a commercial, closed-source application is granted by each and every third-party author.
The copyright owner can choose whatever license he wants for code. However, changing a license is not a retroactive decision, it won't revoke the license of stuff that has already been released. Unhappy users can thus still fork the code and continue the work under the terms of the previous license.
But you should really ask this question to a lawyer (which I'm not). For example I'd tempted to say that released = publicly available but this is just my interpretation. Really, ask a lawyer.
There isn't really an opensource license out there that is retroactive. So even though you close source it later, the people before still have the old code with the old open source license...
Also, if a lot of people contributed, or one person contributed a large amount of code, then certain pieces of code may be more theirs than yours, which means you'd have to get permission from them to change the license of it(if the license is restrictive that is, such as the GPL. With BSD-style, there is no such restriction)
If in doubt, consult a lawyer and not a forum of people
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
There is a lot of open source engines and software with different licences conditions. Most of them are non-free for commercial use.
The question is what does "commercial use" exactly mean?
Example:
I have site where I propose paid service or software. I want to create blog or wiki section on it. I download appropriated open source projects and deploy on my web site. Is it "commersial use" as I will not earn money on these engines but on the services I propose?
"Commercial use" in cases like this is actually just a shorthand to indicate that the product is dual-licensed under both an open source and a traditional paid-for commercial license.
Any "true" open source license will not discriminate against commercial use. (See clause 6 of the Open Source Definition.) However, open source licenses like the GPL contain clauses that are incompatible with most companies' approach to commercial software (since the GPL requires that you make your source code available if you incorporate GPL'ed code into your product).
Duel-licensing is a way to accommodate this and also provides a revenue stream for the company providing the software. For users that don't mind the restrictions of the GPL and don't need support, the product is available under an open source license. For users for whom the GPL's restrictions would be incompatible with their business model, and for users that do need support, a commercial license is available.
You gave the specific example of the Screwturn wiki, which is dual-licensed under the GPL and a commercial license. Under the terms of the GPL (i.e., without getting a "commercial" license), you can do the following:
Use it internally as much as you want (see here)
Run it on your internal servers for external users / clients / customers, or run it on your internal servers for paying clients if you're an ISP / hosting provider. (If Screwturn were licensed under the AGPL instead of the GPL, that might restrict this.)
Distribute it to others, either free of charge or for a payment that covers the shipping, as long as you're willing to also distribute the source code
Incorporate it into your product, as long as you're willing to also distribute the source code, and as long as either (a) it remains a separate program that you merely aggregate with your product or (b) you release the source code to your product under an open source license compatible with the GPL
In other words, there's a lot that you can do without getting a commercial license. This is especially true for web-based software, since people can use web-based software without it being distributed to them. Screwturn's web site even acknowledges this: they state that the commercial license is for "either integrating it in a commercial application, or using it in an enterprise environment where free software is not allowed," not for any use related to commerce.
All of the preceding is merely my understanding and is not intended to be legal advice. Consult your lawyer to be certain.
Fundamentally if you use it as part of a business then its commercial use - so its not a matter of whether the tools are directly generating income or not rather one of if they are being used in support of income generation directly or indirectly.
To take your specific example, if the purpose of the site is to sell or promote your paid services/product then its a commercial enterprise.
If the usage of something is part of the process of you making money, then it's generally considered a commercial use. If the purpose of the site is to, through some means or another, directly or indirectly, make you money, then it's probably commercial use.
If, on the other hand, something is merely incidental (not part of the process of production/working, but instead simply tacked on to the side), there are potential grounds for it not to be considered commercial use.
I suggest this discriminative question:
Is the open-source tool necessary in your process of making money?
a blog engine on your commercial web site is necessary: commercial use.
winamp for listening to music is not necessary: non-commercial use.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm in the process of starting an open-source project aimed at digitising a whole bunch of forms provided by a government department. Basically at the moment if people need to fill out the forms they need to do so on paper, and I'd like to change that so that it can be done on the computer.
At present, the project has no official affiliation with the government and I'd like to set it up in such a way that the public can help contribute to digitising the forms as there are a large number of forms. At some point in the future, the forms may come to be of a standard where it would be feasible that they could be used officially by the government. If this were to be the case, it would be ideal if there was some kind of remuneration, rather than the forms being handed over to the government free of charge.
In such a case, how do you retain authority over where the money goes, given that the project could potentially have had many contributors? Obviously I would like to pass on remuneration to contributors that is based on how much they have each contributed, but is there any legal provisions or statements I would need to have in place to retain the authority to be the person that makes the decisions about who gets what? Is it a simple case of "person that starts the project gets to decide", or would this be in breach of any laws surrounding intellectual property or copyright, given that part of what is sold would be other peoples contributions?
A case (on a much larger scale) similar to mine that I can think of is with Sun buying MySQL - who got to decide where the money from the sale went to, and what did they have to do to retain the authority to make such a decision? As an asides, what did Sun actually get out of purchasing MySQL that they could not have had by simply downloading it, given that it was open source?
Sun, I'm sure, had lawyers. I really suggest you talk to one. They would be able to sort out how to retain some kind of rights over the money so that you (and your contributors) could get remuneration later.
Even open source projects have the concept of copyright.
The code of the project may be open-source but the copyright belongs to someone.
For example most GNU programs belong to the FSF. If you make non-trivial contributions (more than simple patches) they will ask you to give them the copyright of the code.
I suspect this also happens with other big open-source applications (e.g. Mozilla, Eclipse e.t.c).
The controller of the code (and where the money goes to) is the owner of the copyright.
To solve your problem you just ask all contributors to sign papers that assign the copyright of the code to you.
If you later decide to do something else with result you are free to do as you wish since you will be the soler owner of everything.
InterBase is a database system that was branched to an open-source version. Today, it's closed-source again but other developers are continuing to develop the open-source version. The two products are becoming very different nowadays but they have been very similar in the past.
The problem is that the open-source license will stay with that specific source version forever and ever. You can continue to develop your product, adding new features and changing it back to a commercial product again but you would be competing with other developers who might continue to develop on your open-source version. And they hold the copyrights of the modifications they're adding to your project.
Your main problem with turning back your open-source project to a commercial version again are the contributions from other open-source developers. If they gave you feedback and added code to fix certain issues then those changes are copyrighted by them and you can't add them to your commercial version, unless your commercial version continues to be open-source.
Still, a product can be open-source and commercial! Several Linux vendors make big profits doing just this. The profit is from the support they give to users, who are willing to pay for this support. They're not really selling Linux, they're selling support and their services to create an easy-to-install Linux version.In your example, you can't turn the project back to closed-source since you're accepting contributions from others. Those would all fall under the open-source license. But you own the copyright and the (trademarked) name, thus you can determine if people can offer commercial support for your product or not. They might have to pay you to use your trademark! The value is not in the code but in the name...
To contribute to OpenJDK, you have to sign a paper that transfers ownership of your code to Sun.
Providing an infrastructure for signing such a form would be a nice start for your digital form management project ;-).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
This question has always been around my head.
Can someone create a new product based on an existing open source project?
Say you want to create an "Apaxe webserver" that is basically Apache with your some extra plugins ( say support for ASP or something similar )
Is this possible?
Would you be able to create a closed source product ( either free or licensed )
As for GPL seems clear it is not possible because the source should be open. But what about Apache license, BSD and others "corporate friendly"
Are the price ( free for most of the project ) , bug fixes and counting with the core development team the only thing that prevent from others to commercialize those OS products?
What about: Khrome a commercial product based on Chrome with ActiveX support ( who would dare to do such a thing :P )
EDIT
Thank you all you all for your answers.
So, again
What prevents from similar ( clone ) products from appearing in the market?
:)
NOTE: I know we are not lawyers, and we could read every OSS license here http://www.opensource.org/licenses.
Nothing prevents clone products appearing on the market. Look at all the various linux distributions, for example. The X.org project was forked from XFree86. And so on.
It happens relatively infrequently, though, for a couple of reasons:
The original project has the first-to-market advantage
The original is usually being given away free
So unless your version is significantly better than the original, you're not going to get much uptake or make much money out of it. If your version is significantly better, then go ahead!
From the original developer's point of view, the power of the GPL is that it forces such clones to share any improvements with the rest of the world, so they can be incorporated back into the original.
Generally, my read of the licenses is:
You can make a derivative work of any project based on one of the popular licenses (i.e. GPL, LGPL, Apache, MIT, BSD).
You may charge money for at least the distribution & packaging of your derivative work.
Depending on the license, you may also have to distribute your modifications in source form and/or include notices in your distribution.
So to your question about Apaxe: yes, you can do this as far as I know. I believe that the Oracle HTTPD server is actually derived from Apache, and it's definitely not free!
Here's my 10,000 foot view of open source licenses:
"Real" open source licenses (eg: MIT, BSD, Apache I think, etc.):
You can do whatever you want with licensing derived works. It can be closed, open, etc. The license places no restrictions on your licensing of derived works.
"Restricted" open source licenses (eg: GPL, LGPL):
Derived works must include specific license restrictions; for example, the GPL requires derived works to be GPL-ed. Essentially your rights are restricted for derived works.
Charging for products is separate from either of these; neither type restricts charging for products, although some licenses place restrictions on the rights you can retain and/or must convey to receivers of your software (ie: the "Restricted" licenses).
Hope this helps.
Edit: Changed by original "DRM" term for GPL type licenses to "Restricted", cause some people attach negative connotations to DRM, and/or cannot grasp how the GPL restricts your rights for derived works in an almost identical way to any other type of DRM (ie: controlling what you can do with it). Seriously, you can be a FSF supporter and still grok the concept that the GPL is more restrictive than "real" open source licenses. The question is not about which type is right or wrong, it's about what the difference is.
Red Hat (and most of the other Linux vendors) charge for support, not for their software - which is primarily how companies can make money off of code that is GPL licensed.
It really depends on the license the open source project uses.
Disclaimer: I am not a lawyer; you should always read the license for full details.
If a project is under the GPL, then anything you derive from it must also be released under the GPL (or a compatible license, and if it is released at all). You're still allowed to charge money for it, but anyone who buys it has to be provided with the full source, and you can't prevent them also selling it, or giving it away for free.
If a project is under the BSD license, you can do pretty much anything with it including incorporate it into a proprietary closed source product. There is BSD code inside Windows!
Other licenses fall somewhere in between.
look at MyEclipse, its really just eclipse+free plugins+myeclipse's plugins and it cost some money.
What prevents from similar ( clone ) products from appearing in the market?
Nothing. The real question is: How can a similar cloned product get more popular than the original product?
Some cases where somebody might clone/fork a project:
Picking up a dead open source project and continuing its development. If the new derived product is maintained regularly and it gets more updates than the original version, then people will start using the new version. This is one of the big benefits of open source - good software does not need to die, just because the original developers stop developing it, but someone else can continue from where they were left. One example of such a project (which I've used) is that the development of Turck MMCache had died out in 2003, so eAccelerator forked it and continued its development in 2004. I'm sure there are lots of other examples.
There is a disagreement in the developer community of an open source project, and the project splits into two. That's why it's best to strive for a common understanding in open source projects, so that the community would not be split needlessly. If a project is split, the projects may continue living if they managed to attract enough developers and users, but otherwise they may slowly die. In general, splitting should be avoided, because it makes the community more fragmented and weaker. IIRC, in the video presentations of Producing Open Source Software (good stuff!) they mentioned a case where the original developer of some project wanted to take a completely new direction in the development, but the community of other developers wanted to keep the old direction. The result was that the original developer was kicked out of the project, so he created a fork of the project, while the rest of the community continued the development of the original project.
A commercial closed source derivative of an open source project which was released under a permissive license (for example BSD). The derived product would need to be considerably better in features or in support than the original product. Otherwise people will prefer using the original open and free product.
Isn't that essentially what red hat does? Even though they have fedora, they are charging money for their linux distribution. Granted, they've written a lot of code for it, it's still based on open source-stuff.