Live data from Hacker News

Death of an open-source business model

joemorrison.medium.com

221–223 of 223 posts

Re: Death of an open-source business model

#221
post #167

Earlier quoted context omitted.

> what about companies which aren't controlled by the larger corp? Include these companies in the definition? > What do you do? Generally, there will be situations that are hard to define in a license, as is the revenue sharing part of it - and that's probably why no such license exists yet. The easiest way around this is for a blanket catch-all clause such as "you have 1 year to start negotiations with us, after whi…

> Include these companies in the definition? Surely not by name if they don't exist yet? And the rest of the bullets were pointing at why it's difficult to pinpoint them with additional terms. > The easiest way around this is for a blanket catch-all clause such as "you have 1 year to start negotiations with us, after which this license automatically expires". Which is great if you have some kind of legal foothold on…

> it doesn't magically hold third-parties responsible

Whatever scenario you imagine where some $bigtech benefits from using the software, there is some identifiable chain of events from where the software was produced, which can, with some effort, be defined and specified in a general way in the license, in terms of a contract that allows each party in the chain to supply to the next party in the chain.

From that perspective they will never be an independent third party, and therefore you can specify that in a contract. So I don't see a theoretical problem to this, just a practical one of specifying this both precisely enough to be enforceable, and general enough to cover all real cases.

Re: Death of an open-source business model

#222
post #180

Earlier quoted context omitted.

I wish there was a FOSS license with a clause along the lines of: - if your company makes >X revenue a year, give us some of it. Ofc, they (FSF/OSI/DFSG) would have to relax their FOSS definition(s), but with more projects dying in this way hopefully more FOSS organisations will take heed and think about this. Ofc, the wording of the license has to be precise enough to avoid something like fobbing off the servers to…

Is this going to be fixed/known price? then you are describing "source available" model. I don't think we need another word for it -- it exists, and it works pretty well (even Microsoft uses it sometimes) Or are you describing some sort of system where the authors get the fixed share (%) of user's company revenue? I think this is not going to work very well... just imagine a big company which is not focused on comput…

No, "source available" does not generally allow one to distribute and sell your own modifications.

This license would be exactly like today's FOSS, except to force large tech companies to the negotiating table to share revenue.

Re: Death of an open-source business model

#223

Earlier quoted context omitted.

I wish there was a FOSS license with a clause along the lines of: - if your company makes >X revenue a year, give us some of it. Ofc, they (FSF/OSI/DFSG) would have to relax their FOSS definition(s), but with more projects dying in this way hopefully more FOSS organisations will take heed and think about this. Ofc, the wording of the license has to be precise enough to avoid something like fobbing off the servers to…

> - if your company makes >X revenue a year, give us some of it. This would just lead to Hollywood-accounting, where a AWS-Tools subsidiary does all the software at a loss, and AWS-Cloud is just a user etc.

Whatever scenario you imagine where some $bigtech benefits from using the software, there is some identifiable chain of events from where the software was produced, which can, with some effort, be defined and specified in a general way in the license, in terms of a contract that allows each party in the chain to supply to the next party in the chain.

From that perspective they will never be an independent third party, and therefore you can specify that in a contract. So I don't see a theoretical problem to this, just a practical one of specifying this both precisely enough to be enforceable, and general enough to cover all real cases.

Post reply on HN