115
When talking about BSD license, you have to be aware that there is not one, but actually four different BSD licenses. The most basic is the zero-clause BSD license which is basically a public domain license. It doesn't even require attribution:
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby ...
46
I cannot say whether this would be considered open source, but it would not be free software. Free software confers, amongst other things, the right to modify the software; the FSF refer to this as freedom one. It imposes, and allows of, no constraint in the application of this right; constraints on the four freedoms are generally allowed only when they ...
37
You just include the licence in your software, no registration needed. Your software is always copyright protected, you state the terms of use through a licence.
30
Yes
VSCode
Mureinik already pointed out that VSCode is licensed under the MIT license, which is a permissive license. To quote from it (emphasis mine):
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, ...
26
Your question suggests that you regard copyrights as property rights. This is a completely understandable misconception - big content creators push this agenda quite hard - but it is a misconception. Copyright is instead a system of time-limited monopolies on certain acts which the law grants to copyright holders for the ultimate purpose of encouraging ...
24
No; incorporating or linking against GPL requires that your project-as-a-whole be distributed under GPL. But you can include MIT licensed parts (or another GPL-compatible license) in the project. Also, it depends.
The pertinent clause is 5 (c):
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a ...
24
I posted an answer to the announcement post that pretty much sums up why part of this - the exception - is a bad idea:
You're essentially creating a crayon license.
If you modify the terms of an existing license, you create what is known as a crayon license. Those are a problem - see "How can a “crayon” license be a problem?" for the reasons why.
...
23
You don't "obtain" a licence. It's not a licence like a driver's licence that gives you permission to do something; rather, the license you apply to your software is you giving permission for other people to do something. So, just like your driver's licence is the government saying, "You have our permission to drive a car, as long as you behave in certain ...
23
There is not much which would disallow that. The MIT license is pretty liberal and as long as one obeys the requirement to display the copyright notice in the product appropriately, there's not much one could do against that other than offering the better product and/or service.
See also the excellent answer by congusbongus in this similar question as well ...
20
That depends.
If you didn't make any changes in your fork of the project, you can just update your fork to include the latest upstream changes and get the license change along with it.
If the copyrights on the changes made on your fork are all owned by you, and you agree with re-licensing those changes under the MIT license, then you can merge the upstream ...
19
The freedom to modify a piece of software is an essential open-source freedom covered by any open-source license, specifically the MIT License which VSCode is licensed under.
In other words - you most certainly can do this.
19
Firstly, this is against the spirit of open source; if you don't want people exploiting your work without paying you, don't use open source licenses in the first place.
rebranding
However, you do have one option: you can protect the branding itself by registering the name as a trademark.
"Red Hat" is a trademark. Other people can't call their ...
18
Depending on how they chose to provide their fork, yes.
The MIT license, which you chose to license your work under, doesn't prevent anyone downstream from changing the license, nor from changing the license of a derivative - unlike a copyleft license such as the GPL. They can essentially license their fork how they like.
If they relicense it under CC BY-...
18
The important thing to know is that they (almost certainly (*)) cannot retroactively change the license of the version that you are using. They can change the license to new versions they release. So, if you want to keep using what you took when it was marked MIT, you are fine. You can even make a fork and invite other like-minded people to enhance and ...
18
It's correct but unnecessary. It's there for clarity.
When you do some work, the default copyright position is all rights reserved. Nobody can do anything with your work without your express permission, or a license to do so.
The MIT license is your license to other people, to make it clear what they can do. However, any rights not explicitly granted by ...
18
I think you've answered your own question...
While you don't need to disclose your source code, you'll need to mention/acknowledge the MIT software. It's simple, copy the MIT license for the library to your distribution.
18
Do not use non-standard opensource licenses
The other answers are great, and show that what you want to do is probably not too far down an OSS route but here is a different viewpoint.
There's a reason you use MIT license at the moment, because it fits (the majority, noted) of license requirements you are happy to put on your project. Others who use OSS ...
18
As the copyright holder you are in no way bound by any open source license you choose to distribute your own work under.
While you cannot retroactively change the license terms of a particular distribution of your software for those who have already obtained it, you can permit use and re-distribution under the terms of a more permissive license of any ...
17
The MIT license is so simple, you should be able to find the answer to your questions by just reading it. It has only one requirement:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
This means that you have no obligation to specify that a program is a derivative work, nor to ...
17
If your rights to a piece of software derive solely from the GPL -- and this is the usual case for most people who are redistributing GPL software -- then you cannot legally relicense under MIT, BSD, Apache or LGPL, because the GPL does not allow that.
Special cases are possible, of course. If you own the copyright on a piece of software and have not ...
16
Substantial portion is a legal term. Its exact definition will depend on jurisdiction, be subject to interpretation and possibly including subjective analyses. When in doubt, ask a lawyer. To err on the safe side, assume that it applies to any portion, no matter the size.
To give you a random example, here's what Wikipedia has to say for Canadian copyright ...
16
I'm surprised this question doesn't come up more often. It's a tricky issue, and one that is highly open to interpretation.
Disclaimer: I am not a lawyer.
There is not a lot of specific guidance on this issue, but a well-researched overview of the topic was published by The International Free and Open Source Software Law Review, titled "Open source ...
16
The MIT license doesn't require source code to be published. It only requires that the license notice is kept intact. MIT-licensed binaries without source code are rare – no source kinda defeats the purpose of open source – but it's also not the first time I've heard about this construction.
Even for licenses like the GPL that do require source code, it's ...
15
The copyright line isn't actually part of the license, it's a separate entity. So changing that doesn't change the license. In fact "©" is the correct form, so that change at least counts as an improvement in my book.
Beyond that though I'd stick to the canonical form of the license if there is one. The MIT license itself has many slight variants, so the ...
14
There's no legal problem doing that, but it is confusing, and it's almost inevitable that some people will think the MIT license will apply to the whole repository.
This is a situation where a git submodule would make sense - split out the MIT licensed code into its own repository, and link to it with a submodule. Your local folder structure won't have to ...
14
Just like everyone can take your MIT-licensed software and make it proprietary without having to ask all of its authors for permission, you can take your MIT-licensed software and license it under the GPL without asking the contributors.
MIT-licensed software can be integrated/made into GPL-licensed software. The other way around is not possible.
The FSF ...
14
Your assumptions are mostly correct but you can make things a tad simpler...
You are de-facto creating a new package, so you should update your package.json such that it is clear it is something different and a new package. Your users will be thankful for this.
The MIT license requirements are quite minimal: just keep a copy of the copyright and license ...
14
Selling licence exceptions, usually to copyleft licences, is a perfectly normal (though arguably somewhat distasteful) practice. Provided the developer is the sole rightsholder in the package, or has some other lawful means to re-license (eg CTA, or CLA that permits this, on all contributions) then this is a perfectly lawful thing to do..
The licence ...
13
Adding a requirement to notify you when a fork is being made renders a license non-free. The reasoning behind this is that the requirement discriminates against people that, for whatever reason, are not able to send the required notification (for example, because their government doesn't allow free communication with foreigners).
If being notified is not a ...
Only top voted, non community-wiki answers of a minimum length are eligible
