EULA BS: There has GOT to be a comprimise…

Reading Grant’s blog about the EULA stuff (<a href=”http://www.gskinner.com/blog/archives/000034.html”>original</a>, <a href=”http://www.gskinner.com/blog/archives/000036.html”>new findings</a>). Man, what a crock. Most of my clients, however, have custom written solutions. The scope of the projects are changing added with what I can now do in 7, resulting in more and more hybrid solutions because of time constraints; custom solutions take time, where as hybrid ones (using some Macromedia framework combined with my own components) are very cost efficient. I’ll admit there are some projects that where I’ve used existing components in MX, but the source code was included in those components, in the new ones, it’s against the law if I have modified them in anyway, which I do sometimes do to meet project requirements.

I’m not sure how much of this applies to the whole “dual” versions of Flash. Like, if you don’t own Flash Pro, you can still modify the base classes to get what you want to happen… I guess, not sure how it works, but sounds like sound reasoning on a way to protect the Flash Pro assets Flash normal users aren’t supposed to have.

Not having the ability to give out projects for those clients that require the “source” will be a problem for me, I’m sure in the future. Currently, most don’t know what the “source” really is anyway cause they don’t understand it, and if they ask can they modify the Accordion pane, and I say no because that’s the way Macromedia made it, but I can “suggest” how they themselves can modify it because if I do it myself and then give that modified code to them, it violates the EULA agreement.

Uh…no. Good to know, though, that Grant and Nigel are chatting about it. When the big, mature boys get together, I’m sure a comprimise will emerge.