Macromedia quietly released a supplemental EULA tonight (more info), to address some of the concerns I and other members of the Flash community have previously expressed.
If I’m going to carry the burden of being the #1 Flash Bitch, I may as well earn the title. So here’s my take on the new EULA…
The supplementary license is definitely a step in the right direction, as it provides the following:
- The ability to distribute up to 50 lines of Macromedia sample code, though only for the sole purpose of illustration or support.
- Allows you to reference Macromedia and/or Flash in product/marketing materials, provided you adhere to their trademark guidelines
- Distribute components* provided they include material improvements over the originals.
That’s the good news. Unfortunately, the bad news is:
- We are still not allowed to distribute uncompiled MM sample code (even with material improvements), unless it is distributed with, and supports a compiled component (.swc), so don’t expect to see low-level framework modifications like my gDispatcher being distributed under this license.
- You still cannot override and modify MM classes on a per project basis, and distribute the code to your client. This remains a critical necessity for a lot of larger application projects.
- 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.
So where does this leave us? We have a slightly buggy, bloated component set that we can’t easily fix, modify or extend due to the EULA. I’m sure Macromedia is not intentionally trying to stifle our ability to do our work, and share with our community, but they are doing so regardless. I’ve been avoiding all of the attempts to create an open source component framework, in the hopes that MM would right their wrongs, and we could all finally standardize on a single component set – but it’s starting to look like the only real solution. Who’s interested? I’ve got a lovely event model I can contribute. 😉
It might help the situation if someone from Macromedia could clearly articulate the reasoning behind all of these limitations. I can’t find the logic in it, and I haven’t been able to find anyone (in or out of MM) that can explain it to me.
Test… comments should be back on.
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. (Though, I thought there was something about how you can’t even use these in MX Standard).
Thanks,
Phillip
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.
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.
And Phillip, you are right that the idea that you must add “material improvement” to the component is an effort at requiring people to add significant value to the components before shipping them as their own. And part of that reason is that the Flash and Flash Pro products are differentiated in part by components set.
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.
I talked to a bunch of people before making this change and I knew we weren’t going to please everyone 100%. But I also think we took a big step in the right direction and will continue to listen closely to you.
Lucian Beebe
Flash Product Manager
As you say, 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.
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?
hey grant
i think on negative point 3, you were a little off. the supplemental agreement does now include “Component Framework” in the verbage on what you can distribute, and includes a definition of such. this was something that was missing in some of the “beta” EULA attempts that i complained about. so now the “Component Framework” _can_ be included in a third-party component, and _can_ be distributed with such component (provides it provides material improvement, and so on).
🙂
g.
New at Macromedia.com: Updates: EULA, Dreamweaver MX 2004, Studio MX 2004. Tutorial: Gradually Implementing CSS in Your Site
Macromedia Developer Center. Sweet friday! Great news, updates and a nice CSS tutorial at Macromedia. This time I’m linking related posts in the flash community. Special thanks to Macromedia for the EULA update!…
Thanks for the update, we do have a situation better than wat we had before, so thanks.
i think MM has had a few problems… but theyre trying to fix it… thanks for this as well, we really need the next flash update…
personally i think having two versions of a product with a key difference between the two being components, which can easily be redistrubted with or without their source was not a good business decision… but thats me
nik
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!
To clarify point 3 – In the supplemental EULA, Macromedia specifically defines a “Component” as “any of the reusable .SWC files provided by Macromedia” and defines “Developer Components” as a subset of “Component”. We are limited to distributing MM sample code ONLY as a part of a “Developer Component”. Unless I’m misreading something, this means that developers can only distribute “(Developer) Components” that are “provided by Macromedia”. Again, I’m quite certain what was intended, but the legalese doesn’t seem to support it.
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).
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.
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.
Cheers.
First, I agree with most of what everyone else said. But, I may play the devil advocate here by stating that the components that Macromedia distributed with the software are PART of the software.
You cannot give the Flash MX 2004 product to the client, and why should you? I can see how the same can be said of the components that MM ships, it’s part of the published product from MM.
Grant writes:
———-
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).
———-
So 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).
I hand out source code on many projects. In most circumstances, the project will not publish on their systems because they would need everything that we use to build the interactive elements. I can’t give them the software, the plug-ins, the components. I can only give them what has been modified above and beyond the original product (MM component) and what I custom create.
I can’t find much info on working with the .swc format and the license is confusing.
Is the code for .swc encapsulated code available or is there a way to unwrap these files so we can extend them or at least understand how to?
Am I missing something or does the license only allow me to place the .swc file inside a “developer component” and manipulate it from there.
So I could create a myCoolPresentation “developer component” that includes the media component. But if I want to add some method that manipulates the media component or adds a feature it must be extended externally in my shell component?
Is this correct or am I missing something?
thanks
philip, aka:MacTitan
Changement à l’EULA… bofff…
Quelques changements ont été apportés à l’EULA de Flash MX 2004. C’est un pas dans la bonne direction, mais à mon avis c’est trop peu et c’est beaucoup trop tard. Il a fallu plusieurs mois pour ces petits changements,…
To ‘unwrap’ rename the ‘swc’ to ‘zip’ on a PC.
This should result in the ‘unwrapped’ files.
(sorry to be off topic).
u.