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?

    • CapitalistSusScrofa@sh.itjust.works
      2·
      8 months ago

      No, just flat 5% for all compatible. The income is for project level. Downstream would pay the same 5%. They would pay at their discretion to anyone with 1000+ stars on GitHub. (or some variation of this)

      • CameronDev@programming.dev
        1·
        8 months ago

        Okay, that makes a bit more sense.

        Chosen repositories by the payer must be listed on the license

        If two libraries have two different accepted repos, which has priority?

        • CapitalistSusScrofa@sh.itjust.works
          1·
          8 months ago

          The royalty must be paid between at least 10 repositories, with no more than 10% to a single repository

          The person using the license and paying royalty on the license chooses repos to fund. In the example I was considering, they’re limited to funding 1 repository for more than 10% of the total royalty owed. Though, this license would be compatible to a license that someone else requires x%. (As long as the x is less than 10%, as any value of x below 10 is still below 10.)

          edit: I think law is just not as straightfoward to follow as programming. The goal is just a highly compatible royalty charging license that raises money to lots of GitHub repositories that have been highly starred.

          edit 2: I think you’ve also convinced me that the clarity and simplicity of it would be better if the royalty was just paid directly to a smart contract that verified stars and approved repositories… but the perception of that is so bad. I do appreciate the comments though, as I think it’s helped me understand that attempting to interpret a license might not be an enjoyable experience.

          • CameronDev@programming.dev
            1·
            8 months ago

            Righto, library users choose who to fund.

            This would mean that Microsoft could just fund Powershell and never contribute back to anyone else? All of the big names have a project that is OS, so if they are allowed to just fund their own things, the spirit of the licence wont be honored.

            The edge cases are what make and break a licence, its not easy. Even GPL has its issues (see Redhat).

            It may be easier (and more palatable) to just have the 5% donated to a not-for-profit that can then divide out the funds to worthy projects.

            Another thing to consider is that projects with 10k+ stars might not necessarily need money. If they are established and stabilised projects they might be operating just fine. Whereas a new project might have more need for funds, but havent yet got enough stars to be funded. Having a not-for-profit organisation managing it could mean that smaller projects could be invested in.

            • CapitalistSusScrofa@sh.itjust.works
              2·
              8 months ago

              This would mean that Microsoft could just fund Powershell and never contribute back to anyone else? All of the big names have a project that is OS, so if they are allowed to just fund their own things, the spirit of the licence wont be honored.

              I’ll break down my thought process, but maybe it was a mistake of mine to assume it was too much for the post.

              Users of the platform determine approval of a project’s on GitHub. If they don’t want it to be elgible for funding, then they’re not required to star or vote for it. The threshold at 1000 does seem low, especially considering that Microsoft has lots of open source repositories. (They contribute lots!) Though, when comparing the top 500 companies in the US, it starts to look better.

              I stated that the person paying the royalty would have to spread their support between 10 or more repositories, with no more than 10% to a single one. I also stated in my post, that I like the idea of changing this to 1%, but mentioned consequences of that. [1] It’s going to be hard for even Microsoft to have 100 highly approved projects on GitHub.

              It may be easier (and more palatable) to just have the 5% donated to a not-for-profit that can then divide out the funds to worthy projects.

              I think companies frequently understand what they wish they had. It’s not that I don’t wish to make it simpler, I would be happy directing a company to a non profit to direct the funds for them. (And my considerations didn’t disallow that at all in what I had stated so far) I just think it makes it a desirable license to companies if they’re allowed to direct funds to projects they find very important.

              Another thing to consider is that projects with 10k+ stars might not necessarily need money. If they are established and stabilised projects they might be operating just fine. Whereas a new project might have more need for funds, but havent yet got enough stars to be funded. Having a not-for-profit organisation managing it could mean that smaller projects could be invested in.

              I don’t disagree. Companies should have discretion to fund people who need money. Companies should be provided the resources so that they can delegate it out easily to someone who cares about it. (if desired) Companies should be able to promote their own interests. I think these are all good.

              I also think it’s good that developers who are writing very successful and high quality software are able to do more, like hire more developers than typical. (It just seems like good delegation. There’s likely some things they don’t need to do themselves)

              [1] Limiting contributions to 1% (of the royalty contribution) provides less opportunity for a company to choose to highly fund a small group they find individually important. As an example, they may not want to spend more than 5% (of their total income), and this group could have been one they would have otherwise funded if not for the royalty.

              • The total income is the amount they earn. Let’s say they earn 1m, the royalty is $50k. (That’s the 5%)
              • The 1% is a contribution of the $50k. One percent is $500

              After writing all of this, one of the things that I really like about it, is that the license is intended to be compatible with more restrictive versions of it. If a developer thinks 1000 stars is too low, no problem, they can bump it to 10k and it changes for the the other deps that use the same license. (If a company uses the bumped license) If a developer thinks 1k is too much, they can drop it, but it’ll be moved up if a company uses a more restrictive license later

              • CameronDev@programming.dev
                1·
                8 months ago

                So, project A uses library B and library C. B specifies 100 stars, C specifies 10000, does A now have to respect C?

                If so:

                Licences that override the rights of other licences might be a minefield. If thr original licence developer explicitly chose 1000 stars to encourage supporting smaller developers, having a second unrelated project overrule that would be undesirable.

                Could also be weaponised by popular repos. If you have 44k star repo, use a licence that requires the funds for your popular library go to 43k+ repos, and strangle out everyone else.

                • CapitalistSusScrofa@lemmynsfw.comOP
                  1·
                  8 months ago

                  It does seem problematic. I could see it being a larger issue later, so it could be good to find a better solution.

                  Some possible alternatives

                  • Remove the ability to move it up/down.

                    • The consequences of this seem worse to me. Set permanent numbers might have been good at first, but there’s potential for them to become worse

                  • Distribution to different set groups.

                    A simple example would be a distribution on repositories sorted by stars.

                    • The lowest 25% receives nothing, there’s a cut off to reduce abuse.
                    • 25 - 50% receives 33%,
                    • 50 - 75% receives 33%
                    • 75 - 100% receives 33%

                    This is just an bad example, but seems more careful in distribution than 1000 stars that can be increased by other licenses. It’s definitely more complex to understand, but tools could simplify it

                  • Something else?

                    • It doesn’t seem possible to move star counts down easily
                    • It doesn’t seem possible to change the amounts later with the license. I don’t think a company is going to be too willing to choose a license that seems to imply funding groups are available then leaves the potential for them to drastically change later
                    • I mean, I guess it could always be more complex
                      • ex. 5% royalty to a non profit where any person who has had their identity verified can vote in elections yearly to…

                  I’m open to suggestions for how it could better.

                  • CameronDev@programming.dev
                    1·
                    8 months ago

                    I cant say i have any useful ideas tbh, sorry. Licence writing is difficult, especially when you are trying to control known bad actors (havent mentioned licence enforcement yet, but thats a whole other minefield). Lawyers are probably the best positioned to give advice.

                    Licences are generally static. A developer can change their licence, but it only applies for code copies from that point onwards. If you dont like the new licence, you can just just not update your copy of the lib (you can also just take a historical code checkout with the older licence).