Say you have a charm that deploys a proprietary piece of software. That software has an EULA that prohibits anyone from redistributing it. The user is essentially forced to go to the software vendor website, login using their account, buy the software, and accept the EULA before being able to use the software.
In this scenario, we cannot upload that piece of software as a resource into the charm store, and set that as the "default" resource for the charm. The license for that software does not allow us to. Most users that consume such software are aware of this, and is of no surprise to them that they have to "own" those resources before they can deploy them. There are 2 options here: 1) Canonical is given permission to redistribute the piece of software in question (Sharepoint, Exchange, MS SQL ISOs, etc), and validates that the user deploying the charm has the right to deploy that software. 2) Allow a charm to be published without resources, and validate during deployment if the resources are available or not. The charm can handle the missing resources and print a nice comprehensive status message. If the charm also includes a decent README on how to deploy the service, it should be enough to smooth the process. In this scenario, the responsibility of making sure all license terms are satisfied, falls onto the user. It is unfortunate that licensing gets in the way of simplicity, but it is an issue that we need to keep in mind. Cheers, Gabriel On Vi, 2016-12-02 at 13:33 +0000, Rick Harding wrote: On Fri, Dec 2, 2016 at 5:49 AM Konstantinos Tsakalozos <kos.tsakalo...@canonical.com<mailto:kos.tsakalo...@canonical.com>> wrote: This works but has a side effect, the dummy binaries are available for downloading from the charm's page. Is there a way to hide the resources from the charm's readme page? I'm confused why the user cannot know there's a default resource there? In an ideal world, the author would provide a default resource that at least helps guide the user to how to use the charm if they forget or use the wrong type of local resource. We want to make sure the user is guided on how to get things working as smoothly as possible. The other side is charm testing. The charm should have enough of what it needs in the default resource to perform functional tests to pass via tools such as Matrix. I'm curious how the user even knowing a thing is there is bad for the user. At this time we don't have any pattern to assist this. -- Juju mailing list Juju@lists.ubuntu.com<mailto:Juju@lists.ubuntu.com> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Regards, Gabriel Adrian Samfira Cloudbase Solutions SRL
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
