Most active commenters

    ←back to thread

    275 points pabs3 | 12 comments | | HN request time: 0s | source | bottom
    Show context
    palata ◴[] No.45148071[source]
    > Projects with CLAs more commonly are subject to rug pulls; projects using a developers certificate of origin do not have the same power imbalance and are less likely to be rug pulled.

    Would be worth explaining why: my understanding is that if you sign a CLA, you typically give a right to relicence to the beneficiary of the CLA. So you say "it is a GPL project, my contribution is GPL, but I allow you to relicence my contribution as you see fit".

    If the project uses a permissive licence already, honestly I don't really see a big impact with signing a CLA: anyone can just take the codebase and go proprietary with it. However, if it is a copyleft licence, then signing a CLA means that the beneficiary of the CLA doesn't play by the same rules and can go proprietary with the contributions!

    If you don't want a rug pull, you should use a copyleft licence and not sign a CLA: nobody can make Linux proprietary because the copyright is shared between so many people.

    If you use a permissive licence, then a rug pull is part of the deal.

    replies(5): >>45148427 #>>45148502 #>>45148634 #>>45148648 #>>45148948 #
    charcircuit ◴[] No.45148502[source]
    There is no such thing as a rug pull in regards to open source. A GPL copy of your code will exist forever.
    replies(4): >>45148582 #>>45148637 #>>45149245 #>>45154216 #
    zozbot234 ◴[] No.45148582[source]
    Yes, it's a pretty weird notion. The only "rug pull" is wrt. ongoing maintenance of the project, but any maintainer may end up abandoning their own project for any reason or no reason at all. This is why essentially all FLOSS licenses have long provided for the right to fork the existing codebase under a new maintainership.
    replies(2): >>45148671 #>>45167404 #
    1. Spooky23 ◴[] No.45148671[source]
    Unless you can sustain a fork, it is a rug pull if you’ve incorporated the software in other projects. Imagine if a non-trivial critical project like OpenSSL had this happen.

    Shitty behavior like this is more common with software both OSS and commercial than in the past. Treat any meaningful software engagement like a celebrity marriage.

    replies(4): >>45149174 #>>45151762 #>>45152745 #>>45153772 #
    2. sparkie ◴[] No.45149174[source]
    The biggest issue is that companies which depend on something like OpenSSL do not do enough to sustain it, leaving its maintainers working often uncompensated, for the benefit of people making far more money.

    Would it be a rug pull if those maintainers simply burned out and decided "I'm moving onto something else," Leaving the project in limbo, with nobody maintaining it?

    Or maybe they really do enjoy working on the project, but it doesn't pay the bills, so they have to look for an alternative way to monetize it, and that way can continue working on it.

    My opinion is that unless you genuinely just enjoy working on something and sharing it, you are not obliged to do unpaid labour for the benefit of anyone else. Companies depending on FOSS software should be contributing financially to each and every one of them. This is the real shitty behavior - the expectation these companies have of getting bugfixes and improvements for free.

    In the Mongo/Elastic and Amazon cases for example, this is far smaller companies being taking advantage of by a giant. IMO they were right to "rug pull" by relicensing under SSPL. Amazon can easily afford to maintain forks for these projects - but it probably would've been cheaper for them to just contribute financially, and they wouldn't have needed to switch from AGPL. Anyone who works on OpenSearch without compensation is a fool - essentially doing unpaid labour for one of the wealthiest companies on the planet.

    3. Ekaros ◴[] No.45151762[source]
    I find it weird that companies do not have explicit plans for each dependency they pull in. In case of maintenance is dropped and there is critical vulnerability.

    Being able to fully support each and every dependency you use should be absolute minimum for any commercial project.

    replies(2): >>45153348 #>>45153714 #
    4. rpcope1 ◴[] No.45152745[source]
    If you're not paying or contributing, who are you to complain if the maintainer(s) stop working for free? The level of entitlement is amazing.
    5. thayne ◴[] No.45153348[source]
    Unless you are the size of Google, it just isn't feasible. Most companies don't have the resources to fully support every piece of their tech stack. It would be more practical if the cost of continued maintenance was spread among all companies that depended on the dependency, but I'm not sure how best to accomplish that.
    replies(1): >>45154015 #
    6. socalgal2 ◴[] No.45153714[source]
    You could say that about anything though. A bakery has dependenices on fruit suppliers, flour suppliers, paper and wrapping suppliers, the baker(s), the cashier(s), etc. All of which could disappear and they'll have to find new ones
    replies(1): >>45156307 #
    7. zbentley ◴[] No.45153772[source]
    There are also plenty of massive, popular open source projects which don’t require much if any ongoing maintenance. OpenSSL-ish things are the exception, not the rule.

    Of the rest, it’s fine to keep using old versions of things…however, things with ecosystems that move on or contributors/users that fetishize “actively maintained” as a use-this-not-that indicator can complicate that decision.

    8. positron26 ◴[] No.45154015{3}[source]
    Yep. They have to pool resources and effort to make it make sense. That requires some mechanism of coordination that pulls in enough participation to keep it representative. I'm all over this. PrizeForge's Elastic Funding was designed expressly to create meaningful cooperation between businesses, prosumers, and regular users of all shapes and sizes.
    replies(1): >>45155412 #
    9. mastax ◴[] No.45155412{4}[source]
    That’s basically what RedHat is (was?) for
    replies(1): >>45155651 #
    10. positron26 ◴[] No.45155651{5}[source]
    There's several ways to do it:

    - incorporate

    - foundation (a subtype of incorporating)

    - government

    - cooperatives

    The trouble with corporations is that they do have interests that are very independent of their customers and they are not good agents (principle-agent problem). RedHat, partly because they could not figure out better ways to monetize, has increasingly fought gadgets with gadgets, creating service contracts for support interfaces for open-core products and so on. This does not maximize the value delivery of open solutions.

    Government is not known for speed or efficiency. Good luck getting the average Joe to understand why your little git repo needs to come out of his payroll. Even if you get something passed, now all Joe hears on the radio is about how you're stealing his paycheck. Less learned: narrow interests are easy political targets. Okay so let's do a foundation!

    So how about foundations? Every single git repo needs a foundation? That's a lot of overhead. Foundations have a scope. They can also suffer from principle agent problems. Foundations are a good solution, but they themselves have not really adapted to the information age. Rigid, self-serving governance can easily become entrenched by insiders who beat the drum while cashing checks.

    PrizeForge solve a lot of these problems just by being very broad in scope and very neutral as far as interests. More payment is better. If the market wins, we win. We don't really have to care who or why but we should try to protect customer value by making money smarter and creating the means of coordination so that nobody moves alone.

    PrizeForge is not good yet. But it will be. Our solution for the principle-agent problems will completely change how we do social. To start, we've started operating our fund-matching systems. Those will help us bootstrap faster. We can serve some of the communities we know well while building up the rest of our features. (Log in after a few hours, I'm currently doing maintenance).

    replies(1): >>45169699 #
    11. Ekaros ◴[] No.45156307{3}[source]
    Second source is not too hard concept. You should have second supplier ready to go for your business critical supplies. Or be ready to produce those yourself in case of software.
    12. thayne ◴[] No.45169699{6}[source]
    > Good luck getting the average Joe to understand why your little git repo needs to come out of his payroll.

    That specific problem could be solved by funding it from taxes that only tech companies have to pay. Maybe something like how FDIC works, where if you want to sell SaaS, you need to pay for some kind of security insurance from the government, and the funds from that are used to support open source projects.

    Of course, there are other problems with having the government do it, but I think the taxes issue is solveable. And personally, I'd rather see my taxes spent on helping open source software than military and weapons.