Tgppl, a new type of open-source license • Hacker News Board

Re: Tgppl, a new type of open-source license

#61

Post by Chris2048 » Mon, Sep 07, 2020, 3:14 PM UTC

geofft wrote: post #41

giancarlostoro wrote: post #35

Earlier quoted context omitted.

At that rate I'd prefer close sourced now, MIT later.

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.

can't you just release under a second, AGPL license for that?

Re: Tgppl, a new type of open-source license

#62

Post by cycloptic » Mon, Sep 07, 2020, 3:30 PM UTC

ocdtrekkie wrote: post #59

pessimizer wrote: post #54

Earlier quoted context omitted.

"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 th…

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.

Re: Tgppl, a new type of open-source license

#63

Post by lucideer » Mon, Sep 07, 2020, 4:07 PM UTC

nsajko wrote: post #9

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 pos…

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.

Re: Tgppl, a new type of open-source license

#64

Post by dathanb82 » Mon, Sep 07, 2020, 4:37 PM UTC

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.

Re: Tgppl, a new type of open-source license

#65

Post by slgeorge » Mon, Sep 07, 2020, 4:42 PM UTC

jpetso wrote: post #46

iameli wrote: post #23

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 b…

  > 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.

Re: Tgppl, a new type of open-source license

#66

Post by nsajko » Mon, Sep 07, 2020, 5:23 PM UTC

indymike wrote: post #56

nsajko wrote: post #15

Earlier quoted context omitted.

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…

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.

Re: Tgppl, a new type of open-source license

#67

Post by nsajko » Mon, Sep 07, 2020, 5:40 PM UTC

lucideer wrote: post #63

nsajko wrote: post #9

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 pos…

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 produ…

"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.

Re: Tgppl, a new type of open-source license

#68

Post by ocdtrekkie » Tue, Sep 08, 2020, 2:07 AM UTC

cycloptic wrote: post #62

ocdtrekkie wrote: post #59

Earlier quoted context omitted.

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 commu…

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.

Re: Tgppl, a new type of open-source license

#69

Post by kelnos » Tue, Sep 08, 2020, 4:39 AM UTC

pas wrote: post #33

tptacek wrote: post #31

Earlier quoted context omitted.

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.)

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.

Re: Tgppl, a new type of open-source license

#70

Post by arp242 » Tue, Sep 08, 2020, 7:13 AM UTC

lucideer wrote: post #57

amadeuspagel wrote: post #50

Earlier quoted context omitted.

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

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.

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