I recently completed a re-write of the mx.events.EventDispatcher class based on my gDispatcher class. This re-write allows me to plug the new class into a project, and have all of the Macromedia components express all of the event capabilities that I built into gDispatcher.
Now, I would like to be able to share this code with the community, as I think it will be very beneficial to everyone, unfortunately, the Flash MX 2004 End User License Agreement prohibits it. I could distribute the new EventDispatcher class, because it is a complete re-write, but in order to make it work seamlessly with UI components, I had to slightly modify the UIEventDispatcher class. According to the EULA, I cannot distribute uncompiled “sample code” even if it is modified, and the built-in class AS files are considered sample code.
This seems almost intentionally stifling (though I’m sure its just another oversight). With AS2.0, overriding classes is often the best way to modify the behaviour of existing objects. It also seem kind of silly given that anyone can get their hands on the code simply by downloading a trial of F04 – it doesn’t even expire like the F04 demo, because AS files are of course just text files. I literally cannot think of an instance where freely distributing this code would cause harm to MM that couldn’t be accomplished simply by downloading the demo – what good is the code without a copy of F04?
This is what happens when lawyers write the EULA, and engineers don’t think through the implications of it.
But enough ranting, back to the problem at hand. The only solutions I can think of immediately are:
1) completely re-writing the UIEventDispatcher class as well, which I really don’t want to do, both because of the time involved, and because in re-writing EventDispatcher I realized what a heavy dependency MM has on accessing the “internal” properties and methods of super classes (they should refer to them as protected, not internal).
2) distributing instructions on how to modify your own copy of the class to work as necessary (ex. change line 46 to “if (blah == blah) {“. This hardly seems like a solution though – it would certainly put off a lot of developers, and confuse others with typos and the like.
So I’m left asking: Does anyone have a good solution for this, other than the most obvious and logical one of Macromedia changing their EULA? Can anyone at Macromedia comment on this? I see this as a major issue moving forwards – in FMX sharing prototype extensions benefited the community greatly, in F04 sharing classes is going to have much the same effect, and inheritance isn’t always the best choice.
Between this, and Macromedia’s comments (via Bentley Wolfe, Sr. Support Engineer) on the improper classPath implementation in F04, I’m left wondering how apparently no one at MM foresaw developer’s needs to modify existing classes. I’m really not sure why they even distributed the classes as .as files if they didn’t think we would modify them.
Comments are very welcome!
I’ve got no solid info, Grant, but I’m bringing this up internally, and pointing other staffers to your blog and other discussions, if that’s useful context.
I don’t think Macromedia legal staff have any type of electronic input (no “wish-legal@macromedia.com” or “legalquestions@macromedia.com”), but the Flash product team can benefit from having each complaint logged in their database through the wishform, and when you need a reply from the legal department then snailmail or phone seems to be the way… main office contacts are listed on the MM site.
Sorry I’ve got no instant solution, but there’s action behind the scenes on addressing this, if that’s of use.
jd/mm
Thanks for the quick response John. I’ve copied the contents of this post, and sent them to wish-flash. I wish you lots of luck in your quest to get this addressed, and hope you’re successful!
The more I think about this, the more frustrating it becomes. There are SO MANY scenarios in which I would want to be able to distribute modified copies of the built-in classes: low-level re-writes (like gDispatcher), component extension and modification (which can only really be done with class modifications now), etc.
Cheers.
I don’t have any specific stake in it myself, but I think from the company’s perspective, it would prolly be a pretty bad thing to have multiple slightly modified versions of base classes running wild.
Internal methods were meant to stay internal (protected, whathaveyou). MM didn’t want you modifying and distributing existing classes. If we have to change a bunch of internal stuff (hmm, what have I been working on lately…). We can’t say anything other than the external (documented) API will be staying backwards-compatible. Mostly, MM has to protect its ability to keep moving forward, and maintaining the groundwork as its own is kinda part of that.
Believe me, we (the engineers) are the first to admit the groundwork is not perfect, but it seems pretty reasonable for MM as a company to put a stake in the ground and try to keep things more homogeneous.
thoughts?
nig
so this limitation is on purpose, isn’t it ?
then why ho why in the first place did you made that code editable ?
because so you can ensure no one but MM will benefit of enhancing Flash even if one doesn’t get paid for it, but will have to send it to MM which will distribute a (paying?) update, is that the planned scenario ?
Sounds completely paranoid, but right now nothing coming from MM would be a surprise, even if completely dumb.
I understand that MM want to keep the integrity of their API.
But i’m also addicted to GDispatcher! I’m translating to AS2 a lot of AS1 classes right now and i’m using GDispatcher a lot. I would really love to be hable to use the same features that GDispatcher provide with the MM API.
I’m really praying for MM to do something with this case!
Nigel,
I’m not suggesting that we should be overwriting base classes – I’m suggesting overriding them on a per project basis. This is part of the reason I was so concerned with the classPath bug in MX2004 [ http://www.gskinner.com/blog/archives/000029.html ] – because it made overriding more difficult.
I understand and respect the arguments you’ve presented, but with the framework MM has presented to developers, class overriding (on a per project basis), is really the most appropriate method of extending built-in functionality in many situations. gDispatcher is a prime example of this (glad to hear it is working well for you stef).
I really am curious as to why MM would include the uncompiled classes at all if you absolutely did not want developers modifying them (as has been suggested by two different MM employees now)? Can someone please explain this disparity? I would be happy to diseminate the reasoning to the community to avoid further confusion, if someone can just explain the suggested best practice, and the logic behind this stance.
Thanks!
On a per project basis, I see benefit and no harm to MM in modified classes. Of course, it’s the developer’s problem if MM modifies the class in the next version in ways that are incompatible with the developer’s modified class. MM has no responsibility on a front, so I do not see how third-party modified classes could prevent MM from moving forward. On to the other hand, both users and even MM itself can benefit from leveraging the combined intelligence of the Flash community.
On a per project basis, I don’t think we’re in disagreement. The classPath thing is annoying, believe me, I know better than anyone, having to develop every day with a new build where I wasn’t using the installed as files.
If you need to make a bunch of mods to your base classes on a per project basis, I don’t think anyone has a problem with that. What I think MM needs to worry about is the scenario of base class mods picking up momentum. Like, you distribute a new event dispatcher, and someone else takes it and decides they’ve got a bunch of changes to style registration, and bundles that up with that event dispatcher.. and so on and so on, until a new competing framework emerges, half MM’s code, and half open source stuff.
Now, I’m not against competition at all, and think the GPL model is great… but in this case, MM wants to maintain control of direction. Competing frameworks make that a lot harder. And, seeing as how it took MM’s money to develop the original code (oh yeah, I made a ton of $$, believe that…), it’s kinda within reason for them to ask you not to *distribute* mods of it. I don’t think anyone cares if you keep your own library of mods that you use on your projects, but once you start distributing these as open source they become prone to momentum building up, which is really what MM wants to prevent. My personal beliefs may vary; I actually think it’s flattering when people care enough about my code to fiddle with it. But I wasn’t hired for my business sense.
So, the next question was why ship source at all? Well, first of all, would you understand half as much about the components as you do without them? The more sample code we can ship, the better, IMO. Also, think about extending our classes, which would be impossible without source. So there are still lots of reasons to keep it around, not just to tantalize you with our mistakes 🙂
I do think a lot of this area is still extremely new to MM. We don’t really have huge amounts of experience managing this kind of thing, trying to promote an architecture designed for extension and maintaining control over that extension. I think it’s going to be natural to expect MM to be a little defensive and conservative with these aspects of its business until it figures out a way to make everyone happy and accomplish some key goals :
a) leverage our brilliant community. Many of us here come from that community and hold it dear to our hearts as well.
b) Maintain leadership. We need to be seen as managing this process.
c) well, the obvious one that no one really likes to say (…$…).
K, I think I’ve talked to much. Just know that this is really on our minds here at the shop, so be patient with us and keep sending your thoughts.
Nigel,
I can appreciate that MM feels a bit defensive, but let’s analyze why they have good reason to:
1) As an extensible framework, lets face it, the components do need work. Many of them aren’t something I would term ‘feature rich’, they really don’t seem to be abstracted to the point they should be, for a programming framework, and if they (gasp) were to have a bug or a glaring feature missing, a large portion of the user base would probably be unqualified to fix it, (and MM would be slow to do so). So we depend on people like Grant, and we have depended upon those people for several versions. Now isn’t the time for MM to get defensive about the need for them.
2) MM’s track record for making small, frequent, compatible improvements in their work is relatively poor. If we, as users, are required to avoid creating anything that could be considered competing (and derivative) frameworks by law, it seems like we should have some expectation that either: MM’s old component framework has a lifecycle of greater than a single version of flash; or we should have better way to simply extend some types of classes, such as mixins so that existing components don’t have to be changed to use them. This, unfortunately, has not yet been the case. We have no expectation of something not breaking in future versions of flash, not even MM’s own code, so why even question partial replacement/extensions to it? Don’t tell me that the current implementations of the component framework aren’t ever going to be changed by MM in such a way as to break the current ones. I really think they can be improved, clarified, and be made better to build upon. If MM wants to take a leadership role in this process, they have to _lead_ the process instead of trying to bind us to it with legal mumbo jumbo. They simply don’t seem to keep up at a technical level with the exact type of thing that Grant has put together here. They shouldn’t force themselves to by preventing the community from picking up the ball where they have left it. And just to poke my head around the corner a little bit further, claiming ownership of the only (elegant) way to do something in flash is sort of a crappy thing to do. I can draw a bit of a parallel to Eolas claiming ownership of how we include flash content in the browser with MM claiming ownership of what features are available in the event listener of my UIObject subclass. We really don’t like, or need, that type of approach with actionScript code that we write or even actionScript code that we copy and paste from MM’s Sample Code into our classes. The point Grant is making is that because MM wrote a bit of code the ‘logical’ way based upon how the compiler and player interprets it, we shouldn’t be prevented from taking that actionScript, making derivitave flash components from it, and distributing them to the community.
3) In order to leverage our brilliant community, we must empower them to make some decisions, such as “this particular mix-in is underpowered, lets give it some very useful features”. Unfortunately, what MM seems to be doing is taking the approach that they made it ‘the way it is’ and we can’t extend and distribute unless we completely rewrite. This is especially bad when their frameworks hook so deeply into intrinsic code that the only way in which to extend them is to re-use a good portion of the existing code. We can’t leverage our brilliant community by gagging them, and they can’t help us unless they create work that could legally be considered derivative of the component framework.
4) The specific issue here is that Grant made a piece of code that would be useful to me personally. I want to use it. It just so happens that this code is to replace a mixin. If there is a way to extend the mixin so that it is extended the same way for all components using that mixin within a given project without having to rewrite those components, we’re all ears, Nigel. If there isn’t a way to get existing components (even ones we wrote) to use an extension to a mixin, we’ve hit an impasse which exists for no good dirty legal reasons. I know I might be stretching things a little bit technically thin here, but I think there is a technical reason that Grant was cornered into modifying a class rather than only needing to extend it to get the functionality that we wanted from it.
5) Sample code reuse. The legal department considers the built in framework to be sample code? If it is just sample code, I don’t really consider it a framework to begin with, so why should we try to build from it exclusively? (oh yeah, because if we don’t, we cant’ make our components work in FP6) If it is sample code and I distribute one of my components which even includes it, or includes a line from it, would I not be breaking the terms of the EULA, even though MM seems to encourage us to extend (and therefore include) sample code when we author components?
6) Is MM encouraging us not to write components by preventing us from using any sample code? It seems that the restriction would even carry through to code I copied from the help system, if we wanted to get technical. And what lawyer doesn’t want to get technical?
7) MM makes the compiler and player, and defines ActionScript in the way they see fit (er, I mean it is fully ECMA compliant). Controling the comipler and the player is a great way for MM to maintain control of what is done with ActionScript. If they have to hold on to their samples of ActionScript so tightly, they aren’t properly leveraging their control of the compiler and player. Forgive me for saying this, but in my opinion, some of the things that UIEventDispatcher (and gDispatcher) does should be done intrinsically by the player to begin with, and not ActionScript. The break between things that are part of MovieClip and things that are part of UIObject is a little bit kludgey, IMHO. If I have a nonvisual component, why should it have to inherit from a class called UIObject anyway? How could I make a component so that it doesn’t inherit from UIObject yet still has editable parameters in the IDE, but doesn’t use any ‘Sample Code’ to make editable parameters (lets say I’m publishing for FP6)?
I really think that MM should reconsider their code use rules for things that can be compiled by flash. You guys make the compiler and player. You should be able to leverage those two things enough that you don’t ever need to worry what we write with actionScript. You guys define the language, the compiler and the player, and I don’t think anyone here is suggesting that we rewrite any part of that. You should give the components and the component framework to us, the authors of content meant for your compiler, player and IDE. If you try to keep us from using parts of your actionScript-based frameworks, you are only encouraging the community to go completely over your heads and rewrite an entire framework which they are permitted to provide input and improvements for. A secondary limitation we’re faced with is that if we were to try to make a new framework from scratch so that we could edit and distribute fixes/improvements ourselves, is that it may not even be possible to do such a thing in a way that wouldn’t be conisdered a modification to the code you wrote, because of the way the compiler works.
Sincerely,
Sean McKibben
It’s to MM’s benefit to have creative people re-engineering their code, introducing features they never considered. It’ll help the Flash community and be an inspiration to us all if Grant releases it — but ONLY if we all agree not to use it, EVER.
I promise you Grant that if you release this code, I will never use it. I’ll look it over, marvel at the enhancements it could make to the functionality of my projects, but I’ll never use it — and if I do may I be struck down!
Mike
What business is MM in? Selling ActionScript? No. Enabling developers! Dis-enabling developers in order to “protect” investment in AS is backwards thinking.
Grant,
Would you send me your lastest version of GDispatcher and other dependent mods?
Did you resolve the issues of calling scope for the event dispatched? Is it now within the scope of the object being triggered or within the scope of where the event was defined?
Thanks so much. Great work. I value your blogs.
Thanks again.
THomasB
Grant,
Reguarding your second thought about “instructions” on how to modify the classes yourself. Would it be legal to distibute some sort of patch that users could apply to the built in classes? I’ve used subversion to patch php code before. ActionScript and php are both text formats so I’m sure it can be done. The question is: Would it be a violation of the EULA to distribute or apply such patches? Anyone from MM?
Thanks for all the great work!
Brian