Tgppl, a new type of open-source license(electriccoin.co) |
Tgppl, a new type of open-source license(electriccoin.co) |
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.
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.
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.
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.
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.
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!"
¯\_(ツ)_/¯
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.
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.
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 was the ghostscript licensing for many years. Recent versions available under a commercial license, and older versions as open source.
Nowadays would have to worry more about security and backporting fixes.
One challenge is it discourages contribution.
That is a fair point.
Depending on the type of software and the frequency of bug fixes that may be a more or less reasonable strategy.
Also, in case you haven't read the license, the time period is 12 months.
This had me confused and excited for a second. Alas, it's hot the Halo 2 I was thinking of.
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.
This license model fits this product quite well.
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.)
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.
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.
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.
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 feels to me a solution looking for problem.
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).
Even the FSF acknowledges this. See for example "Proprietary software developers have the advantage of money" on https://www.gnu.org/licenses/why-not-lgpl.html.
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.
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.
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.
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
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.
I'm curious about this, do you know which ones?
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
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?
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 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.
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).
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...
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.
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.)
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.
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.)
It's going to be interesting anyhow.