Better design, new features and readme.

... and this is the most popular open source LaTeX book on github ❤️

https://github.com/AnMnv/eBook

cross-posted from: https://lemmy.ml/post/15159862

cross-posted from: https://lemmy.ml/post/15109471

This is a feature that as far as i know lemmy does not have, so it might be worth it to checkout and support piefed, it will probably be useful if there are certain topics that are really relevant to you and you want to develop in depth knowledge of.

Feedback on open source royalty license?

I'm about to release a library, and do not want to use a normal free license like the MIT, Apache, or the GPL. I want to keep the license simple and easy to understand. It also would be considered a non-free license, as it requires a royalty payment. Though, the royalty would not be directly to this library, but open source repositories in general. This is what I had considered so far.

• 5% of generated income (per profit generating product) paid as royalty yearly to "approved open source repositories" if income is above $1,000,000/year. It's free if income is below that amount. The goal is to be similar to Unreal's license.
• All repostiories on GitHub.com that meet these requirements are "approved open source repositories"
  • They have more than or equal to 1000 stars
    • I'm aware that stars can be purchased, but this is against GitHub's TOS and the case for fraud is more obvious. Intentionally purchasing stars with the intent of not paying royalty is similar to just not paying the royalty
  • The royalty must be paid between at least 10 repositories, with no more than 10% to a single repository
    • I might provide some lists with easy methods for averaged mass payments to like 100s or 1000s of repositories, but if they want to use discretion, it's allowed. They are just prevented from contributing everything to 1 repository.
  • They cannot be the same repository or project that is paying a royalty, but the same organization is approved as long the individual repository meets the requirements
    • The intent is to partially reward companies with many highly starred open source contributions, but their use level is on their own PR. I also dislike the idea of verifying and tracking identities of different library authors, as I like to create repositories without them being associated with my name. Though, I do think that it makes sense for stars. (The developers providing stars would technically be voting on who should be elgible for financial contributions)
• After 5 years, the license transitions automatically into MIT or public domain for the version used. Though, new versions could still be under the same license.
• License is automatically compatible with licenses that use the same wording.
  • No extra royalty if another dependency also uses this license
  • If the other license raises or lowers the royalty rate, it's still compatible, with the royalty rate being the higher of the two.
  • It's also compatible if the amount of repositories is raised above 10 by limiting percentages more.
  • And, also compatible if the star threshold is raised.
• If GitHub removes stars, the existing approved repositories at the time of removal will persist as royalty options, but no new options will be automatically defined. (As the copyright holder, I still maintain the right to increase approved repostiories at anytime by issuing under a new license)
• No liability. The liability is still similar to MIT, Apache, GPL, etc.
• Royalty is paid by taxable year, follows tax season for US.
  • Chosen repositories by the payer must be listed on the license
    • Inclusion must link GitHub URL, payment amount, year
  • The license must be distributed in the same location as all other distributed licenses in their application
• Just like the MIT or Apache license, the license cannot be revoked unless the licensed company decides to break the law, sue the license issuer, etc. No expectation of support, etc.
• The source can be modified. Usage of it does not need to stay open source.
• (Maybe, if possible) - Provide GitHub the ability to sue companies in noncompliance for a 10% reward of the settlement after lawyer fees.
• (Maybe) - Include Codeberg too. Though, I'm concerned other developers will be less likely to use a license of this type if they don't recognize the organization.

The motivation is just that I believe it's possible for a license like this to work. Tech companies frequently use a similar income model for their products and do not have issues paying Apple their 30% tax. There's often a expectation that companies contribute back to open source repositories, so I view 5% as an easy amount to meet. (Companies should already be contributing back at a level to where this license is viewed as free) Though, I don't expect any large company to move fast on a license of this type.

I've considered a license like this in the past, but thought about it again when Microsoft requested support for FFmpeg when their engineer hadn't read documentation. When requesting a support contract, Microsoft offered $2000. This was viewed as insulting to the FFmpeg developers as Microsoft generates billions of dollars in income every year while using their software in their products.

Large companies, like Microsoft and Google, pay Apple 30% to list their products. (30% of a billion is 300 million, 150,000x more than $2k) I don't think spending the money is the issue, they just frequently refuse until they are without options.

I haven't consulted a lawyer for it. I'm just interested in understanding how it is perceived. I also am willing to consider significant changes, but I haven't had better ideas for creating a license for funding open source.

As for my library

• It's unimportant, in a niche, and blockchain related
• I wrote it for personal use
• It won't bother me if the license just completely fails or is impossible to enforce. (Though, Unreal Engine uses a 5% royalty license that seems successful)
• It also won't be elgible for part of the royalty until it meets the same requirements.
• I expect developers who might use it will not be generating above $1m, so they won't care that it's not under MIT, Apache, GPL, etc.

Any suggested changes if I decide to do something like this? As an example, larger/lower star requirement? (I was concerned of excluding really high quality software that just hasn't received notice by other developers) I also like the idea of changing the maximum contribution to 1% per repository as I think it could become difficult for companies to exploit. (Though, I was concerned that companies acting in good faith would be encouraged to not support really good projects that badly need financial contributions) I also think same organization contributions seem bad to approve, but my opinion for allowing it is because developers are rating these repositories as highly appreciated. (They're contributing really high quality open source software) Is this a bad idea or seem too complicated?

Hi there!

Since the last time the LemmyWebhook package gained quite a few new capabilities so I've decided it's time for another post.

Quick intro to the package: It adds support for webhooks to Lemmy, meaning you can get notified of events to automatically react to, instead of having to poll for everything, often using multiple http requests. Everything is done in a quite efficient way which avoids hitting your database as much as possible and if it does, it only uses queries on primary key. You can also (optionally) make it available to other users who can then run their bots on your instance only on the permissions you allow them, meaning if you only grant them access to post events, they don't also get access to new user events.

So, what's new?

• When you listen for an update event, you get the previous version of data in addition to the current one, meaning you can directly compare what has changed
• New function for getting parent comment id have been added, with this you can for example detect if someone is replying to your bot
• You can now listen for community subscribe/unsubscribe event

As usual, let me know what you think, feel free to offer suggestions or ask questions.

cross-posted from: https://lemmy.ml/post/13924279

• step in and help review a few PRs

• help the project triage/reproduce bugs

• if code in the PR looks complicated or is hard to understand, ask for an explanation

• express your gratitude to the maintainers

• make your company sponsor projects they depend on

https://mastodon.social/@bagder/112194895793007918

Daniel is the creator of cURL : https://daniel.haxx.se/blog/2021/03/30/howto-backdoor-curl/

Hey!

I not good at understanding a project from its code. So, I try as much as I can to understand it from its technical documentation first. But so many time I fell overwhelm by the information: I don't know were to start to read and I don't know how to find a specific information.

How can I know when I'm lacking in understanding the project and when the project is lacking good documentation?
Where should I start while studying a documentation which readme doesn't say "read this next"?

Thank you

Most mobile games nowadays seem to be crap. Got any good mobile games that are open source and fun to play (for more than a few days)?

“It is with a heavy heart that I'm writing today to inform you that the Board of Directors of the Open Collective Foundation (OCF) has made the difficult decision to dissolve OCF, effective December 31, 2024”.

More details in the hyperlink below.

https://daniel-lange.com/archives/186-Opencollective-shutting-down.html

Chances are you’ve never heard of Igalia, the open source consultancy. Yet you’re almost certainly using something that Igalia helped build.

cross-posted from: https://programming.dev/post/9979951

Monday, February 12, 2024
Ribbon and Ron Williams write:

As Redox functionality becomes more complete, we have been working hard to get a wide variety of software working.

This post will cover our porting strategy for Linux/BSD programs.

We have ported the following games and emulators:

2048
ClassiCube
DevilutionX
DOSBox
eduke32
FreeCiv
Gigalomania
Hematite
Mednafen
Neverball
OpenJK
OpenTTD
PrBoom (Doom engine)
ScummVM
Space Cadet Pinball
and others.

Porting is a major part of the Redox development effort. We are using porting as a way to prioritize and validate Redox functionality.

Currently dozens of programs and many more libraries work. Our initial focus has been on porting Rust programs, but we also recognize the importance of supporting programs written in other languages.

In last year Ribbon began the porting of more than 1000 programs and libraries to Redox! They are still work-in-progress and many require customized cross-compilation scripts or improved library support. You can see them here.

With our recent change to a Linux-compatible path format, we have removed a major hurdle to supporting Linux applications. In the future we plan to expand our POSIX support, port more Rust crates and continue to improve Relibc.

Some thought is being given to virtual machines and Wine as possible mechanisms for running proprietary binaries and possibly even proprietary drivers. However, there are no specific plans for that capability at this time.

Read Porting Strategy - Redox - Your Next(Gen) OS

It's been a while since I've last posted about this package and quite a lot has changed since then.

So, what does this package do? It adds support for webhooks to Lemmy in an efficient way, meaning you can subscribe to various events like a new post created, new comment added and so on. Very useful, for example, for automods or other bots that need to react fast.

Since the last time I've added more object types, so in addition to posts and comments you can now listen for:

• comment reports
• instances being added or updated (for example federation changes)
• local users (users local to your instance, it's a distinct type from all users, it contains stuff like email and other stuff that doesn't get federated to other instances)
• all users in general (this includes federated and local users)
• post reports
• private messages (does not contain the message text itself, only metadata like recipient and the author)
• private message reports
• registration applications

Another huge improvement is an api that allows users to create webhook and even more importantly a simple GUI for management of your webhooks. This means that this package is no longer only for instance admins, but bot authors in general can ask their instance admins for access to webhooks (and to install the webhooks package to their Lemmy instance if they don't have it yet) and if the admins grant it, you now have access to webhooks. Every access is scoped, meaning if your bot only needs access to posts, you don't need to ask for the permission to receive registration applications, meaning admins can freely grant you access to webhooks without also giving you access to stuff you shouldn't have access to.

There's also support for bulk import of webhooks based on a YAML document, meaning creators of bots and other applications that have support for webhooks can create a YAML document with all the webhooks other people then can import without any trouble. Each imported webhook needs a unique ID which allows the system to track changes to it which allows the importer to update old webhooks instead of duplicating them (as long as they share the same ID).

Let me know what you think, your ideas for improvements or any comments in general are welcome!

P.S. If someone wants to try it out, you can use my instance. The webhooks are available at https://webhooks.lemmings.world (accounts must be manually approved, so be patient and ideally write me a PM if you want the access quicker).

the number of people who have left the rust project due to burnout is shockingly high. the number of people in the project who are close to burnout is also shockingly high.

this post is about myself, but it’s not just about myself. i’m not going to name names because either you know what i’m talking about, in which case you know at least five people matching this description, or you don’t, in which case sorry but you’re not the target audience. consider, though, that the project has been around for 15 years, and compare that to the average time a maintainer has been active …

The author doesn't seem like a big fan of capital letters...