4 ms·

I do not say that it is Open Source either. From the front page: "Free to use, source on github. Noncompete licensed - PolyForm Perimeter." Feel free to comme

I do not say that it is Open Source either. From the front page: "Free to use, source on github. Noncompete licensed - PolyForm Perimeter." Feel free to comment on this: Is this a complete deal breaker for all potential users?

tinco 4y ago
Well yeah of course, it's a direct contradiction of the rising tide lifts all boats principle. Do you think Kubernetes would have any traction at all if it had a clause that it couldn't be used on AWS? If it can't be adopted by the industry as a whole, then it can't be considered an industry standard. It wouldn't fly at my organization anyway, not even looking up what PolyForm is.
- stavros 4y ago
  As far as I can see, this doesn't say it can't be used on AWS, it only says Amazon can't launch its own service that uses this software to compete with itself. It's too short to really tell what "compete" entails, though.
  - stolsvik 4y ago
    You are correct, this is meant as an AWS/GCP/Azure preventor. ElasticSearch situation. That is, AFAIU, the intention of the license I adopted. The "examples" part spells it pretty directly out, as I also try to do here: https://centiservice.com/license/ https://centiservice.com/license/ You may definitely use it anywhere you like.
    - stavros 4y ago
      I'm really in favor of something like that. AWS using your own FOSS software to choke your revenue stream is a blight on FOSS, so good for you for using that license.
      - stolsvik 4y ago
        Thank you!
    - mdaniel 4y ago
      I end up regretting it every time I weigh into this mess, but that line of reasoning drives me so crazy that this just baits me into it It is some yeowsers level hubris of every one of these folks who adopts some "source available" license because "Amazon gonna use our software for freeeeee, we go brokkkke". My company goes head-to-head with an existing Amazon closed-source offering and our stance is that if we can't out-customer-service, out-price, and generally make something more awesome than Amazon, that's on us, not because Amazon took our software and somehow ... forked it? innovated in a way we couldn't by using it? In the meantime, during the days up until Amazon Armageddon Day(tm), you don't have any bugfixes from the software engineers in the trenches trying to use your software, the cutesy license carte-blanc rules out its use in a non-trivial number of shops that would otherwise, and it ends up generating a lot of threads during every discussion which aren't "wow, that's awesome you made transactional JMS -- I can't wait to try that out in my use case!" where you do shine I am so sick of people pointing to the NOT OUT OF BUSINESS Elastic as the case study of "Amazon took our stuff, now we broke". AWS offers managed Kafka, also, and Confluent seems to be doing just fine. We use the Apache licensed Kafka not because we hate Confluent, but because it's infinitely easier to deploy a non-locked-in docker image than to deal with licensing keys in our deployment strategy. We similarly avoid Amazon Managed Kafka because it's pricing is stupid and the kinds of risks it drives down are not our risks An alternative viewpoint of AWS taking your software is "wow, what a market validation! Now come get the 5 versions newer release from the experts who built it."
- mejutoco 4y ago
  I see your point, and could not avoid thinking if ElasticSearch would have more revenue if AWS could not offer it directly.
  - mixedCase 4y ago
    Do you believe the fat ugly monster that is ElasticSearch would've had anywhere near its current adoption rates if it had a non-OSI license from the start? It would've been completely overshadowed by some other Lucene-based wrapper or maybe some even better alternative would've come along earlier.
    - mejutoco 4y ago
      Algolia does pretty well I believe. I could be wrong.
    - indymike 4y ago
      I built on Elastic early on over Solr and several others because it was open source and seemed to be better. I would have selected a different Lucene wrapper if I had known where Elastic was going.
jagged-chisel 4y ago
It's muddy/unknown enough that no one in a commercial enterprise can entertain shipping a service using your project.
marginalia_nu 4y ago
Honestly I'm pretty annoyed by the "how dare you give the source away under other terms than the ones I would prefer"-type reactions that crop up from time to time. It's an incredibly entitled attitude and is not a good look for the open source community in general. Like by all means, share code with GPL or Apache or MIT or whatever, but don't get mad when someone selects another license, including non-free ones with weird incompatibilities.
- jagged-chisel 4y ago
  Those kinds of complaints are indeed entitled. At the same time, there's no problem pointing out that fewer people and organizations can select a dependency with an unconventional, unknown license. You're welcome to license your projects however you see fit. But when you get to a point that no one is using your stuff, you have to be ready to hear "it's the license."
- lazyasciiart 4y ago
  Your comment is “how dare you complain about licensing”. What you are responding to is “huh, weird license, won’t use, that’s a shame”.
delusional 4y ago
Well computing is all about redefining problems in terms of other atoms. A messaging service is really just a series of ALU operations and memory writes, which is then a series of nand gates. It seems incredibly muddy to me what "competing" would mean in that sense. If I make something with this it could be argued that my system built on top of MATS is just immaterial configuration that was intended to be done by the user. That the authors intention was for the end user to use MATS themselves, and that I'm therefore in competition with the product. A non programming example would be hammers and houses. You could imagine that if I build you a house, you'd be less likely to need to buy a hammer (to build your own) making my house competition for the hammer. I wouldn't touch this at all.
jgilias 4y ago
Your license would not be a dealbreaker for me in an SME commercial setting. AGPL would be a dealbreaker.
- stolsvik 4y ago
  Thanks a bunch! Seriously. And I agree that AGPL is pretty harsh - I have a feeling that this is typically used in a "try before you buy" situation, where there is a commercial license on the side.
mixedCase 4y ago
Can't speak for all potential users, but the license is in fact a complete deal-breaker for me and any client I've worked with given the FOSS tools available in the ecosystem. But then, there's also the "Java-only" which is a complete deal-breaker in any client I've worked with doing {micro,}services. Then there's the "what the hell does this actually do" deal-breaker when trying to explain it to some decision makers, and the "we already have queues and K8s to solve all of those issues" deal-breaker when explaining it to most fellow SWEs/SREs.
- stolsvik 4y ago
  Hahaha, that's rough! :-) I'll tell you one thing: "What the hell does this actually do?!" is extremely spot on! I am close to amazed to how hard it is to explain this library. It really does provide value, but it is evidently exceptionally hard to explain. I first and foremost believe that this is due to the massive prevalence of sync REST/RPC style coding, and that messaging is only pulled up as a solution when you get massive influxes of e.g. inbound reports - where you actually want the queue aspect of a message broker. Not the async-ness. I've tried to lay this out multiple times, e.g. here: https://mats3.io/docs/message-oriented-rpc/ https://mats3.io/docs/message-oriented-rpc/, and in the link for this post itself.
  - mixedCase 4y ago
    I think I got it, but I'm inclined to believe I'm missing something. From what I understood, it boils down to "distributed CPS" (continuation-passing style), where the state instead of being automatically closed over it is explicitly assigned to, and the continuation execution is distributed. The problem about this specific approachh from where I see it is that something like this should be a few days' work to implement using an off-the shelf persistent queue (which could be abstracted away), something like Protobuf for defining your shared state and auto-generating serializers/deserializers, and then some reusable glue code to push/pull from the queue, and it would support multiple languages almost out of the box. With that said, I am not sure if I'd want to define pipelines as a shared "mutable" state passed around, it sounds like classic object oriented design which makes it easy to create buggy code. It'd be much more robust to clearly define several steps which very strict, well-defined inputs and outputs every step of the way. You're paying for the copies in each serialization anyway (and much more, since this is a Remote Procedure Call), so what reason could there be for choosing a fixed mutable model?
lazyasciiart 4y ago
That comment is quoting from the Polyform license. If it doesn’t represent your position, you may have made a bad choice in license.
- stolsvik 4y ago
  I was referring to the "not open source". I edited my comment to be more specific.
indymike 4y ago
Yes, it is a deal breaker for me.

tinco 4y ago

Well yeah of course, it's a direct contradiction of the rising tide lifts all boats principle. Do you think Kubernetes would have any traction at all if it had a clause that it couldn't be used on AWS? If it can't be adopted by the industry as a whole, then it can't be considered an industry standard. It wouldn't fly at my organization anyway, not even looking up what PolyForm is.

stavros 4y ago
As far as I can see, this doesn't say it can't be used on AWS, it only says Amazon can't launch its own service that uses this software to compete with itself. It's too short to really tell what "compete" entails, though.
- stolsvik 4y ago
  You are correct, this is meant as an AWS/GCP/Azure preventor. ElasticSearch situation. That is, AFAIU, the intention of the license I adopted. The "examples" part spells it pretty directly out, as I also try to do here: https://centiservice.com/license/ https://centiservice.com/license/ You may definitely use it anywhere you like.
  - stavros 4y ago
    I'm really in favor of something like that. AWS using your own FOSS software to choke your revenue stream is a blight on FOSS, so good for you for using that license.
    - stolsvik 4y ago
      Thank you!
  - mdaniel 4y ago
    I end up regretting it every time I weigh into this mess, but that line of reasoning drives me so crazy that this just baits me into it It is some yeowsers level hubris of every one of these folks who adopts some "source available" license because "Amazon gonna use our software for freeeeee, we go brokkkke". My company goes head-to-head with an existing Amazon closed-source offering and our stance is that if we can't out-customer-service, out-price, and generally make something more awesome than Amazon, that's on us, not because Amazon took our software and somehow ... forked it? innovated in a way we couldn't by using it? In the meantime, during the days up until Amazon Armageddon Day(tm), you don't have any bugfixes from the software engineers in the trenches trying to use your software, the cutesy license carte-blanc rules out its use in a non-trivial number of shops that would otherwise, and it ends up generating a lot of threads during every discussion which aren't "wow, that's awesome you made transactional JMS -- I can't wait to try that out in my use case!" where you do shine I am so sick of people pointing to the NOT OUT OF BUSINESS Elastic as the case study of "Amazon took our stuff, now we broke". AWS offers managed Kafka, also, and Confluent seems to be doing just fine. We use the Apache licensed Kafka not because we hate Confluent, but because it's infinitely easier to deploy a non-locked-in docker image than to deal with licensing keys in our deployment strategy. We similarly avoid Amazon Managed Kafka because it's pricing is stupid and the kinds of risks it drives down are not our risks An alternative viewpoint of AWS taking your software is "wow, what a market validation! Now come get the 5 versions newer release from the experts who built it."
mejutoco 4y ago
I see your point, and could not avoid thinking if ElasticSearch would have more revenue if AWS could not offer it directly.
- mixedCase 4y ago
  Do you believe the fat ugly monster that is ElasticSearch would've had anywhere near its current adoption rates if it had a non-OSI license from the start? It would've been completely overshadowed by some other Lucene-based wrapper or maybe some even better alternative would've come along earlier.
  - mejutoco 4y ago
    Algolia does pretty well I believe. I could be wrong.
  - indymike 4y ago
    I built on Elastic early on over Solr and several others because it was open source and seemed to be better. I would have selected a different Lucene wrapper if I had known where Elastic was going.

jagged-chisel 4y ago

It's muddy/unknown enough that no one in a commercial enterprise can entertain shipping a service using your project.

marginalia_nu 4y ago

Honestly I'm pretty annoyed by the "how dare you give the source away under other terms than the ones I would prefer"-type reactions that crop up from time to time. It's an incredibly entitled attitude and is not a good look for the open source community in general. Like by all means, share code with GPL or Apache or MIT or whatever, but don't get mad when someone selects another license, including non-free ones with weird incompatibilities.

jagged-chisel 4y ago
Those kinds of complaints are indeed entitled. At the same time, there's no problem pointing out that fewer people and organizations can select a dependency with an unconventional, unknown license. You're welcome to license your projects however you see fit. But when you get to a point that no one is using your stuff, you have to be ready to hear "it's the license."
lazyasciiart 4y ago
Your comment is “how dare you complain about licensing”. What you are responding to is “huh, weird license, won’t use, that’s a shame”.

delusional 4y ago

Well computing is all about redefining problems in terms of other atoms. A messaging service is really just a series of ALU operations and memory writes, which is then a series of nand gates. It seems incredibly muddy to me what "competing" would mean in that sense. If I make something with this it could be argued that my system built on top of MATS is just immaterial configuration that was intended to be done by the user. That the authors intention was for the end user to use MATS themselves, and that I'm therefore in competition with the product. A non programming example would be hammers and houses. You could imagine that if I build you a house, you'd be less likely to need to buy a hammer (to build your own) making my house competition for the hammer. I wouldn't touch this at all.

jgilias 4y ago

Your license would not be a dealbreaker for me in an SME commercial setting. AGPL would be a dealbreaker.

stolsvik 4y ago
Thanks a bunch! Seriously. And I agree that AGPL is pretty harsh - I have a feeling that this is typically used in a "try before you buy" situation, where there is a commercial license on the side.

mixedCase 4y ago

Can't speak for all potential users, but the license is in fact a complete deal-breaker for me and any client I've worked with given the FOSS tools available in the ecosystem. But then, there's also the "Java-only" which is a complete deal-breaker in any client I've worked with doing {micro,}services. Then there's the "what the hell does this actually do" deal-breaker when trying to explain it to some decision makers, and the "we already have queues and K8s to solve all of those issues" deal-breaker when explaining it to most fellow SWEs/SREs.

stolsvik 4y ago
Hahaha, that's rough! :-) I'll tell you one thing: "What the hell does this actually do?!" is extremely spot on! I am close to amazed to how hard it is to explain this library. It really does provide value, but it is evidently exceptionally hard to explain. I first and foremost believe that this is due to the massive prevalence of sync REST/RPC style coding, and that messaging is only pulled up as a solution when you get massive influxes of e.g. inbound reports - where you actually want the queue aspect of a message broker. Not the async-ness. I've tried to lay this out multiple times, e.g. here: https://mats3.io/docs/message-oriented-rpc/ https://mats3.io/docs/message-oriented-rpc/, and in the link for this post itself.
- mixedCase 4y ago
  I think I got it, but I'm inclined to believe I'm missing something. From what I understood, it boils down to "distributed CPS" (continuation-passing style), where the state instead of being automatically closed over it is explicitly assigned to, and the continuation execution is distributed. The problem about this specific approachh from where I see it is that something like this should be a few days' work to implement using an off-the shelf persistent queue (which could be abstracted away), something like Protobuf for defining your shared state and auto-generating serializers/deserializers, and then some reusable glue code to push/pull from the queue, and it would support multiple languages almost out of the box. With that said, I am not sure if I'd want to define pipelines as a shared "mutable" state passed around, it sounds like classic object oriented design which makes it easy to create buggy code. It'd be much more robust to clearly define several steps which very strict, well-defined inputs and outputs every step of the way. You're paying for the copies in each serialization anyway (and much more, since this is a Remote Procedure Call), so what reason could there be for choosing a fixed mutable model?

lazyasciiart 4y ago

That comment is quoting from the Polyform license. If it doesn’t represent your position, you may have made a bad choice in license.

stolsvik 4y ago
I was referring to the "not open source". I edited my comment to be more specific.

indymike 4y ago

Yes, it is a deal breaker for me.