3 ms·

Strikes me as an odd choice - perhaps ideally the open source announcement should have contained a bit more of the "Hello wallaroo" post: https://blog.wallaroo

by e12e 9y ago

Strikes me as an odd choice - perhaps ideally the open source announcement should have contained a bit more of the "Hello wallaroo" post: https://blog.wallaroolabs.com/2017/03/hello-wallaroo/ https://blog.wallaroolabs.com/2017/03/hello-wallaroo/ It has a pretty good overview of what wallaroo is/does (I think, as someone outside/new to the project). Also: > We are planning on releasing Wallaroo as open source in April of this year. Ouch! :) Congratulations on getting it out the door - looks very interesting.

e12e 9y ago
The release blog post also has some crucial licensing information spelled out: > Parts of Wallaroo are licensed under the Wallaroo Community License Agreement. The Wallaroo Community License is based on Apache version 2. However, you should read it for yourself. Here we provide a summary of the main points of the Wallaroo Community License Agreement. > You can run all Wallaroo code in a non-production environment without restriction. > You can run all Wallaroo code in a production environment for free on up to 3 servers or 24 CPUs. > If you want to run Wallaroo Enterprise version features in production above 3 servers or 24 CPUs, you have to obtain a license. > You can modify and redistribute any Wallaroo code > Anyone who uses your modified or redistributed code is bound by the same license and needs to obtain a Wallaroo Enterprise license to run on more than 3 servers or 24 CPUs in a production environment. Not sure I'm too happy about a custom licence - it'd be nice to hear more about this choice vs a more traditional AGPL / commercial license. Immediately I sense that if wallaroo labs goes bankrupt / is bought - the open source system can potentially become impossible to run legally in production [ed: for new installations] ...
- spooneybarger 9y ago
  re: > Immediately I sense that if wallaroo labs goes bankrupt / is bought - the open source system can potentially become impossible to run legally in production [ed: for new installations] ... You raise an interesting point. We'd be dealing with that with clients on a case by case basis of providing them with whatever assurances that they need should Wallaroo Labs disappear. However, we don't have anything stating that anywhere. The expectation that our lawyers had was that no company would sign a boilerplate contract so issues of "what happens if the company goes away" would be handled the agreement between us and that company. The basic story behind the custom license: 1- Outside of RedHat, there aren't a lot of companies who have shown you can build a successful growing business selling support. 2- We didn't want to have an open source product and a closed source commercial offering. We wanted anyone to be able to modify any of the code as they needed. We wanted to grant more rights than you normally see with open core projects. 3- We want to allow smaller companies to be able to use Wallaroo and all its features, thus the "free up to X" for enterprise features. This boils down to: 1) we don't think you can have a sustainable business as the primary developers of a infrastructure project where the model is selling support. 2) we want to make all source available and grant rights beyond what you would see with most open-core projects.
  - e12e 9y ago
    From a business point of view, I understand the reasoning, but everyone wants everything for free ;-) I my concern is more that such a closed core/custom license doesn't bring with it the peace of mind that I usually associate with Free/OS software: that any work put into it, and any deployments (including future deployments) will be able to at least run on current code, regardless of licensing. And that was mostly an academic worry, until Oracle bought Sun, and demonstrated that companies would indeed do silly things to open software. Note that if it was Wallaroo that was "closed up", there'd be much more work and/or impossible to fork the system and continue using it. Sun with it's CDDL is also interesting for the problem wrt GPL incompatibility (which I think affects your license as well, (see: "Further Restrictions"). While I don't expect any of this code/system to run in the kernel, or inside some other system, like GCC - it is a (small) concern in terms of future use. It'll be interesting to see how this works out for you - I absolutely understand the need to monetize, and even if this is more of a "source available" license, than "Free Software" - it's still better than a completely closed system. But it'll never be distributed as part of eg: Debian/Main - like for example the jdk, or apache or spark is. I guess my main take-away is that this isn't "open source" but rather "source available" - because there's no way I can modify your software and sell/give/distribute it to someone and have them run it as and how they whish (Freedom zero). I don't mean this as criticism, but as an observation. [ed: On a more encouraging note, I know some big clients of Oracle/Solaris that were frustrated with the closed source offering, because there existed patches for problems on the open source OpenSolaris side for serious issues with big zfs deployments that took months to show up in the closed/supported offering from Oracle. So at least having a "transitive" license (if you have a license you can run community-improved code, not be bound to wait for upstream) is an improvement.] [ed2: Now, what happens when company X implements a similar license for compiler for language Z that is incorporated in Wallaroo (eg: APL/J, something new?) - but perhaps choose a different number of CPUs to trigger the need for a license? Could my system X-with-wallaroo require license fees from me to run at 12+ cpus, and from Wallaroo at 32+ cpus?). Just a thought.]
    - spooneybarger 9y ago
      My personal email is in my profile. I'd be interested in chatting more because, I think that 1) you raise some legitimate points 2) some of your points we things we want to address and thought we had but might not be communicating well.
spooneybarger 9y ago
Yeah, we decided our original plan for April was too aggressive. We believe in "put it out there before you are comfortable releasing" but in the end, we decided April was too soon. We have a long roadmap of features, improvements and what not that we want to do with Wallaroo. When we looked at where we were in April, we decided that we needed to execute on more of that roadmap before putting it out and getting feedback from folks. Thanks for the congrats.
dang 9y ago
OK, we'll switch it back from https://github.com/wallaroolabs/wallaroo https://github.com/wallaroolabs/wallaroo.

by e12e 9y ago

e12e 9y ago

The release blog post also has some crucial licensing information spelled out: > Parts of Wallaroo are licensed under the Wallaroo Community License Agreement. The Wallaroo Community License is based on Apache version 2. However, you should read it for yourself. Here we provide a summary of the main points of the Wallaroo Community License Agreement. > You can run all Wallaroo code in a non-production environment without restriction. > You can run all Wallaroo code in a production environment for free on up to 3 servers or 24 CPUs. > If you want to run Wallaroo Enterprise version features in production above 3 servers or 24 CPUs, you have to obtain a license. > You can modify and redistribute any Wallaroo code > Anyone who uses your modified or redistributed code is bound by the same license and needs to obtain a Wallaroo Enterprise license to run on more than 3 servers or 24 CPUs in a production environment. Not sure I'm too happy about a custom licence - it'd be nice to hear more about this choice vs a more traditional AGPL / commercial license. Immediately I sense that if wallaroo labs goes bankrupt / is bought - the open source system can potentially become impossible to run legally in production [ed: for new installations] ...

spooneybarger 9y ago
re: > Immediately I sense that if wallaroo labs goes bankrupt / is bought - the open source system can potentially become impossible to run legally in production [ed: for new installations] ... You raise an interesting point. We'd be dealing with that with clients on a case by case basis of providing them with whatever assurances that they need should Wallaroo Labs disappear. However, we don't have anything stating that anywhere. The expectation that our lawyers had was that no company would sign a boilerplate contract so issues of "what happens if the company goes away" would be handled the agreement between us and that company. The basic story behind the custom license: 1- Outside of RedHat, there aren't a lot of companies who have shown you can build a successful growing business selling support. 2- We didn't want to have an open source product and a closed source commercial offering. We wanted anyone to be able to modify any of the code as they needed. We wanted to grant more rights than you normally see with open core projects. 3- We want to allow smaller companies to be able to use Wallaroo and all its features, thus the "free up to X" for enterprise features. This boils down to: 1) we don't think you can have a sustainable business as the primary developers of a infrastructure project where the model is selling support. 2) we want to make all source available and grant rights beyond what you would see with most open-core projects.
- e12e 9y ago
  From a business point of view, I understand the reasoning, but everyone wants everything for free ;-) I my concern is more that such a closed core/custom license doesn't bring with it the peace of mind that I usually associate with Free/OS software: that any work put into it, and any deployments (including future deployments) will be able to at least run on current code, regardless of licensing. And that was mostly an academic worry, until Oracle bought Sun, and demonstrated that companies would indeed do silly things to open software. Note that if it was Wallaroo that was "closed up", there'd be much more work and/or impossible to fork the system and continue using it. Sun with it's CDDL is also interesting for the problem wrt GPL incompatibility (which I think affects your license as well, (see: "Further Restrictions"). While I don't expect any of this code/system to run in the kernel, or inside some other system, like GCC - it is a (small) concern in terms of future use. It'll be interesting to see how this works out for you - I absolutely understand the need to monetize, and even if this is more of a "source available" license, than "Free Software" - it's still better than a completely closed system. But it'll never be distributed as part of eg: Debian/Main - like for example the jdk, or apache or spark is. I guess my main take-away is that this isn't "open source" but rather "source available" - because there's no way I can modify your software and sell/give/distribute it to someone and have them run it as and how they whish (Freedom zero). I don't mean this as criticism, but as an observation. [ed: On a more encouraging note, I know some big clients of Oracle/Solaris that were frustrated with the closed source offering, because there existed patches for problems on the open source OpenSolaris side for serious issues with big zfs deployments that took months to show up in the closed/supported offering from Oracle. So at least having a "transitive" license (if you have a license you can run community-improved code, not be bound to wait for upstream) is an improvement.] [ed2: Now, what happens when company X implements a similar license for compiler for language Z that is incorporated in Wallaroo (eg: APL/J, something new?) - but perhaps choose a different number of CPUs to trigger the need for a license? Could my system X-with-wallaroo require license fees from me to run at 12+ cpus, and from Wallaroo at 32+ cpus?). Just a thought.]
  - spooneybarger 9y ago
    My personal email is in my profile. I'd be interested in chatting more because, I think that 1) you raise some legitimate points 2) some of your points we things we want to address and thought we had but might not be communicating well.

spooneybarger 9y ago

Yeah, we decided our original plan for April was too aggressive. We believe in "put it out there before you are comfortable releasing" but in the end, we decided April was too soon. We have a long roadmap of features, improvements and what not that we want to do with Wallaroo. When we looked at where we were in April, we decided that we needed to execute on more of that roadmap before putting it out and getting feedback from folks. Thanks for the congrats.

dang 9y ago

OK, we'll switch it back from https://github.com/wallaroolabs/wallaroo https://github.com/wallaroolabs/wallaroo.