May be. Most companies already hate agpl so I figure you could solve some of the freeloader problem by dual licensing agpl and proprietary sorta like Qt does.
He's proposing what sounds like Qt but instead of an app framework led by one company it'd be a huge collection of anything useful from a variety of parties, and developers would be compensated in proportion to usage, somehow.
Can't speak in general (and I'm doubtful you can either) but at the big corporate where I currently work we recently opensourced some stuff.
We (the dev team) were suggesting the AGPL but when we got advice from outside counsel[1] they strongly recommended Apache 2 or MIT because of technical legal stuff to do with how the license is drafted. The concern wasn't due to any sort of GPL "virality" type concerns it was to do with the wording of all the linking and "conveying"/distribution stuff which they felt wasn't drafted very well and might be weak if we later tried to pursue someone who was violating the license.
[1] From one of the most reputable big law firms in the US specializing in IP issues
Idk, as a software developer, the process of looking for a library is basically if it’s not MIT, it’s just easier to do it yourself. not even worth spending time integrating to later rewrite. Imo I’d even release our own stuff as MIT just because otherwise it won’t get used.
I do agree that the state of open source is poor, despite it being basically the reason internet exists as it does. I really think we need a modern model that accounts for how masses of people behave in our current work environment.
(EDIT: to clarify, all this is mostly around other contractual issues)
I honestly think the part of open-source that matters most is that it really has no compliance. Free to download is good enough. The fact that you can just download it and use it and don't need to go through legal cannot be understated. Things that are free for private non-commercial use are good enough, because they can be downloaded and used without a PO and getting legal involved. If I wanted to get a $1 donation to the Linux kernel, would never happen. If it's not something that developer's can use behind management's back it's not useful. They'll tell us we have all the ones and zeros we need and are just being lazy.
The people paying the bills don't want better products and just about anything can already be bodged together. Building better products is only desired by the engineers who have no say in the matter.
You always have to go through Legal at $WORK, for any serious $WORK. That's because $WORK can't let you 'infect' proprietary code with copyleft code, for example. Typically there will be a list of licenses that require no further approval to use in your work at $WORK, and for everything else you need to ask Legal.
For non-commercial work you do on your own there's really no real limits on what open source you take and use, and that's great, yeah.
It sounds like Parens is proposing a centralized mutual fund for closed-source license subscriptions. I'm going to disagree and say I'd rather not have a central authority behind this. Developers should be empowered to sell closed-source licenses, support, documentation, examples, etc. themselves as individuals. As a counter proposal I'd rather have code hosting services and package managers offer better monetization tools because that is more decentralized.
Agreed. Developers and consumers already have a relationship with repository platforms - it makes sense to integrate the monetisation or paid support channel there.
Can I coin the term ‘pay per pull’ (not that I think that’s the best approach)? Perhaps you could pay with a freshly minted CommitCoin?
Yeah, a central authority could potentially be beneficial if/while it's run by benevolent people.
But if it gets taken over by (say) political activism types, or just MBA types determined to treat it like a profit center, then it's going to turn to crap right about then. :(
I mean, it doesn't need to be centralised on a single entity
There was https://tea.xyz/ that does something like this, kind of, to a point, using a blockchain approach to see which packages are used. An extension of the same concept to gits would be interesting?
Maybe "Redhat for individuals" would be a better business plan?
You charge 20 bucks for month, and from this you pay 10 straight to OSS developers and with the other 10 you hire a team to offer a N1 level of support to your customers. You could also provide a repository of "vetted software" to prevent scenarios like the xz attack.
This has got to be the hacker version of watching a band you love sell out.
It's crazy where we're calling "I made this thing that was useful for me and I'm giving it away so that it might be useful to others" corporate welfare like they're the ones betraying the spirit of OSS. But the companies that release OSS as a growth hack for their VC funded startups and are happy to take it away when it benefits them, those guys are the real spirit of OSS.
There has never been a time that selling OSS has ever worked and it seems like business are wising up to the fact that there's no first party advantage in OSS. If your plan is make some software and charge for <something else> you better be damn good at the something else. RedHat made it work with a truly ungodly amount of effort on support, documentation, compliance, and security channels.
What if we collected money from users, and that money went to an organization. Then the organization could pay the developers. We could call this idea "closed source."
You're confused, apparently thinking there is only one goal: fund software development.
But that's incorrect, there are at least two goals: ensure that software development can continue, and provide users (whoever they may be) with some approximation of GNU's Four Freedoms (freedom to use, freedom to study, freedom to modify, freedom to distribute).
At least, those are the minimal two goals for anyone interested in FLOSS.
I'm not confused at all, I've been making a living from the FLOSS DAW I've been developing for the last 24+ years.
There is tension between "free to distribute" (which implies you can get it without paying), as well as "free to modify" (which implies you can build it yourself from source) and "the need to ensure that development continues".
But it is only a tension, not a contradiction. Anyone can get Ardour without paying, yet it raises $200k+ per year to help ensure that development continues.
To this day the single most successful open source business model is the SQLite Consortium's. Their approach is to make the codebase open source (public domain even) and the test suite proprietary. Having a fantastic test suite that is proprietary acts to blunt the community's ability to fork the project, and it encourages those who want new features to pay for consortium membership because the team can't easily accept outside contributions (because in order to do so the team has to write tests for those outside contributions). It's brilliant!
It is an amazing model! I think it works well because it's a library that is "infrastructure" / "support" for other systems though (browsers, android)
I wonder if it applies to the kind of software that is more complete like anything with a UI etc. If I get the final result the tests don't mean much to me.
Well, it applies to very popular software. SQLite3 is probably the most popular software ever written. This really might be a special case. But it probably would work for things like: OpenSSL, PostgreSQL, Java, Rust, and a few others. Most if not all of those don't need to change models, which leaves newer / less popular projects, and for those to bootstrap this model is difficult. It might be that the SQLite model is unique -- that it won't be repeated much or at all.
I wish you well, Paul, and I'm glad that you're making open source work. I was just saying that what Bruce Perens is suggesting isn't open source.
In fact, what Bruce is proposing is a "source under glass" license. Look, but don't touch. Pay to play. Microsoft offers some companies access to the Microsoft Windows source under that kind of license. Is it open source? No.
Whose goals are you talking about? OSI's? Yours? Some average person?
Open source is always part of a business strategy, typically even for individual tinkerers since they can use their own open source work/contributions as part of their portfolio and thus leverage it to get more and better contract work / jobs.
> Whose goals are you talking about? OSI's? Yours? Some average person?
Just what I said in the GP: anyone interested in FLOSS
It may be the case that in 2024, lots of people "do open source" as part of a business strategy. But I can assure that it was not so in 1986 (when I first encountered the GNU project) and it wasn't that way in 1999 when I started working on Ardour.
> Just what I said in the GP: anyone interested in FLOSS
Except we're not monolithic. We each have our reasons, and one person's rationale for open sourcing (and with what license) may vary by project and with time.
> It may be the case that in 2024, lots of people "do open source" as part of a business strategy. But I can assure that it was not so in 1986 [...]
Not explicitly, perhaps, but already in the 70s there was something of an understanding of mind-share. Building mind-share is easily (IMO) the most important reason to go open source for any given project, though there's others too.
As we have recently discovered, the current system is clearly open to exploits. Closed source isn’t any better. We need a way to audit the source to find the potential exploits before they are deployed.
A single incident doesn't really demonstrate that it's "open to exploits"; it just demonstrates that it's possible, but no system is 100% foolproof so that's not really meaningful.
I can only recall two incidents: the other being the JS event-stream cryptothing and that was five years ago. Perhaps there are others I'm not aware of, but by and large, it seems very rare that projects that see real-world usage get compromised.
(and don't give me any of that "but we don't know how often it happens!"-bollocks – you can always say that about almost anything; go find evidence).
> "but we don't know how often it happens!"-bollocks
I am not sure why you describe that as bollocks. The most surprising part of the xz backdoor is that it was discovered by sheer luck. Imagine what would've happened if the backdoor hadn't caused a noticeable slowdown. It is not a stretch to imagine that there might be other backdoors in OSS that are not (yet) found.
Don't see how this can work. How would you encourage collaboration between projects when they are kind of competing for resources? How to track the 'contribution' of certain projects?
Some projects may be more important to some and less important to the others, does it mean they need to pay a subscription plus a donation to support that a specific project?
And it feels like this will become a paywall, like those academic publishers, with most of the money going to 'administrative fees' as well as legal fees.
I sympathize with Perens but I don't that this is the right approach. At least not yet.
The recent moves by the EU and the DoJ to regulate companies like Google and Apple fill me with hope that we can fix the problems that these monoliths create.
We shouldn't have to destroy something like open source to stop them from taking advantage of us.
We should just regulate away their ability to take advantage of us.
I have wondering about this model. Somehow developers/companies should get marketing from product being free, but then should also be paid for it... I personally see that these technologies are often picked up because they are free. Meaning that if they were not it would have been unlike option to choose.
It is like having your cake and eating it too...
I'm not sure if there is any good solution. Maybe it is just going back to something like source available... And selling actual products or services.
By "OpenAI" I mean anything that scrapes open source code to profit off of it especially without giving credit. Any other conversation is a distraction. And while tech bros pontificate Red Hat is dying.
This feels like the opposite direction of where we should be going. Open source should be more like science where you will never get paid unless some company or lab is paying you to do it, and there is a hard focus against commercialization. Parens approach seems revolting
I work at a big company where we both consume and contribute to open source. Our single biggest problem in open source is vendor license issues like confluent and redis, where we can't get that service from a cloud provider without hoops.
It should be a union, like the Screen Actors Guild. An entrepreneur model already exists for developers; start a company with your software and monetize it. But most developers don't want to do all the activities involved in making a company. Open source developers want to work on their choice of software and get paid. A collaborative venture, like a union or guild, aligns with this.
> OSI has always existed to shift the conversation from talking about freedoms and rights in the digital era to about software quality.
That seems wildly inaccurate.
If you take a look at their internal license discussion mailing list, the majority of the time the members are talking about the freedoms and rights of various licenses and proposals.
open source let some of the most brilliant people in the world find each other, collaborate, and coordinate to produce a tech ecosystem that transformed our whole species and its quality of life in three short decades. it succeded. there are no poor FOSS contributors either.
the music industry is a bad model to emulate because the incentives are even worse than FOSS to rob creators. Streaming platforms paying out fractions of a cent for thousands of uses would be the example software would likely converge on. what free software did phenomenally well is establish merit and signal capability in a culture that produced the most wealth of any other era.
who is it broken for? maybe people who want to use tech as a proxy to govern people without adding value, but i'd argue that's a feature not a bug.
Asking that because there seem to have been plenty of posts over the years from people working on OSS stuff, who are or have faced financial difficulties.
many troubled people who have experienced homelessness and addiction as well, but if you are committing code to projects that people use, you are separate and a part of a rich community
(1) Proprietary license with annual term, annual mandatory customer audits, and customer revenue-based payment,
(2) Massive bundling so it would all be under one license and payment,
(3) Automated, “git depository”-based determination of revenue sharing to contributors,
(4) Despite #2, multiple different companies involved in actually taking and redistributing payment.
Whose problems is this solving? It’s not solving real user problems (except maybe for some large enterprises, where the added annual fee might be worth the supposedly simplified compliance, though I don’t actually see that this offers necessarily offers simplified compliance.) It’s not solving the problems of the VC-funded startups that have been complaining about not being able to make money off open source. I don’t think its really solving individual developer payment issues better than users with substantial interest paying developers directly for work that those users are interested in and/or supporting foundations backing projects of interest.
reply