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

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

#71

Post by lucideer » Tue, Sep 08, 2020, 9:59 AM UTC

arp242 wrote: post #70

lucideer wrote: post #57

Earlier quoted context omitted.

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.

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

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

#72

Post by pas » Tue, Sep 08, 2020, 8:50 PM UTC

kelnos wrote: post #69

pas wrote: post #33

Earlier quoted context omitted.

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, an…

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

It's going to be interesting anyhow.

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

#73

Post by cycloptic » Tue, Sep 08, 2020, 9:00 PM UTC

ocdtrekkie wrote: post #68

cycloptic wrote: post #62

Earlier quoted context omitted.

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

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.

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

#74

Post by jancsika » Tue, Sep 15, 2020, 1:21 PM UTC

egypturnash wrote: post #20

jancsika wrote: post #16

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…

So you want developers to spend a lot of time making new features on spec?

That's what FOSS developers already do. It's just that typically they don't get paid for it at all.