[kragen]

I feel like those restrictions don't violate the OSD (or the FSF's Free Software Definition, or Debian's); there are similar restrictions in the GPLv2, the GPLv3, the 4-clause BSD license, and so on. They just don't have user or revenue thresholds. The GPLv2, for example, says:

> c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

And the 4-clause BSD license says:

> 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the organization.

Both of these licenses are not just non-controversially open-source licenses; they're such central open-source licenses that IIRC much of the debate on the adoption of the OSD was centered on ensuring that they, or the more difficult Artistic license, were not excluded.

It's sort of nonsense to talk about neural networks being "open source" or "not open source", because there isn't source code that they could be built from. The nearest equivalent would be the training materials and training procedure, which isn't provided, but running that is not very similar to recompilation: it costs millions of dollars and doesn't produce the same results every time.

But that's not a question about the license.

[mindcrime]

It may not violate the OSD, but I would still argue that this license is a Bad Idea. Not because what they're trying to do is inherently bad in any way, but simply because it's yet another new, unknown, not-fully-understood license to deal with. The fact that we're having this conversation illustrating that very fact.

My personal feeling is that almost every project (I'll hedge a little because life is complicated) should prefer an OSI certified license and NOT make up their own license (even if that new license is "just" a modification of an existing license). License proliferation[1] is generally considered a Bad Thing for good reason.

[1]: https://en.wikipedia.org/wiki/License_proliferation

[wongarsu]

Aren't most licenses "not fully understood" in any reasonable legal sense? To my knowledge only the Artistic License and the GPL have seen the inside of a court room. And yet to this day nobody really knows how the GPL works with languages that don't follow C's model of a compile and a link step. And the boundaries of what's a derivative work in the GPL are still mostly set by convention, not a legal framework.

What makes us comfortable with the "traditional open source licenses" is that people have been using them for decades and nothing bad has happened. But that's mostly because breaking an open source license is rarely litigated against, not because we have some special knowledge of what those licenses mean and how to abide by that

[mindcrime]

Aren't most licenses "not fully understood" in any reasonable legal sense?

OK, fair enough. Pretend I said "not well understood" instead. The point is, the long-standing, well known licenses that have been around for decades are better understood that some random "I made up my own thing" license. And yes, some of that may be down to just norms and conventions, and yes, not all of these licenses have been tested in court. But I think most people would feel more comfortable using an OSI approved license, and are hesitant to foster the creation of even more licenses.

If nothing else, license proliferation is bad because of the combinatorics of understanding license compatibility issues. Every new license makes the number of permutations that much bigger, and creates more unknown situations.

[user_7832]

I'm of the personal opinion that it's quite reasonable for the creators to want attribution in case you manage to build a "successful product" off their work. The fact that it's a new or different license is a much smaller thing.

A lot of open source, copyleft things already have attribution clauses. You're allowed commerical use of someone else's work already, regardless of scale. Attribution is a very benign ask.

[mindcrime]

I personally have no (or at least little) problem with attribution. As you say, quite a few licenses have some degree of attribution required. There's even a whole dedicated (and OSI approved) license who's raison d'être is about attribution:

https://en.wikipedia.org/wiki/Common_Public_Attribution_Lice...

What I'm saying, if I'm saying anything at all, is that it might have been better to pick one of these existing licenses that has some attribution requirement, rather than adding to the license proliferation problem.

[hnfong]

You speak as if "license proliferation" is actually a problem.

But is it really?

Sure, it may make some licenses incompatible with each other, but that's basically equivalent to whining about somebody releasing their code in GPL and it can't be used in a project that uses MIT...

And your argument that the terms are "less understood" really doesn't matter. It's not like people know the Common Public Attribution License in and out either. (I'm going to argue that 99% devs don't even know the GPL well.) Poor drafting could be an issue, but I don't think this is the case here.

And on an ideological standpoint, I don't think people should be shamed into releasing their code under terms they aren't 100% comfortable with.

[kragen]

You can totally use GPL code in a MIT-licensed project, by changing the license on the overall work to the GPL. What you can't do is, for example, use GPL code in a CDDL project, or vice versa. The Apache Foundation went through a whole long process to release the Apache License 2 when version 1 was found incompatible with the GPL. License proliferation can be a big deal. In this case it's undesirable but less of a problem. I think.

[ensignavenger]

The OSD does not allow for discrimination:

"The license must not discriminate against any person or group of persons."

"The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research."

By having a clause that discriminates based on revenue, it cannot be Open Source.

If they had required everyone to provide attribution in the same manner, then we would have to examine the specifics of the attribution requirement to determine if it is compatible... but since they discriminate, it violates the open source definition, and no further analysis is necessary.

[sophiebits]

This license with the custom clause seems equivalent to dual-licensing the product under the following licenses combined:

* Small companies may use it without attribution

* Anyone may use it with attribution

The first may not be OSI compatible, but if the second license is then it’s fair to call the offering open weights, in the same way that dual-licensing software under GPL and a commercial license is a type of open source.

Presumably the restriction on discrimination relates to license terms which grant _no_ valid open source license to some group of people.

[kragen]

Well said.