The license in our README is wrong

[N-R-K]

Currently the readme states that scrot using MIT-advertising license. But the gentoo ebuild says it's MIT-feh.

After adjusting the newlines and then diff-ing our COPYING file against the two, it seem that gentoo ebuild is correct here. We're using MIT-feh, not MIT-advertising. (Removed some of the noise from the diff output).

$ diff -u COPYING MIT-feh
$ diff -u COPYING MIT-ad
--- COPYING
+++ MIT-ad
-The above copyright notice and this permission notice shall be included in all copies of the Software and its documentation and acknowledgment shall be given in the documentation and software packages that this Software was used.
+The above copyright notice and this permission notice shall be included in all copies of the Software, its documentation and marketing & publicity materials, and acknowledgment shall be given in the documentation, materials and software packages that this Software was used.

[guijan]

Makes sense, both scrot and feh were originally authored by Tom Gilbert. One time I sent feh a PR because I noticed scrot and feh had the same dead code.

Also, maybe it's time to require all new contributions to be under the MIT license and start asking contributors if they want to relicense their code?

I previously suggested ISC because that's the one I like, but maybe it'll be easier to convince people (if any convincing is needed) if the new license is the same as the old one minus one clause.

[N-R-K]

Also, maybe it's time to require all new contributions to be under the MIT license and start asking contributors if they want to relicense their code?

AFAIK, we cannot change the license unless every contributor agrees. Given scrot was originally published in 2000-ish - this will probably be next to impossible.

So even if we get the current/active contributors to agree on relicense, we'll still have to make it dual-licensed - which is just unnecessary complication. And besides, I don't think there's any problem with the current license. Not being GPL compatible doesn't really matter much since scrot is not a library, it's an end user facing application.

We should just fix the README (and any other places) and move on.

[guijan]

There'll come a time when all the current code will be under the new license, then we can remove references to the old one. It's the same situation as BSD people modifying AT&T Unix until they owned all the source. I think it's worth going through that process.

The parts of the source code that take screenshots won't be too useful outside of another screenshot program, but e.g. our CI, imPrintf(), scrotWaitUntil(), our configure.ac, etc, could be learned from or used elsewhere with some or no modification. I'm sure we can refine scrot until it's an example to be followed and people copypaste it. That's definitely not the case currently for many functions such as scrotCheckIfOverwriteFile(), but we've been fixing it.

The MIT license is also familiar and widely used, but MIT-feh is something that people will go look up instead of thinking about contributing to scrot or using it.

And, most likely, our users are violating the license. But we're not going to do anything about it because that would be mean and most likely something no contributor agrees with. For instance, the license grants:

without limitation, the rights to use ... subject to the following conditions: ... acknowledgment shall be given in the documentation and software packages that this Software was used.

Is spectrwm violating our license by using our program and not giving acknowledgement? Is everyone who takes a screenshot and publishes it on a wiki without putting a footer under the image that says "taken with scrot" doing the same? The license should reflect that we don't care.

[N-R-K]

There will come a time when all the current code will be under the new license

1. It encourages rewriting existing code that might be otherwise working just fine. (It also feels like a very disrespectful thing to do - rewriting code just to change a license and/or remove older copyright owner).
2. Who will track which line is new and which is old? (git blame isn't enough, since things like moving a function around or renaming variables etc exists).

but MIT-feh is something that people will go look up instead of thinking about contributing to scrot

I don't think 95%+ people care as long as it's a free/open-source project (in spirit, I don't mean FSF/OSI approval).

I think it's worth going through that process.

I don't think it is (especially due to point 1 above).

(FYI, I'm fine re-licensing my contributions under ISC/MIT or whatever as long as it's free. Though I don't really like the copyright + permission notice clause of them - so my preference would've been something truly public domain-ish such as Unlicensed or WTFPL.)