Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

WARNING. Tipsy is not MIT licensed, it has additional restriction, in ideas similar to GNU GPL #124

Closed
senotrusov opened this Issue · 4 comments

2 participants

@senotrusov

Tipsy in first line of README.md has misleading statement

Released under The MIT License.

Effectifly it is not. At the bottom of the same README.md file there is a statement which put additional restriction:

By forking this project you hereby grant permission for any commits to your fork to be merged back into this repository and, with attribution, be released under the terms of the MIT License.

So, anyone who is "forking" tipsy MUST grant permission to release code back under the terms of MIT license. This restriction has ideas similar to GNU GPL licence and put sensitive limits on library usage and adoptation.

Is it unacceptable to some environments to use code with such restrictions.

Another issue is that statement is questionable from the legal standpoint. For example the meaning of term "forking" is not well defined.

If the original intension was to cleary define licence of code pushed back by contributors i sugest you to define developer policy as in, for example LLVM project:

As a contributor to the project, you agree that any contributions be licensed under the terms of the corresponding subproject. (source)

Another option is to use Apache 2.0 license. From wikipedia:

The Apache License is permissive, so it does not require modified versions of the software to be distributed using the same license (unlike copyleft licenses - see comparison).

Unless explicitly stated otherwise, any contributions submitted by a licensee to a licensor will be under the terms of the license without any terms and conditions

Like any free software license, the Apache License allows the user of the software the freedom to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software, under the terms of the license.

Hope you clarify on that issue. Thank you.

@jaz303 jaz303 referenced this issue from a commit
@jaz303 Update README.md
Removed forking section of readme for now (see #124)
3545aa6
@senotrusov

Thank you for such immediate response!

@senotrusov senotrusov closed this
@jaz303
Owner

Sorry, good point, I should have considered the implications more thoroughly when I added this clause to the README, I've removed it for now.

I agree that "forking" is a term alien to established legal lexicon, and could apply to numerous acts - an explicit Github "fork", merely cloning the repo, or cloning and publicly hosting elsewhere (whether in git or not). For clarity, it is only the first of these I was interested in, and furthermore, there was no desire for perpetuity - the obligation would persist for only so long as the public fork existed; there was never any intention of creating GPL-like virality (obviously, courts don't really like nebulous idea of "intent" in contacts, and prefer to examine what is actually written...).

What I was trying to address was the (IMO) grey-area of casual forking (casual forking is rampant these days, all the kids are doing it...), which is breeding murky legal waters. In the absence of a pull-request, is there a tacit assumption that I can cherry-pick a couple of commits back? Or do I need to ask permission? If permission is granted, what distribution rights are granted? Remember, the MIT License isn't viral, and just posting stuff publicly doesn't make it fair-game for copying (legally). Even in the presence of a pull-request, what's the situation? (although thank you for pointing me to the Apache license - this seems to address the second case). These are inter-jursidictional questions with non-trivial answers (although maybe the Github TOS addresses these, I have to confess TL;DR on this one), so my intention was simply streamlining: if you're hosting a public fork, I can merge commits back.

Perhaps a better wording would have been "by maintaining a public fork of this repository on Github, you agree that for the duration of the fork's existence, any of public commits to the same repository may be merged back to the master repository and released, with attribution, under the same license terms as the original project". I don't believe this would be incompatible with the terms of the MIT License, as it says nothing about the source code itself - just the repository and actions taken thereon, which could be regarded as a separate entity. That's the argument I'd make if I was still pursuing a legal career :)

Anyway I'll stop rambling. Thank you for bringing this up, it's an interesting subject for discussion.

@senotrusov

It's the interesting question, indeed.

I think even if you clarify in a manner like

"by maintaining a public fork of this repository on Github, you agree that for the duration of the fork's existence, any of public commits to the same repository may be merged back to the master repository and released, with attribution, under the same license terms as the original project"

it is still a licence restriction and technically the work must be labeled not "MIT licensed" but "MIT license with additional restrictions", which is not looks good.

Then someone who want to license the product must review that additional restrictions and consider it acceptance.

In the case of corporate environment there may be a defined policy on usage of MIT/BSD/Apache2 licensed components but for such restricted cases a separate review must be done by some kind of law specialist. Don't think such complications ease the product adoption.

For the topic of cherry-picking from public forks, one point of view is that by forking library and making the fork publicly available with the same license terms as in original product, someone is effectively distribute product and his modifications to it by the terms of original license. And if the license is permissive like MIT/BSD then the original product owner may use that derived product to merge back some changes.

But that point of view may be run into some unpleasant person who just like "I dont publish and distribute anything, i just mindlessly click that nice fork button and then do my very expensive and indeed talented work, and then you just stole it back to your product! So face my lawsuit!".

For that terrible cases one idea for github and other hosting providers is to educate users on that topic and make them do some explicit statement on distribution and license terms when someone making the fork or public repository.

Before that, think it is better safe then sorry - and ask for a pull request is the way to acquire changes from forks.

For my cases, Apache 2.0 license covers derived works and contributions in a nice manner, glad you found it interesting.

@jaz303
Owner

Agreed on all points, especially this:

For that terrible cases one idea for github and other hosting providers is to educate users on that topic and make them do some explicit statement on distribution and license terms when someone making the fork or public repository.

I shall consider a change to the Apache 2 license for my projects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.