6

I recently received a "surprise" email asking a question about one of my GPL'ed projects, and referring to code downloaded from https://github.com/icaoberg/mimetex/ That was the first I ever heard about that GitHub project! Moreover, that code's now out-of-date compared with the code that I've been maintaining (ever since I originally wrote every single line of it) at http://www.forkosh.com/mimetex.html

Rereading the GPL, as best I can interpret it, I don't see it prohibiting that GitHub project... But I'd like to prohibit it! That is, you can use my code for your own purposes, under the GPL license restrictions, but I don't want you simply re-releasing it as your GitHub (or any other similar repository) fork or project. Especially not when your fork just lies there and gets stale. But really not at all: I'll be the maintainer of my code.

So How do I say that, license-wise? Right now, my code has a GPL comment block at the very top that looks like this:

/****************************************************************************
 *
 * Copyright(c) 2002-2017, John Forkosh Associates, Inc. All rights reserved.
 *           http://www.forkosh.com   mailto: john@forkosh.com
 * --------------------------------------------------------------------------
 * This file is part of mimeTeX, which is free software. You may redistribute
 * and/or modify it under the terms of the GNU General Public License,
 * version 3 or later, as published by the Free Software Foundation.
 *      MimeTeX is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY, not even the implied warranty of MERCHANTABILITY.
 * See the GNU General Public License for specific details.
 *      By using mimeTeX, you warrant that you have read, understood and
 * agreed to these terms and conditions, and that you possess the legal
 * right and ability to enter into this agreement and to use mimeTeX
 * in accordance with it.
 *      Your mimetex.zip distribution file should contain the file COPYING,
 * an ascii text copy of the GNU General Public License, version 3.
 * If not, point your browser to  http://www.gnu.org/licenses/
 * or write to the Free Software Foundation, Inc.,
 * 59 Temple Place, Suite 330,  Boston, MA 02111-1307 USA.
 * --------------------------------------------------------------------------
 * etc */

How can I modify that to incorporate these desired ideas?

 Edit
-------
As per comment to Steve Barnes, below...

I guess I should have made my objections clearer. The fork didn't bother me, per se. Indeed, it would be flattering if other developers picked up my code and kept working on it. But this guy just copied it to GitHub and never touched it, not then and not later. So it got stale. If you're going to fork a project, you should actually intend to do something, not just leave it for other people to unknowingly download years-old stale code, leaving the original developer to explain the problem. Why should I have to do more work because of his laziness, not even bothering to keep his own fork up-to-date?

Mureinik
  • 5,112
  • 3
  • 31
  • 42
John Forkosh
  • 845
  • 6
  • 11
  • 26
    If you don't want people copying, modifying and releasing your code, in what way is it open source? Just use a private/commercial license if you want to restrict use. – Brandin Nov 10 '17 at 10:00
  • 5
    Another option is to release the code freely but protect a trademark. Normally to do this you will have to register your trademark and then actively protect it. Basically, you can permit people to copy and release your code, but not to use your trademark. – Brandin Nov 10 '17 at 10:04
  • @Brandin It's open source because you're given the source. For free. And you can modify it, etc, etc, under all the usual gpl restrictions. But this guy just uploaded it, not modified at all, to github. And when code's on github, lots of people just assume that's the official copy. But it's just a stale five-year-old copy, with bugs that I've fixed long ago. The current code is only available from my site, where I maintain it, and which is the real official site. That github fork is unmaintained and stale, and really should just be removed. Shouldn't have been put there in the first place. – John Forkosh Nov 10 '17 at 10:08
  • @Brandin re trademark. That's quite a pain in the elbow. The jf logo in the upper-left of my homepage http://www.forkosh.com is indeed trademarked. That's an initial $375 fee and a long application, plus another $100 that you have to remember to file (with another long application) during the fifth year after initial registration. Copyright's much, much simpler -- just a one-time $35 fee, with all the paperwork online. – John Forkosh Nov 10 '17 at 10:13
  • 12
    I just clicked on the link and the author was pretty clear about attribution on the front page "A fork of mimetex from John Forkosh." so I don't personally see where someone could get confused. The fault lies in whoever didn't read that message. You could restrict people from redistributing code, but then it wouldn't be open source anymore and therefore off-topic here. – Brandin Nov 10 '17 at 10:13
  • @Brandin That's true, he is clear that I'm the original author. He's also clear that every single file says "untested by me". As far as I can tell, this guy did absolutely nothing except put a copy of my code on github without ever even bothering to tell me. And then he forgot all about it, and that code got stale. And then I got an email from someone using that stale code, and had to deal with the problems he caused. So I think it's perfectly reasonable for me to try to plug that kind of loophole. I wouldn't mind a legitimate fork with active developers, but this wasn't that!!! – John Forkosh Nov 10 '17 at 10:20
  • Let us continue this discussion in chat. – Brandin Nov 10 '17 at 10:21
  • @Brandin No need. I don't want to get into an extended discussion. I feel the way I feel about it, and nothing's going to change that. And I think I've explained my feelings just about as completely as I can explain them. – John Forkosh Nov 10 '17 at 10:22
  • 12
    This is not a forum for "Explaining your feelings." Yes, I can see how you could possibly be annoyed. But it doesn't matter. If it is open source, then others may copy it. Maybe they copy it and make no changes, or maybe they copy it and add tons of bugs. The best is that they make it clear "this is a fork" so that you everyone knows. And in this case that was done, so I think the real problem is the person who didn't even bother to read the attribution notice. – Brandin Nov 10 '17 at 10:25
  • 4
    I'm voting to close this question as off-topic because the requested restrictions put it outside the Free Software Definition. – curiousdannii Apr 13 '18 at 03:27
  • I think your only option would be the part of the Debian Free Software Guidelines via the "Integrity of The Author's Source Code" part, which includes "The license may require derived works to carry a different name or version number from the original software." But I'm not aware of any F/OSS licenses that actually contain that clause.... – ivanivan Sep 26 '18 at 21:32
  • Before letting people open an issue on your project, they should read a statement, that you do not give support for 3rd party forks of your project. If you have received an e-mail regarding a faulty 3rd party fork, you should shortly mail back 1 sentence, telling the sender that they should download your original project, instead of the 3rd party fork. That's it. Yes, it's a bit more work, but if you put huge statements all over the place, stating, that people should use your original project, then the work expected will be kept to a minimum. – Akito Oct 28 '21 at 18:51
  • @Akito You know that this thread is four years old, right? Anyway, yeah, like you said, "shortly mail back 1 sentence, telling the sender that they should download your original" (actually, download my current) is exactly what I did, along with asking him whether or not the current version already fixed his problem. And he shortly mailed back that, yes, the problem he'd experienced with the stale github code was already fixed. So I posted the question thinking this could be a general problem -- people uploading projects to github and then not maintaining them, leading to bugs already fixed. – John Forkosh Oct 30 '21 at 05:20

7 Answers7

29

Once you have Open Sourced some code other people can, and probably will, place it on other hosting services and there have been many times when everybody has been grateful for this because the original maintainer has moved on, lost interest or otherwise stopped maintaining the code and their original hosting has stopped.

If you find an out of date copy of your code on GitHub simply raise a ticket to point people to the maintained copy or better yet fork their GitHub project to one of your own and double push your changes to your normal location and to your GitHub one. When people see a branch that is years later and 100s of pushes in advance of their one they will mostly use it. The additional benefit is that you might get some PRs from your GitHub repo that reduce your own maintenance effort.

To reduce your efforts

Personally I would also look at setting a mail auto-responder/rule that looks for the URL of the stale branch in the body of any message and automatically replies with something along the lines of "If you are reporting a bug found in the code at httt.... please try the current, up to date code at .... before filing bug reports at ....."

Steve Barnes
  • 739
  • 5
  • 7
  • Thanks, Steve. I guess I should have made it clearer that the fork didn't bother me, per se. Indeed, it would be flattering if other developers picked up my code and kept working on it. But this guy just copied it to github and never touched it, not then and not later. So it got stale. If you're going to fork it, you should actually do something, not just leave it for other people to unknowingly download years-old stale code, leaving the original developer to explain the problem. Why should I have to do more work because of his laziness, not even bothering to keep his own fork up-to-date? – John Forkosh Nov 11 '17 at 07:14
  • 2
    At least raising an issue on their fork will let people know where to go - I forgot to mention one more point - adding it now. – Steve Barnes Nov 11 '17 at 07:18
  • 1
    Thanks again, Steve. Yeah, I already have a procmail script that auto-replies to emails whose subject contains "mimetex" (and doesn't contain "noautoreply"), to answer the most often-asked questions, which had been getting tiresome to repeatedly answer manually. Modifying it to incorporate your suggestion should be pretty easy. – John Forkosh Nov 11 '17 at 07:44
  • 4
    @JohnForkosh It's obvious from the GitHub repo you are complaining about when it was updated (All files say "updated 3 years ago."). The precompiled binaries on your site, however, are even older. So one could say that the official site is not up-to-date either. Of course, as maintainer that is your prerogative. – Brandin Nov 11 '17 at 10:14
  • @Brandin Yes, I'd noticed that "updated 3 years ago" myself. But the source that's actually there is from 2012, not from 2014, and I'd done about half a dozen fixes/updates during the intervening two years. So, for one reason or another, three years ago this guy updated his repository with code that was already two years old at the time. Go figure. – John Forkosh Nov 12 '17 at 07:45
  • 1
    @Brandin Re the precompiled binaries, yeah, I'd given up on them and should probably take them down. I no longer have any vaxstations or alphas to compile the VMS versions. And, at the moment, no windows boxes to conveniently compile a new win version (though I could easily get my hands on one if I really cared). And I thus haven't bothered keeping the linux binaries updated either -- anybody running linux has gcc (and if they can't type the one single line necessary to compile mimetex, they probably can't install a cgi either:). – John Forkosh Nov 12 '17 at 08:08
  • 2
    @JohnForkosh For windows builds it might be worth while looking into a free Appveyor account - https://ci.appveyor.com/signup/free which will automatically build your windows executables if you are using GitHub or BitBucket, (you can add a step to trigger a build if you are using other hosting). – Steve Barnes Nov 12 '17 at 09:49
  • 1
    I found this question by accident in 2023: it seems the author's website is down, while the GitHub repo is still online. This fact proves your point quite well. – Andrea Lazzarotto Jun 14 '23 at 09:37
25

Bob wrote a GPL-licensed media player that I really liked, FooPlayer v1.0. Then Bob "updated" FooPlayer to 2.0 and decided to put ads in the software. He stopped offering the original 1.0 altogether. I didn't like that, so I found an old copy of 1.0 I had downloaded last year and uploaded it to GitHub.

What part of this process do you want to prevent? What you want simply isn't an open source license. As a licensee of an open source project I expect (and, indeed, am required to receive, per the Open Source Definition)

  1. the right to post an older version of the code that I like better,
  2. the right to publicly archive the project in case it disappears, and
  3. to be free from the onus of updating my mirror of a project if it happens to fall out of sync with mainline development (and if the project experiences a major fork, which branch am I supposed to sync with anyway?)

You are free to write a license that doesn't grant these rights, but you will not find a FLOSS license that suits your needs.

You are free to ask the maintainer of a clone of your project to please keep it up to date, or link to the "mainline" origin the you personally prefer, or to take down the out-of-date repo if it serves no purpose but to cause minor confusion. The maintainer of the copy is free to refuse. If your request is reasonable to them, they'll probably help you out. If instead the maintainer refuses your demands, seriously consider that they may have good reasons, and the license is operating exactly as intended -- after all, I am very proud to be hosting the ad-free FooPlayer 1.0, despite Bob's request that I take it down

apsillers
  • 35,995
  • 4
  • 94
  • 131
  • Thanks for your remarks. In my case, the situation's exactly like you describe with, "the out-of-date repo...serves no purpose but to cause minor confusion". There are no ads, no nothing of that nature. Yeah, I guess I'll just ask the guy to take it down. – John Forkosh Nov 12 '17 at 08:17
  • 2
    @JohnForkosh The example about ads was only an example. If it is an open source, the rights include permission to copy and redistribute older versions. The older version was not posted to cause confusion and clearly indicates the original author. Rather than ask the forker to take it down, it would be more reasonable to ask him to update it to version x.yz or the latest version. Before that you should probably update your site to make it clear which version is the latest. – Brandin Nov 13 '17 at 11:41
  • 4
    @JohnForkosh Sure, I only meant to show (though I could have made more explicit) that there is no way to avoid the case you now face without also blocking the very helpful case in my answer. This fork and my hypothetical no-ads fork are mechanically indistinguishable; the only difference is the intent of the person doing the fork, which isn't something you can easily regulate in a legally-sound license. – apsillers Nov 13 '17 at 13:12
  • I've had the much more reasonable situation of a community of users of my software who want to carry on using an old version because it runs on a platform that I no longer wish to support. The only problem for me is that people outside that community don't always realise that they are using an ancient version, which causes reputational damage. – Michael Kay Aug 06 '19 at 15:37
10

As long as you use open source your wish is impossible. Actually it is essential part of open source to allow the easy access and publish ability of the source code. Todo so without notifying the original author.

The are some limitations, e.g. changing the license, using in combination with some other licenses, switching the author ...

You have no right to let this version on github removed. But just ask the guy publishing to add a line to README to add you as author and the age of it, were the actual current code is. You can also ask to remove it. But the later is actually non open source.

openCage
  • 583
  • 3
  • 11
  • Okay, but how would you feel as an end user, downloading a program you wanted to use, installing it, and then finding it had a bug, and then taking the trouble to document the bug and emailing the author, just to find out you'd downloaded stale code, and the bug had been fixed years ago? Moreover, I didn't ask the user who emailed me, but I'd guess he first emailed the guy who forked the code, and got no answer or an inadequate answer. I guess there should be some better form of "source/version control" for forks, not just willy-nilly copying projects all over the place. – John Forkosh Nov 11 '17 at 07:34
  • 6
    @JohnForkosh According to the README in the "stale" GitHub repository, the version there is "Version 1.74", while the .zip file from your Web site also says in its README "Version 1.74." So as an end user I would assume they are the same version. I notice your Web page itself says "(for mimeTeX version 1.75)" so maybe something in your distribution is also out of date. Putting the version number in the file name would also help. E.g. mimetex-1.75.zip. – Brandin Nov 11 '17 at 10:06
  • 1
    @Brandin Oops, my bad re the readme, which I apparently haven't kept up-to-date. But the code itself says "version 1.76, last revised 11 July 2017" (and mimetex's \version command dynamically displays that info). – John Forkosh Nov 12 '17 at 07:58
9

What you can do is require the users to

use my code as per the GNU GPL, but don't put it on GitHub under the same name

Such a policy can be implemented using a trademark. GPL doesn't allow you to restrict source code distribution, but it doesn't prevent you from protecting your software's name (and the logo, if your software has one) from unauthorized use.

Note that while most businesses register their trade marks to insure their legal status (and pay registration and renewal fees), there's no strict requirement to do that. At the very least, it is advised to use the trademark legend (™) after the name of your software (that is, mimeTeX™) to show your intention to use the said name as a trade mark.

Then, if someone makes your software available under the same name, you can ask them to rename their project, or clearly state in the description where the original project is hosted, and follow up with GitHub if they refuse. You'll have to provide reasonable proofs of ownership and precedence of your site over the GitHub repo if you want to succeed. If, as you say, the GitHub repo contains an older version from your site, and your site made it to the web archives, that should not be too difficult.

If both the author and GitHub turn down your request, the only recourse you have is to dispute the trademark rights in court. That's how Python project managed to dispute the domain name python.co.uk (they didn't have a registered trade mark at the time, just like you). It will require quite a bit of effort and investment, and sometimes is not possible at all depending on country laws involved. For a personal / hobby project, you will probably choose to avoid that fight.

Dmitry Grigoryev
  • 1,362
  • 10
  • 20
  • 1
    Thanks for the additional suggestion, Dmitry. Yeah, I have my s-corp's logo trademarked (see http://www.forkosh.com upper-left corner), which cost $375USD in the 1980's plus $100 in the fifth year after registration. I also copyrighted the logo using the Visual Arts (VA) copyright form (which was just $35 in the 1980's). And I always officially copyright (using Form TX) all my GPL'ed software, but trademarking it is a bit more effort than I'd usually care to do. However, if some program I write ever strikes me as a potentially serious commercial venture, then I may very well do that. Thanks. – John Forkosh Mar 08 '19 at 03:45
  • This is probably not workable unless you internally create a distinction between your trademarked product and its open source components. Ie, the GPL does not let you require that someone do a global rename on the code before sharing it in accordance with the GPL. Or you can have a dual license where you alone are allowed to have a proprietary version; but that limits your ability to incorporate other GPL pieces, and may limit contributions. – Chris Stratton Aug 05 '19 at 15:26
  • @ChrisStratton: It should be workable to (1) include a link to the official site in the official branch and (2) require that modified versions use a different name under clause 5 of GPLv3. In fact, you can also require modified versions to include a link to the official distribution, under clause 7b of GPLv3. However none of this can be done retroactively. – Ben Voigt Aug 05 '19 at 16:14
  • @BenVoigt Section 5 requires a notice that a modification has been made, it does not prevent keeping the basic project name embedded in the code and it does not even cover the situation at hand where it no modification has been made. A true fork should probably get a new or at least hyphenated name, a simple bugfix less so, a mere archive needs no change. Section 7 requires keeping notices intact, if that originally included a link they they could not remove it, but it doesn't allow forcing someone to keep a link up to date if the location changes, or, as you did say, to add one now. – Chris Stratton Aug 05 '19 at 16:38
  • 2
    Consider for example the usual case where someone "mechanically" forks a project on github, makes a bug fix, and submits a pull request. No renaming is appropriate, and in fact a rename that touched any contents (vs external metadata controlling what github calls it) would make a mess of pull requests. It doesn't actually matter if the original is not on github. Remember the original intent of the GPL is for software to have user-maintainable parts inside. The goal is to establish a right of repair and to share the repair, but yes it is necessary to avoid misleading recipients. – Chris Stratton Aug 05 '19 at 16:51
  • @ChrisStratton: Those cases (no modification, or a patch intended for submission to upstream) would be covered by the requirement to link to the official distribution. Which like I said, is compatible with GPL but cannot be enforced retroactively.\ – Ben Voigt Aug 05 '19 at 17:01
  • @BenVoigt it doesn't seem like that would satisfy the asker's GPL-incompatible goals, as it happens that the project already contains an original README giving the original web site and original author's email and in fact the commit message shown at top level for most of the files in the repo begins "Original download from www.forkosh.com. I have not tested personally …" That repo seems to be doing exactly what the GPL encourages - the "issue" is with the asker. – Chris Stratton Aug 05 '19 at 17:12
  • @ChrisStratton: The problem is that it's hidden away in the README. If OP had put the requirement in the license, then the person setting up the GitHub project page could have been required to put that link on the project page, project summary, project wiki, ... Also, there's a difference between "Original download from ..." and "For official downloads of XYZ visit ...". OP could have controlled the wording in a way compatible with GPL, if that had been done up-front. – Ben Voigt Aug 05 '19 at 19:04
  • @BenVoigt - nope, you really can't make such a requirement that a webserver show show one file in preference to another. The author's notification is in the source code being served; it happens that github displays README.md with the repo owners wording (that credits the original author) and not the umodified README from the original author that is also there - if anything that is a good thing as it clarifies. The real root of the problem is that the original author seemingly can't be bothered to provide their code via a distributed VCS, so someone else stepped up to fix that "bug" – Chris Stratton Aug 05 '19 at 19:20
  • @ChrisStratton: It's not a requirement that the webserver show README in preference to README.md, it is a requirement that anyone creating a fork place the attribution notice at the top of README.md. Clause 5b -- The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”. A README.md that doesn't emphasize the link to the official distribution page would violate the license and be subject to takedown. – Ben Voigt Aug 05 '19 at 21:42
  • @BenVoigt - no, it wouldn't. Because the author's README is retained, fully satisfying the notice requirement. The README.md is basically a post-it-note pointing out that it is not the original author's repository and does happen to mention who the original author is. That github uses one file and not the other for a preview summary is irrelevant - the sources are being distributed fully intact with all original notices. Remember github is not a UI of the software but is does have a UI for browsing the source. – Chris Stratton Aug 05 '19 at 22:16
  • @ChrisStratton: You seem to have bypassed the requirement that it be prominent. This is not the clause that requires attribution in the software UI, that's 5d, I am discussing 5b. – Ben Voigt Aug 06 '19 at 00:23
  • The notices are exactly as prominent as the original author made them! – Chris Stratton Aug 06 '19 at 01:06
6

The way to prevent this is to not make your project open source.

No, really. What do you think open source means?

user253751
  • 538
  • 3
  • 8
  • 1
    It means what the license you're using says it means. There are several different licenses all considered open source. What I was expecting as a really adequate was something like: "Say your program's licensed under the gpl with the following exceptions...". And that "..." part would contain wording explicitly enumerating what I'd need to say in order to do what I want, as informally stated in the question. – John Forkosh Dec 20 '17 at 04:25
  • 3
    @JohnForkosh Open source does not mean whatever your license says it means. That's like saying that "bread" means whatever the recipe I'm using says it means. Both "open source" and "bread" have particular meanings. If I have a recipe for nachos and I change the word "nachos" to "bread" that doesn't mean it's a recipe for bread, it just means it's incorrect... – user253751 Dec 20 '17 at 09:35
  • 3
    @JohnForkosh Also GPL exceptions only allow you to give people more rights, not take them away (for that it would have to not be GPL any more). – user253751 Dec 20 '17 at 09:36
  • Re "whatever it says", I followed that with "There are several different licenses all considered open source". So these different licenses say different things, but are nevertheless all considered open source, and that's what I meant. By way of your analogy, not everything's bread, but there's more than one bread: Rye, Whole Wheat, etc, are all generally considered bread. And there are likewise several licenses generally considered open source, even though they say somewhat different things. – John Forkosh Dec 21 '17 at 12:18
  • 1
    Re "more, not less, rights", then I'd ultimately have to write a license entirely from scratch, but I could nevertheless cut-and-paste vast swaths of the gpl (or any other open source license, or any other license whatsoever). I don't care whether or not it's called by the name "gpl". Ultimately, if it's my copyright (which it is for the code I'm talking about), then I can license it any which way I like. I just have to write the right wording to accomplish what I want, which is what I was fundamentally asking for. – John Forkosh Dec 21 '17 at 12:24
  • 4
    @JohnForkosh Sure. But none of the types of bread is a liquid, because then it wouldn't be bread. Likewise no open source license prevents someone from modifying the source (or not modifying it) and redistributing it, because then it wouldn't be open source. Bread is a kind of solid food. Open source is a movement for letting people modify and redistribute source. – user253751 Dec 21 '17 at 20:32
  • 1
    @JohnForkosh Yes, you can license your project however you want (or not license it) but if they can't modify and redistribute the code, it's not open source by any definition. – user253751 Dec 21 '17 at 20:35
  • Re "modify", that's the key word. Please read my question where it says, "...it would be flattering if other developers picked up my code and kept working on it. But this guy just copied it to github and never touched it..." I'm not objecting to "modify and redistribute" (your words above). I'm objecting to "put a copy on github with absolutely no modifications and then let it just sit there and get stale" (my words here). And then I got emails complaining about bugs I'd already fixed five years ago in my "official" copy. – John Forkosh Dec 22 '17 at 01:52
  • 2
    @JohnForkosh It doesn't matter. If the license said "redistribute but you have to modify" they can add an inconsequential space somewhere and then they've modified it. – user253751 Dec 22 '17 at 03:11
  • 4
    @JohnForkosh The versions of the GPL itself are copyrighted, and come with a license to reproduce as desired but not modify. If you take language from any GPL and incorporate it into your own license, you're violating copyright. – David Thornley Sep 28 '18 at 17:41
  • 4
    @DavidThornley The FSF has granted a blanket permission to reuse the terms and text (but, importantly, not the preamble) of the GPL in totally new (and differently-named) licenses in this GPL FAQ item: https://www.gnu.org/licenses/gpl-faq.en.html#ModifyGPL (See also https://opensource.stackexchange.com/a/254/50) – apsillers Aug 05 '19 at 20:02
2

GPL "with exceptions" (usually quite a murky area since the license text and license number and identification lose meaning) is incompatible with other GPLed software and thus you lose a lot of what the GPL is actually about.

Note that Stallman has strong politicial leanings and opinions and goals while the GPL steers clear of anything but his principal goals in writing it. The point is that it takes a lot of discipline to make a license do what it is good at and leave things off that it isn't as good as, particularly if you want others to join your efforts.

If you can't let your license do your job without more damage than utility, you have to do it manually. Stallman has a full speaker schedule. In your case, the work is manually contacting the GitHub project contact and registering a ticket for upgrading the repository to your current version. If you have an announcement mailing list for new releases, it may be worth suggesting to the GitHub project maintainer to subscribe.

And so on. This is not zero-maintenance but a bit like whack-a-mole but getting the license to help here in its indiscriminate way is not going to really help a lot.

  • 3
    Normally the "exceptions" mechanism of GPL is used to give an additional permission. An example is the "GPL with linking exception" -- but in that example the "exception" actually gives you more permissions than the GPL normally does. I'm not sure how you could use this mechanism to take away a permission from the GPL (e.g. "you are allowed to redistribute the Source, as long as you make non-trivial changes") while still saying that your license is the GPL. You would basically need to write a new license that is GPL-like (but not GPL). – Brandin Aug 05 '19 at 13:51
  • 2
    GPL-with-exceptions will be a barrier against use. I know what "licensed under GPL" means, and much more importantly so does the corporate legal & IT department. So if it's under GPL I have an easy pathway to using the tool, if it isn't then I have to read & think about the license, then try to get Legal to do the same. Which immediately makes adopting this software about the most time-consuming option, possibly even worse than just hacking up something crappier-but-barely-functional. – Tom Goodfellow Aug 06 '19 at 10:12
1

One way to mitigate this issue is to clearly and conspicuously include the URL to the official website and/or repository in multiple places in your project.

Someone who makes a copy and does not change anything (or very little) is not going to bother changing these references.

For GitHub in particular, make sure you have a README.md file that links back to the official project. GitHub displays that file automatically.

Perhaps mention that to get the latest version, go to a particular URL.

If someone forks your project and makes significant changes, they are welcome to change these notices. But they should be using a different name for the project in that case. And that is a different scenario than discussed in the original question.

Scott M. Stolz
  • 209
  • 1
  • 7
  • How does including URLs in various places prevent me from copying the project and putting it on GitHub, though? Copying and putting something on GitHub (or putting it anywhere) is generally allowed by open source licenses. Granted, having all the URLs in there may make it more obvious where that software came from, in case somehow it was not clear already (e.g. in case I didn't press the "fork" button in GitHub). Also, I think most programmers know about global search and replace, so if they really want, and changing all those URLs would be allowed by most open source licenses. – Brandin Jun 20 '22 at 08:59
  • Of course, they can. But if someone went through all of that trouble, they probably changed other parts of your source code too. It truly would be a fork in that case, and it is no longer a copy of your script. Your biggest danger is people posting a copy of your code to GitHub and then never changing it. This helps mitigate that particular situation. – Scott M. Stolz Jun 20 '22 at 15:08