Oleg, et. all.. One of the key aspects of Apache is that any software that is submitted to the project is 100% clear and legal, and can be used by others knowing that they won't have any legal threats against it. We want to make sure that we abide by this or we will never get out of incubation. Adobe still has copyrights on that library, so they have the ability to declare the license, regardless of what a readme says (or doesn't).
My hope is that we clear these legal hurdles soon. I know a lot of people are antsy to get our first release out the door :) -Nick On Thu, Apr 26, 2012 at 9:09 AM, Left Right <olegsivo...@gmail.com> wrote: > > > > I'll try to rephrase to make sure I understand - IIUC someone needs to > > tell people to unpack the Apache Flex source distribution and mix that > > with other files which do not come from Apache, in order to use > > FlashBuilder which is an external tool that does not belong to us. > > > No, files like playerglobal.swc are necessary for the compiler to function. > I.e. the compiler inside the SDK will not be able to compile AS3 code if > playerglobal.swc is absent from the distribution. > On the other hand, playerglobal.swc library isn't a separate product > distributed by Adobe. It used to be part of either the SDK, or Flash CS or > Catalyst. > > I mentioned this problem before, but the discussion got carried away in a > different direction, so I'll repeat. It is possible to completely replace > playerglobal.swc with an alternative, although it will take time to write > it and there would be a chance of it being misaligned with the real player > API, but it would ultimately solve all possible licensing issues. > I.e. 90% of this library contains only the definitions, which we can > compile ourselves, the rest of it are either some bits of AS3 code, that we > would need to reverse (not much of it, mostly the Proxy class, the > ExternalInterface and that may be it) and the core classes, same as in > Tamarin project. I'm not sure of the particularities, but it could be > possible to also substitute the core classes (String, int, Date etc.) just > the same way as the rest of flash.* package. > > The biggest problem of this library is the documentation for the core and > flash.* classes, of which we don't have the sources and cannot compile > ourselves. I've asked about this bit of documentation about a year ago and > was told that it was complicated for w/e reason to check in this > documentation with the SDK code. If we would want to write the > documentation ourselves, it is really a lot of work... could be a year or > so, but other than that, coming up with the replacement for > playerglobal.swc could take about a month, I guess. > > Best. > > Oleg >
