EULA work-around & more issues.

Sorry for harping on this, but I think it’s important. I just finished re-reading the EULA again, and ran into a possible work-around to the issue of distributing code (maybe), and a host of other potential problems.

All of the problems I’ve found so far are in section 2.f in the F04 EULA, specifically where it describes the terms under which you may distribute Sample Application Code. Admittedly, I’m not a lawyer, but this is how it reads to me:


“…however, you are permitted to copy and distribute the Sample Application Code (modified or unmodified) only if all of the following conditions are met:”

“(1) you distribute the compiled object Sample Application Code with your application;”

This would seem to give us an easy loop-hole for distributing modified classes – my interpretation of this is that we can distribute Sample Application Code, as long as we distribute it with a compiled copy. Seems pretty goofy, and I’m sure what they mean is that you can only distribute the code IF it is compiled, but that’s not what it appears to actually say. Though I suppose they may define “Application” only as compiled code, which would block that approach.

So maybe I can distribute my modified UIEventDispatcher, I just need to include an swf that uses it in the zip file with the AS files. ??

“(2) you do not include the Sample Application Code in any product or application designed for website development;”

So, what about applications like gModeler? It is designed for website development (sort of) – am I not allowed to use any of the built-in classes in it? This doesn’t specify whether it refers to compiled or uncompiled Sample Application Code, and neither does it specify an exemption for applications that are actually built in Flash…

“3) you do not use Macromedia’s name, logos or other Macromedia trademarks to market your application.”

What this says to me is that if I build a Flash application using Sample Application Code (ex. a PushButton component), I can’t say “built with Macromedia Flash” on the product’s website. Huh? Sure, I might be stretching the definition of marketing to make a point, but we all know lawyers never do that.

Can someone (hopefully with more law experience) clarify any of this for the rest of us? I hope I’m just totally misreading the EULA, and someone can set me straight.

Grant Skinner

The "g" in gskinner. Also the "skinner".

@gskinner

5 Comments

  1. Hi Grant,

    I think you are reading the first one differently from intended. The idea is that you can distribute the sample code if (and only if) it is compiled in your application. It can’t be distributed to be used one its own.

    Nigel’s comments on this were not legalese or the words of an official “spokesperson” (just a team member trying to be helpful), but he did capture the essense of the problem I think.

    While your desire in and of itself seems harmless, we want a avoid a scenario where lots of people distribute lots of different versions of the components that are slightly different, other developers with varying understanding of those differences adopt them (for various reasons) and find later that they are incompatible with other components, and/or future versions of our components. Of course, if anyone wants to create their own components, that is great—but we want to avoid confusion around varients of the components that come with the product. This is similar to the reason we occasionally have undocumented features—not that we are trying to hide something, rather that we are trying to avoid long term problems by having people adopt usage of something that we may not support in the future.

    I hope this helps. I don’t know much myself about the specific changes you want to distribute, but if you send me email offline with details, I can ask product management to take a look at your case and see if there is something we can do to accomodate each other.

    Regards,

    David

    Macromedia

  2. Grant Skinner et l’EULA (suite)

    C’est toujours la confusion totale sur ce sujet (voir mon premier billet ici). Macromedia a avantage à régler le cas rapidemment, ça commence à chauffer. Quand des types comme Bokel disent “As a professional developer, you should start asking yourself…

  3. The crucial question here appears to be this:

    Can we distribute component source built on the F04 framework. It would appear that we cannot.

    How would this not affect developers who give away the source of their projects to clients. They couldn’t legally do this.

    Perhaps the solution would be an open source component framework that does not use any Macromedia code.

    Thoughts?

  4. Why does the client need the source of the components? If he owns a copy of f7, he already has the sources.

    On the other hand: An open source framework could be a nice solution to a lot of problems. The question is: Who builds it ?

  5. In response to David:

    “While your desire in and of itself seems harmless, we want a avoid a scenario where lots of people distribute lots of different versions of the components that are slightly different, other developers with varying understanding of those differences adopt them (for various reasons) and find later that they are incompatible with other components, and/or future versions of our components.”

    I’m not sure about this, but I think that what Grant is proposing to do is not to replace existing macromedia code on a user’s computer, but to put a separate actionscript file in a user’s own directory which replaces a macromedia file of the same name if and only if a user edits their class paths in just the right way for their project.

    It sounds like the problem is that his separate actionscript file (which doesn’t delete the macromedia one) contains some of macromedia’s base code for event handling, but also has additional code which is better than what macromedia was able to do with their very unfortunate deadline.

    In fact, David, I don’t know why you macromedia people think that we have any reason to expect you to support your own code, much less code which someone modifies…

    To quote David:

    “we are trying to avoid long term problems by having people adopt usage of something that we may not support in the future.”

    For example, macromedia’s V1 components?

    You seem to be biting the hand that feeds you, macromedia. That is a much more significant long term problem than some poor bastard who gets confused because he screwed up the source code for the application he purchased (and apparently doesn’t know how to use).

    At this point, if my DevNet subscription was returnable, I’d be on my way to the store right now, and happily converting my single v2 project back to v1 (and sticking with tags without external javascript files, for that matter). Since that can’t happen, and I actually like to use community driven code over proprietary (and pretty poorly organized, macromedia) code…I think the end-around solution is for us to make a new, open source framework.

    To answer bokel, I think macromedia should do it (or, rather should have done it in the first place!). Since they seem to refuse to take that approach with flash (focusing on making proprietary AS instead of making a better flash player and IDE), I think the community has to try to get its own support for a more usable (and community oriented) component foundation framework.

    For example, we could start with a class that just does what UIObject does, but write it from scratch as squeakily clean as we can. If we did this, and called the methods the same things, we could at least have that base to work with as a community, but potentially force the MM components that we don’t want to rewrite to use our base class instead of macromedia’s. Generally we can extend macromedia’s classes, so distributing most component code isn’t an issue, but for UIObject and its mixins, it becomes an issue unless we have something we could distribute. I certainly wouldn’t mind seeing a parent class to UIObject which handles the event handling and links to the intrinsic functions and other, generally nonvisual things….we could untangle the code ourselves and end up with something more useful than what MM tried to do, we could distribute it legally, and, most important of all, we could have Grant’s EventDispatcher (with all the MM code rewritten) as the base event dispatcher for the community driven version of UIObject.

    Hopefully just naming the public methods the same as the MM class wouldn’t be a violation of the EULA.

    Is there a CVS site which we could use to start such a thing? Given the attitude from macromedia employees, the quality of their components (or lack thereof), the problems in overriding base components that flash shipped with, the stickeyness of their EULA (we all pressed the accept button, didn’t we?) and the fact that we would be doing exactly what they don’t want us to be doing, but preventing them from sicking our lawyers on us by doing it legally….is there a better way to spend our free time?

    I don’t have time or money to talk to my lawyer about code that is worth sharing for free.

    Sean McKibben

    graphex

Comments are closed.