Following my previous post on the Flash MX 2004 EULA update, there was some interesting discussion in the comments about the changes, which I thought was worth moving into a proper post, because the content seems valuable. I’ll try not to misrepresent anyone with my inexpert editing.

If you have your own thoughts and ideas about this issue, please post them in the comments at the end.

On the reasoning behind the restrictions:

Philip Kerman:

Here’s my stab at an answer, and I really don’t know if it’s accurate. I think the idea is that because the MXPro version has certain components, they don’t want people to share with Flash standard users components such as the datagrid

Grant says: Can’t standard users get these components from the trial anyway?

Lucian Beebe – Flash Product Manager:

I’ll try to clarify what I can of the logic behind what we did and where we’re heading with this. We did a lot to open up the EULA for the 90% case that people needed. We feel pretty good about the changes and they will allow you to use our framework (modified all you want) to make your own components. You can do anything you want with the components you make: sell them, trade them, give them away. That was the goal for modifying the EULA.

…

We didn’t go so far as to open up the Framework to be modified and distributed. We worried a lot that doing this would create complete changes to people’s systems and that could cause competing frameworks to create a lot of confusion and bugs. When people spend hours troubleshooting problems with incompatable frameworks, it won’t be a good experience for anyone. We realize that by allowing people to distribute components based on modified framework code we are allowing this to happen a bit, but we thought we’d test the process a bit before opening it up all the way.

Grant Skinner:

With regards to Lucian’s point that opening the framework would potentially cause problems: I can appreciate that, but it’s similar to banning the sale of knives because someone might stab themselves. If you rely on third party modifications, there is an inherent risk that things might break (heck, this is a risk even with MM code). This is something that any semi-competent developer should be aware of. Further, if MM had shipped F04 with the class path’s in the correct order, overriding framework elements on a per project basis without touching the original framework would be a simple task.

I’m not even that concerned with how this issue impacts the distribution of code in the community (though it’s definitely an issue). I’m more concerned with how it impacts client projects, as I am unable to modify the functionality of components on a per project basis, and then hand over the source code to the client (which is a requirement for many contracts).

On the contradictory definition of a developer component

From the original post:

Macromedia’s definition of a Component (ie. the only thing we are given the right to distribute) is “…any of the reusable .SWC files provided by Macromedia…”. Hmmm… so we can only distribute our own components if they are “provided by Macromedia”? Seems kind of contradictory. I’m pretty sure I know what they meant to say, but they sure didn’t succeed. Gotta love Lawyers’R’Us.

Lucian Beebe – Flash Product Manager:

Grant, in number 3 of the bad news list, you ask whether you can only distribute Macromedia components. No, you can distribute any components you build as long as you add material value to the component beyond what Macromedia shipped.

Grant says: This reinforces what I thought the EULA was meant to say, unfortunately, the legalese doesn’t seem to support it fully.

Gregg Wygonik:

i think on negative point 3, you were a little off….

Grant says: Gregg later noticed what I was talking about, and explained it well in a post on his blog.

Possible solutions:

Carlos Rovira:

The Open Source set of components proposed by Grant it’s a really a good idea, and it could bring us a extreme optimized set of components with the funcionality of the MM components plus a few new widgets ready to be improved by the comunity.

Maybe a sourceforge project?

Jon Bradley:

…don’t distribute the MM components as part of the deliverable for source code. That is completely acceptable and should be general practice. If they want to make changes to the product, then they should buy MX04. If you want to extend or modify the MM components for alternate use, then you kinda need to find a method whereby you can make changes that are separate from the actual components themselves – such as inheriting a certain class and overriding a particular method that you wish to re-do. That would probably be fine to distribute, and the client would NEED the MX04 application and components to publish it (duh).

Grant Skinner

I believe my short term solution will simply be to write a dummy component that I can package framework modifications with. It won’t really do anything useful, but it will let me distribute my modifications under this EULA.

Thanks Macromedia!

Grant Skinner:

First, I really want to offer very sincere thanks to Lucian, Mike, John and all the other Macromedians that helped to make these changes a reality. As much as I still feel there are still changes that need to be made to facilitate ease of development, and community, you have made some definite progress, and it’s very much appreciated! Thank you!

…

Again, the changes are definitely appreciated. It’s a step in the right direction, and I hope to see more of the same. I commend Macromedia for reacting to input, and involving members of the community in the process.

Nik Khilnani:

Thanks for the update, we do have a situation better than wat we had before, so thanks.

Carlos Rovira:

…it’s a great step in the right direction but now we’ve to expect for the next step. It’s hard to try to introduce Flash tech at our work when we encounter this type of limitations.

Feel free to post your own thoughts in the comments below.