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.
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.
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.
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.
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.
> 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).
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.
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.
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.
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.
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. :)
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.
"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.
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?
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.
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.
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.
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!"
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.
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.
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.
"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.
Well I'm skeptical, but at least unlike 99% of "radically new type of open-source license[s]" I think this one is actually, y'know, an open source license and not shared source pretending otherwise. If I'm reading "External Deployment" correctly, it's sorta like AGPL but with a time delay, which is... Not terrible, really.
Haven't gone line-by-line on this one, but I like the new trend of "time limit" licenses. If I'm trying to start a business, something AGPL-ish might make sense in the short term to avoid bigger competitors copying everything we're doing. But that doesn't mean I want my great-grandchildren to be able to sue for violations 90 years from now. "AGPL for now, MIT later" seems like a good compromise.
The issue with "time limit" licenses is that it effectively centralizes contributions.
As an independent developer, I won't want to write patches for a project that will have already advanced internally. Sure I can make a change, but instead of collaborative development at trunk, I have to fork the year-old codebase to make my change available to users. Or hope that the company behind the project picks it up and it becomes open source after the long waiting period.
As the company behind a "time limit" licensed codebase, this means I won't get much from the community in terms of code contributions. Patches that do get contributed are going to result in merge conflicts. Sure you can privately collaborate with selected other entities, and in that case you've reinvented the Android development model wherein the owner company (Google) privately shares code with phone vendors and releases it to the rest of the world at a later point.
In short, this model may work for companies that want the branding aspect of open source while saying no to code contributions or even community governance models. The recent KDE Free Qt brouhaha also shows that this can easily imply delayed security fixes for the open version as well as increased risks of hostile forks. I don't see this as a particularly popular model going forward, although I imagine it covers some use cases well.
> As the company behind a "time limit" licensed codebase, this means I won't get much from the community in terms of code contributions.
Which 'in my experience' is the situation for the __majority__ of commercially driven open source projects. Most commercial OSS projects receive few contributions, most often around the edges. In these cases it may well be rational to protect yourself from large competitors (e.g. cloud vendors) taking your code vs losing some small contributions.
It's true that:
> In short, this model may work for companies that want the branding aspect of open source while saying no to code contributions or even community governance models
Often it's not 'bad faith' that's driving these sorts of trade-offs in licenses. Rather, it's the harsh realities of trying to get open source business to work.
It probably won't be a "popular model" because there's lots of reasons for creating FOSS - from individual drivers to strategic - so by volume of projects etc. But, for someone trying to create an OSS business "time delayed" licenses are not bad.
You don't really need a new kind of license for that; you can just AGPL now, and release MIT later (assuming you're assigned the copyright for all the code).
That doesn't guarantee downstream users that later they'll in fact have the code as MIT licensed. The author can change their minds, or just thinks it isn't worth the hassle. (Or some big corp buys them and they won't care.)
Isn't that always the case if the author is the sole copyright holder (or all copyright holders agree)? (Meaning that regardless of the license the copyright holder can always choose to not distribute new versions under that license anymore.)
But that's completely different than having a released version that we know will be available as MIT in X months.
It might mean you can start developing something based on the code and when it becomes MIT you can launch it and keep your additions to yourself. (Let's say in case of a server side thing.)
Is it difficult legally to draft a meta-license that says "This work is licensed under X upon release; Y months after release it will be licensed under the terms of Z"?
Presumably you'd have to also specify what it means to do a non-release pull from their git repository -- when does that particular git commit switch to Z -- but that can't be too hard. Just make the clock not start ticking until a release is made, and if you want a safety valve for the case that someone wants to fork, or if the company folds and doesn't make any more releases, you can have a clause where it switches to Z after N*Y months or something, where N is chosen with an understanding of the usual release cadence.
I could understand how all this might be legally risky for another company to base their business on software licensed like this, but I kinda think that's ok. If we're talking about X=AGPL and Z=MIT, I imagine many non-corporate developers would be happy to use the software under the AGPL, while corporate types will -- as intended -- be more likely to use (for example) the developer's enterprise hosted version, or some other paid self-hosting agreement.
Hm, they could simply put the exact date into the LICENSE file upon release and be done with it.
So by default the code in trunk/master/main has AGPL license in the LICENSE file.
Then when they do a tagged release they just specify 2021-09-08 or something.
Also they can probably refer to the git commit date as release date for the code. (After all it's reasonable to specify a canonical place and method for source code access by the author in the license itself. That is, unless you got the code via this and this site then the code is unlicensed.)
Usually successful (widely used) code has simple licenses. Sure, in the future it's possible there will be complex licensed successful things. But currently big corps just don't really touch complex stuff, they spend rather large amounts on preventing these kinds of risks, even if that means buying an inferior software or reimplementing it. (But then there's also the risk of patent infringement.)
The advantage of AGPL now is that you can get your code into distributions / services that require your code to be under an OSD-compatible license (like Debian, Fedora, Travis CI, etc.) or a source-available one (GitHub, etc.), but it dissuades the AWSes of the world from setting up a competitor, and it may also dissuade certain corporate users from using your OSS release instead of your enterprise one.
You know that the Copyright started with a similar reasonable time limit. Here it's a year.
But then lawyers and politicians extended the period and fine prints decade by decade, so that the original sense of the protection was overturned. Now it's a sham. Holding back fixes for one year is Apple/Microsoft like. Google also started holding back critical services for their Linux variant. No good compromise at all.
This seems like a fundamentally bad idea for software.
Simply put, living software contains a constant stream of patches, which "reset" the clock continuously.
It would be one thing if this license were used on a book or some other work which is substantially finished. Once the book is published, the clock starts ticking and users eventually get to the MIT pot of gold at the end of the timer.
With software, the only time that happens if after the software is abandoned. At that point, there's rarely many people interested in using it anyhow.
...to distribute or communicate copies of the Original Work and Derivative
Works to the public, with the proviso that copies of Original Work or
Derivative Works that You distribute or communicate shall be licensed
under this Transitive Grace Period Public Licence no later than 12
months after You distributed or communicated said copies
It looks like the effect is that the public versions must always lag a year behind the proprietary versions.
So, this isn't open source, although it is abandonware protection.
That's my reading as well. It's actually kind of funny to me: the term of copyright has grown so long that folks are essentially looking for ways to reimplement reasonable copyright term length inside of the construct of copyright protection itself.
Yes, I think that's the objective for the licence. Reading slightly more into the product (Halo 2), they would benefit from more adoption by others as it could facilitate cross-chain interoperation.
The license model gives everyone equal access to the code, and equal rights to improve Halo commercially (make money?) with the promise that they subsequently open-source their improvements after 12 months.
That was my impression too. However, where a patent expires, I couldn't see when the source code had to be released by. Seems a bit problematic if that is the case. I also don't see a substantial difference to just releasing the source code at a later date under a open source license when the copyright holder chooses to.
“Congress shall have power… to promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries.”
Depends on the time limit. US copyright was once 23 years, now it's 95-120 years in the US. If this is for 1 year, well, maybe. If it's for 10 years, no.
And can it be "evergreened", with the time limit running out 1 year after the most recent change? (See MPEG-LA for how to do that.)
Can someone better-versed in legalese explain how this works? What is the restriction before the 12 months (and what happens after that?). Say I make money from the code, what about the contributors? Do they contribute code and get nothing for it, or am I supposed to pay them a cut?
If I'm reading the blog post right, it's essentially MIT for 12 months after you make changes, then (A?)GPL after. (To be clear, not those actual licenses.)
Can someone summarize in like 2 sentences what this license is trying to solve?
The article mentions underfunding, but since this is a license and not a price tag I don't see how this is going to change that. Also from the comments it reads like this is going to limit usage within "big $$$ cloud providers". Well, my wild guess would be that such projects would get even less attention (read as: money) then.
Their BSL has a 3 year period (whereas this license has a 1 year period). Sentry also admit it is by definition not an open source license since it has restrictions on particular uses.
TGGPL claims to be open source and probably is because everyone gets the same rights. But you are always potentially looking at code that is a year behind.
I've never understood why there isn't a dev framework to allow users to "unlock" certain FOSS features.
E.g., you scroll through a list of already implemented/tested features that are stored somewhere that isn't publicly accessible, perhaps with demo videos if it's UI stuff. Each one is priced. If someone pays the price, then the source for the feature gets automerged (if possible) and ships with the next version of the software.
If it's served by the same maintainers who run the project then there's no trust issues with it.
This doesn't seem like it actually solves the capture problem, though. The most egregious cases I can think of of third-party capture involve taking a project, bundling it with infrastructure, and offering it via a SaaS model (obviously thinking of Kafka, Elastichsearch, Postgres, MySQL, etc. via AWS). Only direct modifications to the project source are covered by the license, right? So the infrastructure code that make it easy to create instances of the product (but don't involve changes to the product code directly) aren't affected.
I vaguely remember reading a similar Open Source License, but couldn't google it.
And it reads very AGPL like. Which may be a big no no for many Cooperation and Enterprise. And what if the Author Set a Grace Period of 50 years or longer?
It is a solution for people who want to keep their software proprietary because they think they can't make money out of it if it is open source. All the while they get to claim credit for it being "open source".
The problem is that this license completely obliterates the major points of OSS licenses - which are open collaboration and security. Nobody is going to contribute and fix bugs in old versions of the software which may not even work anymore (e.g. because some underlying protocol or infrastructure have changed already).
This is just more license proliferation and a solution to a nonexistent problem. Releasing software under a license like the GPL doesn't somehow prevent you from making money from it. See Ardour - GPLv2, paid binaries.
One example of a project working with existing licenses doesn't mean that there isn't a problem. And they don't claim that it entirely "prevent[s] you from making money from it". (Although I'm not convinced this license is a good solution, need to take a deeper look)
That's just semantics. Sure, nothing in the license says you can't make money, but the basic rules of capitalism say you won't. Every single model I've heard of is unsustainable because of the cost of development puts the developer at a permanent disadvantage.
A "repackager" can charge less than the developer while also having much higher margins. Lower price leads to more market share, which brings more total revenue. In addition, these companies now have more to spend on advertising etc., bringing in even more money, none of which ever has to go to the original devs.
This is simply unavoidable and the only reason we don't see it more often is that most of us with the required skills have morals telling us to not do that and those who don't have much better ways of getting money without creating value.
Super! My understand is that Krita's distribution through app stores has a similar flavor - it's pure GPL, no tricks, but people pay for the convenience and assurance of downloading the official version of the app.
My personal feeling is that as PC's become more locked down and less under user control, paying for the digitally signed version might increasingly become a viable business model. Trademarks and TOS enforcement might be a more effective moat against being undercut than copyrights and licenses.
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.