Hot answers tagged

65

First of all, these two statements are made in sequence, not parallel (credit to MSalters for crystallizing this point): Generally speaking, the absence of a license means that the default copyright laws apply. ...if you publish your source code in a public repository on GitHub... you allow others to view and fork your repository. The first ...


39

There is no requirement whatsoever in any version of the GPL to maintain a reference to some upstream project. Imagine if you use substantial code from multiple GPL-licensed projects: the GitHub website only allows one "upstream" pointer anyway. GitHub's upstream link is only a helpful reference and is unrelated to any license requirements.


19

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 ...


18

Forking is not only a possibility of open source development, it's an express intention. If their fork is more popular than yours, this may be because they do something technically better than you, in which case you can merge back their patches if they operate under a compatible license. If they are doing something socially better than you are, take notes ...


18

It would be more correct to state that Chrome is a fork of Chromium. Chromium is an open source web browser available under many different licenses. Many of them are permissive and allow to use it as part of a closed source application. Google Chrome is a closed source web browser based on Chromium. However, Google is the driving force between both ...


18

Oddly enough, I just did this with two repos I wanted to ensure continued access to. So no, it's not a silly idea. However, remember that you have now committed yourself to monitoring the upstream (original) repository, and regularly pulling any new commits to keep your fork up to date. You may also wish to put an explanation in the Description field ...


16

The general term for this type of license is copyleft, share-alike or (pejoratively) viral licenses. The two best-known examples of such licenses are the GNU General Public License (for source code) and the Creative Commons ShareAlike licenses (for any creative content). Note that these licenses sometimes allow you to use an alternate, compatible license ...


16

You should (github) fork when: You intend on submitting pull requests back upstream. The maintainer doesn't like your new feature set, so you decide to add them anyway, and maintain the fork in parallel, routinely merging in changes from upstream as an alternative to the main branch. (Note that you may be required to change the name due to trademark ...


14

What's the difference? Is there a difference at all? The obvious difference is that "derivative (work)" is a legal term, and "fork" is a software term. For example, the musical and motion picture "West Side Story" (by Jerome Robbins, Robert Wise, Arthur Laurents and Ernest Lehman) is a derivative work of the stage play "Romeo and Juliet" (by William ...


14

Well, you actually give up a few rights by accepting the terms of service. The terms of service declare: 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. So effectively you don't have ...


13

Should I list myself as author, and original author as contributor? Or should I somehow refer to the company in general? Or it is legal to only mention myself here (and leave the reference to company in README, which I feel I must do anyway)? The documentation for the package.json file says that The “author” is one person. “contributors” is an array ...


12

The main problem with a private fork is that you now have to do the maintenance work of merging any changes made on the upstream version. This work will become more and more the further your forks diverge because you will encounter more and more conflicts (including some non-obvious ones). There are, however, still situations where you might still want to do ...


12

Forking and starting your own repo and submitting a PR to the current repo are not mutually exclusive. You could do both and decide which branch to keep working on based on the action or inaction of those who have been involved in the past. I think public communication would be preferable. Since there has been no activity in 2-3 years, your public ...


12

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 ...


11

The two fragments you've highlighted contradict each other. The real question is: What will the courts make out of this, if a fork happens, and the original author decides to sue? I am not going to predict the outcome of such a conflict. The court may decide the law is superior to the click-wrap of GitHub's TOS, or vice versa. Nobody will know the answer ...


11

Not after you've been given it. When giving you support, the supporter (the dev in this case) has essentially said "I'm happy with the payment I'm getting for this." If the payment is nothing, fine. They're happy. They can't suddenly change their mind after giving you the support and say "hey pay me for that now" - it'd be like someone giving you a present ...


11

When you release software as open source, it's your intention that others can take it and do whatever they want with it — either as copyleft (where they must do so under the same license) or as permissive software (where they can choose a different license if they want to). Taking the software, changing it (for example, by taking out ads) and sharing it ...


11

It certainly sucks when people take your work and use it in ways against your permission, like copying your copyleft work without also sharing their changes. Fortunately you don't have to go straight to the lawyers, as there are a number of things you can do, and also some things to check, to be safe. Is it worth it? Copyright infringement for software is ...


10

An Open Source license allows forking and redistributing with changes under the (at least) same license under which you got it (though there may be trademark issues). This is one of the fundamental requirements to be Open Source. Using the same license is not necessarily required but depends on the license of the project. A copyleft license like GPL ...


10

With the recent demise of Google Code, I've strived to get a lot of popular repositories that I may potentially use, and host copies of them on Github, or on my own personal computer. I don't really do anything with them, nor do they get any activity. They're just... there. If people are interested, you can ask them to make a fork. I suppose you could put a ...


10

Licenses only matter if there is a conflict between programmers. If programmers don't get in any conflict or dispute, then you can be as informal as you want and everything will go fine. According to The Federalist, "If men were angels, no government would be necessary." But men aren't angels, and that's why licenses exist (to serve as the "law" that guides ...


10

No, you are not allowed to change the copyright notice. Indeed, the license text states pretty clearly: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. But you are allowed to add a copyright notice. If you want to keep the MIT license, which is what I would advise you to do, ...


9

If they're out-competing you, they've got something you haven't. This may be: more updates more in-demand features more contributors better publicity Whatever it is, try to find out what it is. If they're doing more publicity stuff than you, then increase what you do. Run things like community ads on Stack Exchange - they're free, and they get eyeballs on ...


9

There is a third option: Create a fork and publish it under the same license as the original Your changes might not be desirable to the original upstream but that doesn't mean somebody else couldn't find use for them.


9

In Debian, Iceweasel is Firefox once again, since March 10, 2016. There's an Iceweasel branding add-on which can be used to restore the Iceweasel branding. There are some non-cosmetic differences between Mozilla's version and Debian's; you can see all the patches here. You'll find changes which disable "phone-home" features (Firefox health report), change ...


9

The right to fork refers to forking as in taking a software project and maintaining it separately from the original. Having the right to fork a work means having the right to modify your own copy. In the context of freely distributable works, the right to fork means having the right to redistribute modified copies. The practical importance of the right to ...


9

Generally, a fork done without consultation of the original project (and without the intent to merge change back upstream eventually) is called a "hostile fork". Performing a hostile fork is -- as its name suggests -- a socially aggressive move. So long as people have disagreements about the management of open source projects, we will continue to have ...


8

That's pretty basic: an open source license is irrevocable. Code that was released once under the terms of an open source license can always be used under these terms if someone mirrored it so it is still available. If you change your mind it means that you cannot retract your earlier decision. You only can enforce a new license on new contributions, but if ...


8

"Ad supported" is a business model which simply doesn't work for Open Source because anyone can just disable the ads and redistribute the work. If you want to monetize open source software, you need to look for a different approach. For more details, I recommend the question "How can large open source projects be monetized?". However, most of these ...


8

Yes, creating derivatives of a copyrighted work is generally the exclusive right of the copyright holder. If the copyright holder has not licensed this right to you, you don't have the right to create or distribute a derivative. You only have rights that the author is required to offer you under the Github terms of service, which does not include the ability ...


Only top voted, non community-wiki answers of a minimum length are eligible