[HN Gopher] GitButler is now fair source
___________________________________________________________________
GitButler is now fair source
Author : odo1242
Score : 69 points
Date : 2024-08-07 18:35 UTC (4 hours ago)
(HTM) web link (blog.gitbutler.com)
(TXT) w3m dump (blog.gitbutler.com)
| thmsths wrote:
| That's the first time I've heard about the fair source license.
| From what I understand it's slightly more restrictive than FOSS,
| but it aims to prevent hyperscalers from basically running your
| software in their cloud while you can't make a dime from it.
| eslaught wrote:
| The term appears to be a new one. There's a definition here:
|
| https://blog.sentry.io/sentry-is-now-fair-source/
| andrewstuart2 wrote:
| I'm really glad that they've made a conscious effort to be
| transparent in the fact that this is not open source. That said,
| I'm less sure how I feel about the movement as a whole. I admire
| the desire to make source code transparently available, and let
| people use it for free, but I think strict open source is the
| best net good for the world we live in. I can run apps on Linux
| in any cloud I want to because every cloud is free to run it. And
| so I benefit from getting to choose among competitors (including
| self hosting) where that doesn't exist in a world where
| competition is forbidden.
|
| It's also ironic to me that this software is being built on top
| of git, and thus is a business model entirely dependent upon
| FOSS, while wanting to differentiate and build a business on top
| of it with a moat but still sharing the code in a way that
| protects them. It just seems like an uncomfortable position
| straddling the fence between two paradigms.
|
| Maybe I'm privileged in the fact that I've always lived
| comfortably enough in my career to feel like I can write and
| release OSS under the most permissive terms (whether it's used or
| not). But that feels like the best way to give back to the
| movement that effectively led me into this career for free, and
| lets me pick from offerings that are forced to differentiate on
| price or other features rather than whether they can license the
| software.
| paxys wrote:
| The contributor side of it is important as well.
|
| If I'm using an open source product, I'm generally very happy
| to spend long hours debugging edge cases, writing detailed bug
| reports, pushing fixes, suggesting and adding enhancements and
| generally being involved in the community, knowing that I'm
| doing my share and improving the experience for everyone.
|
| Nowadays it is increasingly likely that my effort is eventually
| going to be relicensed and repackaged into non-free software
| without my consent, and no one (not even me myself) will be
| allowed to continue to benefit from my work.
|
| IMO the issue really lies with the VC funding model. Every
| single one of these projects that has done a license bait and
| switch has taken outside funding, and these investors want to
| see an exponential return, which simply cannot be attained by
| keeping the software free. Stewardship by a reputed open source
| foundation is the only possible future for such projects if
| they want to actually stay open and do right by their
| community.
| gjsman-1000 wrote:
| > Nowadays it is increasingly likely that my effort is
| eventually going to be relicensed and repackaged into non-
| free software without my consent, and no one (not even me
| myself) will be allowed to continue to benefit from my work.
|
| The curious thing (and developers have the right) is that
| permissive licenses, like MIT, are growing every year while
| copyleft licenses like the GPL are decreasing in popularity.
| According to a loose Statista graph, ~41% of OSS projects
| used permissive licenses in 2012. By 2021, it was ~78%.
|
| _The Register_ has also noted this phenomenon. Copyleft is
| completely out of fashion. https://www.theregister.com/2020/0
| 1/17/mit_apache_versus_gpl...
|
| Personally, if I was making a solo OSS project, I completely
| get it. If Google wants to use it, even if they never gave
| back, I would be honored and quite possibly get a job from
| that. Using GPL just means my software will only be useful to
| GPL-loving compatriots, which is to say, almost nowhere
| outside the Linux communities. It's also not fair when my
| company (like most companies) benefitted immensely from
| various bits of MIT/Apache licensed software, so to give back
| to the community as a whole with the GPL feels unfair.
| WesolyKubeczek wrote:
| > The curious thing (and developers have the right) is that
| permissive licenses, like MIT, are growing every year while
| copyleft licenses like the GPL are decreasing in
| popularity.
|
| Not very surprising given the sizeable army of all the
| "developer evangelists", "developer advocates", and "devrel
| people" who have been quite vocal on the gpl-bad-mit-good
| stance, all the while being on Big Tech's dime, one way or
| another.
|
| Why would Big Tech want to promote this view so much?
| Commoditize your complement, that's why.
| danenania wrote:
| Open core is a tried and true business model. It's
| essentially just freemium, which businesses have done
| forever. If a healthy proprietary product can be built on the
| open source base, that's a win-win. The company gets revenue
| and a sustainable business; the community gets free open
| source software with a highly motivated steward. There's no
| reason to relicense if it works.
|
| Things can go wrong in various ways of course, and drawing
| the line in the right place is a challenge, but that doesn't
| mean that every VC-backed open core product is doomed to
| relicense. There are many examples of it working out well for
| both the company and community.
| the_mitsuhiko wrote:
| Open core in practical terms keeps many useful parts away
| of a product. A good example of this is clickhouse recently
| which keeps some of the most interesting features locked to
| the cloud version exclusively.
| ezekg wrote:
| This is the reason why I believe Fair Core [0] is
| superior to open core, because the former eventually open
| sources everything, while the latter never open sources
| the useful parts. That's actually one of the main reasons
| I relicensed to the FCL from the ELv2 [1].
|
| [0]: https://fcl.dev
|
| [1]: https://keygen.sh/blog/keygen-is-now-fair-source/
| bigstrat2003 wrote:
| > Nowadays it is increasingly likely that my effort is
| eventually going to be relicensed and repackaged into non-
| free software without my consent, and no one (not even me
| myself) will be allowed to continue to benefit from my work.
|
| I disagree with the conclusion you have drawn here. In the
| scenario you describe, you (and everyone else) can continue
| to benefit from your work. The original project is still
| there, it's still just as useful and open as the day you made
| your contribution. How then is anyone prevented from
| continuing to benefit?
| andrewstuart2 wrote:
| While true, I think the reality is that this is still being
| figured out in the legal system right now. Forks of redis
| and hashicorp products _should_ be completely fine
| theoretically, but there 's a lot of legal chaos right now
| with the owners of the BSL versions trying to figure out
| if/how to prosecute the open versions for adding similar
| features to the "source available" versions. I've heard
| contributors to the forks on popular podcasts having to say
| "I'm not sure I can comment on this right now" due to
| ongoing battles and legal advice.
|
| I'd love it to be cut and dry fork-wise but there are
| parties with vested financial interests trying to keep the
| OSS forks frozen in time. If anything, "source available"
| is almost weaponized because if you've looked at the
| available source, it's tenuous. And if two implementations
| of the same feature look similar (as they will) it might
| not be as easy to convince a jury that it's not a copying
| of copyrighted now-unlicensed code.
| nindalf wrote:
| > these investors want to see an exponential return
|
| Don't think this is the reason, at least for Sentry. They've
| been in business for more than a decade.
|
| The bigger reason is that it would take AWS 2 weeks to offer
| a version of their product. It would be API compatible
| because it would be exactly the same code. AWS would offer an
| introductory price of $0 for the first year. Not all Sentry
| customers would switch, but many would. Sentry would continue
| to develop their product, while AWS maintained a skeleton
| crew to deploy their changes and make most of the money off
| it.
|
| While it may be easier to assume the worst of people,
| ascribing all kinds of intentions to them, just listen to
| them. They say "we don't want AWS to deploy our product and
| take all our customers". They say it because it's what
| they're really worried about.
| paxys wrote:
| https://sentry.io/about/press-releases/sentry-
| raises-90-mill...
|
| Sentry raised $90 million in a series E round in May 2022,
| and their total funding is sitting at $217 million.
|
| No cloud provider even offers a hosted version of Sentry,
| so it's not like that's an issue for their business.
| Spinning up a VM and deploying your own version is
| incredibly straightforward. Which is exactly why they now
| need to switch licenses and put newer features behind more
| restrictive terms so users are forced to pay.
| ezekg wrote:
| > No cloud provider even offers a hosted version of
| Sentry, so it's not like that's an issue for their
| business.
|
| https://cra.mr/the-busl-factor
| bentlegen wrote:
| > Which is exactly why they now need to switch licenses
| and put newer features behind more restrictive terms so
| users are forced to pay
|
| Sentry switched to BUSL in 2019, almost 5 years ago.[1]
|
| Most of the aforementioned fundraising occurred after the
| license change (e.g. the $90MM round you mention from
| 2022, and another $60MM round in 2021).
|
| The "restrictive terms" - which again, were introduced in
| 2019 - are that you can use the software but not use the
| code to compete against the software's authors. For
| 99.99% of users, this has been a non-issue, because most
| people have no interest in doing so.
|
| [1] https://blog.sentry.io/relicensing-sentry/
| whit537 wrote:
| In addition to our 100,000 SaaS customers, we also have
| 10,000+ (unmonetized) self-hosted users:
|
| https://openpath.chadwhitacre.com/2024/widespread-use-of-
| a-f...
|
| Fair Source is working quite well for us. You should try
| it. :^)
| layer8 wrote:
| > It's also ironic to me that this software is being built on
| top of git, and thus is a business model entirely dependent
| upon FOSS, while wanting to differentiate and build a business
| on top of it with a moat but still sharing the code in a way
| that protects them
|
| To be fair (no pun intended), they could build it on top of
| two-year-old Git just the same. I rather fear that two years of
| DOSP are too short to be attractive for many companies that
| might otherwise adopt that license model.
| gjsman-1000 wrote:
| This will probably be the biggest weakness with the FSL.
|
| Some companies will say, "it's FSL 1.1, but three years." Or,
| "it's FSL 1.1, but four years." Or, "it's FSL 1.1, but only
| if we go bankrupt." And on and on.
| zeeg wrote:
| FSL is strict on two years. We certainly would not promote
| a version that's variable. You could make one, but it's our
| job as a community to say "no!"
| ezekg wrote:
| When we really think about it, what's the real fear behind
| 2-year vs 4-year DOSP? Is it that users will choose the
| 2-year OSS version over the latest version, or that it
| encourages more viable competition? The former sounds like a
| value problem, and the latter sounds like an adoption
| problem, and those share a root problem.
|
| The BUSL with a 4-year delay has shown to work, so why
| wouldn't the FSL with a 2-year delay also work? I personally
| feel like 2 years is a good enough head start i.r.t.
| competition, while providing users with more viable options
| to recover a lost or sunken ship.
| layer8 wrote:
| The longer a product/service exists, the easier it is to
| compete with it based on the version two years prior, in
| particular if the source of the current version is also
| available (even if you can't use it verbatim -- but you can
| build your own variant of newer features, possibly even
| with a fully compatible API).
| ezekg wrote:
| Sure, but the same can be said for the 4-year delay, too.
| I don't really see a big difference, and I'm using the
| FCL [0] which is also 2-year DOSP.
|
| If the author is no longer improving the product in
| 2-year cycles, they deserve to be usurped.
|
| [0]: https://fcl.dev
| layer8 wrote:
| I'm assuming that they do keep improving the product, but
| the longer the product exists, the lesser that
| improvement will be, relative to what was achieved
| cumulatively in the years before. A moat is built up by
| keeping accumulating years of improvement, not by only
| retaining a constantly diminishing lead.
| solidsnack9000 wrote:
| Many business models are entirely dependent on FOSS. It's not
| really an argument either way. If it weren't for those
| businesses, a lot of FOSS work would not happen...
| godelski wrote:
| > I think strict open source is the best net good for the world
| we live in.
|
| I agree BUT we've also seen through decades that this model is
| not working. While there are plenty of notable exceptions, it
| is difficult to make a living developing code transparently and
| making it available to the public. We've seen that large
| companies will build around these tools and pressure developers
| but not return compensation. We've seen that many of these
| projects become integral in our infrastructure (though often
| hidden several layers deep). We've seen that code quality is
| degraded as things are rushed and the reality is only a few
| people work on these projects. We've simply learned that we
| can't really rely on donations and corporations will find it
| difficult to justify funding even if they highly depend on it
| (even when it is in their best interest). Because charity is
| "charity".
|
| The real best thing would be to ensure we have an economy where
| we compensate people for work that others find beneficial. As
| in, work is work. If you're developing tools that others are
| using and monetarily benefiting from, you should be compensated
| for that work. The world I want to see is where you can make a
| living as a full time open source dev. And not just for
| gigantic projects that are easily recognizable as critical, but
| anything that is critical. Anything that is useful.
|
| I really want to live in that OSS world, but I think we should
| also have a serious conversation about the issues we face. That
| we need to question if the incentives align like we think they
| align. And consider time, as they might have in the past but no
| longer do. I'll ask a proxy question: Could you research and
| invent a (Star Trek style) replicator in this environment?
| Replace with some other device if you will, but such a thing
| like this would upend many businesses and likely the
| cannibalize itself. But such a tool would fundamentally change
| peoples lives for the better, making post scarcity not only
| possible, but trivial (there are other easier ways to get post
| scarcity). Fwiw, when I ask the economists[0] they give a two
| letter answer.
|
| It is undeniable that the way we've done things has been
| successful. But past performance is no guarantee of future
| performance. The burden of advancement is that you have to get
| more nuanced over time. Essentially, we can do well with a low
| order approximation, but that only goes so far. As you
| progress, you need to account for more and more higher order
| terms. So the question is if we've advanced enough where these
| matter.
|
| [0] I only explain what the device does. Having the ability to
| assemble things from the atomic level. Like a 3d printer but
| for atoms. They are smart enough to figure out the rest and I
| do confirm this. (My partner is an economist, so I pester them
| about things like this and they do others in reverse. It's good
| fun)
| m463 wrote:
| > strict open source is the best
|
| RMS gets a lot of flack, but he's pretty good about defining
| terms like this precisely.
|
| Free software has no restrictions on USE, the restrictions are
| on redistribution.
|
| Open source is ambiguous can mean all the way from "you can see
| the source" to being public domain.
|
| Fair source is not free software. They are restricting how it
| is used.
| cobbal wrote:
| Probably the widest accepted definition of the term open
| source is https://opensource.org/osd
| m463 wrote:
| https://www.gnu.org/philosophy/open-source-misses-the-
| point....
| hn_throwaway_99 wrote:
| > but I think strict open source is the best net good for the
| world we live in.
|
| Hard disagree. I think, importantly, that it is case-dependent.
|
| I don't think it's "the best net good" that essentially the
| only companies that are able to make a profit from certain
| types of open-source products are Google, Amazon and Microsoft.
| It took quite a long time to determine if it would be possible
| for companies to build business models off open source, and so
| now that (again, for certain types of software) those business
| models basically evaporated due to the hyperscalers, I love
| this "fair source" movement.
|
| Like you said, I think it's great that they are _not_ trying to
| confuse this with open source. I think each has its place, and
| I think it 's good that they sound like they're not trying to
| "compete" with open source, they're just trying to build a
| model where companies can be permissive with their source code
| but not have all their profits sucked up by giant tech
| companies.
| bsder wrote:
| > I admire the desire to make source code transparently
| available, and let people use it for free, but I think strict
| open source is the best net good for the world we live in.
|
| Genuinely open source is also a better defense against
| lawsuits.
|
| If the code is open source, some big company can sue, but the
| _end users_ have rights as well as the code copyright holder.
| They 're going to have to prove what code is being used and
| someone is likely to write code around the issue immediately.
| Sure, lots of people _could_ get sued, but it 's either not
| going to be worth it or someone with a big wallet is going to
| get involved which puts an immediate stop to things.
|
| If the code isn't completely open source, then a lawsuit from a
| big company to a small one demanding a pulldown has a _LOT_
| more force since end users have no rights in that case at all
| (see what happened to Our Machinery).
| confident_inept wrote:
| Is there anyone who can break down the advantage of something
| like this over a typical open source model? I read through the
| page and FAQ for fair source and still don't quite grasp the
| angle here other than making software less free for a temporary
| amount of time.
| gjsman-1000 wrote:
| Simple - the standard open source business model sucks. Nobody
| donates, you're in competition with the lowest common
| denominator when offering hosting services, and you might get
| ElasticSearched.
|
| The entire purpose of Fair Source is to allow companies to open
| up the code when they would have never considered it an option
| otherwise. It's a more open license for companies that would've
| otherwise been proprietary without apology.
| apantel wrote:
| The main benefit is you get a rolling two years where no one
| else can use your code to compete with you. It's a lot like a
| patent which gives you a window of time where you have an
| exclusive right to benefit from your creation.
| fishtoaster wrote:
| An increasingly common situation for open source projects is:
|
| 1. The FooLabs company creates the Foo open source software,
| which gets popular
|
| 2. FooLabs offers FooCloud, a paid, hosted, managed version of
| Foo for those who don't want to run Foo themselves.
|
| 3. AWS sees that Foo is popular and creates a competing paid,
| hosted, managed version of Foo (say, "AwsFoo").
|
| 4. FooLabs' hosted version doesn't really have much advantage
| over AWS and AWS has a huge base of existing customers, so it
| outcompetes FooLabs.
|
| 5. FooLabs perceives this as unfair. They did all the work
| creating + maintaining this software, but are unable to reap
| any rewards.
|
| Different people have different opinions on #5, ranging from
| "Hell yeah, screw AWS!" to "What did you expect when you made
| this open source?"
|
| As a result, there have been a wave of not-quite-open-source
| licenses aimed at preventing #3, often with a clause like "This
| license doesn't let you run a paid, hosted, managed version".
| GitButler's license is aimed at doing exactly that. People have
| been calling that "source available." Some people are trying to
| rebrand that as the cooler-sounding "Fair Source."
|
| Some of these have caused huge community upsets because Foo is
| often popular _because_ it 's open source, and it feels like a
| bait-and-switch to suddenly yank that away once Foo reaches a
| certain point of growth. ElasticSearch is the biggest example
| that comes to mind: https://www.elastic.co/blog/licensing-
| change. GitButler, thankfully, is being much more up-front
| about it!
| paxys wrote:
| You forgot 1.1 - FooLabs takes hundreds of millions of
| dollars in VC funding and these VCs want to see a 10x return
| on their investment, which is incompatible with keeping the
| software free and open source.
| somebodythere wrote:
| Sure. Presumably also the developers at FooLabs would like
| to continue having a job developing Foo, and the broader
| software community would like to continue benefiting from
| additional features and improvements to Foo, which probably
| wouldn't happen if developing Foo was economically
| unviable.
| yjftsjthsd-h wrote:
| I think some of the tension is that:
|
| > 2. FooLabs offers FooCloud, a paid, hosted, managed version
| of Foo for those who don't want to run Foo themselves.
|
| > 4. FooLabs' hosted version doesn't really have much
| advantage over AWS and AWS has a huge base of existing
| customers, so it outcompetes FooLabs.
|
| FooCloud is often run with what is perceived as excessive
| costs/margins, so 1. they get really poor uptake, and 2. it's
| really easy for AWS to undercut them.
| escapecharacter wrote:
| I'm trying to find a clear distinction between "Source
| Available" and "Fair Source". Sounds like there isn't any
| common definition for source available other than that you
| are allowed to read the code.
| fishtoaster wrote:
| From use, it seems like "Source Available" generally means
| "it's not open source, but you can go and read the code
| somewhere." So it's more a definition by contrast, really.
| "Fair Source" is a new term defined more precisely by
| https://fair.io/about/ - it seems to refer to be a more
| specific term referring to this specific license type.
| ezekg wrote:
| Exactly. The problem with "Source Available" is that it
| has no real definition and it conveys no user freedoms
| outside of the (loose) freedom to read the source code,
| which is why the term has never taken off with anybody.
| It's wholly inadequate. That's why we needed a new term
| that does have a concrete definition and does convey user
| freedoms. Fair Source is meant to sit on the gradient
| between Open Source and Source Available.
| ensignavenger wrote:
| Fair Source licenses place restrictions on how code can be used
| (for a "limited" time) in order to prevent others from using
| the code to compete with the corporate sponsors of the Fair
| Source code.
|
| It isn't clear what restrictions will be allowed and still
| qualify as a "Fair Source" license. The first Fair Source
| license is the Functional Source License, which converts to
| Open Source after 2 years. It places restrictions on using the
| code to offer any commercial product or service that competes
| with the corporate sponsor.
|
| If you choose to adopt such software, you will be unable to
| switch vendors for hosting, technical support or assistance, or
| any other service which the corporate sponsor offers in any
| way. The corporate sponsor can raise rates, offer terrible
| service, or otherwise do a bad job of supporting your business
| and the only alternative you will have is to adopt a different
| product (with all of the integration and development efforts
| that takes) or to self host and self support the product. You
| will be unable to engage a new vendor, at least for two years
| from the release of the version you are reliant on.
|
| Also, if you contribute to a Fair Source product you will
| likely be forced to sign a CLA that grants rights to the
| corporate sponsor ponsor that go beyond the rights that you
| recieve under the license.
|
| As you can see, I feel that Open Source is a much better model
| that better protects users, contributors, and community members
| of software.
| gjsman-1000 wrote:
| > As you can see, I feel that Open Source is a much better
| model that better protects users, contributors, and community
| members of software.
|
| Assuming that said vendor was even going to open-source in
| the first place. I would take Windows, Affinity, macOS,
| Adobe, literally any major software project under the FSL any
| day. Realistically, the companies that FSL appeals to, were
| never going to consider open-sourcing to begin with.
| ensignavenger wrote:
| If the vendor doesn't go open source, I will look for an
| open source alternative. If none is available, I will
| consider building one. Only after researching those options
| would I consider a propeietary or "Fair" source product.
| And I would be very careful with how I integrate such a
| product into my business.
|
| So yeah, if there are no good open source alternatives and
| building my own would be cost prohibitive, I might consider
| a Fair Source product.
| solidsnack9000 wrote:
| This approach is not available to most people most of the
| time, so it's not going to make a difference.
| the_mitsuhiko wrote:
| > It isn't clear what restrictions will be allowed and still
| qualify as a "Fair Source" license
|
| We called that out on the website though:
|
| Fair Source Software (FSS):
|
| * is publicly available to read;
|
| * allows use, modification, and redistribution with minimal
| restrictions to protect the producer's business model; and
|
| * undergoes delayed Open Source publication (DOSP).
|
| The delayed open source publication part is explicit.
| ezekg wrote:
| In addition, underneath the definition, we touch on that
| even more:
|
| > The intention is for the first point to be a bright line,
| and for the second to invite exploration. We expect Fair
| Source licenses to emerge and evolve and shake out into a
| few clear winners over time, as companies apply Fair Source
| within their own particular business context. The third
| point is also intended as a bright line, and a key
| differentiator of Fair Source from Open Core and other
| approaches.
|
| The key line is to "invite exploration."
| ensignavenger wrote:
| Thank you for pointing that out, I did a quick read
| through of that part and missed the intention behind it.
| I also found the Readme which helps explain the direction
| things are going. (https://github.com/fairsource/fair.io/
| blob/main/README.md)
| ensignavenger wrote:
| "minimal restrictions to protect the producer's business
| model"
|
| That isn't very clear to me. Does every license author or
| licensor get to decide for themselves whether or not a
| license is Fair Source, or whether or not a limitation is
| "minimal"? Honestly, I don't think the limitations in the
| Functional Source License are "minimal". But others clearly
| believe they are.
|
| The delayed part is explicit... but could a license that
| delays release to open source for 1,000 years be considered
| "fair source"? It is a DOSP as you say?
|
| I understand that the Fair Source branding movement is
| still young and is likely evolving policies and procedures,
| but those are some of the questions I already see coming up
| when discussing whether or not a license is Fair Source. It
| may take a while for the definition to mature.
| the_mitsuhiko wrote:
| And it's important that we have these conversations. I
| would however like to understand why you believe the
| limitations on the FSL are too strict and what exactly
| they prevent which you believe they should not.
| ensignavenger wrote:
| Lets say there is an FSL licensed SaaS app. And that the
| company behind it offers two tiers, a lower monthly fee
| that is "self service" with no integration assistance,
| and a higher monthly fee with a long contract term that
| offers integration assistance.
|
| I decide I want to self host the product. I reach out to
| the company about integration assistance. They tell me
| they don't provide any support for the self hosted
| product and aren't interested in providing me with
| integration assistance if I don't use their hosted
| version.
|
| Now, I decide to hire a local contractor I know to help
| me integrate the self hosted version. They don't touch
| the code or do anything with it, they just work on
| integrating it into my existing business stack.
|
| Now, the SaaS company offers a competing product and
| service- the hosted SaaS with integration assistance. Is
| my contractor violating the license by offering a a
| service that substitutes for the service offered by the
| SaaS company?
|
| I think many such SaaS companies would be fine with it,
| it wasn't a job they were interested in... but it rides
| up against the license really closely. And there are many
| variations of this scenario that could play out that
| could easily cross the line. (Perhaps SaaS company puts
| in a bid to do the work, but I decide a local contractor
| I have used many times in the past and is thus familiar
| with my stack and what they would be integrating would be
| better, or maybe the contractor does have to make changes
| to the FSL licensed code in order to make it work with
| something I need.
|
| Those things can be negotiated and clarified, but
| generally only if you know they are an issue up front. If
| business needs change after you have adopted the
| software, you are in a tough negotiating spot.
|
| One big benefit to the well worn and simple permissive
| open source licenses is simply knowing very early what
| exactly I can and can't do. The FSL is trying to get as
| close to this as possible, but it is inherently more
| complicated that "take this code and use it, just credit
| me and don't expect any warranty from me, oh, and by the
| way, if you want my help I offer my service for $$$ so
| reach out" style open source licenses (not all open
| source licenses are simple like that, though).
| zeeg wrote:
| No ones saying Fair Source is better than Open Source,
| but in your analogy one protects the commercialization of
| a project, and the other does nothing to protect the
| creators.
|
| The clarity of what is and isnt permitted is something
| we'll be looking to make sure is enforced via the
| license, at least in FSL's sake. The intent is that if
| you're commercializing by say, providing support or
| integration services, that its totally valid. What's not
| valid is hosting a competitive offering using the source
| code. That is, with FSL you cannot spin up the project
| and sell it as a cloud service, but you can provide
| professional services to customers using said product.
|
| If you decided to build something that tried to sneaky
| leverage the business model that funds development, that
| its so closely related to what the company would do, and
| then the company does it... well, don't do that? You'd be
| stuck on the old version. Thats the price you pay for
| trying to be sneaky. The license is effectively encoding
| a set of values/ethics in how people should run
| businesses, particularly when building on top of other
| peoples businesses. I think this is totally fine, so
| whenever people bring up these hypotheticals I just shrug
| them off, as they're an academic edge case that all but a
| handful of individuals will never need to care about
| them.
|
| Also generally speaking, the case you're describing
| sounds more likely to be an integration say between your
| service and their service, or more specifically, your
| code and their service (say an integration between Sentry
| annd MyCoolTicketTracker). You could still sell that
| integration just fine, as its your code, not the FSL
| code. What you couldn't do is sell a cloud service that
| was MyCoolTicketTracker, that funnels to a privately
| hosted Sentry, and then exposes the functionality of
| Sentry into MyCoolTicketTracker. At that point you're
| commercializing Sentry itself, not your services.
| the_mitsuhiko wrote:
| > Now, I decide to hire a local contractor I know to help
| me integrate the self hosted version. They don't touch
| the code or do anything with it, they just work on
| integrating it into my existing business stack.
|
| We even specifically call out that case in the license as
| a permitted purpose:
|
| > Permitted Purposes specifically include using the
| Software: [...] in connection with professional services
| that you provide to a licensee using the Software in
| accordance with these Terms and Conditions.
|
| And yes, Fair Source has limitations over Open Source and
| by design. We figured the best way to balance this out is
| to transition it into a full and unquestionable Open
| Source via a springing license.
| ensignavenger wrote:
| "accordance with these Terms and Conditions" implies that
| the above limitations still apply, does it not?
| solidsnack9000 wrote:
| All of the points you raise would be too if the project were
| simply a proprietary product, too. We're not worse off for
| having to deal with them for two years instead of forever.
| MadsRC wrote:
| Does anyone know why companies don't release under AGPL for
| everyone and then under a proprietary commercial license to
| themselves? Essentially dual-license it.
|
| AGPL would dissuade Google and AWS from using it, and the
| commercial license would allow the licensee (themselves) to
| commercialize it?
| weinzierl wrote:
| I thought so too and argued it in another thread a while ago.
| Others commented that apparently AGPL wasn't working to
| dissuade cloud providers enough for MongoDB and that is why
| they switched away from the model you described to a source
| available model.
| whit537 wrote:
| One big reason we don't use AGPL at Sentry is that we want
| companies to be able to self-host individually (just not start
| a competing SaaS), and many have a blanket ban on AGPL.
| fsflover wrote:
| > and many have a blanket ban on AGPL
|
| Sounds like their own self-created problem.
| bentlegen wrote:
| Google has an organization-wide ban on using AGPL software,
| and they explain why here:
|
| https://opensource.google/documentation/reference/using/agp
| l...
| nullfield wrote:
| I don't get the blanket ban on AGPL-am I misunderstanding
| how attach-y it is?
|
| For example, people seem to have the impression that if you
| host something like an AGPL email validation service that
| just has an API to request a check for an email and then
| connects via SMTP, which another service calls, that you
| "infect" your product that even uses that API.
|
| I get that if you change the service and/or expose it
| publicly you have to make the changes available, but it
| seems misunderstood.
| the_mitsuhiko wrote:
| It might be: but as a creator of software one wants to make
| their users happy. We certainly do we at Sentry.
|
| Even personally, years ago I relicensed all my GPL code to
| BSD/MIT because I wanted people to use my software. I'm not
| there to tell them that they are wrong about their license
| restrictions.
| fsflover wrote:
| https://opensource.org/delayed-open-source-publication via
| https://news.ycombinator.com/item?id=41184476
| jumploops wrote:
| Wow, I most certainly confused https://fair.io/ with
| https://faircode.io/
|
| This new "functional" license is interesting, in that it converts
| to MIT or Apache 2.0 automatically after 2 years.
|
| I'm all for open source (and free!) software, however I hope
| these new licenses move more service-level businesses to follow
| suit and at least open up their source code in some way or
| another.
| breck wrote:
| > shift closed source to publicly available software by default
|
| Congrats! You made a big step in the right direction,
| mathematically [0] and morally [1].
|
| > What is the right license
|
| The right license is no license. Public domain is the only
| morally acceptable way to treat ideas. It's also strictly faster
| than any other way[2]. In the long run, licenses are for losers.
|
| > (c)
|
| You still have a (c)hains symbol on your site. Time to take those
| down!
|
| But you are now pointed in the right direction. Go further!
|
| [0] https://breckyunits.com/eta.html
|
| [1] https://breckyunits.com/freedom.html
|
| [2] https://breckyunits.com/how-the-public-domain-can-win.html
| Destiner wrote:
| Related: Keygen is also Fair Source now
| (https://keygen.sh/blog/keygen-is-now-fair-source/)
| WesolyKubeczek wrote:
| I fear that clearly defining what does it mean to compete in the
| context of this license is going to be a bitch.
|
| Was it Unity recently that they had to do this ridiculous back-
| and-forth, issuing multiple statements to clarify whether this or
| that edge case is a violation or not? Or was it Redis? I don't
| remember which product it was, but the turmoil I remember quite
| well.
| brianzelip wrote:
| Here's an informing podcast episode about their thinking behind
| "fair source" and more, https://changelog.com/podcast/586.
| samatman wrote:
| I don't love the name.
|
| It was hard to put my finger on why that is. It doesn't smell of
| marketing (a whiff, maybe), I don't think it's dishonest, it
| strikes me as a sincere way of trying to explain why the
| users/authors feel like they need to do anything other than just
| give the software away.
|
| It's that there's an inevitable comparison baked in to the choice
| of name: we have open source, and fair source. Fair source is
| meaningfully less open, but open source is at least equally fair,
| one can argue that it's more so, but not less. It doesn't really
| hit at the reason for having these licenses in the first place,
| and it does have a sort of aura of "see! We're trying, we're
| doing our best over here", which is accurate, but also, off-
| putting.
|
| I have a suggestion, not that I expect it to matter: first, drop
| the [adjective] source pattern completely. You don't need a
| category of software licenses, you need a software license -- and
| you really, truly, do not need the headache of trying to decide
| which non-free licenses get to live under the 'fair' umbrella.
|
| Call it the Head Start License. That's what it does: it gives the
| authors a head start. I consider that fair! As I was saying at
| the beginning of the post, my objection isn't nearly so simple as
| "you say it's fair and that's wrong".
|
| If pushed on what "kind of" license that is, you can call it
| eventually-open source. There's no 'spin' there, because it's
| literally true: it is, eventually, open source software. Plus you
| can put your foot down, because the essence of what the license
| is now lives in the name: "eventually, in this context, means two
| years. We consider less than two years also eventually open, more
| than that is, at best, eventually eventually-open source
| software." That probably sounds funny but it would work, with the
| right memetic buy in: no, we've established this, your six-year
| license is not eventually open source, eventually means two
| years, here, check out this website I'm linking to.
|
| I hope I've made it clear that while I dislike the choice, I
| don't find it distasteful. Others are going to find it
| distasteful. I'm not going to speak on behalf of those people,
| but mind share is critical with an idea like this, and you're
| going to be doing battle with "if it isn't free it isn't fair".
| Good slogan actually, you don't have to agree with it (I don't)
| to recognize that.
|
| Anyway, good luck with the project. I commend you for not
| succumbing to the temptation to try and slice a bit of salami off
| the open source definition, although as I write that out, I'm
| realizing some of my dislike here is in fact that 'fair source'
| tries to borrow some of the emotional valence of free software,
| and that's the thing, you don't need to do that: eventually-open
| source becomes open source, eventually, it's a binding
| commitment, you just need people to show some patience, because
| you have a living to earn in the meantime. You wrote it, so you
| get a head start. Seems fair.
|
| If it was my bikeshed, well, that's the colour I'd paint it.
___________________________________________________________________
(page generated 2024-08-07 23:01 UTC)