You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support email has recently received another enquiry regarding the terms under which they can pre-install Rockstor.
It is proposed that we publish (shortly) an initial doc entry to address such enquiries: given this is not an isolated enquiry. This entry can then be revised over time as needed; effectively evolving its scope in response to its target audience's feedback (OEM representatives).
Conditions or restrictions required to observe/remain compliant with item 1 above. I.e. essentially the functional compliance of our most prevailing license of GPL-3.0-or-later along with the required, for our own compliance: Copyright (joint work) 2024 The Rockstor Project <https://rockstor.com>.
Our preferred, given the freedom stance re GPL, cooperative arrangements. I.e. a mutual beneficial arrangement as per our non-profit stance re sustainability. If a for-profit entity benefits from our sustainability, it would be pertinent/expected/honourable to foster a mutual and open arrangement regarding sponsorship etc. This is also a requirement of our non-profit stance. I.e. we have open accounts. Noteworthy here is that our OEM orientated installer should be honoured. I.e. said OEM's would be in violation of our wishes if machine recipients (ultimate clients) were delivered any hardware that did not, on first boot, run our installer setup screen: https://rockstor.com/docs/installation/installer-howto.html. Easily achieved by simply bundling an install USB: which doubles as a restore to factory defaults recovery mechanism: assuming no data use of the system disk (default for current and future installers). Alternatively the installer could be run up-to, but not beyond, the point at which the Web-UI setup procedure is to be completed: https://rockstor.com/docs/installation/installer-howto.html#visit-rockstor-s-web-ui. That is, the end recipient of the sold hardware should be the responsible party to complete this step: ensuring that they at least complete this final stage. But the down-side of this arrangement is that the root users password would have been established by the OEM. Hence the preference on the current maintainers part, that a bundled USB installer key (pre-loaded with an official installer downloaded from our main website) be the preferred mechanism for initial setup. Further emphasising the end users freedoms to install on hardware not of the OEM's supply.
The above is a quick sketch of what we need in this dedicated OEM orientated doc. All is up for discussion / clarification within our Licensing terms as stated. It may be that we should establish a new OEM Tier in our Open Collective, given these 3rd parties should be openly identified as contributing, & likely benefiting, from The Rockstor Project's developmental & infrastructure support efforts; and similarly serving as a voluntary mechanism to show mutual active interest in a sustainable setup.
@FroggyFlox & @Hooverdan96, as current (active) full & partial org co-maintainers (along with myself) your thoughts here are, as always, most welcome. There is a recent support email inquiry from last week that I would like to address with this proposed public docs entry; so I was hoping that our usual PR/pier-review process could be used to establish at least an initial 1st draft. I'll try to present something soon, if not beaten to it, so that we can have something published ready for early next week if possible. In essence we are simply sketching out GPL-3.0-or-later compliance issues: and ramifications if compliance is not maintained (in-ability to use GPL software there after for the offending party). And honouring the given/bundled Copyright. I also like to request that only installers containing non RC Stable candidates be bundled. We are due very shortly to have one of those :) so this is quite timely. That way OEMs have a more know-property: which works best all around. It's just a shame this last testing phase has been so extensive: but all good never-the-less. My above proposal re OEM Tier in OC also needs it's details to be established. An OEM is necessarily more responsible than an individual end user client: representing as they will more than a single instance use; all-be-it by proxy. As such they could, understandably, expect priority response times, challenging our development efforts re resources. Ergo providing a voluntary Open Collective OEM Tier to assist the project in maintaining/sustaining a prior support channel to those providing pre-build NAS instances bundled with our offerings. We are, after-all, in the non-business of the greater good, read win-win, here :) .
N.B. we are not, I propose, at the stage where we are able to offer custom installers. And so any proposals for this issue pertain to our regular and likely future offerings re installer: which is already orientated towards end-users with an OEM capability anyway.
The text was updated successfully, but these errors were encountered:
@phillxnet thanks for summarizing and formulating your thoughts on this. From a technicality of the OEM installation. I think the third alternative could be that the download and install procedure is documented and accompanying the equipment, so the end-user still has to download and USB-install the appliance (at least that's what I've seen on other offerings in other areas). Would that fit here as well?
Doc entry intended as a guide for original equipment manufacturers/suppliers
OEMs/NAS hardware sellers, and value-added resellers (VARs) interested in
bundling Rockstor with hardware they source/build/redistribute.
Support email has recently received another enquiry regarding the terms under which they can pre-install Rockstor.
It is proposed that we publish (shortly) an initial doc entry to address such enquiries: given this is not an isolated enquiry. This entry can then be revised over time as needed; effectively evolving its scope in response to its target audience's feedback (OEM representatives).
Points to address:
rockstor
package specific license entry here: https://rockstor.com/docs/interface/system/update_channels.html#rockstor-licenseGPL-3.0-or-later
along with the required, for our own compliance:Copyright (joint work) 2024 The Rockstor Project <https://rockstor.com>
.root
users password would have been established by the OEM. Hence the preference on the current maintainers part, that a bundled USB installer key (pre-loaded with an official installer downloaded from our main website) be the preferred mechanism for initial setup. Further emphasising the end users freedoms to install on hardware not of the OEM's supply.The above is a quick sketch of what we need in this dedicated OEM orientated doc. All is up for discussion / clarification within our Licensing terms as stated. It may be that we should establish a new OEM Tier in our Open Collective, given these 3rd parties should be openly identified as contributing, & likely benefiting, from The Rockstor Project's developmental & infrastructure support efforts; and similarly serving as a voluntary mechanism to show mutual active interest in a sustainable setup.
@FroggyFlox & @Hooverdan96, as current (active) full & partial org co-maintainers (along with myself) your thoughts here are, as always, most welcome. There is a recent support email inquiry from last week that I would like to address with this proposed public docs entry; so I was hoping that our usual PR/pier-review process could be used to establish at least an initial 1st draft. I'll try to present something soon, if not beaten to it, so that we can have something published ready for early next week if possible. In essence we are simply sketching out GPL-3.0-or-later compliance issues: and ramifications if compliance is not maintained (in-ability to use GPL software there after for the offending party). And honouring the given/bundled Copyright. I also like to request that only installers containing non RC Stable candidates be bundled. We are due very shortly to have one of those :) so this is quite timely. That way OEMs have a more know-property: which works best all around. It's just a shame this last testing phase has been so extensive: but all good never-the-less. My above proposal re OEM Tier in OC also needs it's details to be established. An OEM is necessarily more responsible than an individual end user client: representing as they will more than a single instance use; all-be-it by proxy. As such they could, understandably, expect priority response times, challenging our development efforts re resources. Ergo providing a voluntary Open Collective OEM Tier to assist the project in maintaining/sustaining a prior support channel to those providing pre-build NAS instances bundled with our offerings. We are, after-all, in the non-business of the greater good, read win-win, here :) .
N.B. we are not, I propose, at the stage where we are able to offer custom installers. And so any proposals for this issue pertain to our regular and likely future offerings re installer: which is already orientated towards end-users with an OEM capability anyway.
The text was updated successfully, but these errors were encountered: