Hacker News new | past | comments | ask | show | jobs | submit login

The MIT, BSD, and Apache licenses, which Fuchsia uses, have almost no restrictions aside from attribution. Anyone would be able to fork Fuchsia and re-license as GPL.



How exactly does that work, what stops anyone from maintaining a 1:1 branch, the "fork", with upstream and claiming it's GPL?


You can relicense MIT source to GPL. Nothing is stopping anyone from maintaining a relicensed fork like you described. The real question is, would anyone even use or contribute to that fork? (probably not)


That's not a correct statement.

Nothing in the MIT license says that you can claim credit, ownership, or restrict licensing terms on someone else's code.

What you can do, of course, is include the original MIT licensed work in a larger project with other GPL'd pieces. That does not "relicense" anything, and I'm only constrained by the GPL if I use the GPL'd part of the codebase.

I can download X11 from Redhat and still use it under the original terms from MIT.


What everybody needs to learn is the concept of 'derivative works'.

When you combine MIT code with GPL code you are creating a derivative work of involving at least 3 sets of copyrights. Your copyright (since I am assuming you did more then just copy paste), the MIT licensed copyright, and the GPL copyright.

Anybody using that code is subject to those 3 sets of copyrights combined. It's a derivative work of all 3 code bases so it has all 3 copyrights and depend on the original licenses for anybody else to legally copy.

Since the GPL is the most restrictive and disallows any additional restriction then the code base is _effectively_ GPL licensed.


You can view GPL as a bunch of restrictions on top, as I don't think the GPL grants any freedoms the MIT doesn't grant. So why shouldn't you be able to say "you can use my version, but only if you also adhere to the GPL terms"? After all the MIT gives me the right to distribute without any stipulations under which terms the distribution has to take place.


> Nothing in the MIT license says that you can [...] restrict licensing terms

The MIT license explicitly grants the right to sublicense.


That’s different from relicensing the code https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...


Seems people are talking past each other.

The world "relicensing" doesn't exist in copyright, nor in the linked article. Instead there are some similar situation being bunched together and faulty used interchangeably.

A copyright author can redistribute a work they own under new terms. This would be the case when they have offered a work under say MIT and change the copyright license for any future offer under the GPL. It is similar to a merchant changing the price, ie in the past the product cost X but now it cost Y. Naturally past customers don't suddenly have to pay more for something they already paid for, but buying more (or getting updates) applies the new price.

The copyright author can also dual license it. In this case they would offer the work but under two different licenses at the same time. This would be like a merchant offering a product under two payment plans, one where you pay up front and an other more expensive method where you pay a small amount each month for a bigger total. In both cases the product is the same but the condition of sale is different.

The MIT license itself also allows for something similar to resellers, ie people who take a copy and apply their own additional set of conditions when they distribute it. This doesn't change the original offer, but those getting a copy from the reseller has to honor the resellers term and condition in addition to the original conditions of the author. This is similar to going to a store where you pay both the product original price and the margin of the reseller. You can always go to the original manufacturer and only pay the original price, but you may miss out on features that the reseller include in their package.


It kind of defeats the purpose of GPL too. You can't keep future changes to the codebase public and open source since anyone who wants to do so will just not use your fork, so why bother?


Once somebody contributes to the fork the fork contains code that can't be backported to the MIT licenced version. The hope would presumably be that the GPL version grows faster since the GPL version can merge any change to the MIT version but not the other way around.

In practise it wouldn't work all that well unless you pay a development team to push the GPL version significantly ahead, but it's a possibility.


Nothing stops you. These licenses are philosophically very different from the GPL. They tend to be designed to provide literal freedom to do what you want with the code, basically as long as it doesn't interfere with the original use and provides acknowledgement. This includes relicensing it and including it in proprietary products.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: