I often use the MIT license for my projects.

But recently I've had the thought that I really would like to be notified if someone forked my software, whether it's for personal use, released or not I don't really mind or care to restrict. It's more of an ego/motivation thing.

E.g. if I know people are using the stuff I make, I would really like to see their contributions if it's public to possibly incorporate it into mainline. But I don't want to prevent people using it commercially either. Just knowing for what it's being used, and by whom.

Would this still be considered Open Source?

How would you go about modifying the license in this way, that it clearly communicates this desire, and people don't mistake it for the existing MIT license?

  • 6
    No. Put it on github where you can see when other people fork and what they do with it. – Thorbjørn Ravn Andersen Jun 15 '18 at 10:53
  • 15
    Just to add to existing answer (since it is not directly answering a question). Don't require it - ask for it. People are actually more willing to do something on their own will rather than being enforced to. If you put it a part of your license, people will probably sometimes avoid your code for the very reason. Others will ignore it anyway since you're probably in no power to enforce that anyway. But if you ask nicely instead, chances are people will like to share information about their successful implementation with a guy who partially made that possible. – Ister Jun 15 '18 at 12:01
  • 5
    By the way: the MIT license is copyrighted by the MIT, so if you want to modify it, you need to obtain a license for it! – Jörg W Mittag Jun 15 '18 at 12:28
  • 4
    @thorbj it is trivial to just download it and upload it elsewhere, an open source project does not have to be on GitHub – PlasmaHH Jun 15 '18 at 14:47
  • 4
    @ThorbjørnRavnAndersen: No. It is vise versa. Only inexperienced users will fork it using GitHub. The experienced, those who want to fork it without showing that, will just download the repository as an archive. – mentallurg Jun 16 '18 at 12:08

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 increase user freedom - not developer freedom.

One of the specific problems with what you want is that people who can't or won't communicate (for whatever reason) have then lost freedom one. Debian folks have even named this particular issue: they refer to it as the Desert Island test.

Since such a modification would make a licence non-free, the details of how to do it are off-topic for this site.

  • 3
    open source = source code is accessible/available. While often associated with free software, it doesn't exclusively cover just free software. There is also the term "free open source" which specifies that the software is also free besides being open source. And you can have "free software" that is closed source too. – DetlevCM Jun 15 '18 at 8:41
  • 24
    @DetlevCM On this site "free" is to be understood by the Free Software Definition and "open" by the Open Source Definition. While there are pockets of people in the broader free/open community who want to define them differently, these are the dominant definitions, and are not really ambiguous on this site. – curiousdannii Jun 15 '18 at 10:20
  • 3
    When you say "It imposes, and allows of, no constraint in the application of this right" you're of course excluding the rather important constraint that you can't combine the free software with commercial software. Most people I work with consider that a rather fundamental limitation. – Michael Kay Jun 15 '18 at 11:35
  • 6
    This would be the age-old philosophical question of whether true freedom includes the freedom to deprive others of their freedoms. Most don't recognise that as a legitimate exercise of freedom, and so free software's refusal to permit its users to deprive other users of those freedoms tends to be seen as legitimate. But I accept that it is a point capable of argument. – MadHatter Jun 15 '18 at 16:29
  • 1
    @MadHatter I think your first statement contradicts your last. Ideas about what is and is not open source should at least be open for discussion on this site (and this idea is opensource). What you and OP describe relate to freedom not openness. – KalleMP Jun 15 '18 at 20:12

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 licenses regularly know at a glance what they are required to do to use your project.

It may feel like a small change adding in a notification clause, but if you do this it is no longer the MIT license and you now need to create a new OSS license called "Ryan The Leach's super amazing open source license" and noone wants to read through your entire license document to work out what they can and can't do.*

Other people discuss on the internet why you shouldn't write your own open source license and if you look on TLDR legal there's already a whole bunch of them.

*Unless your code is super duper amazing

  • 6
    Doubly true for someone who has to have legal review of the software they use and the licenses it's under -- a corporate lawyer has probably already signed off on the MIT license. The Ryan license needs a whole new set of paperwork. – Charles Duffy Jun 15 '18 at 18:14
  • 2
    Agreed, i've worked in places where using code with standard licenses was hard enough, not alone non-standard ones. That'd have been a flat out No. – GPPK Jun 15 '18 at 20:11

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 hard requirement for you, then I would recommend to keep it out of the license, but to put a nicely worded request in the documentation.

  • "for example, because their government doesn't allow free communication with foreigners" Then one could probably add a provision for that like "you must notify XXX unless external forces beyond ... hinder you". I guess that would effectively fix the mentioned flaw. – Trilarion Jun 18 '18 at 6:31
  • 1
    @Trilarion, that flaw would also be fixed with zero additional legal complication by leaving it out of the license and putting in a nicely worded request in the documentation. – Wildcard Oct 29 '18 at 22:20
  • @Wildcard Absolutely agree, but that does not seem to be the intention of the asker here. He/she seems to be interested in weighing reasonable legal complications with the desire to know more about the usage of the own work. Not sure if even a nicely worded request wouldn't be ignored by most. – Trilarion Oct 29 '18 at 22:59
  • 2
    @Trilarion, the point is that the license clause itself could also be ignored by most. The only reason to put it in the license is to give it legal teeth and make it enforceable. That comes at the cost of reduced circulation (from people's distaste for nonstandard licenses). If you don't intend to enforce it, you're just reducing your potential audience for no good reason. And if you want to carve out big vague exceptions like "external hindering forces," you can't possibly enforce it anyway, so why reduce your audience? Also see opensource.stackexchange.com/a/6968/4550. – Wildcard Oct 30 '18 at 0:28
  • @Wildcard I see your points. The judgment is still somewhat subjective and I could make counterarguments. Ignoring one license clause is equivalent to ignore the whole license. Also your desire to know about the usage might just outweigh your desire to spread your work. Whether it can be made reasonably legally watertight - I don't know. Just look at CC-NC which leaves a lot of room for interpretation and is nevertheless popular. Maybe you want to write a new answer here? – Trilarion Oct 30 '18 at 8:00

To take a slightly different tack, also my first post here so be gentle.

Given the wider complexities of license fine tuning perhaps leave the licence alone and make the software send an ACK to a server somewhere when it is used. While this is usually objectionable behaviour and can send users away it may be acceptable in this situation. Make it do this only once for each instance. Document, test and verify that the routines work. Make this as unobtrusive as possible but let the application data mine the end-user to his comfort level before he sends the ping.

The Heggert field transform algorithm library was developed by Simon Green. He would be pleased to know of cases where the library is used and hopes you can assist. All that is required if for you to select [Send] and a one time notification will be sent to SimonGreen-Heggertfieldtransform@gmail.com. This step is voluntary and you can skip it by selecting [Cancel] or alternately you can recompile the library with #define NO-AKNOWLEDGEMENT or remove the associated code segments completely. The library will attempt to save a local file with the same name as the associated application appended with .acknowledge to avoid repeating this questionnaire. You may provide some of the further suggested details if you like.

Locale [Country, state]
Institution [Name or type]
Contact [Phone or email, if you want to be appraised of bug fixes]
Comments [Any other information you wish to share (max 250 characters)]

[Send] [Cancel]

While this does not answer the exact question the OP posed it may solve his problem in an alternative manner that achieves his actual stated goals of knowing where the routines are used and gaining the desired personal recognition.

  • 1
    What about the GDPR? – Ryan The Leach Jun 18 '18 at 0:45
  • 2
    This behavior might track the users of the software, but not the number of forks (other developers) working on the software, I think. – Trilarion Jun 18 '18 at 6:33
  • 1
    So, what about when someone inevitably forks it and makes no other changes besides removing the notification routines? – Wildcard Oct 29 '18 at 22:22
  • @Trilarion The starting point is that you have no guarantee of things outside the licence model and the MIT licence is what it is. My proposal was to make the best of a limited thing. – KalleMP Nov 1 '18 at 7:21
  • 1
    @RyanTheLeach This technique would not differ from any other in GDPR concern. In many ways it is lighter as the sender gets to decide how much information to send and can be warned about the use thereof. Storage management stays with the requester. – KalleMP Nov 1 '18 at 7:33

Other answers point out the conflict between what you want, and many free/open source/copyleft licenses. But there is a way that might at least partly help you to achieve what you want.

Open licenses relate to the rights of a person given a copy of the code. They don't specify or limit how you yourself distribute the code. For example, you can put a download link on your webpage, together with a request to link to this page (or more recent location) so that anyone else can easily find the latest version, and you can also ask that you are told about any forked or modified versions for personal interest.

This doesn't conflict with any open source licence because it doesn't limit use in any way. Anyone can do what they like, but you'll find that many people will respect it, if asked on the download page.

  • Hmm, not sure if this really helps a lot. Probably the first one to obtain the code this way puts it on Github and all others get it more easily from there then. – Trilarion Jun 18 '18 at 6:35

Other answers point that your license would be open source but it wouldn't be free anymore, and that people don't want to read non standard licenses. Both are true, and good points.

However, there is a better reason why you shouldn't do what you intend to do: your code wouldn't be useful for many people anymore. MIT license is compatible with GPL and similar licenses. Adding a restriction not allowed by GPL (or similar) license prevent your code to be used combined with software with GPL (or similar) licenses.

However, answering your questions:

It still would be open source if you define it as "source is available", but not according to OSI definition.

What I would do to show people that's a different license: name your license with a completely different name, not including MIT in the name, so people can see easily that it is not a standard license. Begin your license with a text like this one:


This license is the same than MIT license, with the following exception: you must notify me, Ryan The Leach, as the original author, if you make any derivative work based on this one. You can notify me mailing to aaa@bbb.com. Given you comply with this point, you can use or change the software in any way allowed by the MIT license.


Here goes the full text of MIT license

I also recommend to include a second paragraph, just before the text of the MIT license:

I will give permission to use this code under standard MIT license (without the exception above) to any person who request it when contacting me, so this code will be compatible with GPL and similar licenses.

This way less people will be discouraged of using your code, and it will be useful for many more people who will be allowed to mix it with GPL code. However, people that make a fork of the fork will not be required to notify you.

  • 4
    Not all software for which source code is publicly available complies with the Open Source Definition. – Charles Duffy Jun 15 '18 at 18:11
  • That second bit is rather clever. Id only change it to more definitive language, and perhaps make the first license gplv3 or something. I.e. this code is licensed under GPLv3, but automatic licensing under MIT is available to anyone notifying the copyright holder of forking, via creating an issue on GitHub. (Should GitHub no longer accept issues, no notification is needed) – Ryan The Leach Jun 15 '18 at 18:29
  • 4
    @RyanTheLeach The technical shortcoming of this plan is that once any person has a copy under MIT terms, that recipient may may freely distribute it under vanilla MIT terms (and those secondhand recipients may further may further redistribute it, and so on) that don't require contacting you. People can still get it from you (and perform the obligatory personal contact) or they may get it from someone else who has already performed the necessary contact, and never contact you. – apsillers Jun 15 '18 at 20:37
  • 2
    I said that what you say will happen in the last sentence – naggety Jun 17 '18 at 10:57
  • 2
    It still would be open source because source code is available. Wrong. This is not the definition of Open Source given by the OSI and used on this site. (That said, the term "open source" is not legally protected, and others have used it differently.) – TRiG Jun 18 '18 at 8:49

If you want your code to stay free/open as per the usual definitions, you should stick to the plain MIT license that you already use, and put your request to be notified somewhere else prominent on the project pages. People who really value your work will at least try to honor your request, and the others you probably don't care about anyways. In any case, since the MIT license comes with an attribution requirement, you could always use Google to find where your code gets used. It may not give you 100% coverage, but at least a good impression on how your code spreads.

  • If you want your code to stay free/open, surely you should use a strong copyleft licence? Your point about googling for attribution only applies if anyone who makes a modified version has an obligation to distribute the source. – MadHatter Jun 15 '18 at 7:53
  • 1
    @MadHatter The source may never make it to Googles awareness even so. – KalleMP Jun 15 '18 at 20:07


Do not ever put "I really would like" items into a license proper. What belongs in a license are things you feel strong enough about to be willing to sue over (or some prospective future copyright holder other than you). Everything else is just causing trouble while weakening people's respects of licensing terms.

Many open source licenses are public licenses where any downstream contributors have the same rights as the initial copyright holder reserves for himself. If everyone could add a postcard requirement, compliance would get harder and harder over the lifetime of software both because contributors grow in number while their reachability declines: addresses often go stale.

This kind of unintentional consequence is a good reason to stick with tried licenses.

Outside of licensing proper, you can add "I would appreciate getting to hear..." requests in vicinity of the license or in general documentation. The ratio of users actually heeding such requests tends to be minuscule so that is sort-of a recipe for frustration.

It's often easier to set up mailing lists for users, development and bug reports and solicit further development. The fraction of feedback gotten in this manner is still a minor fraction of the actual user base, but the interaction tends to me more active and gives you more of a clue what people are using the software for than a "thankyou" card would.

  • 1
    Have to heavily disagree. Just because I'm using loose language while talking about ideation or asking a question, doesn't mean that stuff isn't still important. Honestly half the stuff I write that I release I wouldn't be willing to sue over for any reason. If I really felt that strongly it wouldn't be released or OS in the first place. – Ryan The Leach Jun 17 '18 at 9:45

Two suggestions for the “middle path”, keeping an open source license and still getting a bit of intel where your code is at works:

(1) You can force people to make their modified versions available with the GNU AGPL license:

The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.

This is a true and tested open source license, even recommended by the FSF.

It does, however, not contain a “back channel”, i.e., the forced feedback, when a developer uses your code. He just has to make the code available, but doesn’t need to notify you.

(2) The other possibility is, that you move your code off Github or a publicly available website and make it available, still free of charge if you like, only if someone leaves his e-mail address. The classical “I’ll mail you the download link” solution. That way you still don’t see, what exactly people are building, but you know, who (most of) them are and you can still use a traditional open source license for the code.

In combination with the AGPL you can then dig deeper if you’re interested (maybe a developer used an @large-company.com e-mail and you want to see, what they’re doing. Then simply drop them a line asking for the download link of their version.)

  • 2
    The AGPL only applies to those accessing an app over a network, so it doesn't apply to everything. – curiousdannii Jun 16 '18 at 22:45

Your Answer

