The Rhino license agreement allows you to use Rhino on one computer at a time.
If you want to use a single license for Rhino WIP on multiple computers, you need to either add your license to the Cloud Zoo using your Rhino account (recommended), or install and manage a Zoo server on your network. If you install your license directly on your computer, you will only be able to validate on one computer.
To Add Your License to the Cloud Zoo:
From the Tools menu, click Options
In the Licenses tab, select your Rhino BETA license, then click Change your license key
Click Remove License in the lower-left corner of the dialog box
I suppose that Rhino 5 licenses will not be able to be added to the ācloud zooā (Rhino Account). Correct?
As stated before, if Rhino 6 uses a cloud zoo license, Rhino 5 wonāt be able to see this license and - in that case - wonāt be able to be installed on new hardware. Still correct?
If Iām following, anybody that is dependent on being able to run legacy RH5 plug-ins will either have to run a Zoo server on a network PC or will only be able to use Rhino on one single machine - or ānever everā switch to new hardware.
Also,
ā¦ does that still require ownership of the hardware that Rhino is run on?
For now I really donāt know how to proceed with a just started project - WIP doesnāt do what I need to do (plug-ins) and R5 which Iām targeting now may not be supported on new hardware(?).
And more; Iām developing GH plugins on a Virtual Machine (a ādeveloper machineā using VS2015 and all kinds of dev tools) which cannot utilize the VM hostās Rhino instance for debugging, therefore I need to have Rhino(5) installed on the VM as well, but, the hardware Iām targeting doesnāt work on the VM, so I need to have Rhino running on both machines (the host and the VM) at the same time andā¦ that doesnāt seem to be allowed according to the licence terms(?).
No matter which way I turn the rear end points backwardsā¦
Thatās still open for debate here at McNeel. We barely have it working in the WIP, and itās a really massive change to the core code.
Actually, no, thatās no longer correct. If you validate your Rhino 6 standalone on a new computer, and then validate your Rhino 5 on the same computer, it will just work. Our goal is to make it possible for standalone licenses to be movable from one computer to another without significant pain or hassle. When you uninstall or remove your license from Rhino WIP/6, it will return the license validation to our servers, letting you move it without contacting us.
What you describe is currently outside the terms of the license agreement, even for Rhino 5. Were you using a license manager (Zoo or Rhino Accounts), youād be able to seamlessly start Rhino on one or the other computer in rapid succession, but not at the same time.
I think what matters most is whether the licence is useful for development as described above.
Development on Virtual Machines is standard set up in these days due to the ever increasing complexity of configurations that simply must be replacable within minutes when things go wrong. You guys at McNeel knows all about that.
But it follows that if I cannot test my (Rhino/GrassHopper) application on the VM host, while developing on the VM guest, then thatās a showstopper in some cases. :(
What exactly are you trying to prevent: RUNNING Rhino on more than one machine or ACTIVELY USING Rhino on more than one machine (usually so more than one user can use a single license at the same time)?
Quite frankly, I donāt see any difference between a single user activating multiple instances of Rhino on a single machine or distributed over multiple machines - even if some of them are on virtual machines, especially if the virtual machine is on the same physical machine as the non-virtual instance. As long as ALL the simultaneously running instances are under the sole active control of a single authorized user.
I have always interpreted your license terms in this spirit. Of course, as an individual user, itās pretty hard for me to work outside those terms without doing something which is definitely and clearly not permitted.
Or are you getting carried away with overly complicated license enforcement schemes just because you can and all the other folks are? What problems that exist with the Rhino 5 setup are you trying to solve?
Yep, I use developer tools all day long that work exactly like I described. I can run PyCharm on my Mac or my Windows VM - but not at the same time. If I really need it in both places, I can buy another license - but generally, I donāt need it running at the same time on both platforms.
In my view, using your Rhino account to store your license makes VM setup simpler. You can use any number of VMs, start them, shut them down, and not have to worry about running out of license validations. I imagine you must have several if not dozens of VMs that you test on (I know I do). By using your Rhino account, you wonāt have to deal with individual licensing of each of those VMs anymore. And when you need to destroy and rebuild a VM, you donāt need to worry about first returning your license validation to our servers, or contacting us to get another validation.
Our customers want their Rhino licenses to be a bit more freely accessible than they are currently with Rhino 5. By allowing users to log into their Rhino account to get their license, weāre giving them that flexibility.
And, in order to allow users to easily move their licenses from one computer to another (or from one computer to the Zoo or to their Rhino account) we need to do more strict accounting of where Rhino is installed. So for Rhino WIP/6, weāre only allowing your license to be one place at a time: one standalone computer, one Zoo server, or one Rhino account. Doing anything else seems to be more complex.
I have never used regular zoo, so this may be a silly question, but is it each machine would be checking out a Cloud zoo license, or each instance of Rhino is checking out a license? In other words, will we be able to have multiple instances of Rhino running on the same computer at the same time?
Actually, I seriously doubt that Rolf, Brian, or any other single developer equipped with only one brain, one set of eyes and two hands will simultaneously test and develop using multiple instances any more than a designer will simultaneously use two running instances of Rhino for modeling. Why should one be allowed and the other not?
OK, but so far this sounds like you are abandoning folks like me, who do most of their work on an offline machine but want to have a copy on a notebook for those occasions where itās needed offsite. How would that work?
The concerete problem I described isnāt what you described here. If I cannot debug a Rhino from whithin VS without having Rhino installed and running on the VM (which according to PIAC is an unfortunate bug) AND some hardware isnāt recognized by the VM, then thereās only one option - to run two instances of Rhino at the same time, one on the Guest and one on the Host, and at each test run drop the compiled .gha file also on the Hostās instance and test.
Notice that this limitation is, well an unintended limitation, and not a about demanding for extra lyxury license terms.
If having to shut down the Guest instance and starting the Hostās instance each time (iteratively) while doing intensive testing during development (which requires the same ācontextā between each run, like having the same files open etc) then it becomes too complex and time consuming stopping and starting (swapping between) the two instances all the time.
I didnāt realize this limitation before I moved my VS to a VM only a few days ago, and had my hostās Win10 choke entirely due to some configuration hassle. And although I had my licenses on Zoo, of course I ran out of validation when I had to reinstall the hostās OS from scratch (well, this is one of the good reasons for using VMs for developmentā¦ but I was too late this time).
I do have, not dozens of Developer VMs but more than half a dozen, but I had never used VS before now, when I recently started to develop plugins for Rhino/GrassHopper.
Iām basically very positive to everything Rhino, I really am, and perhaps I encountered a ācorner caseā but I cannot afford to buy another Rhino license to cover this case (although I hope to be able to afford āmany licensesā in the future). :(
Since I asked about RH6 using a Rhino Account license and not a standalone, I see that the answer is actually yes. But I see that you are considering this more. Thanks. In my case specifically, I have a laptop and a workstation and I need to be able to run RH5 with legacy plug-ins and RH6 on both (though not at the same time). And need to be able to replace one of those machines when that becomes necessary.
I totally do agree with you on this one. This is exactly how I see it. I have Rhino running on my main workstation and on my laptop AT THE SAME TIME most of the time and I see it as multiple instances (Iām the only person who is using it, nobody else). Why I do it? Due to serial nature of Rhino and 1 CPU core active,as a workaround, I spread some parts of GH calculations to my laptop to speed up the process. I donāt like the idea of having to buy another license because of that but if thatās the case @brian I donāt see another option than to buy another license.
As I see it the āspiritā of the license would allow for this, but the āletterā of the terms would have problems allowing for it.
If the āletterā would allow for any number of instances running on different machines (although allowing any number of instances for the same user on the same machine), that would open up a ātechnical loop holeā for running any number of instances on a VM server pretending to be āa single userā, while in reality many different (users on the same network) could attach to those instances.
But then again, if looking at the āspiritā of the license terms, it actually would allow for any number of instances running - for one user at the time - but it would be difficult to technically ensure that it is the same user on the different machines. Perhaps itās possible, for example by checking onlogged Win10 user accounts if itās the same user.
SLAVERY
Anyway, I think that this discussion rises the question about āslave instancesā of Rhino which could be an insteresting concept (while still allowing for multiple instances on the same machine with the same onlogged user). Due to the fact that Rhino is slow at baking geometry, while the GrassHopper concept invites to making massive computations of geometry, such jobs can be split and deployed to multiple instances of Rhino (map/reduce concepts).
Just like Render engines often can utilize slave instances, Rhino/GH instances could do something similar. Ripping out the GUI of a Rhino instance, selling such a slave for 50 dollars, I would consider buying ātens of them.ā And without the GUI the slaves canāt be used as a normal Rhino for any meaningful purpose. Many problems solved.
RHINO SLOW -> FAST
At least it would be one way of dealing with the fact that Rhino is internally very slow at generating geometry, especially for use in massive GH computations etc (which I plan to use it for, BTW). Cheap slave licenses would be one way of addressing this problem, a problem which is unlikely to be (never will be) solved by rewriting the Rhino core.
I will return to this aspect of using Rhino/GrassHopper when I have come a bit further in one of my projects, but the Morpheus Hotel project should be enough to explain why slave Rhinoās would be an interesting way to make slow Rhino into a poor mans HPC platform.
Rhino slaves wouldnāt ācostā much to McNeel, while it would increase revenue using what you already have (only rip out the GUI). It would have the poitential to making Rhino a first hand choice for many upcoming R&D projects. More on that when I can demonstrate what I mean in more concrete terms.
