[tzs]

> I'll respond to the little part where it puts using a "non-OSI approved license" under the umbrella of open source. It's not OSI approved because it isn't open source, as the community defined it long ago, and as it still makes sense for it to be defined

So what would you call a license that meets OSI's open source definition [1] but has not been OSI-approved?

OSI no longer approves new licenses unless they think the new license fills a gap that is not filled by existing OSI-approved licenses, which means there are millions of possible new licenses that meet every criteria of their open source definition but will become OSI-approved.

[1] https://opensource.org/osd/

[em-bee]

So what would you call a license that meets OSI's open source definition [1] but has not been OSI-approved?

arrogant, as in: do you really believe that your project is so different that one of the existing approved licenses will not do? (addressed to the hypothetical project with such a license)

i mean, i am with bruce perens who believes that we need to rethink licenses completely to address many problems that have come up recently: https://news.ycombinator.com/item?id=38783500 and i guess this article does hints at some of the problems that need to be addressed. but coming up with a license that is in the spirit of FOSS and yet solves some of these problems is a non-trivial task that i do not believe an average developer or company is capable of by themselves, therefore it is very unlikely that your non-approved license is really worth it.

by all means please participate in the process of developing a new license, but do not actually use such a non-approved license until there is a broader consensus that this new license actually is worth it. otherwise it's just making things complicated for no good reason.

[tzs]

> do you really believe that your project is so different that one of the existing approved licenses will not do? (addressed to the hypothetical project with such a license)

Actually, I think it would be pretty easy to have a project for which none of the existing OSI approved licenses will do without even being all that different, ever since OSI approved AGPLv3.

AGPLv3 contains a distribution requirement that triggers for your program if you have users who are "interacting with it remotely through a computer network".

Now all it takes is wanting a license similar to that, but with the trigger being different. Maybe a project agrees with AGPLv3 that if you run their program on your server you should have to give the users source, but wants that to also apply to users who are interacting with it locally on a computer network, or are interacting via some method other than a "computer network" such as serial terminals.

[franga2000]

I love the AGPL, but even that has some holes. One classic case is a "backend service", which the user doesn't ever directly interact with, but is used by the application backend to provide the user service. Like if I modify an AGPL geocoding microservice, which is used by my backend to plan a trip to show the user, do I need to release the source? What if it's not displayed to the user at all and is just a small part of another calculation that is (like predicting bus arrival times)? What about an AGPL database or cache server? And if backend services don't count, are the users not interacting only with the reverse proxy and everything else is a backend service?

[em-bee]

yes, it is easy to come up with a change that seems to make sense. but it is not at all easy to vet that change legally. and no: "we have talked to our lawyers about this" is not enough. your lawyers operate in your interest. they are not operating in the interest of the Free Software or Open Source definitions. the bar for a license that would be acceptable to OSI is much much higher. and my claim that it is not easy to come up with a new license is based on that.