This has been discussed 10 billion times; the only reason it wasn't resolved is because anyone who ever resolved a thread that popped up wasn't a certified laywer that could answer the questions that arose after said post.
Since I'd prefer to keep the world turning, and thus repeat history, *ahem*: http://www.macromedia.com/software/eula/tools/flash_components.html That should answer all questions (it hasn't in the past, but repeating just because I'm good at repitition, too much techno...) Here is the full license: http://www.macromedia.com/software/eula/tools/supplemental_license.html If you are looking for the Material Improvement definition, it's at the bottom: >>> "Material Improvement" shall be defined as perceptible, measurable and definable improvements to the Components Framework or a Component that provide extended or additional functionality that add significant business value to the components. <<< ...and, let the discourse resume... ----- Original Message ----- From: "Martin Wood" <[EMAIL PROTECTED]> To: "Open Source Flash Mailing List" <[email protected]> Sent: Tuesday, July 19, 2005 7:12 PM Subject: [osflash] redistributing MM classes with MTASC fixes scott started this on the mtasc mailing list, but i think its worth us discussing here... i've stuck together the relevant parts : ============= <scott> Since every release of MTASC contains a 'std' folder containing the Macromedia classes necessary to compile Flash projects with MTASC, I have a couple of sugggestions: 1. Include all the (freely available and legally distributed) Macromedia classes currently in use. For example, the Remoting classes which are often neglected users new to Remoting who then have to track them down on MM's pages etc. This will mean MTASC users will always have everything they need to compile their projects at all times. 2. Make the class library available from CVS so the community can update them when necessary without requiring Nicolas to take on an extra duty, which will also allow for: 3. Those of us which like to compile with the -strict setting can modify the MM classes to include strict typing as and when we use those classes which require it. This means no one person will be stuck with the job of updating all those classes, and they will become progressively more complete over time. Each new release of MTASC will include the latest set of classes in the std folder. This won't affect users who compile with MMC since the MM compiler will use the original MM classes. And MTASC compilers who prefer not to take advantage of the strict type checking can simply not use -strict and/or point to the MM classes too. ============= This raises the question about re-distribution of MM's code. David Rorex made this point : You might want to check the license on all the macromedia classes, I wouldn't be surprised if they didn't allow redistribution, which would mean we couldn't do this. ============= <scott> True, I believe Grant Skinner faced legal issues when he wanted to distribute gDispatcher and other modified classes a few years back. But on the other hand I'm surprised that MTASC can distribute the core MM classes for exactly the same reason - do the core classes not face any legal redistribution issues, or does MM simply turn a blind eye to this? ============= <me> :) i think this is a great idea, so maybe Mike and John (and any other MM employees who read this list) can give us an idea of what MM's thinking is about this. If we cant re-distribute their code with modifications, then i can imagine a scenario where we can distribute a patch file and some verbose instructions about 1. where to get the MM code 2. how to apply the patch to make it compile with MTASC but thats not pretty. so...where do we go? martin _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
