[HN Gopher] Fair Source: Sustainability with no customer risk
___________________________________________________________________
Fair Source: Sustainability with no customer risk
Author : ezekg
Score : 21 points
Date : 2024-08-11 16:16 UTC (6 hours ago)
(HTM) web link (pepicrft.me)
(TXT) w3m dump (pepicrft.me)
| ezekg wrote:
| Prior musings on the topic from the author:
|
| - https://pepicrft.me/blog/2024/08/02/commercial-oss
|
| - https://pepicrft.me/blog/2024/07/22/openness-as-a-tool-of-tr...
|
| - https://pepicrft.me/blog/2024/07/09/when-you-are-open
| Sytten wrote:
| Is there a similar license for non SaaS software? I feel the B2C
| space didnt get the same attention for those new licenses.
| ezekg wrote:
| There's the Fair Core License [0] for projects that monetize
| self-hosting with commercial features e.g. an "open core"-style
| project. Is that what you're thinking? Or what's the difference
| between B2B and B2C in your case?
|
| [0]: https://fcl.dev
| Sytten wrote:
| Nah I am selling software you install on your computer so
| that probably wont work
| ezekg wrote:
| So am I via self-hosting. The license's non-compete isn't
| specific to SaaS like e.g. the ELv2 is. Why wouldn't it
| work?
| wmf wrote:
| For B2C you might be better off monetizing with
| trademarks/branding and marketing.
|
| There's also the FUTO License
| https://gitlab.futo.org/videostreaming/grayjay/-/blob/master...
| but since donations don't work...
| arccy wrote:
| I don't see why you couldn't use it for non SaaS, the Fair
| Source License (FSL) [1] they're using here doesn't say
| anything about hosting, only competition in the form of:
|
| > - substitutes for the Software; > - substitutes for any other
| product or service we offer using the Software that exists as
| of the date we make the Software available; or > - offers the
| same or substantially similar functionality as the Software.
|
| I'm not sure what you'd target with B2C, these licenses exist
| explicitly to allow end users to run their own versions for
| private use.
|
| [1]: https://fsl.software/
| Sytten wrote:
| Because I am selling to thinkerers so if the license allows
| redistribution of modified software that say removes
| limitations of pricing tiers then it is not good.
| Zambyte wrote:
| > Open Source and permissive licenses like MIT and Apache bring
| freedom but don't protect the business. Companies can try to
| benefit from it in a predatory way [...]
|
| I get that this post is about choosing a certain non-Free
| license, but it seems _very_ weird to me to describe businesses
| leveraging the permissive terms of permissive licenses as
| "predatory" behavior. Permissive licenses were created in
| response to hereditary licenses like the GPL _specifically_ to
| allow the kind of behavior that the author is referring to as
| "predatory". Blaming anyone but yourself for choosing to license
| your code with a license designed to enable behavior you don't
| like seems quite silly.
|
| > Other organizations seek protection by adopting AGPLv3, which
| many companies have policies against, and selling dual licenses
| and enterprise features. Those businesses are often referred to
| as Open Core.
|
| Open core is related to, but not the same as the dual licensing
| pattern they are describing. Open core is basically the same as
| dual licensing, but the different licenses actually apply to
| different sets of software under the Open core model.
| nickpsecurity wrote:
| Some people release software under a permissive license, people
| use it according to the terms of that license, and they get mad
| about it. It's unreal.
|
| If they want specific behaviors, they should put them in the
| license or in a contract. Businesses will probably not use it
| over permissive software, though.
| nope1000 wrote:
| > If they want specific behaviours, they should put them in
| the license
|
| But that's exactly the point of the article, isn't it?
| oddevan wrote:
| What's the risk for businesses in a dual-license situation? The
| public can use the AGPL, or the business can get a private
| license with no viral stipulations at all. Is it just the FUD
| around a GPL-like license?
|
| (Serious question, as this is the business model I'm pursuing.)
| nickpsecurity wrote:
| Part of the problem is: "what can I do with the commercial
| source?"
|
| The open-source code lets you modify and distribute. There's
| either no risk (permissive) or well-understood. Proprietary
| licenses often don't allow freedoms like that. So, some of the
| new licenses are addressing modification and redistribution of
| source-available, proprietary code.
|
| Far as AGPL, it's very unpopular even among FOSS users. Just
| using it almost guarantees less adoption of your code. Whether
| that's fair or not, I'm just saying it's a reality that you
| might be limiting the impact of FOSS code if it's AGPL.
| SpicyLemonZest wrote:
| I wouldn't really say there's a _risk_. It 's just inferior to
| an open core model in most cases. The private license deters
| independent contributions, the AGPL license prevents small
| businesses who can't yet afford your system from using it, and
| large corporations don't care at all that your full source code
| is publicly available.
| ezekg wrote:
| I would argue that fair core is, in a lot of cases (not all
| ofc), superior in the long run to open core, because under
| fair core, the entire code base eventually becomes open
| source, unlike open core where commercial features remain
| proprietary/closed indefinitely. There are pros and cons of
| both that need to be weighed ofc, but I personally really
| like fair core.
|
| (Disclaimer: I contributed to the FCL: https://fcl.dev)
| SpicyLemonZest wrote:
| I like the idea in principle after reading through it - it
| lines up with a lot of conventional wisdom about how fast
| software becomes commoditized. But there's a lot of
| practical aspects of commercial development that I'm not
| sure really work when your commits go out to the public.
| How would an FCL codebase, for example:
|
| * Merge a bad change which makes the project worse, because
| it'll unblock a contract that stands to make your company a
| lot of money.
|
| * Iterate on support for a proprietary workload from one of
| your customers, who has _not_ licensed that workload
| publicly and indeed may consider it a trade secret.
| wmf wrote:
| 1. Just do it and don't apologize to freeloaders.
|
| 2. Don't name customers in commits.
| max-privatevoid wrote:
| Perhaps one day we will have a way to monetize software
| development that works for true Free Software and doesn't require
| these bullshit openwashing licenses.
| TheChaplain wrote:
| Then how does it work if I haven't started a business yet?
|
| I invent something, AWS find it useful and start providing it as
| a service.
|
| Now I want a piece of the action and start a business myself.
|
| Does that means AWS have to stop offering the service?
|
| Also same if I change direction of my business, to begin
| competing with a company providing the service.
|
| If that is the case, I don't see why companies would touch
| anything with that license...
| stavros wrote:
| If you're starting a project with the intent of eventually
| making it into a business, you use this license and AWS doesn't
| touch it. If you're starting a project with the intent of
| always keeping it FOSS, you use MIT and don't care what AWS
| does.
|
| Sentry's license is a fantastic alternative to just never
| opening up the source, and that's how we should be thinking
| about it.
| cge wrote:
| While I'm not quite sure what my opinion on this license is
| yet, it does appear to try to at least partially address that.
|
| Whether or not you are offering the software itself as a
| service, the license does not allow it to be commercially
| offered as a service directly at all.
|
| For services _using_ the software, it prohibits the user making
| the software available to others as part of a commercial
| product or service that "substitutes for any other product or
| service we offer using the Software that exists as of the date
| we make the Software available", with the "Software" being
| "each version of the software".
|
| That would seem to mean, for simply using the software, that
| AWS could continue offering the service, but after that point,
| would not be able to update to the next version of the
| software. It seems like the other prohibitions would prevent
| them from forking it, but possibly not from working around the
| old version in other code.
|
| In practice, it would likely mean no one would use the software
| commercially for two years, or would simply use two-year-
| outdated versions, perhaps with patches.
| stavros wrote:
| "Fair Source" strikes me as a great idea, but I see many many
| people misunderstand the intent, and being mad at the company for
| not using a FOSS license. However, that was never the choice: The
| choice was always between "fair source" and "closed source", and
| I'm glad a reasonably open alternative to closed source exists.
| wmf wrote:
| We're still in the hangover period from when VCs would shovel
| money into open-source startups that had no business model.
| Fair source feels like a step down from that.
| stavros wrote:
| And it's a smaller step down than closing the source
| completely.
| woodruffw wrote:
| I think it's a great idea, but I'd love to see a _little_ bit
| more consideration around labeling one's licensing scheme as
| the "fair" one.
|
| Intuitively: if I named my political party "the party without
| stinky feet," it's clear that I'm indirectly saying that other
| parties do have stinky feet. In a similar manner, labeling
| yourself the "fair" one indirectly suggests that other
| licensing schemes, including OSS ones, are somehow unfair.
| LoganDark wrote:
| Open-source licenses absolutely can be unfair. If a company
| takes your MIT-licensed software and builds a huge enterprise
| on it and gives you none of the money? That's unfair for you.
| But with closed-source software, it's unfair for everyone who
| uses it. So imagine if there were some sort of middle ground.
| (I'm not currently aware of a good one, lol)
|
| I'm not talking about if someone uses left-pad as part of a
| billion LOC project, but more like if a company builds its
| entire stack on top of something like, say, ffmpeg, or
| ImageMagick, and the original devs never see even a smidgeon
| of thanks.
| woodruffw wrote:
| Sure, I wouldn't describe that as fair. But that's my
| point: OSS licenses don't use phrases like "fair": they
| talk concretely in terms of _rights and guarantees_ , and
| they leave it up to both parties to determine whether those
| rights and guarantees are what they want.
|
| I think this _can_ be fair. But I would love to have seen
| that communicated as "we wrote the license to address the
| problem of fairness in corporate usage of OSS," not "this
| _is_ a /the fair license." The latter is a value judgment
| that isn't universalizable.
| LoganDark wrote:
| I read it at first like the usage of fair was as in
| quantity, as in a middle ground between fully closed and
| fully open. But calling it a "medium source license"
| would probably sound weirder than "fair source".
| woodruffw wrote:
| King Solomon has a thing or two to say about middle
| grounds :-)[1]
|
| (I agree that "medium source" sounds very weird. Maybe
| they could have called it the "Availability License" or
| something similar to emphasize that this is about finding
| a sweet spot between monetization rights and exposing the
| source code to the public eye. I don't think that would
| carry the same baggage as "fair," but it also certainly
| doesn't have the same marketing flair to it.)
|
| [1]: https://en.wikipedia.org/wiki/Judgement_of_Solomon
| ThrowawayR2 wrote:
| Use without compensation is what an author intentionally
| signed up for by choosing the MIT license or other FOSS
| licenses. The marketers are trying to sell this as
| "unfair", "predatory", etc., as if the authors were too
| ignorant to understand the implications of their own
| license choice.
|
| It is perfectly fine to choose Fair Source as a license;
| that's the prerogative of whoever is writing the code. But
| don't let these people marketing Fair Source circulate the
| idea that FOSS licensing is "unfair". It's just another
| sleazy tactic they're trying after their attempt to
| redefine open source to include their proprietary Fair
| Source licensing got rebuffed by the community.
| eikenberry wrote:
| Does is require a CLA? That's the deal breaker for me as
| distributed license ownership is one of the most important ways
| free software is kept free. Changing the license of a large free
| software project should be hard/impossible.
| the_mitsuhiko wrote:
| The FSL and other licenses are not special when it comes to how
| the contributions are managed. In theory every contribution
| needs a CLA or something similar regardless of where you
| contribute it accept contributions.
|
| That most projects don't require that is typically a result of
| "it doesn't matter until it matters".
| davidgerard wrote:
| Yet another way to spell "proprietary" - who says tech can't
| invent new things?
|
| Why is it all these companies try to change the meaning of "open
| source" rather than open their source?
| bigstrat2003 wrote:
| They very specifically are not using the term "open source", so
| your objection is kind of unreasonable.
___________________________________________________________________
(page generated 2024-08-11 23:01 UTC)