[nsajko]

This (under the same name and version 1.0) has already been presented to FSF and OSI in the 2000s and 2010 on their mailing lists and other places, so I guess it didn't get approval. Since it thus isn't an open-source license, why present it as such in article title - starting out dishonest is probably not a good idea.

If I'm wrong and it is approved by OSI, that info should probably be more prominent in the blog post.

EDIT: indeed, both the 2008 mailing list post and this blog post call it "Transitive Grace Period Public Licence v. 1.0".

EDIT2: to be more constructive, a more proper way to describe the license could perhaps be "open-source-like".

EDIT3: framing this as an issue of honesty was a mistake, because Zooko or whoever can hold whatever opinion they like. It is a big issue anyways, see downthread if not convinced.

[geofft]

There's a number of other reasons the OSI doesn't approve licenses, such as avoiding license proliferation https://opensource.org/proliferation . As a simple example, there are a huge number of variants of the 4-clause BSD licenses where the advertising clause lists more and more people besides the University of California; they're all open-source licenses under the Open Source Definition, but the OSI isn't interested in promoting them, because including all of those advertising clauses is a pain.

I think this post is not claiming that the license is (yet) approved by OSI, but it is claiming that it's an open source license under the OSD.

[nsajko]

Still, the claim of "open source" or "libre" or "free software" doesn't hold water effectively if there is nobody to verify it (lawyers are probably needed, too). License proliferation is a separate issue.

BTW, the OSI people on their mailing list weren't convinced that the license is conformant (during the grace period) in 2008, 2009, or 2013. Hypothetically there could have been a change of heart since, but I can't know either way without much more research.

My main point is that there is a lack of transparency in the linked blog post about the license by ECC (Zooko?).

EDIT: If someone wants to choose this (or any other) license, it is important for them to know if it is legally sound, how compatible it is with other licenses/project, and possibly also what are the prospects for the license's future adoption in the "market". Approval by FSF or OSI gives some assurance with all of those. Without that everyone involved with software licensed under the license will just lose time, unless hypothetically TGPPL makes it really big, big enough for everyone to switch from FSF and OSI approved licenses to TGPPL.

[indymike]

Contracts can't be verified like code. You have to go to court and actually litigate before you actually know for sure. . A lawyer's opinion... well, there are usually at least two opinions in every lawsuit. One is usually "this is legal" the other "this is illegal". We have trials to determine who is right, and then sometimes, a couple rounds of appeals.

[nsajko]

I agree, I just couldn't think of a better term than "verify". Still, when a non-lawyer designs a license, I think there are likely to be issues with the license that would be obvious to almost any lawyer.

[geofft]

> BTW, the OSI people on their mailing list weren't convinced that the license is conformant (during the grace period) in 2008, 2009, or 2013.

Thanks, that's interesting. If you happen to have the links to the discussion it'd be worth figuring out what they thought was nonconformant (and whether it can be fixed).

[nsajko]

One issue seems to be that it wasn't seen as desirable to promote something that is not source-available under whatever license, which conflicts with the main idea of the TGPPL of keeping the software closed-source during the grace period. Another issue was ensuring the source becomes available after the grace period as intended. I may be wrong, though, as I haven't read even half of the extensive discussions on this topic.

OSI board meetings discussing TGPPL briefly: https://opensource.org/minutes20090205 https://opensource.org/minutes20090304 https://opensource.org/minutes20090401

Relevant mailing list threads:

Dec 2008 thread: https://lists.opensource.org/pipermail/license-review_lists....

Jan 2009 thread: https://lists.opensource.org/pipermail/license-review_lists....

Feb 2009 thread: https://lists.opensource.org/pipermail/license-review_lists....

Jul 2013 threads: https://lists.opensource.org/pipermail/license-discuss_lists... https://lists.opensource.org/pipermail/license-discuss_lists...

Dec 2013 message: https://lists.opensource.org/pipermail/license-discuss_lists...

Jul 2018 thread: https://lists.opensource.org/pipermail/license-discuss_lists...

You might also be slightly interested in this small Wikipedia page section relevant to the motivation for the TGPPL: https://en.wikipedia.org/wiki/Business_models_for_open-sourc...

[ocdtrekkie]

I don't feel like we're going to make any progress in this space while a single entity is considered the sole authorizer of something being open source or not.

[cycloptic]

I don't feel like we're going to make any progress either if we consider it open source to toss random code up on github under random licenses with no legal review from any outside parties whatsoever. Sorry I don't mean to be snarky but someone has to fund the lawyers and organize the committees to look over this stuff and it seems those orgs are the only ones willing to foot the bills so far. The groups pushing for newer licenses that skirt the existing definitions almost never seem to be interested in doing this, they only really care about getting someone to bend the rules for their license.

[geofft]

It's not - there are two entities (FSF and OSI), they happen to have similar definitions, and a number of important organizations (Linux distros, vendors with special plans for open-source users, employers with open-source contribution policies, etc.) all happen to have specified their definition in terms of one or both of those because they're pretty good definitions. For instance, Ubuntu's licensing policy has text that pretty closely matches the OSD's, but does not defer to the OSI for the definition. (And Debian's, of course, is the text on which the OSD was based - any changes to the OSI-maintained OSD would not necessarily flow back to the DFSG. Debian also considers some of the FSF's own licenses non-free, for good reason IMO.)

Concretely, if the OSI were to change the OSD in either a way that included things like the SSPL or that included things like the Hippocratic License, I think there's a good chance that my employer's internal OSS policies would change to say "the version of the OSD before 2020," because it's not clearly in their interest to contribute company-owned code to projects under those licenses. On similar grounds, I'd expect companies that provide free services (hosting, CI, etc.) to F/OSS projects to say "these licenses don't count," Linux distros to not universally agree on including them, etc.

So you're already in a place where there's no sole authority: you need to start by convincing everyone other than the OSI that a new sort of license is actually a good idea and the change you want to make to the OSD is actually something that they, too, should consider "open source." And once you get to the point where enough people agree with you, the OSI isn't going to be in your way in any practical sense.

[notRobot]

> Debian also considers some of the FSF's own licenses non-free, for good reason IMO.

I'm curious about this, do you know which ones?

[duskwuff]

The GNU Free Documentation License (GFDL). It's generally well-intentioned, but it places some weird restrictions on modification and reuse. In particular, it allows the author of a text to define "invariant" sections of a text which cannot be removed or altered in copies of the work, and automatically applies this restriction to sections of a document with certain names (like "Dedication").

The GFDL also theoretically forbids users from storing GFDL-licensed documents on encrypted storage, as the license states that "You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute". I don't think that reading was intended, but the license doesn't clarify further. :)

Further analysis: https://people.debian.org/~srivasta/Position_Statement.xhtml

[ocdtrekkie]

I would say, by and large, every conversation about a new license is near immediate dismissal because the OSI hasn't approved it. The conversation that should happen rarely does because the OSI has decided they have no desire or need to make open source development sustainable.

[pessimizer]

"Open Source" is an arbitrary label assigned to licenses accepted by the OSI as "Open Source," just like "Free Software" is an arbitrary label assigned to licenses accepted by the FSF as "Free Software." Accepting other definitions as "Open Source" is just like accepting other definitions of meters and grams.

It's also piggybacking. You don't need to be Open Source, you can be something else. You don't have to use the word "open" to mean "available, and can be used under these conditions." It's not a standard usage. "Open" normally means that something can be passed through something else i.e. that something else is not blocked, or that it is currently doing business.

People calling their own licenses "open source" when they're not approved is a way to attempt to trade on the reputation and regard established by licenses that were written or approved by the OSI. That reputation and regard is a result of the consistent standards that OSI have applied to the license language that they approve.

The cases for calling explicitly unapproved licenses "open source" are no more coherent than a hypothetical argument about how we can't let a group of four unelected people, half of them dead and the other half very old and deeply embedded in the industry, decide what bands can be called The Beatles.

[ocdtrekkie]

It's insane to me that people can argue the OSI owns the phrase "open source" or that the FSF owns the phrase "free software".

In the current scenario, where the OSI has flatly failed to act to do anything necessary to protect open source as a workable concept, at what point can we decide that they aren't adequate stewards of the term?

[cycloptic]

This question comes up fairly often on HN and I'll paraphrase what I've said before. I could see some other group becoming an adequate steward of the term when the larger open source community agrees with their changes, and they do a re-review of all the existing OSI licenses to ensure they meet the new definition and are compatible with whatever the new incoming licenses are. This will probably involve lots of community outreach and paying lawyers to do it over some years. I'm not sure what else you would expect to happen -- forking the entire community over a legal nit pick is going to be just as expensive as forking a software project.

When you say it's not a workable concept, without context it's very hard for me to interpret this in any way besides the usual "open source doesn't let us make profits off of keeping the source code restricted and/or secret" or "open source doesn't let me deny access to my competitors or personal enemies" which are kind of the entire point. Please fill me in if I'm not doing a charitable interpretation.

[ocdtrekkie]

I am not particularly invested in a given approach, but the fact that open source is easily lifted by non-open corporate entities seems particularly problematic to open source business models.

I think the interests of open source would be better served by allowing licenses that prohibit entities like AWS from running off with the original developers' bread and butter: After all, for open source development to happen, open source developers need to be able to eat.

Restricting the type of business uses or resale, delaying open sourcing to provide an edge to being a paid user, etc. are approaches that, sure, don't meet today's definition according to the OSI, but the end result is more funded open source code for the community to use, eventually at least.

[cycloptic]

If you're trying to describe AWS as being opposed to making open source contributors, this appears to be not true, at least at cursory glance: https://aws.amazon.com/opensource/

I always hear these type of complaints about Amazon but it's not clear to me why they're always singled out for doing something vaguely anti-open-source. They don't seem to be doing anything different than any of the other F500 companies that selectively open source things but still produce a lot of closed source. The "traditional" way to deal with companies that don't give back is copyleft. If that's not enough and you want to totally deny access to these companies, that's fine, use a proprietary license. It makes no sense to me to insist on calling that open source, when you yourself would admit to purposefully trying to make it so it's closed source to a certain group of people.

[arp242]

HN: "Facebook, Google, and other Big Corp being gatekeepers is censorship and horrible!"

Also HN: "The OSI is the One True arbiter of the term 'Open Source' and anyone who uses it in a way that disagrees with the OSI is dishonest and trying to cheat you!"

¯\_(ツ)_/¯

[cycloptic]

If what you want is a situation where anyone can just call anything open source and individual users have to manually re-check all the licensing for any given project that gets posted to HN to make sure it doesn't add additional restrictions or conflict with the common MIT/BSD/GPL, I'm pretty sure that's already happening. There isn't any big corp gatekeeping -- they don't care if the community gets stuck dealing with fallout from these new licenses because that means they didn't have to pay the legal costs to get it tested in court. And in the meantime if the big corp really wants to be a customer they'll just ask to buy a standard proprietary license because it's cheaper and doesn't involve legal.

[amadeuspagel]

There's nothing dishonest about having a different definition of open source then the FSF or OSI.

[lucideer]

I disagree.

You can make that statement in theory, for a general term without any biasing factors.

For a term like "open source", that has a generally strong positive connotation, using it to self-define when your own definition of it liberally includes yourself, while the popular definition does not, strongly implies your alternate definition is designed for self-benefit. This is definitely dishonest.

[arp242]

"Open source" has been in use in the early 90s, as a simple usenet search will show.

[lucideer]

I mean you're right, but I don't see what this point has to do with my comment...

[nsajko]

Thus my "EDIT3" at the end of the post you replied to.

[lucideer]

I wish you'd retract your EDIT3 as I think you really were right the first time. This is definitely an issue of dishonest framing.

Having your own definition of something that differs to some central authorities' definition is not only fine, but something I'd positively encourage.

But when you then go and use that different definition to categorise your product more favourably, and you flagrantly advertise your product using that categorisation, without referencing the fact you're using a non-mainstream definition, that IS dishonest.

[nsajko]

"Dishonest" was probably the wrong choice of word, from at least a tactical perspective. I guess many people here disagreed with my comment here because they operated with a slightly narrower "definition" of dishonesty. I guess maybe you could have worded that better than me while still using the word "dishonest"; but if I could go back in time to when I wrote the first comment, I would use "deceitful" or "deceptive" (in regard to both the entire blog post and just its title) - that should have gotten my point across with less friction.