definitely nothing easy to deside and where to set the limits.
if you would be forbidden to use sencha based methods, then you would create pure js widgets and no sencha addons / ux.

it should also depend on how much (in %) sencha code you use. example: you change 2 lines of code in a big module and release it with a version that is not yet made public to non support subscribers. in that case there has to be at least a check if the buyer is the owner of a licence or the developers have to stick to the public versions.

i can not speak for sencha here, but i think there are a lot of points that should be thought through carefully.

This is a very valid question, and every add-on author will no doubt have the exact same question. There may be some situations that require contacting the licensing dept., but I'm sure that we can provide some general guidelines that most people will be able to follow. I'll make sure that the appropriate people see this question and see if we can get some guidelines put together.

This problem wouldn't be so pronounced if Ext JS was less monolithic. I have already pointed this out and I am going to repeat it: please consider opening up for collaboration with the community, that would be a win-win situation for everyone.

An example: when I developed my Chart extensions I had to refactor significant chunks of Ext JS Chart code in order to avoid copy/paste of colossal proportions. The result is clean separation of my code from Ext JS code, but also a bunch of buffer classes that contain almost 100% Sencha code. I don't know if I have any rights to release these, but considering that my code doesn't work without it I just have to. Of course I'd love to contribute refactored code back to Ext JS but I have no way to do this presently. This situation bugs me somewhat and I'd like to resolve it. Any thoughts?

This problem wouldn't be so pronounced if Ext JS was less monolithic. I have already pointed this out and I am going to repeat it: please consider opening up for collaboration with the community, that would be a win-win situation for everyone.

OK, that's a valid discussion to bring up, but we're not going to stop and refactor the Ext JS framework from the ground up in order to deal with how to approach licensing add-ons. And while your suggestions might (arguably) make such licensing less of an issue, it is still an issue that needs to be clarified either way. There will always be overrides of existing code.