Alex, My answers below:
2012/11/14 Alex Harui <aha...@adobe.com> > OK, I skimmed through the files. Code-wise, it looks very nice, so thank > you for being willing to donate this work. > > One thing that was bugging me as I was looking at the code is this: Did you > look at the Java code for the Java equivalents when writing your code, are > any portions of your code "substantial copies" of the Java sources, and if > so, does Java's source license allow you to leverage their code, and if so, > without attribution? I would think there are BigDecimal equivalents in > other platforms as well so this must all be "ok", but I think we need to be > sure. > Good point. All classes from the org.granite.math package were written from scratch, but part of the BigDecimal code is inspired (not copied though) from the Java implementation. What do you suggest in order to make sure that there is no legal issue? > Some other questions: > 1) Terminology/Names: I saw a reference to "Bean" in one of the files. > That > is also a Java concept, but is that term trademarked? I think "JavaBean" > is, but I think it would be hard to trademark just "Bean". > I don't think Bean is a trademark and we can change that term if necessary. > 2) Packaging: All the packages are currently org.granite.*. Do you have a > large body of users who will complain loudly if you change the package > name? > I don't think so: changing package names is just a research / replace operation... > 3) I noticed FormValidator had a reference to mx.core.Container. That ties > you to the "mx" project in SVN. Does it work with Spark Form? > Yes, it works with Flex 4 and Spark Form. The explicit use and import of mx.core.Container could be changed to something based on reflection if necessary. > Anyway, based on your answers, we should have a brief discussion on the > destination folder and package names. Then, I would ask you to do the > following: > > A) get the sources for Apache Flex > B) copy your code into the decided-upon folders > C) replace all headers with Apache headers > D) replace package names if necessary > E) (optional) create a build.xml in your folder and edit the main build > script so your code actually builds. > > It is the zip of the sources in this final folder that should be the actual > files donated to Apache. We won't pull it from GitHub. You definitely > have > the rights to change from GPL to ALv2. There is plenty of precedence for > this. > Ok. > You may notice that the standard Apache header says that your copyrights > are > in a NOTICE file. This is an odd "gotcha" in the donation process. You > can > create your own file called NOTICE and move your copyrights there, but > really, your copyright has to end up in the central NOTICE file. You can > opt to leave your copyright notice in the files for now and move them once > in Apache SVN if you want. I think it is pretty much up to you. > Ok. > Thanks again, > -Alex You're welcome, Franck. > > On 11/14/12 12:45 PM, "Franck Wolff" <franck.wo...@graniteds.org> wrote: > > > I agree: we are the copyright owners, there is no external contribution > in > > that part of our code and we can freely choose the license (LGPL, Apache, > > commercial, etc.) > > > > You could certainly ask some legal guy at the ASF over this potential > > issue, but I'm pretty sure we have the right to change the license to > > whatever we want. > > > > Franck. > > > > 2012/11/14 Justin Mclean <jus...@classsoftware.com> > > > >> Hi, > >> > >> Only issue I see is the current license which I believe is not > compatible > >> with Apache. Given you own the software and can licence it how you see > fit > >> I don't see this being an issue. > >> > >> Thanks, > >> Justin > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > > -- Franck Wolff Granite Data Services Inc. CEO & Founder
