Protecting Intellectual property (IP)

Celtic

Bit of a business question here so any advice much appreciated

Myself and customer both have a copy of AWAREIM, as the customer wants to be able to edit apps themselves.
I develop an app for a customer and then pass this to him/her to start using, the customer then decides they want to be able to customise the existing application, (add new forms, attributes, change layouts).

I don’t think its possible to prevent the customer from editing the parts of the application that I have developed, or securing parts of the app that I have worked on and preventing the customer from checking out all the work that I have done!

Its more of a question of IP and probably something that would need to be nailed down in a legal agreement or licensing terms and a hefty charge to enable them to resuse all the config/rules/processes methods that I created and the trade secrets! Of course there is always the risk the customer will bodge it also!

The runtime version doesn’t suit as the customer will want to edit and change the application.

Thoughts on best approach?

Giving the customer some level of customisation is always a great thing to be able to offer, a lot of commercial apps provide some level of customisation (custom Screens, form builders new attributes, basic rules) without exposing the source code or detailed config of the core system, some sort of cutdown AWAREIM version would be ideal just by offering form layout builder without letting the customer get into the details. Any thoughts here?

tazzmaxx

I've wondered the same thing. It would be great if there was a limited version of the configuration tool that could be limited by the developer and deployed to the end user for simple changes but keeps them out of the parts of the app that only the developer should control.

Maybe a configuration tool only with access to queries, visual perspectives, notifications, access levels (but limited control), basic form changes, reports and that's it. The rules, processes, services..etc would still be under the control of the developer. It would certainly offer a Aware development company more flexibility when deploying apps. Currently you either have to limit them altogther or have a legal agreement signed by the end user prior to deployment.

aware_support

I think legal agreement is the best approach here. It is possible for the customer to use the Configuration Tool with the runtime version. You can also supply your own licensing file, where you can spell out the terms of the legal agreement.

Protecting parts of the Configuration Tool is tricky - you never know what people might need if they want to extend the application.

bazar2009

Fair enough.

Instead of having a Access Levels updated via the configuration tool it would be nice to be able to have that available from within the user interface. Just as it is great to have user adjustable drop-down lists.

Other things would be users being able to select preferences for their application, like selecting the theme color for their default visual perspective, being able to control what displays and where it displays on their dashboard. Maybe even allowing them to create, store and assign their own notifications.

Does anybody else have people that want to have the same control over the application but don't want to relenquish control of the configuration tool?

tazzmaxx

I was hoping to be able to sell my Aware apps via the web. Unfortunately, I could sell my app to a competitor and they could have my design and easily reverse engineer the product by owning a version of Aware.

I will have to sell my products and use the developer runtime and not provide the configuration tool to anyone since I don't know who they are and it doesn't matter if they sign an agreement they can still reverse engineer a product.

What are other users doing to sell Aware apps and maintain exclusive control of the design?

When I have developed other applications using different platforms, I am the developer (designing the creation and the initial configuration - based on the requirements), an owner/super user/configurator who can manage the system (without seeing the details of the compiled system) and an end user who logs in and uses the product. I am providing an un-compiled version of the product to a user if I allow them to have the configuration tool.

Hopefully there are other ways around this as I want to sell Aware developed applications and want to offer as much flexibility to the end customer without exposing the creation and not having to maintain the entire configuration myself. I don't want to belittle Aware's strength as a development utility because it is just as powerful (if not more) as other platforms and the end results speak for themselves as the performance is great. My .NET and PHP counterparts would significantly disagree if they knew that I can't offer configuration abilities without exposing my "code".

I am very open to other options and other users experiences. Thanks for your thoughts and help.

aware_support

You can always protect your configuration when building a runtime for a customer. In this case the customer will not be able to reverse-engineer your design. The tricky part is when you also want your customers to add extensions to your application without exposing your configuration.

If you allow them this, your are always asking for trouble (that is, if you are paranoid about your IP) - almost irrespective of the technology you use. The best thing is to either not allow them this or anticipate the changes and build them into the configuration and provide configuration options at run time (not inside the Configuration Tool).

rocketman

There are a number of problems associated with allowing the user to change an app. What happens if he/she screws his/her data. who is responsible for the rebuild? Run time's are best but here's a suggestion for a different business model.

Control the server (VPS, dedicated, internet/intranet - it doesn't really matter) and charge your customers a monthly rental/maintenance fee which will include an amount for any changes they may wish to make - but YOU make the changes. How long does it take to add an attrib, or change a form or add an option to a drop down - 30 seconds??

Incidentally, the best way to handle drop down lists is to call them from a referenced. BO rather than hard coding the options into the attrib. That way the user CAN change them without having to call you every 5 minutes

One thing I would like to see built into a future release is the ability for a user to schedule their own process events (from a selection of useable processes) and (as I've mentioned before - and I think support said it's coming) the ability for a user to define a search and then save it away for future recall and use.

aware_support

rocketman wrote
...and I think support said it's coming) the ability for a user to define a search and then save it away for future recall and use.

This is already available in the Developer Edition (user defined queries)