You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2012/04/26 02:36:01 UTC
[MENTORS] Handling Adobe Binaries
Hi Mentors,
We discovered yesterday that playerglobal.swc is not under MPL and is still under Adobe license. Same for the AIR SDK.
Since these files represent the Flash Platform, I would think they should be defined as “build tools”. If you agree, I want to check my understanding of how to handle these binaries.
1. We still cannot check these into Apache Flex SVN because we don’t have permission from Adobe to do so.
2. We cannot put them in either a source or binary distribution because we don’t have permission from Adobe to do so.
3. Since these are required files, we cannot download them as part of the build script.
4. FlashBuilder currently expects an SDK to be a folder tree contain a set of SWCs some of which are a result of compiling the Apache Flex code, but one is, for example, playerglobal.swc. Can we tell folks to take the source distribution and unzip it into the same folder tree as playerglobal.swc? Or does that go into dangerous territory where it would be confusing to someone as to what the license is for various files after the source distribution is unzipped?
5. Are the rules for a convenience binary distribution different? Could we instruct folks to unzip the binary into the same folder tree as playerglobal.swc?
Thanks,
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, May 2, 2012 at 10:41 AM, Simon Morvan <ga...@zone84.net> wrote:
> ...Maybe Java JDK needs build tools to be downloaded separately by the
> developper in order to perform some specific task, but with a vanilla JDK,
> without downloading anything else, you can produce a working 'Hello World'....
>From a licensing point of view, I would compare playerglobal.swc with
the Java JDK itself: you have to download it separately, and it is
usually under a more restrictive license than the Apache License.
>
> ...Without playerglobal.swc, you can't do anything. Having it to be d/l
> separately from Adobe make the Apache Flex SDK broken by design IMHO and
> dangerously dependent on Adobe future decisions regarding those files....
I agree that it's not an ideal situation, that's why I mentioned that
the Flex team might find a better way later, but *for now* this allows
the project to go forward. For now you also need the Flash player
anyway to run Flex apps, and that's not open either, so having to get
those swc files under a different license doesn't make things much
worse right now.
-Bertrand
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 5/2/12 1:41 AM, "Simon Morvan" <ga...@zone84.net> wrote:
> Le 02/05/2012 10:34, Bertrand Delacretaz a écrit :
>> I think considering them as build tools that people have
>> to download separately is fine for now.
> For what is worth, I think that this denote that the comparison with the
> Java JDK is biased.
>
> Maybe Java JDK needs build tools to be downloaded separately by the
> developper in order to perform some specific task, but with a vanilla
> JDK, without downloading anything else, you can produce a working 'Hello
> World'.
>
> Without playerglobal.swc, you can't do anything. Having it to be d/l
> separately from Adobe make the Apache Flex SDK broken by design IMHO and
> dangerously dependent on Adobe future decisions regarding those files.
In looking around other Apache projects I found this [1]: It appears that
other projects have required JARs from outside the JDK. At least for Apache
Flex, playerglobal wouldn't also need deployment with the app.
[1] http://ws.apache.org/wsif/requirements.html
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Simon Morvan <ga...@zone84.net>.
Le 02/05/2012 10:34, Bertrand Delacretaz a écrit :
> I think considering them as build tools that people have
> to download separately is fine for now.
For what is worth, I think that this denote that the comparison with the
Java JDK is biased.
Maybe Java JDK needs build tools to be downloaded separately by the
developper in order to perform some specific task, but with a vanilla
JDK, without downloading anything else, you can produce a working 'Hello
World'.
Without playerglobal.swc, you can't do anything. Having it to be d/l
separately from Adobe make the Apache Flex SDK broken by design IMHO and
dangerously dependent on Adobe future decisions regarding those files.
--
Simon Morvan
Re: [MENTORS] Handling Adobe Binaries
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Alex,
On Thu, Apr 26, 2012 at 2:36 AM, Alex Harui <ah...@adobe.com> wrote:
...
> We discovered yesterday that playerglobal.swc is not under MPL and
> is still under Adobe license. Same for the AIR SDK....
Based on your clarifications in FLEX-53, I think it's fine to go ahead
and implement a mechanism to download playerglobal.swc and/or
airglobal.swc, with a suitable warning that points people to FLEX-53
for example. Or just instruct users to download those files
themselves.
Even if the Flex team finds a better way later that avoids requiring
those files, I think considering them as build tools that people have
to download separately is fine for now.
Your original post also mentions mixing up Apache Flex code with other
files for FlashBuilder, it might be best to discuss this as a separate
issue, for clarity.
-Bertrand
Re: [MENTORS] Handling Adobe Binaries
Posted by Left Right <ol...@gmail.com>.
Nick,
I don't understand why is it illegal to write an alternative
playerglobal.swc. This does not reproduce what Adobe has done, this is just
a program that serves the same purpose, which, as a consequence, exhibits
similar behavior. It is easy to show that you don't need to reverse
anything in order to write such a program - because the documentation is
published and available to everyone.
On the other hand, it's probably me wishing that there be least possible
connections to Adobe and any other outside dependencies, too. I also
mentioned that this library is not a product distributed by Adobe before in
a less formal sense. I.e. there is no way to tell if the computer that is
going to have SDK installed might already have this library - same thing as
with flash player, for example. This is kind of a sloppy tradition of
proprietary soft to put their programs in random locations never
advertising the location, so I'd rather rely on something distributed in a
normal way, then hope that Adobe will ever comprehend the importance of
transparency of their installations. I mean, Flash player is one of the
most widely distributed programs for PCs, and there is no certain way to
tell if it is installed on a PC - I wouldn't want this kind of policy to
plunder SDK installations too.
Best.
Oleg
Re: [MENTORS] Handling Adobe Binaries
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Apr 26, 2012 at 6:58 PM, Alex Harui <ah...@adobe.com> wrote:
> On 4/26/12 12:22 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>>... If you can document (in JIRA I'd say) what makes you consider those
>> files as build tools, that relaxes some of the licensing requirements
>> as described at http://apache.org/legal/resolved.html#build-tools
>>
> In JIRA under the Flex project?...
Yes - I just created FLEX-53 for that, and made it block FLEX-4 as
this must be clarified before making a release.
-Bertrand
Re: [MENTORS] Handling Adobe Binaries
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Carol,
On Thu, Apr 26, 2012 at 6:46 PM, Carol Frampton <cf...@adobe.com> wrote:
> ...The code in question is
>
> 1) playerglobal.swc to compile the majority of the Flex components
> 2) airglobal.swc to compile the Flex components targeted at AIR
> 3) many pieces of the AIR Integration kit which are need to do Flex mobile
> development..
Ok, added that info to FLEX-53 which I just created to handle this issue.
> ...I think playerglobal.swc/airglobal.swc can be looked at as Actionscript
> system libraries much the same way as the java compiler has system jars.
> java is considered a build tool and people can compile their code with
> those jars. If that argument is correct that means one would need to get
> the two swcs and put them someplace in order to build ...
I agree that this looks very similar to requiring people to get a Java
compiler, so it might not be a problem as long as users are made aware
of the limitations.
> ...and then the
> remaining question is could we provide a convenience script, outside of
> the build procedure, that could download the two swcs and put them into
> place?...
That would be ok IMO, provided the script requires active agreement
from the user.
>
> ...I think you covered AIR Integration kit in your 4. below. We would
> instruct the user to unzip the kit on top of the Flex tree. We don't use
> all the pieces of the kit so we delete some of them. Again the question
> would be could we provide a convenience script that either downloaded the
> integration kit and unzipped it deleting the unused pieces, or just
> unzipped it and deleted the unused pieces?...
I think a script is ok. As this is similar to the above, we might just
create a website page that explains what's going on, and point people
to that when they run the convenience scripts.
-Bertrand
Re: [MENTORS] Handling Adobe Binaries
Posted by Сергей aSt Егоров <bs...@gmail.com>.
BTW, playerglobal.swc is aviable here:
http://www.adobe.com/support/flashplayer/downloads.html
We can just note user that he needs to manually download this binary.
How about that?
On Thu, Apr 26, 2012 at 11:22 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi Alex,
>
> On Thu, Apr 26, 2012 at 2:36 AM, Alex Harui <ah...@adobe.com> wrote:
>> ....We discovered yesterday that playerglobal.swc is not under MPL and is still under Adobe license. Same for the AIR SDK....
>
> What's that Adobe license exactly? URL?
>
>> ...I want to check my understanding of how to handle these binaries....
>
> I'll try that assuming that Adobe license does not allow us to
> redistribute those files.
>
>>
>> 1. We still cannot check these into Apache Flex SVN because we don't have permission from Adobe to do so.
>> 2. We cannot put them in either a source or binary distribution because we don't have permission from Adobe to do so.
>
> Both correct IMO.
>
>> 3. Since these are required files, we cannot download them as part of the build script.
>
> Not automatically, but if the user needs to take active action to
> confirm that they accept using those files, and us encouraging them to
> do so is not illegal, the build could download them.
>
> However, if Flex cannot work without them we have a problem - required
> dependencies of an Apache product must have compatible licenses.
>
> If you can document (in JIRA I'd say) what makes you consider those
> files as build tools, that relaxes some of the licensing requirements
> as described at http://apache.org/legal/resolved.html#build-tools
>
>> 4. FlashBuilder currently expects an SDK to be a folder tree contain a set of SWCs some of which are a result of
>> compiling the Apache Flex code, but one is, for example, playerglobal.swc. Can we tell folks to take the source
>> distribution and unzip it into the same folder tree as playerglobal.swc? Or does that go into dangerous territory
>> where it would be confusing to someone as to what the license is for various files after the source distribution
> + is unzipped?...
>
> 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.
>
> I don't see a problem, we are just providing instructions about how
> people can make use of Apache Flex in the FlashBuilder context, as a
> convenience to them.
>
>> 5. Are the rules for a convenience binary distribution different? Could we instruct folks to unzip the binary into
>> the same folder tree as playerglobal.swc?
>
> We can IMO, in the same way.
>
> -Bertrand
>
> -Bertrand
--
С уважением, Сергей Егоров
Re: [MENTORS] Handling Adobe Binaries
Posted by Carol Frampton <cf...@adobe.com>.
Bertrand,
I know you like inline responses but not sure how to do that with the
information I want to add.
The code in question is
1) playerglobal.swc to compile the majority of the Flex components
2) airglobal.swc to compile the Flex components targeted at AIR
3) many pieces of the AIR Integration kit which are need to do Flex mobile
development
The relevant license info is
http://opensource.adobe.com/wiki/display/flexsdk/Legal+Stuff. The above
code is all covered by the later license mentioned which is, "Adobe Flex
SDK license". I can't even pretend to understand all the licensing issues.
I think playerglobal.swc/airglobal.swc can be looked at as Actionscript
system libraries much the same way as the java compiler has system jars.
java is considered a build tool and people can compile their code with
those jars. If that argument is correct that means one would need to get
the two swcs and put them someplace in order to build and then the
remaining question is could we provide a convenience script, outside of
the build procedure, that could download the two swcs and put them into
place?
I think you covered AIR Integration kit in your 4. below. We would
instruct the user to unzip the kit on top of the Flex tree. We don't use
all the pieces of the kit so we delete some of them. Again the question
would be could we provide a convenience script that either downloaded the
integration kit and unzipped it deleting the unused pieces, or just
unzipped it and deleted the unused pieces? There is a benefit to this
strategy regardless of the licensing issues since the mac version of the
kit has symbolic links and many of the build tools obliterate those links
which cause runtime issues when debugging.
Carol
On 4/26/12 3 :22AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>Hi Alex,
>
>On Thu, Apr 26, 2012 at 2:36 AM, Alex Harui <ah...@adobe.com> wrote:
>> ....We discovered yesterday that playerglobal.swc is not under MPL and
>>is still under Adobe license. Same for the AIR SDK....
>
>What's that Adobe license exactly? URL?
>
>> ...I want to check my understanding of how to handle these binaries....
>
>I'll try that assuming that Adobe license does not allow us to
>redistribute those files.
>
>>
>> 1. We still cannot check these into Apache Flex SVN because we don¹t
>>have permission from Adobe to do so.
>> 2. We cannot put them in either a source or binary distribution
>>because we don¹t have permission from Adobe to do so.
>
>Both correct IMO.
>
>> 3. Since these are required files, we cannot download them as part of
>>the build script.
>
>Not automatically, but if the user needs to take active action to
>confirm that they accept using those files, and us encouraging them to
>do so is not illegal, the build could download them.
>
>However, if Flex cannot work without them we have a problem - required
>dependencies of an Apache product must have compatible licenses.
>
>If you can document (in JIRA I'd say) what makes you consider those
>files as build tools, that relaxes some of the licensing requirements
>as described at http://apache.org/legal/resolved.html#build-tools
>
>> 4. FlashBuilder currently expects an SDK to be a folder tree contain
>>a set of SWCs some of which are a result of
>> compiling the Apache Flex code, but one is, for example,
>>playerglobal.swc. Can we tell folks to take the source
>> distribution and unzip it into the same folder tree as
>>playerglobal.swc? Or does that go into dangerous territory
>> where it would be confusing to someone as to what the license is for
>>various files after the source distribution
>+ is unzipped?...
>
>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.
>
>I don't see a problem, we are just providing instructions about how
>people can make use of Apache Flex in the FlashBuilder context, as a
>convenience to them.
>
>> 5. Are the rules for a convenience binary distribution different?
>>Could we instruct folks to unzip the binary into
>> the same folder tree as playerglobal.swc?
>
>We can IMO, in the same way.
>
>-Bertrand
>
>-Bertrand
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 4/26/12 12:22 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>
> What's that Adobe license exactly? URL?
http://www.adobe.com/products/eulas/pdfs/adobe_flex_software_development_kit
-combined-20110916_0930.pdf
>
>
>> 3. Since these are required files, we cannot download them as part of the
>> build script.
>
> Not automatically, but if the user needs to take active action to
> confirm that they accept using those files, and us encouraging them to
> do so is not illegal, the build could download them.
>
> However, if Flex cannot work without them we have a problem - required
> dependencies of an Apache product must have compatible licenses.
>
> If you can document (in JIRA I'd say) what makes you consider those
> files as build tools, that relaxes some of the licensing requirements
> as described at http://apache.org/legal/resolved.html#build-tools
>
In JIRA under the Flex project?
Is there yet another distinction between "prerequisites" and "build tools"?
I see other projects say that you have to download a JDK as a prerequisite.
That's basically what I'm proposing here, although Adobe is the only
supplier of a usable SDK. Before getting the Apache Flex distribution, you
would download and install Ant, a JDK (to build the compiler), and the Adobe
FlashPlayer and/or Adobe AIR SDKs. I don't think we need to actually
include these files in a distribution other than as a convenience and then
only if we can get redistribution rights.
There is no code in these files that go into the output executable. They
represent the classes in the VM/runtime. Roughly the equivalent of
java.lang and java.awt. Some of the other files are utility applications
used to package the executable for installation on a mobile platform, or for
launching the runtime in debug mode.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Alex,
On Thu, Apr 26, 2012 at 2:36 AM, Alex Harui <ah...@adobe.com> wrote:
> ....We discovered yesterday that playerglobal.swc is not under MPL and is still under Adobe license. Same for the AIR SDK....
What's that Adobe license exactly? URL?
> ...I want to check my understanding of how to handle these binaries....
I'll try that assuming that Adobe license does not allow us to
redistribute those files.
>
> 1. We still cannot check these into Apache Flex SVN because we don’t have permission from Adobe to do so.
> 2. We cannot put them in either a source or binary distribution because we don’t have permission from Adobe to do so.
Both correct IMO.
> 3. Since these are required files, we cannot download them as part of the build script.
Not automatically, but if the user needs to take active action to
confirm that they accept using those files, and us encouraging them to
do so is not illegal, the build could download them.
However, if Flex cannot work without them we have a problem - required
dependencies of an Apache product must have compatible licenses.
If you can document (in JIRA I'd say) what makes you consider those
files as build tools, that relaxes some of the licensing requirements
as described at http://apache.org/legal/resolved.html#build-tools
> 4. FlashBuilder currently expects an SDK to be a folder tree contain a set of SWCs some of which are a result of
> compiling the Apache Flex code, but one is, for example, playerglobal.swc. Can we tell folks to take the source
> distribution and unzip it into the same folder tree as playerglobal.swc? Or does that go into dangerous territory
> where it would be confusing to someone as to what the license is for various files after the source distribution
+ is unzipped?...
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.
I don't see a problem, we are just providing instructions about how
people can make use of Apache Flex in the FlashBuilder context, as a
convenience to them.
> 5. Are the rules for a convenience binary distribution different? Could we instruct folks to unzip the binary into
> the same folder tree as playerglobal.swc?
We can IMO, in the same way.
-Bertrand
-Bertrand
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 4/26/12 12:19 PM, "Rick Winscot" <ri...@gmail.com> wrote:
> ( I'm speaking to Apache Flex in general - excluding Adobe or its employees )
>
> At this point in time, Apache Flex has a direct dependency on playerglobal.swc
> as well as other bits and bobs... all of which provide interoperability (
> which was promised ) with Flash Player. Any kind of 'Iron Fist' or cease and
> desist would be difficult to dismiss as not being discriminative,
> anti-competitive, and a direct attempt to undermine our efforts ( just sayin'
> ).
>
> 'How' this detail was missed is inconsequential... and we are all gainfully
> engaged in trying to find a solution - which is good... but it might be better
> ( I might be going out on a limb here ) if we place the burden on Adobe.
The burden is already on Adobe. We're working on it. I'm not worried yet.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Rick Winscot <ri...@gmail.com>.
( I'm speaking to Apache Flex in general - excluding Adobe or its employees )
At this point in time, Apache Flex has a direct dependency on playerglobal.swc as well as other bits and bobs... all of which provide interoperability ( which was promised ) with Flash Player. Any kind of 'Iron Fist' or cease and desist would be difficult to dismiss as not being discriminative, anti-competitive, and a direct attempt to undermine our efforts ( just sayin' ).
'How' this detail was missed is inconsequential... and we are all gainfully engaged in trying to find a solution - which is good... but it might be better ( I might be going out on a limb here ) if we place the burden on Adobe.
* We require a reasonable degree of freedom to explore ( without the fear of Adobe Legal ) interoperability with the Flash ecosystem
* We require documentation of any attachment points that may raise concerns of patent infringement
* We require substitutions ( stubs ) of primary dependencies or well-documented alternative(s) that are Apache compatible
In other words... we should raise the red flag, deliver our best laundry list, and let them get to work on a solution.
As a disclaimer... I want to offer the fact that there are great minds here - without a doubt! My concern ( aka tirade ) is that we can easily get side-tracked on items that we are not well equipped to handle... or perhaps _shouldn't_ be handling. Again, speaking to Apache Flex in general and not Adobe employees.
On Thursday, April 26, 2012 at 1:30 PM, Left Right wrote:
> >
> > I'll ask legal about this, but it might fall under the reverse engineering
> > restriction.
> >
>
>
>
> But there's published documentation with precise description of what the
> API do - why copying that would be a reverse engineering? It's like if I
> wanted to write a driver for NVidia adapter - there's no way I would avoid
> copying all the same API they have in the hardware, and, eventually it
> would have all the same interface as the NVidia proprietary drivers. That's
> not stealing from NVidia (in the case outlined above), it's just creating
> an alternative, which cannot vary from the original because of what it does.
>
> Best.
>
> Oleg
Re: [MENTORS] Handling Adobe Binaries
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 4/26/2012 4:19 PM, Alex Harui wrote:
> On 4/26/12 10:30 AM, "olegsivokon@gmail.com"<ol...@gmail.com> wrote:
>
>> But there's published documentation with precise description of what the
>> API do - why copying that would be a reverse engineering? It's like if I
>> wanted to write a driver for NVidia adapter - there's no way I would avoid
>> copying all the same API they have in the hardware, and, eventually it
>> would have all the same interface as the NVidia proprietary drivers. That's
>> not stealing from NVidia (in the case outlined above), it's just creating
>> an alternative, which cannot vary from the original because of what it does.
> I'm not a lawyer, and I've been surprised by how some of this legal stuff
> works. Above you used the word "copy" which I believe the legal term
> "Copyright" is meant to limit.
The purpose of Copyright is [and I'll quote Wikiepdia] "to promote the
creation of new works by giving authors control of and profit from them".
Copyright was intended to encourage authors/artists create new stuff.
"Big Media" lobbying and lawyers are doing their best to change that,
though.
--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 4/26/12 10:30 AM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
>
> But there's published documentation with precise description of what the
> API do - why copying that would be a reverse engineering? It's like if I
> wanted to write a driver for NVidia adapter - there's no way I would avoid
> copying all the same API they have in the hardware, and, eventually it
> would have all the same interface as the NVidia proprietary drivers. That's
> not stealing from NVidia (in the case outlined above), it's just creating
> an alternative, which cannot vary from the original because of what it does.
I'm not a lawyer, and I've been surprised by how some of this legal stuff
works. Above you used the word "copy" which I believe the legal term
"Copyright" is meant to limit. IMO, the problem is made more complex in
that playerglobal.swc is not really code, it is more like a document.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Left Right <ol...@gmail.com>.
>
> I'll ask legal about this, but it might fall under the reverse engineering
> restriction.
But there's published documentation with precise description of what the
API do - why copying that would be a reverse engineering? It's like if I
wanted to write a driver for NVidia adapter - there's no way I would avoid
copying all the same API they have in the hardware, and, eventually it
would have all the same interface as the NVidia proprietary drivers. That's
not stealing from NVidia (in the case outlined above), it's just creating
an alternative, which cannot vary from the original because of what it does.
Best.
Oleg
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 5/1/12 4:12 PM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
> For flash.* classes there seem to be only their constructors / some
> rather innocuous pieces of code, but the ES code is entirely embedded there.
> There's something difficult for me to understand though - what pieces of AS
> code from playerglobal actually go into resulting SWF, and why that code is
> there (because, obviously, most of it is not needed). What was the intent,
> or was it just a mistake? (I won't be surprised if it was).
I looked into the playerglobal binary, and ran a quick test. The conclusion
is that I am correct: code in playerglobal does not go into the output swf
because the API is marked native and the compiler knows better.
I would have to dig through the player source to confirm, but I was told in
the past that some parts of the player API are written in AS and I believe
the byte code or maybe the JIT of that code is embedded in the player.
I do know for sure that lots of player APIs have .as files representing them
that contain stubs. This is done in order to generate ASDoc for those
classes. Those .as files are in the player codebase and Adobe is not
planning to donate those files.
So, it appears that there are other .as files in there that contain actual
AS code that is probably also embedded into the player, but again none of
that gets linked into the output SWF.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Left Right <ol...@gmail.com>.
For flash.* classes there seem to be only their constructors / some
rather innocuous pieces of code, but the ES code is entirely embedded there.
There's something difficult for me to understand though - what pieces of AS
code from playerglobal actually go into resulting SWF, and why that code is
there (because, obviously, most of it is not needed). What was the intent,
or was it just a mistake? (I won't be surprised if it was).
Best.
Oleg
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 5/1/12 3:40 PM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
> Alex, why are you sure it violates anything?
I'm not sure.
> I believe there must be a
> legal procedure to declare it a reverse engineering. I saw it done many
> times before in a similar context, and beside Oracle trying to press
> charges on Google for some superficial reason I don't know of any similar
> case. (Beside, the case with Google is really different, Oracle claims
> Google stole their implementation of their smelly J2EE, because they found
> a handful of functions with same signatures).
> Gnash exists for what would be like a decade, they implemented some of the
> functions with same signatures as there are in Flash player - and I don't
> remember / can't imagine anyone will try to sue them for that. ASDT first
> and then FDT and FlashDevelop had mock-up classes / interfaces replicating
> Flash player API for the purpose of parsing the code. Can you imagine a
> code editor for AS other than that created by Adobe being even conceivable
> if this was a real concern?
Tools have the option to get a re-distribution agreement from Adobe to
bundle Player or AIR SDKs. But my understanding of Apache's rules are that
we can't have that kind of relationship because the license is too
restrictive.
>
> So, there are actually two options: if we actually only need the
> "outlines", then the library would be 90% smaller then it is now, and it
> would hardly have anything in common with what Adobe provides today. But if
> for any reason we need that library, then the code it contains probably has
> to go with Tamarin's license, whichever it is, because that is what it is.
> But then there's yet another option - maybe it will be easier to "make
> friends" with Tamarin and compile their code into that library? Is Mozilla
> license any better for Apache then Adobe's?
Mozilla allows re-distribution, if I understand correctly.
> (Again, I'm blur on why is that
> library under any Adobe's license since the code it contains isn't).
Not sure, but the flash.*.* stuff is probably not Tamarin
>
> Best.
>
> Oleg
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Left Right <ol...@gmail.com>.
As I looked inside the playerglobal.swc, it has actual AS3 code compiled
into it, not just dummy definitions :S
All classes listed here:
http://hg.mozilla.org/tamarin-redux/file/fdf1416a3536/core are there (maybe
there are more of them, I didn't count).
Alex, why are you sure it violates anything? I believe there must be a
legal procedure to declare it a reverse engineering. I saw it done many
times before in a similar context, and beside Oracle trying to press
charges on Google for some superficial reason I don't know of any similar
case. (Beside, the case with Google is really different, Oracle claims
Google stole their implementation of their smelly J2EE, because they found
a handful of functions with same signatures).
Gnash exists for what would be like a decade, they implemented some of the
functions with same signatures as there are in Flash player - and I don't
remember / can't imagine anyone will try to sue them for that. ASDT first
and then FDT and FlashDevelop had mock-up classes / interfaces replicating
Flash player API for the purpose of parsing the code. Can you imagine a
code editor for AS other than that created by Adobe being even conceivable
if this was a real concern?
What we really have to know - it seems like a lot of things in that library
aren't really needed, or, if they are, then we are in a very sad situation,
because it contains the entire ES implementation, literary, not dummies. It
also contains loads of undocumented functions, not from ES variety - all
the "global" functions, like describeType() and even some arcane like
bugzilla(). If we actually need all that in order to produce SWFs, than it
meas that we are using Tamarin's code.
So, there are actually two options: if we actually only need the
"outlines", then the library would be 90% smaller then it is now, and it
would hardly have anything in common with what Adobe provides today. But if
for any reason we need that library, then the code it contains probably has
to go with Tamarin's license, whichever it is, because that is what it is.
But then there's yet another option - maybe it will be easier to "make
friends" with Tamarin and compile their code into that library? Is Mozilla
license any better for Apache then Adobe's? (Again, I'm blur on why is that
library under any Adobe's license since the code it contains isn't).
Best.
Oleg
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 5/2/12 2:24 PM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
> That doesn't really matter... it's not my question, whether player's API
> are written in AS3 or not :S it could be COBOL for all I care - what
> bothers me is why there is code in that library that shouldn't be there.
>
> And yeah, I'm getting used to the sort of answer "everyone wears their
> pants on their head, so should do you". What does it matter what other
> Apache project do, if doing what we are going to do is, well, bad. I mean,
> do you always buy a TV when you need to replace the battery in remote
> control? Because someone else does that too?
>
> And, which bothers me most, is that if we choose this *easy* path of
> accepting whatever there's in that library, then we can forget about normal
> ways of distributing the SDK. I can understand this as a temporary measure,
> until we come up with our own, but in the long run - this is just bad. If
> Adobe did such a crappy job at compiling that library - why do we need to
> copy it from them? Common sense says we need to either fix it, or ask Adobe
> for something to replace it... I'm not inclined to ask Adobe / don't think
> they will do it anyway / I wouldn't like them to either because I don't
> like their approach to writing code, especially not when it comes to AS...
>
Once we get to parity, you are welcome to fix all of this stuff as long as
you do it in the Apache way.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Left Right <ol...@gmail.com>.
That doesn't really matter... it's not my question, whether player's API
are written in AS3 or not :S it could be COBOL for all I care - what
bothers me is why there is code in that library that shouldn't be there.
And yeah, I'm getting used to the sort of answer "everyone wears their
pants on their head, so should do you". What does it matter what other
Apache project do, if doing what we are going to do is, well, bad. I mean,
do you always buy a TV when you need to replace the battery in remote
control? Because someone else does that too?
And, which bothers me most, is that if we choose this *easy* path of
accepting whatever there's in that library, then we can forget about normal
ways of distributing the SDK. I can understand this as a temporary measure,
until we come up with our own, but in the long run - this is just bad. If
Adobe did such a crappy job at compiling that library - why do we need to
copy it from them? Common sense says we need to either fix it, or ask Adobe
for something to replace it... I'm not inclined to ask Adobe / don't think
they will do it anyway / I wouldn't like them to either because I don't
like their approach to writing code, especially not when it comes to AS...
Best.
Oleg
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 5/2/12 12:33 PM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
> I'm still puzzled - why does that library contains actual code?
For the third time, I believe some player APIs are written in AS and the abc
is embedded in the player. Instead of having both a stub copy for
playerglobal and an actual copy for the player, there is just one copy that
generates both the ASDoc and the ABC. Regardless, none of that code in
playerglobal seems to end up in the output SWF.
> Maybe
> asking Adobe for a *normal* library without that code (which we seems like
> don't even need!) would sort out the patents / copyright issues?
I can ask, but it won't happen soon. Again, this is all for "fun". It
looks like we can treat these files as part of the build tools.
>
> On the other hand, I feel bad telling someone they have to download a piece
> of *software*, of which they, under any circumstances, will not use more
> then 10%. This is sad / stupid / bizarre.
Plenty of other Apache projects have folks download stuff beforehand. The
API signatures are being used by the compiler, but any code in there isn't.
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Left Right <ol...@gmail.com>.
I'm still puzzled - why does that library contains actual code? Maybe
asking Adobe for a *normal* library without that code (which we seems like
don't even need!) would sort out the patents / copyright issues?
On the other hand, I feel bad telling someone they have to download a piece
of *software*, of which they, under any circumstances, will not use more
then 10%. This is sad / stupid / bizarre.
^ No, mxmlc *should'nt* need playeglobal.swc to compile anything - your
problem, however, will be that you won't be able to use String, int, XML,
DisplayObject etc. in your code, which kind of limits you... :) In the very
early days of SDK there used to be a *reduced* version of playerglobal with
Tamarin-only classes (i.e. the ES4 classes), and the Flash classes used to
be in a separate library, or even just plain text files... can't remember
atm.
If, and I hope it is still correct, MXMLC allows this situation to
continue, this would be the best option (consciousness-wise) to ask users
to download Tamarin's library and our own headers of AS classes. Tamarin
is, at least, a *friendly* license, and it may be possible to do something
about a binary package on Linux/BSD distros about it. But if that's coming
from Adobe - you can forget about binary package :(
Best.
Oleg
Re: [MENTORS] Handling Adobe Binaries
Posted by Clint Modien <cm...@gmail.com>.
On May 2, 2012, at 10:54 AM, Om wrote:
>> From the catalog.xml I/we could write some air as3 code using describeType
>> to gen a copy of the playerglobal api.
>>
>
>
> Even if we succeed in doing it, we still need mxmlc or compc to compile the
> actionscript files into the library.swf which goes inside
> playerglobal.swc. That would not be possible because the compiler has not
> been built yet. Chicken/egg?
>
O ya… :/
Re: [MENTORS] Handling Adobe Binaries
Posted by Om <bi...@gmail.com>.
> From the catalog.xml I/we could write some air as3 code using describeType
> to gen a copy of the playerglobal api.
>
Even if we succeed in doing it, we still need mxmlc or compc to compile the
actionscript files into the library.swf which goes inside
playerglobal.swc. That would not be possible because the compiler has not
been built yet. Chicken/egg?
On Wed, May 2, 2012 at 10:33 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 5/2/12 10:41 AM, "Clint Modien" <cm...@gmail.com> wrote:
>
> > Read an article this morning that I felt was a parallel to this threadŠ
> >
> http://www.forbes.com/sites/oliverherzfeld/2012/05/01/oracle-v-google-are-apis
> > -covered-by-copyright-law/
> >
> > From the articleŠ
> >
> > <quote>
> > The heart of the copyright phase of the trial is Oracle¹s claim that
> Google is
> > infringing its copyrights in and to 37 Java APIs used by Android by
> copying
> > their ³structure, sequence and organization². Google claims such APIs
> are not
> > subject to copyright protection.
> > </quote>
> >
> > Perhaps the break in the parallel is that playerglobal is not open
> source.
> >
> > Since playerglobal is a swc and when you unzip it you get catalog.xml.
> >
> > From the catalog.xml I/we could write some air as3 code using
> describeType to
> > gen a copy of the playerglobal api.
> >
> > If API's are currently not copyright protected like the article contends
> we
> > should be fine to do this.
> >
> > That way even if playergobal code is compiled into the final output we
> > wouldn't be infringing.
> >
> Again, I am not a lawyer, but using describeType and unzip swcs could be
> considered reverse-engineering.
>
> This is sort of fun to discuss, but really, I think we have been ruled to
> be
> a "build tool" and will be instructing folks to download it as well as Ant
> and a JDK, so really, this is discussion isn't critical to the mission.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 5/2/12 10:41 AM, "Clint Modien" <cm...@gmail.com> wrote:
> Read an article this morning that I felt was a parallel to this threadŠ
> http://www.forbes.com/sites/oliverherzfeld/2012/05/01/oracle-v-google-are-apis
> -covered-by-copyright-law/
>
> From the articleŠ
>
> <quote>
> The heart of the copyright phase of the trial is Oracle¹s claim that Google is
> infringing its copyrights in and to 37 Java APIs used by Android by copying
> their ³structure, sequence and organization². Google claims such APIs are not
> subject to copyright protection.
> </quote>
>
> Perhaps the break in the parallel is that playerglobal is not open source.
>
> Since playerglobal is a swc and when you unzip it you get catalog.xml.
>
> From the catalog.xml I/we could write some air as3 code using describeType to
> gen a copy of the playerglobal api.
>
> If API's are currently not copyright protected like the article contends we
> should be fine to do this.
>
> That way even if playergobal code is compiled into the final output we
> wouldn't be infringing.
>
Again, I am not a lawyer, but using describeType and unzip swcs could be
considered reverse-engineering.
This is sort of fun to discuss, but really, I think we have been ruled to be
a "build tool" and will be instructing folks to download it as well as Ant
and a JDK, so really, this is discussion isn't critical to the mission.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Clint Modien <cm...@gmail.com>.
Read an article this morning that I felt was a parallel to this thread…
http://www.forbes.com/sites/oliverherzfeld/2012/05/01/oracle-v-google-are-apis-covered-by-copyright-law/
From the article…
<quote>
The heart of the copyright phase of the trial is Oracle’s claim that Google is infringing its copyrights in and to 37 Java APIs used by Android by copying their “structure, sequence and organization”. Google claims such APIs are not subject to copyright protection.
</quote>
Perhaps the break in the parallel is that playerglobal is not open source.
Since playerglobal is a swc and when you unzip it you get catalog.xml.
From the catalog.xml I/we could write some air as3 code using describeType to gen a copy of the playerglobal api.
If API's are currently not copyright protected like the article contends we should be fine to do this.
That way even if playergobal code is compiled into the final output we wouldn't be infringing.
On May 2, 2012, at 5:01 AM, Nicholas Kwiatkowski wrote:
> But isn't creating an exact copy of the API our goal, in order to have
> feature and functional parity?
>
> If I don't match the function signatures, then the world goes to shit.
>
> -Nick
>
>
> On Tue, May 1, 2012 at 8:18 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>>
>> On 5/1/12 4:54 PM, "Jeffry Houser" <je...@dot-com-it.com> wrote:
>>
>>> It shouldn't violate copyright; because we are writing our own code
>>> from scratch. Unless Adobe wants to claim copyright on the API which is
>>> possible. I know I read about a API related lawsuit at one point, but I
>>> have no idea what the results were.
>> Again, I'm not a lawyer, but here's my logic: If we were writing actual
>> code that did something, then I would agree, starting from scratch
>> shouldn't
>> be a violation of copyright. But to try to create an exact replica of an
>> API is to me the equivalent of hearing a song, but not having the sheet
>> music, re-creating the song exactly. I don't think you can do that in the
>> music business.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
Re: [MENTORS] Handling Adobe Binaries
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
But isn't creating an exact copy of the API our goal, in order to have
feature and functional parity?
If I don't match the function signatures, then the world goes to shit.
-Nick
On Tue, May 1, 2012 at 8:18 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 5/1/12 4:54 PM, "Jeffry Houser" <je...@dot-com-it.com> wrote:
>
> > It shouldn't violate copyright; because we are writing our own code
> > from scratch. Unless Adobe wants to claim copyright on the API which is
> > possible. I know I read about a API related lawsuit at one point, but I
> > have no idea what the results were.
> Again, I'm not a lawyer, but here's my logic: If we were writing actual
> code that did something, then I would agree, starting from scratch
> shouldn't
> be a violation of copyright. But to try to create an exact replica of an
> API is to me the equivalent of hearing a song, but not having the sheet
> music, re-creating the song exactly. I don't think you can do that in the
> music business.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 5/2/12 1:09 AM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
> Regardless of how the legal side of this pans out, I'm terribly confused
> about the content of playerglobal.swc - again, it is not "fakes". Or, if
> you consider that analogy with C - it is not the headers only, it is both
> the headers and the actual code / implementations. And implementations are
> the 90% of that library.
Some of it is fakes, some of looks to be real code whose ABC is embedded in
the player. Regardless, none of it appears to end up in the executable.
> If compiler needed only the headers (definitions) - why does Adobe put all
> that stuff into the library?
Probably to avoid having a fake version and a real version.
>
> Besides, there are some kindergarten-style functions, like this one (/***
> ***/ are my comments):
>
> Is this _really_ how this code works in the player?
Probably.
> And if so, don't we
> have any way to fix this?
Not really. You can file a bug with the player if you want.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Left Right <ol...@gmail.com>.
Regardless of how the legal side of this pans out, I'm terribly confused
about the content of playerglobal.swc - again, it is not "fakes". Or, if
you consider that analogy with C - it is not the headers only, it is both
the headers and the actual code / implementations. And implementations are
the 90% of that library.
If compiler needed only the headers (definitions) - why does Adobe put all
that stuff into the library? How does compiler know what to include /
exclude (a function / variable declared as native cannot have
implementation - so all the ES stuff gets compiled w/o the native
namespace, some Adobe stuff, which is originally Tamarin (ByteArray for
example) has both native declaration and actual implementations (of several
methods, like, compress() for example). Is that anything that the compiler
actually needs to know? Or if it doesn't, then why is it there?
Besides, there are some kindergarten-style functions, like this one (/***
***/ are my comments):
// avm+ specific utility method
public static function throwError(type:Class, index:uint, ... rest)
{
// This implements the same error string formatting as the native
// method PrintWriter::formatP(...) any changes to this method should
// also be made there to keep the two in sync.
var i=0; /*** What do you need this variable for? ***/
var f=function(match, pos, string) /*** obviously type constraints are
for the weak ***/
{
var arg_num = -1;
/*** Did you know you could do `match.charCodeAt(1) - 48` instead
of this switch? ***/
switch(match.charAt(1))
{
case '1':
arg_num = 0;
break;
case '2':
arg_num = 1;
break;
case '3':
arg_num = 2;
break;
case '4':
arg_num = 3;
break;
case '5':
arg_num = 4;
break;
case '6':
arg_num = 5;
break; /*** where are 7, 8 and 9? ***/
}
if( arg_num > -1 && rest.length > arg_num )
return rest[arg_num];
else
return "";
}
/*** digit has an alias - \d, no need to use [0-9], but more than
that, this filters 0..9 characters, but you only replace 0..6 characters,
why? ***/
throw new type(Error.getErrorMessage(index).replace(/%[0-9]/g, f),
index);
}
Is this _really_ how this code works in the player? And if so, don't we
have any way to fix this?
Best.
Oleg
Re: [MENTORS] Handling Adobe Binaries
Posted by jude <fl...@gmail.com>.
NAL (not a lawyer) either but when I was working on music copyright issues
you could use copyright materials if you were granted permission from the
copyright holder. ie "...you may not reproduce, redistribute or otherwise
use any materials *without* the express written consent..." etc
Not sure if this was already mentioned but if Adobe is donating this
project, it would make sense for them to grant permission or a perpetual
license to, "use, modify and distribute files necessary to the project" as
they already have been... ...not sure if this was already mentioned.
On Tue, May 1, 2012 at 7:42 PM, Jeffry Houser <je...@dot-com-it.com> wrote:
> On 5/1/2012 8:18 PM, Alex Harui wrote:
>
>>
>>
>> On 5/1/12 4:54 PM, "Jeffry Houser"<je...@dot-com-it.com> wrote:
>>
>> It shouldn't violate copyright;
>>>
>>
Re: [MENTORS] Handling Adobe Binaries
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 5/1/2012 8:18 PM, Alex Harui wrote:
>
>
> On 5/1/12 4:54 PM, "Jeffry Houser"<je...@dot-com-it.com> wrote:
>
>> It shouldn't violate copyright; because we are writing our own code
>> from scratch. Unless Adobe wants to claim copyright on the API which is
>> possible. I know I read about a API related lawsuit at one point, but I
>> have no idea what the results were.
> Again, I'm not a lawyer, but here's my logic: If we were writing actual
> code that did something, then I would agree, starting from scratch shouldn't
> be a violation of copyright. But to try to create an exact replica of an
> API is to me the equivalent of hearing a song, but not having the sheet
> music, re-creating the song exactly. I don't think you can do that in the
> music business.
You certainly can do that in the music business. Independent creation
is a copyright defense (even if it isn't a patent defense).
The "infringed" party has to prove that you had access to their song
and copied it in order to receive any damages. This is extremely
difficult to do.
I remember reading a case where the drummer of an unknown band went on
to play for a well known artist. Even though the drummer testified that
he gave their demo to the 'big artist' that included the song in
question; the original band lost the case based on the "big artists"
testimony that he didn't remember that
The only way to protected a song is to be the one who makes it famous.
It'd be a lot easier to prove that someone heard "HollaBack Girl" by
Gwen Stefani than say, "Read it on the Radio" by 22nd Century.
I think this is covered in this book somewhere:
http://www.amazon.com/Need-About-Music-Business-Edition/dp/0743293185
By the same token, Adobe would [in theory] have to prove we copied
their code as opposed to writing our own. Of course, once again, I am
not advocating this as a route we should consider. Sometimes I like to
make decisions on things that are least likely to get me sued.
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 5/1/12 4:54 PM, "Jeffry Houser" <je...@dot-com-it.com> wrote:
> It shouldn't violate copyright; because we are writing our own code
> from scratch. Unless Adobe wants to claim copyright on the API which is
> possible. I know I read about a API related lawsuit at one point, but I
> have no idea what the results were.
Again, I'm not a lawyer, but here's my logic: If we were writing actual
code that did something, then I would agree, starting from scratch shouldn't
be a violation of copyright. But to try to create an exact replica of an
API is to me the equivalent of hearing a song, but not having the sheet
music, re-creating the song exactly. I don't think you can do that in the
music business.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 5/1/2012 6:02 PM, Alex Harui wrote:
> On 5/1/12 2:51 PM, "Justin Mclean"<ju...@classsoftware.com> wrote:
>
>> Hi,
>>
>> Perhaps we can consider this as a fallback?
>>
>> I was just look at this thread on the Adobe forums [1] where the same issue
>> come up before (for creating a Fedora package for the OS Adobe SDK) and it's
>> suggests that it may be possible to create our own dummy swc using code like
>> so:
> If we have to, I will ask about it, but to me, it violates the reverse
> engineering clause in the license, and potentially, the copyright as well,
> but I am not a lawyer.
I am not a lawyer either, but I've been known to play on the Internet
and such topics catch my interest at times; so this is my ramble on such
things.
I, personally, feel that it wouldn't violate the reverse engineer
clause because all this stuff is already well documented publicly. We
wouldn't be reverse engineering anything; just creating our own thing to
the own API.
It shouldn't violate copyright; because we are writing our own code
from scratch. Unless Adobe wants to claim copyright on the API which is
possible. I know I read about a API related lawsuit at one point, but I
have no idea what the results were.
However, this is all very tricky as we live in a lawsuit happy world;
and it makes sense to follow Adobe's guidance on such issues; as I doubt
we could win against them (from a funding perspective) and any related
wranglings would effectively stunt the project.
The first lawyer I hired offered to "send a letter claiming X, Y, and
Z" even though there was no legal truth to X, Y, or Z. This was under
the assumption that the people said letter was being sent to
wouldn't/couldn't hire a lawyer to tell them "this is all a lie." The
same concept is used a lot these days w/ "Pre settlement Letters".
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 5/1/12 2:51 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
> Perhaps we can consider this as a fallback?
>
> I was just look at this thread on the Adobe forums [1] where the same issue
> come up before (for creating a Fedora package for the OS Adobe SDK) and it's
> suggests that it may be possible to create our own dummy swc using code like
> so:
If we have to, I will ask about it, but to me, it violates the reverse
engineering clause in the license, and potentially, the copyright as well,
but I am not a lawyer.
Right now, the goal is to get approval based on the fact that it is
analogous to JDK/JRE
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Perhaps we can consider this as a fallback?
I was just look at this thread on the Adobe forums [1] where the same issue come up before (for creating a Fedora package for the OS Adobe SDK) and it's suggests that it may be possible to create our own dummy swc using code like so:
package flash.accessibility
{
import flash.display.DisplayObject;
public class Accessibility
{
public static native function get active():Boolean;
public static native function sendEvent(source:DisplayObject, childID:uint, eventType:uint, nonHTML:Boolean = false):void;
public static native function updateProperties():void;
};
}
And that this code could be generated programatically from the player global catalog.xml file.
Thanks,
Justin
[1] http://forums.adobe.com/thread/423432
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 5/1/12 1:41 PM, "Nicholas Kwiatkowski" <ni...@spoon.as> wrote:
> The files are not needed to be included separately in the final output, but
> they are compiled in to the final output. I'm not sure if this distinction
> makes life easier or harder for us.
>
I will double check, but I am pretty sure no code from playerglobal.swc or
airglobal.swc gets compiled into the final output.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
The files are not needed to be included separately in the final output, but
they are compiled in to the final output. I'm not sure if this distinction
makes life easier or harder for us.
-Nick
On Tue, May 1, 2012 at 6:54 AM, Bertrand Delacretaz
<bd...@apache.org>wrote:
> Hi Alex,
>
> On Fri, Apr 27, 2012 at 5:11 PM, Alex Harui <ah...@adobe.com> wrote:
> > ...I'm still confused about how to "resolve" FLEX-53. In my
> > understanding, given the current license, we aren't really looking to
> > "include in a distribution" so I'm not clear we have to meet the
> definition
> > of "build tools"...
>
> IIUC the binary files mentioned in FLEX-53 are more like "build time
> dependencies".
>
> Am I correct that they are not needed to distribute or run
> applications built with Apache Flex? That's an important point.
>
> > ... Or is a JDK "included in a distribution" of other
> > products? My main concern is the "library or lesser license" part of the
> > definition...
>
> The JDK is not included in distribution of Apache projects that use
> the Java language.
>
> IIUC we don't need to distribute the FLEX-53 binary files, but just
> point people to them? That would be analogous to a JDK then.
>
> >
> > I think I want to show that this is equivalent of the JDK and is a
> > prerequisite to be downloaded and installed by someone...
>
> It looks like this is the case - my goal with FLEX-53 is to clarify
> exactly how those binary files are used by Apache Flex users, so that
> we have a documented explanation of how/when people are bound by the
> licenses of those files.
>
> As discussed in this thread, not needing those files would be best,
> but I assume it's much more work technically.
>
> -Bertrand
>
Re: [MENTORS] Handling Adobe Binaries
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Alex,
On Fri, Apr 27, 2012 at 5:11 PM, Alex Harui <ah...@adobe.com> wrote:
> ...I'm still confused about how to "resolve" FLEX-53. In my
> understanding, given the current license, we aren't really looking to
> "include in a distribution" so I'm not clear we have to meet the definition
> of "build tools"...
IIUC the binary files mentioned in FLEX-53 are more like "build time
dependencies".
Am I correct that they are not needed to distribute or run
applications built with Apache Flex? That's an important point.
> ... Or is a JDK "included in a distribution" of other
> products? My main concern is the "library or lesser license" part of the
> definition...
The JDK is not included in distribution of Apache projects that use
the Java language.
IIUC we don't need to distribute the FLEX-53 binary files, but just
point people to them? That would be analogous to a JDK then.
>
> I think I want to show that this is equivalent of the JDK and is a
> prerequisite to be downloaded and installed by someone...
It looks like this is the case - my goal with FLEX-53 is to clarify
exactly how those binary files are used by Apache Flex users, so that
we have a documented explanation of how/when people are bound by the
licenses of those files.
As discussed in this thread, not needing those files would be best,
but I assume it's much more work technically.
-Bertrand
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 4/27/12 6:09 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>
> If there are more such issues, best is probably to create jira issues
> like FLEX-53 and make them blockers for FLEX-4, so that we can keep
> track of things.
Hi Bertrand, I'm still confused about how to "resolve" FLEX-53. In my
understanding, given the current license, we aren't really looking to
"include in a distribution" so I'm not clear we have to meet the definition
of "build tools". Or is a JDK "included in a distribution" of other
products? My main concern is the "library or lesser license" part of the
definition.
I think I want to show that this is equivalent of the JDK and is a
prerequisite to be downloaded and installed by someone.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Fri, Apr 27, 2012 at 2:25 PM, Nicholas Kwiatkowski <ni...@spoon.as> wrote:
> ...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 :)...
If there are more such issues, best is probably to create jira issues
like FLEX-53 and make them blockers for FLEX-4, so that we can keep
track of things.
-Bertrand
Re: [MENTORS] Handling Adobe Binaries
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
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 <ol...@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
>
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 4/26/12 10:33 AM, "Rick Winscot" <ri...@gmail.com> wrote:
> Is this not a clear case where playerglobal.swc could be 'stubbed-out' to
> side-step the dependency?
>
I'm not sure what you mean. It is already stubs for VM/runtime APIs.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Rick Winscot <ri...@gmail.com>.
Is this not a clear case where playerglobal.swc could be 'stubbed-out' to side-step the dependency?
On Thursday, April 26, 2012 at 1:04 PM, Alex Harui wrote:
>
>
>
> On 4/26/12 6:09 AM, "olegsivokon@gmail.com (mailto:olegsivokon@gmail.com)" <olegsivokon@gmail.com (mailto:olegsivokon@gmail.com)> wrote:
>
> > On the other hand, playerglobal.swc library isn't a separate product
> > distributed by Adobe.
> >
>
> It can be downloaded from the FlashPlayer page.
> >
> > 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'll ask legal about this, but it might fall under the reverse engineering
> restriction.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 4/26/12 6:09 AM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
> On the other hand, playerglobal.swc library isn't a separate product
> distributed by Adobe.
It can be downloaded from the FlashPlayer page.
>
> 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'll ask legal about this, but it might fall under the reverse engineering
restriction.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Left Right <ol...@gmail.com>.
>
> 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
Re: [MENTORS] Handling Adobe Binaries
Posted by Simon Morvan <ga...@zone84.net>.
Le 26/04/2012 19:02, Alex Harui a écrit :
>
>
> On 4/26/12 4:48 AM, "Simon Morvan"<ga...@zone84.net> wrote:
>
>> Le 26/04/2012 02:36, Alex Harui a écrit :
>> BTW, playerglobal is redistributed in the 'mavenized' version you can
>> find on Sonatype repository that is crafted by velo (Flemojos author).
>> Redistribution of that stuff had never lead to complaints from Adobe AFAIK.
> Doesn't mean it is "legal", IMO.
>> I think this need clarification from Adobe. From my point of view
>> there's no issue with automatically downloading it when building the
>> package and redistributing such package containing it (aside potential
>> ASF rules violation).
> I am trying to get clarification, but I don't see how you can make that
> conclusion. There is explicit language in the license about redistribution.
>
Oh. I don't make any conclusion. It's outside my skills to address the
issue from the 'legal' point of view. But as stated in this thread, from
a 'technical' point of view, those files are basically the ".h files" of
the VM API. They do not really expose its internals.
For Adobe, refusing to relax licensing rights would be a serious
showstopper of the incubation process IMHO.
--
Simon
Re: [MENTORS] Handling Adobe Binaries
Posted by Alex Harui <ah...@adobe.com>.
On 4/26/12 4:48 AM, "Simon Morvan" <ga...@zone84.net> wrote:
> Le 26/04/2012 02:36, Alex Harui a écrit :
>
> BTW, playerglobal is redistributed in the 'mavenized' version you can
> find on Sonatype repository that is crafted by velo (Flemojos author).
> Redistribution of that stuff had never lead to complaints from Adobe AFAIK.
Doesn't mean it is "legal", IMO.
>
> I think this need clarification from Adobe. From my point of view
> there's no issue with automatically downloading it when building the
> package and redistributing such package containing it (aside potential
> ASF rules violation).
I am trying to get clarification, but I don't see how you can make that
conclusion. There is explicit language in the license about redistribution.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [MENTORS] Handling Adobe Binaries
Posted by Simon Morvan <ga...@zone84.net>.
Le 26/04/2012 02:36, Alex Harui a écrit :
> We discovered yesterday that playerglobal.swc is not under MPL and is still under Adobe license. Same for the AIR SDK.
This is kinda weird.
playerglobal.swc is (and has always be) part of the 'opensource' version
of the SDK
(http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4.6).
The description of the package on opensource.adobe.com states :
*Open Source Flex SDK* – For users who want a package that contains
only open source code, we offer the Open Source Flex SDK, which is
available from this site. This package is entirely under the MPL,
including its binaries. It contains the majority of the Flex SDK
(compilers, framework, debugger) but does not include anything that
is not open source like the Adobe Flash Player, Adobe AIR, or the
advanced font encoding libraries. This SDK is capable of creating
Flex applications and can be used in whatever fashion the MPL
allows. If you have questions regarding the use of code licensed
under the MPL, you should consult with an attorney.
(http://opensource.adobe.com/wiki/display/flexsdk/Downloads)
Which clearly states that content of the .zip is /entirely/ opensource
*but* the readme.htm inside the .zip states :
All files contained in this Adobe Flex SDK directory are subject to
and governed by the Adobe Flex SDK License Agreement specified here:
Adobe Flex SDK License Agreement
<file:///C:/Users/simon/AppData/Local/Temp/Temp1_flex_sdk_4.6.0.23201_mpl.zip/license-adobesdk.htm>,
EXCEPT those files specifically identified below as "Mozilla Public
License Files".
(...)
The files located in the following directory locations of the Adobe
Flex SDK are governed by the "Mozilla Public License Version 1.1"
found below.
ant
asdoc
frameworks/javascript
frameworks/locale
frameworks/projects
frameworks/themes
playerglobal.swc resides under frameworks/libs/player
BTW, playerglobal is redistributed in the 'mavenized' version you can
find on Sonatype repository that is crafted by velo (Flemojos author).
Redistribution of that stuff had never lead to complaints from Adobe AFAIK.
I think this need clarification from Adobe. From my point of view
there's no issue with automatically downloading it when building the
package and redistributing such package containing it (aside potential
ASF rules violation).
--
Simon