« Gawker seeking maps | Main | Andrew Grygus on 2003 »
March 03, 2003
AMF PHP legalities
AMF PHP legalities: Robert M. Hall wrote of his experiments in connecting the myPhoto application from Christian Cantrell with the AMF PHP project, for fast transfers of binary data structures between machines. In the comments he writes: "My only concern right now is that we haven't really seen any official comment on the project come down from Macromedia pertaining to the utilization of the undocumented AMF format. I hope Macromedia see this as a win-win situation and are able to come up with a way to give it their blessing and if we are lucky maybe even seek to publicly document the AMF spec so that this project and others could benefit."
Like Mike, I haven't seen any official legal opinion from others in the company, and I tend to avoid saying anything in such situations for risk that my casual words may later be understood in a different sense. If you need something in writing, then I'd recommend contacting the legal department at Macromedia directly.
This seems like another case of working backwards from a communication format to an implementation. Mike mentioned how JGenerator worked backwards from SWF templates to create a server which replicated much of what Macromedia Generator did (Generator is now "honorably retired"). NewAtlanta's BlueDragon has worked backwards from ColdFusion tags to create its own server. In the past we've seen web editors which offer JavaScript remarkably similar to that in Dreamweaver's JavaScript behaviors. I don't know the overall legal angles at all, but I do see some similarities between several types of cases.
Jarle and Robert got into an interesting discussion about the potential expense of GNU Public License... if you give it away it's free, but if you want to sell it then there are complications. I haven't parsed all the GPL implications, but if you want to sell the software you make, commercial software carries such rights with it.
Robert had a request for "public documentation". That makes it cheaper to use, but it's not cheaper to produce... if you've commented code for someone else's use then you know that this is more expensive than just making something which works. Documenting a format also carries connotations of implicit support for other implementations in the future... right now the ActionScript Message Format is in its early stages and may change, and if the company did go to the expense of preparing documentation on the 1.0 then we'd also lose the freedom to quickly evolve it as circumstances dictate. Some formats get documented, but not all do.
My big takeaway from this thread is that the people developing AMF-PHP found this compact data transmission method to be worth their time to enable in PHP. People have connected a Flash client and PHP backend together for years, but avoiding the serialization, bandwidth, parsing and deserialization costs was important enough for them to personally invest in this development. That's great validation for the principles behind Flash Remoting.
Anyway, if you've read this far, yes, I don't know anything about the legalities of all this. ;-) If you need something ironclad then I'd recommend contacting the lawyers directly. I haven't seen any red flags in this area, for whatever that's worth.
Posted by John Dowdell at March 3, 2003 03:11 PM
Trackback Pings
TrackBack URL for this entry:
http://weblogs.macromedia.com/mtadmin/mt-tb.cgi/2739
Listed below are links to weblogs that reference AMF PHP legalities:
» Comments from John Dowdell on AMF-PHP from jdb cyberspace
Robert had some concerns about how Macromedia will respond to the AMF-PHP project. So its nice to see John write about AMF PHP legalities. Or... [Read More]
Tracked on March 3, 2003 04:10 PM
Comments
Hey John,
Thanks for the info. The comparison to JGenerator that you and Mike brought up is a good analogy for this case. I was a big Generator user and also used JGenerator a lot for my personal work. I got into it after I was able to get it running under Mac OS X. I think your best point that I hadn't thought of though was the expense to document a communication spec that is still in a state of flux or development. I think thats all I needed to hear to really understand the situation. Thanks for the post! -Rob
Posted by: Robert M. Hall at March 4, 2003 07:19 AM
I think there's a long line of legal precedent for "clean room" reverse engineering. This goes all the way back to the original IBM PC BIOS, and the cloners that recreated their own version. That successful effort is the reason you can buy a Dell today.
The key is whether the reverse engineering was done completely independently, and without using any Macromedia trade secrets. The behavior of a device or protocol is public information, so as long as you're smart enough to figure out what it means, good for you.
If you misappropriate trade secrets however, that's a whole other story.
Posted by: emberton at March 6, 2003 06:43 AM
John:
You said: "Anyway, if you've read this far, yes, I don't know anything about the legalities of all this. ;-) If you need something ironclad then I'd recommend contacting the lawyers directly. I haven't seen any red flags in this area, for whatever that's worth."
I thought that as Community Manager for Macromedia that you were one of the people at Macromedia who is responsible for finding these things out for us developers. I'm not involved with the AMFPHP project, but in general we developers need someone at Macromedia who can give us the lowdown on what we can and can't do. Who should be contacted about this?
Posted by: Tom Muck at March 10, 2003 04:46 AM
one, as u said, amf-php is reaffirming the value and efficiency of the ActionScript Message Format. two, i would like to point out that the amf-php team has not reverse engineered the code for amf. if u look at branden hall's wiki the .sol stuff has the format right there. plus u can get it within flash. you are not touching the flash player or flash mx source code. therefore, no reverse engineering has been done. once the format is figured out, it's just a matter of using php to serialize and deserialize this.
Posted by: sgd at March 10, 2003 12:54 PM
Hi Tom, any time you've got a legal question about legal issues, then it's wise to get the info in writing from someone who has that legal certification.
I can speak informally, and informally I say I've seen no problems with it, but if you're in a situation where you do "need something ironclad" then I'd definitely recommend getting it from a lawyer. (Macromedia legal department can be contacted at the original link.)
Posted by: jd at March 10, 2003 05:10 PM
Another important consideration is that there are developers out there like myself who want to use Flash clients beyond just the web realm and would like to see the AMF format extended to other areas. As Flash continues to evolve it is quickly becoming a multi-platform client platform applicable to many traditional client/server disciplines some of which may not be directly web related per se. In a web based environment it requires more specific knowledge and configuration experience to get a server up and running successfully as well as reliably. A stand alone server on the other hand requires little expertise other than a working knowledge of how to double click an installer file. There is a vast world of opportunity when leveraging Flash with a very simple server that is in turn connected to a db and so forth. Limiting the Flash Remoting elements to only web based solutions over complicates things from a deployment perspective. Imagine a simple VB or Delphi server talking to a Flash client via remoting (vs. XML sockets) and let your imagination run from there. I am extremely glad to see the AMF protocol information starting to show up as it creates opportunities to take thing further. I'd gladly invest in a component that I could use in Delphi or VB for Flash Remoting. Since none exists (yet) we have no choice but to go this direction. It is definately out of necessity and not out of greed or trying to short Macromedia of any dollars (although the continued increases in prices are very concerning). I'd also very much like to see a similar component enabling Flash Comm Server functionality from a stand alone application platform for the same reasons as above. Both would further help extend Flash beyond the current web centric focus and empower developers to leverage Flash based solutions to a much larger audience.
Posted by: MediaStorm at April 1, 2003 09:24 PM