ssddanbrown

Open Printer is distributed under the Creative Commons BY-NC-SA 4.0 license.

So not open source.

Because the code is not provided under a free/open-source license, and therefore does not meet the requirements for the main F-droid repo.

Many of the main authors of the Git source code are friends of mine and I have no intention to steal anything from anyone, only to make their great ideas more broadly useful.

By working-around/subverting the terms they provided their contributions under? While you claim to be doing this in good faith, and state "it's what's best for the broader Git ecosystem", that's all based on your own opinion which appears to ignore the benefits and intent of licenses such as the GPL.

Out of interest, Would you be happy for someone to do the same with the GitButler source code? (Feed it through an LLM and re-publish the result under an MIT license with different branding)

I've been using PyInfra for a while, albeit just for simple automation (Updating systems, checking certain stats) and I'm a big fan. Compared to Ansible, I found the docs, syntax and usage patterns much easier to get on with. Might just be a preference thing, but I always had trouble going through the Ansible docs.

Ran into some bugs, like one machine that seems to cause errors and mess up the output on restart, although that looks like it might have been addressed in this release.

If it helps, I put together a video when initially exploring PyInfra: https://www.youtube.com/watch?v=S-_0RiFnKEs

I can understand that viewpoint. Ultimately though, audience/growth is not a core success metric for me, and the values/points explained in the blog post are more important. Plus there's a factor of wanting to help de-centralise away from GitHub, and help provide momentum to alternatives.

Looking at those who have starred the new Codeberg repo, at least 15 people are new today, and thus form part of a bigger audience on Codeberg.

BookStack maintainer here. Just to clarify on that, the GitHub repo will continue to be updated and mirror the Codeberg repo (including release tags/code) for the foreseeable future, it's just that I might stop specifically publishing GitHub release entries (details on the release tag) at some point to avoid the duplication of work.

Just as a warning the licensing of Dokploy is a little complex/questionable, which I've documented here [1] and queried with the project here [2].

[1] https://isitreallyfoss.com/projects/dokploy/

[2] https://github.com/Dokploy/dokploy/discussions/3

Just a warning, the license [1] specifically blocks EU use:

3. Conditions for License Grant. You represent and warrant that You will not, access, download, install, run, deploy, integrate, modify, or otherwise use the Model, directly or indirectly, within the European Union.

[1] https://gitcode.com/ascend-tribe/pangu-pro-moe-model/blob/ma...

I've been sustaining myself for a couple of years now on my open source project (BookStack). Still going in a positive direction.

Other than that, some that come to mind: Proxmox, Opnsense, SnipeIT, GitLab, Canonical, Codeweavers/wine, Plausible, Home-assistant/open-home-foundation/NabuCasa, FreeBSD Foundation, Laravel, Blender, Godot.

Within there is a whole mix of business plans, some offer hardware, some are open core, some offer related paid services, some offer hosting, some offer support etc...

Ah, okay, thanks for explaining and cross-linking!

I'm not sure, maybe they don't want to take a hard stance on the issue either way (to indicate how open source is defined on HN). Dang has been receptive to input and updated (what I believed to be) misrepresenting "open source" titles in the past though.

This post also seemed to be thrown off the front page for some reason.

I would argue it is possible to run a business and be sustainable on open source, it's just harder and is not so compatible with the growth that many want.

I don't have an issue with this kind of license being used where open source does not suit, but I don't think we should change/widen the definition of "open source" to suit the sustainability needs of those that open source isn't compatible with, at the impact of the freedoms and open rights it provides.

Additionally, this submission's title was changed from "Gumroad Did Not Become Open Source Today" to "Gumroad’s license wouldn’t meet the widely regarded definition of open source"

The license used [1] would mean this very much wouldn't be widely considered open source, since the license sets limits on use and does not seem to provide open modification nor distribution.

[1] https://github.com/Safe3/uuWAF/blob/393262d525d0e35c14819bfa...

Your readme states "MIT License - See LICENSE file for details" but there is no such license file. I've been seeing this a lot lately, did you use an LLM to generate this part of the readme? If so, was MIT a concious choice of yours?

I looked at the page for my software you provide (at https://octabyte.io/fully-managed-open-source-services/appli...) and noticed the "BookStack Website" button leads to a kind-of iframe version of the site which also breaks links (and maybe other functionality) on the website. This is kind of sketchy IMO, since your not leading users to the actual project site, but some kind of modified/framed version. Please don't do this, just lead people to the site if that what the buttons says instead of a modified and potentially broken version of it.

I also see a lot of applications that are not generally considered open source listed on this service, including those with licensing considerations in regards to providing a hosted (or assisted hosting) service; Like Hashicorp Vault for example. There's also some which, unless you're manually patching the underlying projects, you'd technically being using their code which is under a non-open/enterprise-agreement license (like those I've included on my blogpost here: https://danb.me/blog/poisoned-source/)

Fully open-source: Every line of code is transparent

The client libraries look to be provided under a license [0] which many would not consider to be open source since they seem to limit redistribution:

2. With restriction on copy, sublicense, and/or sell copies of the software

[0] https://github.com/earthodev/eartho/blob/66ee1c2098242c719a8...

The software is platform abstract, I've ran it on Debian & Ubuntu, RHEL & Fedora, Arch, OpenBSD and Windows systems. I stay out of system specific packaging methods though to avoid the extra maintenance burden, although community offers do form to enable this in some cases (like with BookStack in Arch's AUR).

Thanks for sharing my project! I started building BookStack just over 9 years ago to suit a need at work, and have been improving & maintaining it since. I left full time employment three years ago and have been focusing on BookStack since, with my living costs now covered via project donations, sponsorships & support services, and the growth of these continue as shown in my blogpost here: https://www.bookstackapp.com/blog/9-years-of-bookstack/#fina....

The platform has been designed for ease-of-use, with mixed-technical-skill workplace use in mind. The design and content structure is (purposefully) quite opinionated though so does not suit all use-cases, but for many it works quite well.

Technically it's built as quite a technically simple PHP/Laravel/MySQL stack with custom JavaScript sprinkled in where needed. The default WYSIWYG editor is TinyMCE based, although due to TinyMCE license changes I'm currently building a lexical-fork-based new editor.

If you'd like to understand the project more, a project FAQ can be found on our site here: https://www.bookstackapp.com/about/project-faq/

[0]

Just an advisory so folks don't get caught out, as far as I can tell the offering advertised as the "open-source version" defaults to [1] (and heavily makes use of) the Elastic license. More context here [2].

[1] https://github.com/airbytehq/airbyte/blob/v1.0.0/LICENSE [2]: https://github.com/ssddanbrown/Open-Source-Confusion-Cases/b...

This wouldn't be widely considered open source since your license puts limitations on use & distribution [1].

[1] https://github.com/trynyro/nyro-app/blob/5a5884126d83ecab89c...

The project is licensed under a Business Source License [1] which wouldn't be widely considered open source due to the limitations it's placing on use, so advertising this as open source may be misleading to many. Source available is a more common term for these kinds of license.

If you're interested in why I think this distinction matters, I've written some thoughts about that on my blog [2].

[1] https://github.com/npi-ai/npi/blob/ 991bdc7e0c9830c89a81b07b0ebabca9b506677a/LICENSE

[2] https://danb.me/blog/open-source-available-distinction/

I've added extra explanation in a discussion I've opened on the project: https://github.com/Dokploy/dokploy/discussions/3

I wouldn't consider this open source, the license [1] appears to put very non-open terms on the use, modification and distribution of the project.

[1] https://github.com/Dokploy/dokploy/blob/be56ba046cb3b2b8676d...

Not yet open source, but there are plans to open source the stack as mentioned by the article which references this HN post from yesterday: https://news.ycombinator.com/item?id=39836745

That's generally what LGPL is. It does get a bit murky outside of standard compiled applications though.

Otherwise, I think it's generally the other way around. Permissive can be used in stronger copy-left licenses, but strongly copyleft libraries can't be used (there's a lot of detail skipped when it comes to what counts as "used" here) in works provided under a more permissive library since a permissive license doesn't provide the terms required by the strong copyleft license (which generally try to ensure freedom of the code, which permissive licenses don't do so well).

Yeah, it wouldn't affect most users, but some users will be in that group. Plus it may (stupidly) raise legal term alerts for a portion of users it won't affect. As I said, is an option but one with concerns/considerations as per my last comment.

Honestly a better choice for a library would always be LGPL.

That's what they used originally, but I get the impression they want someone a little more forceful to move folks onto their commercial licenses.

I (and no sane person/lawyer) would consider your project derivative work, thus except for the need to relicense the code as GPL.

I wouldn't consider it a derivative work either, but from what I know that does not matter. TinyMCE is a core part that we also currently distribute with the application. The technical details of GPL combined works can get fuzzy in these contexts as it seems like a lot of it was originally written for compiled code. There are ways we could maybe technically put it at "arms distance" but there are still considerations if users have to add that (currently core) element back in. It can help our distribution but the end result is kind of the same really. This may be more significant in my case since It's a core value to me that this project is very much "batteries included".

That's definitely an option, but I originally chose the MIT due to the simplicity & low friction/requirement for users, and for me it'd be a shame to change that, especially as it could impact users that have been using my software over the last 8 years. While I've gained a lot of understand & respect for GPL licenses over the years of being involved in open source, I'd still have a preference for MIT for this particular project for the reasons I originally chose it.

Feels a bit annoying to change the licensing (and philosophy) of my project based upon a change from a dependency (but to be clear I respect their right to change license, and the value they've provided us to this point). Additionally, due to their licensing changes/hijinks over the years, I'm not overly confident there wouldn't be more changes ahead in favour of proprietary enterprise offerings.

TinyMCE provided a bit more information about this change in a GitHub discussion thread here: https://github.com/tinymce/tinymce/discussions/9496

As I posted there, this directly affects my open source project which is heavily tied to TinyMCE so I may end up forking, and reducing down to what my project needs to reduce maintenance scope & burden.

TinyMCE have been jumping around with their licensing. They were under LGPL, with some (what I believe were) misleading guidance into meeting the LGPL (they specified rules about keeping specific branding elements). They then jumped to MIT, and since moved some of the open plugins to their commercial offering. Now they're making this change.