9 ms·
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 i
by nsajko 6y ago
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 6y agoThere's a number of other reasons the OSI doesn't approve licenses, such as avoiding license proliferation https://opensource.org/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 6y agoStill, 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.
- geofft 6y ago> 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 6y agoOne 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/minutes20090205 https://opensource.org/minutes20090304 https://opensource.org/minutes20090304 https://opensource.org/minutes20090401 https://opensource.org/minutes20090401 Relevant mailing list threads: Dec 2008 thread: https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2008-December/000461.html https://lists.opensource.org/pipermail/license-review_lists.... Jan 2009 thread: https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2009-January/000477.html https://lists.opensource.org/pipermail/license-review_lists.... Feb 2009 thread: https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2009-February/000499.html https://lists.opensource.org/pipermail/license-review_lists.... Jul 2013 threads: https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2013-July/018425.html https://lists.opensource.org/pipermail/license-discuss_lists... https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2013-July/018443.html https://lists.opensource.org/pipermail/license-discuss_lists... Dec 2013 message: https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2013-December/018782.html https://lists.opensource.org/pipermail/license-discuss_lists... Jul 2018 thread: https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-July/020029.html 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-source_software#Delayed_open-sourcing https://en.wikipedia.org/wiki/Business_models_for_open-sourc...
- deleted 6y ago[deleted]
- ocdtrekkie 6y agoI 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.
- geofft 6y agoIt'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.
- amadeuspagel 6y agoThere's nothing dishonest about having a different definition of open source then the FSF or OSI.
- nsajko 6y agoThus my "EDIT3" at the end of the post you replied to.
- lucideer 6y agoI 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.
- lucideer 6y agoI 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 6y ago"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.