11

I'm using this script in one of my projects. It's licensed under MIT or Apache 2.

I've committed JSON.sh (as in, just the script) to my project, and copy+pasted the MIT license (as it appears in LICENSE.MIT) to the bottom of it.

Is that sufficient?

2
  • 1
    Are you distributing your project? If so, as open source or proprietary? If your project is open source, which license? Will the project be used / maintained months from now, or even longer? Does JSON.sh represent a significant portion of your project, or is it a tiny little slice? Commented Aug 11, 2015 at 11:45
  • Possible duplicate of programmers.stackexchange.com/q/234511/44761
    – user44761
    Commented Dec 9, 2015 at 19:22

4 Answers 4

6

Yes, what you have done is sufficient.

The README.md states that the project is available under the MIT or Apache License 2.0. That means that you get to choose which license you use. In this case, you have chosen the MIT license, so those are the rules that apply to your use and distribution of the project.

The MIT license requires that "the above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." By including the license in the source file, you have met this obligation.

However, I would recommend putting the text of the MIT license at the top of the JSON.sh file, not at the bottom. From my experience, the license information (whether it's full license text, boilerplate, or a short identifier of some kind) is usually one of the first things in the file. Putting it at the top will make it easier for people to identify that a particular component is MIT licensed.

I would also recommend putting a link back to the original project (or at least the source that you used to obtain the project) somewhere as well. If you are releasing your project under a viral license, this will make it easier for someone to obtain a permissive-licensed copy.

This question also discusses sublicensing a library that is under the MIT license. Some of the information there may be useful to you as well.

1

It is perfectly all right. However you need to be careful.

In the whole code structure if there is only one file LICENSE.MIT, it doesn't make it clear whether it applies to only JSON.sh or other works. Hence ideally you should have your main license file (e.g. LICIENSE) which should mention that grant for JSON.sh is available through LICENSE.JSON.MIT or something like that.

If you are also extending your work under MIT license, then there is no need for duplicate effort.

-1

Whether or not what you have done is sufficient depends on certain details of the JSON.sh project. As I write this (commit 2afb06) there are two major problems with the licensing of that project.

First, both licenses that the authors and contributors seem to want to use (ALv2 and MIT) are improperly applied; both require that each source file (and especially the JSON.sh file) contain certain text referring to the license (or the entire license, in the case of MIT). However, that was not done by any of the contributors.

Second, it is totally unclear whether the licensee (you) are free to choose which of the two licenses to use, or whether both must apply to JSON.sh. In programmer terms, are the two licenses "and"ed or "or"ed together? This matters because if the licenses both apply, then what you have done is not sufficient; you would have to include the Apache License v2 in its entirety in your source distribution, among other things.

I recommend that, since you are a developer, you submit 2 pull requests to the JSON.sh project. The first could add some license text to the JSON.sh file. The second could add an "or" in their README.md, to indicate that licensees have the choice of license. If your PRs are accepted, then the ambiguity disappears and your problem is solved!

7
  • 3
    This is incorrect. First, when multiple licenses are applied, it's never an "and" situation. The recipient gets to choose which of the licenses they choose to use the software under and must adhere to that license. That means that a downstream version may only be available under one of the two licenses, or if the license allows relicensing or sublicensing, a new license entirely.
    – Thomas Owens
    Commented Mar 17, 2016 at 9:52
  • 3
    Second, nothing in the MIT license requires including the license in a source file - it only requires that the license be reproduced in "copies or substantial portions" of the software. A license file meets this intent. The project is a substantial portion. I also don't see an issue with the use of the Apache License. Although most projects do include the full license text, simply because if that link is unavailable, they fail to meet 4a (recipients no longer receive a copy of the license terms). I would not advise what they are doing, but I don't see a problem right now.
    – Thomas Owens
    Commented Mar 17, 2016 at 9:55
  • @ThomasOwens no, it's only "or" if a project is giving you the choice of either license; it's "and" if the project includes different pieces of code which are individually under different licenses. If the project is vague/ambiguous, you cannot safely assume either, not if you want to minimize risk of litigation which you might lose (or which might be too long for you to afford to win) and this answer is very correct to warn about this. This is why lawyers exist. Be more careful, you are underestimating the gaps in your relevant knowledge, and when it comes to law that can be catastrophic.
    – mtraceur
    Commented Jun 28 at 4:35
  • And to be clear, if you act as if it's "or" when it's actually "and" with licenses, that's not just some lawyer-nerd technicality, that's literally a crime (copyright infringement, or patent infringement, or whatever exactly applies in that situation in the relevant jurisdictions)... Which might have severe penalties. And the risk profile is: at any time in the future, anyone who ever significantly contributed to that code under the license you didn't choose might decide they might profit from suing you. Consult a lawyer if you need more accuracy and precision on that.
    – mtraceur
    Commented Jun 28 at 4:55
  • Reason 1 (of 3) for why it seems like it's only ever an "or" situation: most "and" situations involve "compatible" licenses. Like, if a GPL-licensed library vendors an MIT-licensed library, it technically has to propagate both the MIT and the GPL notices, because it's redistribing the MIT part, which is still MIT-licensed (and MIT doesn't allow relicensing). But the GPL is strictly more limiting than the MIT (well, besides details of what notices you must pass along), so for the most part, as a user or developer, you can just mentally treat the whole thing as if it's just licensed under GPL.
    – mtraceur
    Commented Jun 28 at 5:20
-4

It's correct but you should include the licence or a link to it in every file of your software, as specified in the text:

Copyright (c)

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 follow this approach:

  1. create the MIT licence file (something like LICENCE.txt) and put this file on the root of the project
  2. add a link to this file in every file of my project, just a comment with the url to the licence.

I like this approach because is not so expensive and "protect" each file of your software. The comment I use is something like that:

//This code is under MIT licence, you can find the complete file here: www.mylicencefile.com

Anyway GitHub gives you an easy way to add a license to your project, you can read how to do that here.

2
  • 5
    Every file? No! The MIT license is not a viral license that makes every file in ones project open source with the inclusion of MIT-licensed file in the project. Commented Aug 11, 2015 at 11:01
  • Ok, can you explain me how it works? I really don't understand
    – Ema.jar
    Commented Aug 11, 2015 at 12:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.