Hacker Newsnew | past | comments | ask | show | jobs | submit | dannylmathews's commentslogin

Hey, I'm Danny, the author of this post. I go over how we can build something like WeChat Mini Apps using regular QR codes and open web standards. Feel free to give me your feedback or ask a question.


Hey, I am the founder and developer behind this app.

Antler tries to showcase how we can build something similar to WeChat mini apps but on open web standards.

I'll be around so feel free to give feedback or ask any questions.


The license on this project is pretty confusing. The license at the root of the project links to backend/cc/LICENSE.md which says you need a subscription license to use the code.

Can you call it open source if you need a subscription license to run / edit the code?


You don't need any subscription to run the code! By default, none of the enterprise code runs (and it can all be completely removed and the app will work as expected). Fully FOSS version here: https://github.com/onyx-dot-app/onyx-foss.


that's fair. What does the enterprise code do vs the FOSS?


As I see it has whitelisting and enterprise integrations.. as for the OS version maybe you need to roll your own. This is a usual monetization method though.


All of the core chat UX + "add-ons" is in FOSS!

In the enterprise:

- permission syncing

- UI-based white labeling

- Advanced RBAC

- Usage analytics UI


It's not really confusing at all.

Content under backend/ee requires a license, everything else is MIT Expat. Pretty standard stuff.

> Can you call it open source if you need a subscription license to run / edit the code?

MIT is open source, their other stuff isn't. Pretty clear.


That's exactly the same approach employed by Gitlab and is actively being deployed and used by GNOME and F-Droid.

Could you elaborate why this approach is confusing?


Yes. Open source doesn’t mean free.


No, they must then state that it is source-available, not open source.


It really does, by any definition I've ever heard. I suppose the authoritative one would be [1].

A common "trick" for commercial open source software is to use a copyleft license, which restricts redistribution as part of commercial products, and to offer a paid license to get around that.

[1]: https://opensource.org/osd


GNU disagrees.

> Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible—just enough to cover the cost. This is a misunderstanding.

> Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license.

https://www.gnu.org/philosophy/selling.html


Fascinating, from skimming that, it does indeed appear that it would be within the GNU philosophy to distribute source code solely in exchange for payment. Doesn't cover a case where the source code is _already_ distributed though, then it's free to run.

And even if the source code was only distributed to paying customers, that'd likely be a temporary situation. A relevant quote:

"With free software, users don't have to pay the distribution fee in order to use the software. They can copy the program from a friend who has a copy, or with the help of a friend who has network access."

I do read the GPLv3 such that if someone _does_ buy the code in any fashion, you must provide the source code to them for free. Relevant excerpt from section 6:

"[...] give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge."

But yeah, no obligation to provide the source code for free to non-customers, fair point. Just no ability to stop customers from sharing it with non-customers. Does make sense.


> > Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license.

This is interesting. If it had a limitation on reselling or a non-commercial / non-compete clause, it'd be almost perfect.

Today lots of companies come in and take open source software and "steal" the profits. (You could argue that theft is invalid since the license allows for this.) This makes it hard for the authors to build a durable business. Certainly difficult to build into a large-scale company.

Open source needs a better mechanism for authors to make money with what they create while still enabling user freedom to do what they want with the software - modify, reuse, publish changes, etc.

"Open core" is one strategy, but it feels like stepping around limitations in the license. Just spelling out "we want to make money in a defensible way" and giving user freedoms seems like a step in the right direction. More companies would probably opt to share their code if this happened.


Nothing in that "authoritative" definition says you cannot charge for binaries, for example. It's talking mainly about source code itself. Something you just publish the source for but charge for anything else, would be fair game and still "open source" by that definition.


Agreed, "free" is too broad.

I was responding to parent's question though: "Can you call it open source if you need a subscription license to run / edit the code?"

I'd say no. If you have the code in front of you, it shouldn't require a license to run. Even if the whole point of the open source software is to interact with a proprietary piece of software or service, you could still run it for free, it probably just wouldn't have much utility.


Hey, I'm the developer behind Inkverse and I just open-sourced it under the AGPL License. (http://github.com/taddyorg/inkverse)

Inspiration for Inkverse: I wanted to build an indie-friendly comic platform, similar to what Bandcamp does for indie musicians. If you are not familiar with the digital comics space, it is a brutal industry to earn a living in as a creator. It is a niche industry dominated by some big players and they take full advantage of that. For example: If you want to access the monetization tools on any of the big platforms, you have to negotiate with them on a contract where they get exclusive IP rights to your comic and take a 50 to 75% revenue cut. In contrast, Inkverse has standard terms of service for all our creators and takes no IP rights. Right now we have a Patreon integration for monetization and in the future we plan to add our own payments system (with a fairer rev split ~10%).

Inkverse is open-source ie) all our code is open and available for people to use, but I think, more importantly, all the comics use an open-source comic specification. Why use a comic specification? None of the comics on Inkverse are hosted on Inkverse, a creator self-hosts their own comic on their own server OR uses a tool like Taddy (https://taddy.org) to help them distribute their comic. The benefit is there is no platform lock-in, a creator can share their comic feed with any other comic app, not just Inkverse.

Inkverse specifically focuses on comics that use the webtoons format. Webtoon is a comic format, made specifically for mobile phones (vertical scrolling). Here is an example: https://inkverse.co/comics/a-is-for-alice. It is the format a lot of the younger generation uses to read comics. I do think Inkverse will always focus on the Webtoons format, but the SSS spec and Taddy can support other types of comic formats like page layout or manga etc in the future. btw, If you are a user of Komga or Kavita, Inkverse may not be for you as it isn't a comic app for self-hosting your own comics, it's more a way for creators to more easily distribute their comics to their fans.

Lastly, one really cool technical thing I did: I implemented OAuth directly in the SSS feed. Creators want to be able to have exclusive episodes of their comics only available to their paying backers. So, on the SSS feed, you can specify OAuth endpoints which can be used to get back a token to view exclusive content. In practice what this looks like is, a creator connects their Patreon and picks which episodes are exclusive to their Patreon backers, and readers on Inkverse can connect their Patreon and only Patreon backers of the creator get access to read their exclusive episodes.

Stack: Typescript, React/React Native, GraphQL, Node.js.

Let me know what you think!

Inkverse: https://inkverse.co GitHub: http://github.com/taddyorg/inkverse SSS comic specification: http://3s-docs.org/ OAuth on SSS: https://3s-docs.org/hosting-provider-oauth


Hey, I'm Danny, the author of the post.

The idea of the article is to look at what are the pros & cons of rebuilding my app on AT Protocol from the perspective of an indie dev.

Let me know if you have any comments / feedback.


AWS copilot has been very useful for me. It's their cli that tries to simplify integration (and give useful defaults) when you are setting up these services.

I recommend it for anyone who is starting getting into AWS.


Hey, I am the founder and developer behind Taddy.

Taddy’s Podcast API helps anyone build a great podcast app. To give some context on why this is helpful, 4 years ago I built Podyssey Podcasts ([https://podyssey.fm](https://podyssey.fm/)) and it would have saved me a lot of time if Taddy had existed at that time. What is unique about podcasts is that no one company owns podcasts. in fact, anyone can build their own podcast feed, all you have to do is output an RSS feed in a certain format. Here are some of the things Taddy’s API can help you with:

1) Since, anyone can create their own RSS feed, that means these feeds can be inconsistent or messy. We’ve taken the time (and have the experience) to deal with edge cases for bad or missing data. 2) There are 2 million podcasts which may update at any time, but your users want to know right away when there is a newly released episode. We sent you a event through a webhook when new episodes are released, so you can update your app or notify your users about the new episode. 3) Fast search through all 2 million podcasts & 60 million episodes.

There are alternatives to Taddy’s API like Listen Notes, the PodcastIndex and Apple’s iTunes API. I wrote a quick summary on the key difference here: [https://taddy.org/blog/best-podcast-api-tools](https://taddy...

Lastly, there is a bigger idea that i am working towards. I really believe in the idea of feeds to power different types of content other than podcasts. Taddy is starting with a Podcast API, but I will be launching a Comics API and a Music API within the next year. They will all be powered by open standard feeds (just like podcasts), so anyone can easily build a comic or music app based on them.


Great job on explaining the different podcasting APIs available and how Taddy became a need with your previous product .

Looking forward to playing around with the API soon


Fun . And appreciate you sharing the file.


Hey!

I'm starting a Podcast Club for people interested in Tech entrepreneurship .

This is the idea: - Every few weeks, you'll get a great podcast episode to listen to, handpicked by members of the club. (I going to pick the the first one, and its going to be on the no-code movement.) - People in the club will listen and discuss the episode online within the same week. - You come away having learned more about entrepreneurship from the podcasts and from others going through the entrepreneurial journey.

Click the link if you'd like to signup for the newsletter. I'll send out the first episode this weekend.


Hey, could you send me a email of what terms you were searching for zodPod? Curious to see them. dannyl.mathews@gmail.com


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: