SATA license is non-free and incompatible with free software licenses such as the GPL

[Lesik]

Hello,

I wanted to inform you that the SATA license is non-free and incompatible with free software licenses such as the GPL, as it fails the Desert Island Test:

Imagine being on a desert island (or any place that has no internet connection, for that matter). Free software should obviously still be legally to use in such a place.

However, as the SATA license requires you to "star/+1/like the project(s)", which is something you can't do without internet access, the license becomes non-free. Free software can't impose any condition on the usage of software, anyone must be able to use the software in any way you want and for any purpose. The SATA license excludes anybody who is poor and can't afford an internet connection, lives in a region where there is no internet connection at all, or just temporarily resides in a place without internet, like a forest or an airplane, from using SATA licensed software.

That also means that you can not license any software that uses GPL (or most other free software licenses) under SATA. GPL explicitly requires for derivates to grant the same rights to the user.

See https://people.debian.org/~bap/dfsg-faq#weird_clauses for other common pitfalls regarding additional clauses in software licensing that make the license non-free.

[zTrix]

Thanks for your findings, which is really interesting. I haven't considered about this case. Do you have any suggestions on how to modify so that this issue can be solved?

[Lesik]

Yes indeed. :) I'll roughly quote the DFSG FAQ:

So-called postcardware, or emailware (which requires users to send an email to the author, and is very similar to the SATA license), fails the Desert Island Test, so it is not free. However we understand your desire to receive emails/thanks/+1 from users, and would like suggest another way to achieve this goal.

Instead of making this a requirement in the license, make it a personal request. Just add a personal note from the author, which is clearly not part of the license itself, saying "Although it is not required, I'd very much appreciate it if users would send me an email telling me how they like my program". You should still get thanks mail, but it will be voluntary. Which is actually nicer, when you think about it.

[zTrix]

I've got another idea to bypass this issue, by only require the emails/thanks/+1 action if the user downloaded the software/source code in the project URL, by himself.

Does this idea work in the desert island test?

[ziqin]

What if GitHub stops providing service one day and thus we cannot star the project?

I would like to mention that

• Google Code Project Hosting has become Google Code Archive
• Somebody has no GitHub account or cannot access GitHub

[ouuan]

I think simply change "you shall star/+1/like the project(s)" to "you should star/+1/like the project(s)" is OK?

By RFC 2119:

MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

[neila-a]

I think simply change "you should star/+1/like the project(s)" to "you'd better star/+1/like the project(s)" is better? My PR

[zTrix]

@neila-a "should" means user is required to star/+1/like the project when applicable (not in desert, has internet access).

If changed to "better", this requirement will be too weak. So I think it's better to keep it as should.

[neila-a]

@zTrix But open source license shouldn't force people to do things.

[Eletary]

So, many this issue can be closed, as SATA has become free license now.